Proksi untuk AI

Setiap platform AI utama mengehadkan bilangan permintaan yang boleh anda hantar. OpenAI, Anthropic, Google, DeepSeek — semuanya menetapkan had penggunaan bagi setiap akaun, setiap minit, setiap hari. Apabila anda membina produk, menjalankan automasi, atau memproses data pada skala besar, satu akaun dengan satu IP akan mencecah siling dengan pantas. Anda akan menerima ralat 429, permintaan bertimbun dalam baris gilir, dan saluran kerja anda terhenti.

Pelayan proksi AI berada di antara aplikasi anda dan pembekal AI. Anda menghantar permintaan ke proksi, dan ia mengagihkan permintaan tersebut merentasi pelbagai kunci API, setiap satu melalui alamat IP tersendiri. Pembekal hanya nampak pengguna berasingan, bukan satu akaun yang terlebih beban. Kapasiti keseluruhan anda berganda manakala setiap kunci individu kekal selamat dalam had yang ditetapkan. Dalam amalan, proksi yang dikonfigurasi dengan baik hanya menambah 15–30ms latensi bagi setiap permintaan — boleh diabaikan untuk pemprosesan kelompok dan hampir tidak ketara walaupun dalam aplikasi sembang masa nyata, di mana masa penjanaan model itu sendiri mendominasi pada 500–3000ms.

Ini berkesan kerana platform AI mengikat had kadar kepada akaun, bukan IP — tetapi mereka memantau corak IP. Jika satu alamat bertukar melalui 10 kunci API berbeza secara berturut-turut dengan pantas, itu ialah tanda amaran. Proksi berdedikasi berasingan bagi setiap kunci memastikan semuanya kelihatan semula jadi. Anda juga memerlukan strategi failover: pantau kadar ralat setiap kunci, dan jika IP tertentu mula mengembalikan ralat 429 atau 403 secara konsisten, putarkannya keluar daripada kumpulan secara automatik dan halakan trafik kunci tersebut melalui IP sandaran. Semakan kesihatan setiap 60 saat bagi setiap pasangan kunci-IP mengesan masalah sebelum ia merebak.

Rupa bentuk tetapan ini dalam amalan

Kebanyakan persediaan proksi API AI mengikuti corak yang sama tanpa mengira pembekal. Anda menjalankan pelayan proksi ringan (FastAPI, Node, Go — apa sahaja stack anda) yang memegang kumpulan kunci API. Apabila permintaan masuk, proksi memilih kunci seterusnya yang tersedia, menghalakan permintaan melalui IP yang ditugaskan kepada kunci tersebut, dan mengembalikan respons. Jika satu kunci mendapat 429 (ralat had kadar), proksi beralih kepada kunci seterusnya. Berikut ialah contoh Python minimal menggunakan FastAPI dan httpx:

import httpx, itertoolsfrom fastapi import FastAPI, Request, Response

@app.post("/v1/chat/completions")async def proxy(request: Request): body = await request.json() slot = next(keys) async with httpx.AsyncClient(proxy=slot["proxy"]) as client: r = await client.post( "https://api.openai.com/v1/chat/completions", json=body, headers={"Authorization": f"Bearer {slot['api_key']}"}, ) # TODO: Add retry logic on 429 — try next key/IP before returning error to caller return Response(content=r.content, status_code=r.status_code)

Nota: contoh minimal ini menggunakan itertools.cycle demi kemudahan, tetapi ia tidak secara automatik mencuba semula apabila berlaku ralat 429. Dalam persekitaran pengeluaran, tambahkan logik cuba semula yang melangkau kunci yang dinyahkelajuan dan mencuba pasangan kunci-IP seterusnya yang tersedia sebelum mengembalikan ralat kepada pemanggil. Memandangkan hampir setiap pembekal AI kini menyokong format API OpenAI, satu proksi boleh mengendalikan terjemahan format yang diperlukan oleh setiap pembekal AI — halakan ke pembekal yang betul, dan aplikasi anda tidak perlu mengetahui perbezaannya. Tukar base URL dan kumpulan kunci mengikut pembekal, dan pelayan 20 baris yang sama boleh mengendalikan OpenAI, Anthropic, Google, dan DeepSeek.