Her sağlayıcı size bir anahtar verir. Üçüncüsünden sonra, anahtarlar artık bir kolaylık olmaktan çıkıp inşa etmeniz ve bakımını yapmanız gereken bir sisteme dönüşür. N sayıda sağlayıcınız var; her birinin kendi temel URL'si, kendi kimlik doğrulama başlığı, kendi hız sınırı semantiği, kendi hata kodları, kendi faturalandırma sayfası var. İsteği "sabit kodladığım model" yerine "mevcut en iyi model"e yönlendirmek istediğiniz anda, bir yönlendirme probleminiz olur ve bir ağ geçidinin çözdüğü şey tam olarak budur.
Sorun API değil, operasyonlardır
Ham API çağrıları kolaydır. Asıl birikerek büyüyen, onların etrafındaki her şeydir:
•Kimlik bilgisi dağınıklığı. Sağlayıcı başına bir anahtar, farklı zamanlamalarla döndürülen, farklı sır yöneticilerinde saklanan.
•Hız sınırları. Her sağlayıcı farklı şekilde sınırlar ve hata yanıtları tutarlı değildir, bu nedenle yeniden deneme mantığınızın her biri için özel durum işlemesi gerekir.
•Kullanım görünürlüğü. Her sağlayıcının kendi kontrol paneli vardır. Hepsi arasındaki toplam harcamayı gösteren tek bir yer yoktur.
•Yedekleme. Sağlayıcı A çökerse, trafiği sağlayıcı B'ye taşımak yeni bir anahtar ve yeni bir uç nokta ile yeniden dağıtım yapmak anlamına gelir.
Bunların hiçbiri bir demoda görünmez. Bir sağlayıcı çöktüğünde ve yeniden deneme kuyruğunuz biriktiğinde, gece saat 2'de üretimde ortaya çıkar.
Bir ağ geçidi aslında nedir
Bir ağ geçidi, uygulamanız ile model sağlayıcıları arasında yer alır. Uygulamanız tek bir anahtarla tek bir uç nokta ile konuşur. Ağ geçidi kimlik doğrulama, yönlendirme, hız sınırlama, kullanım muhasebesi ve yedekleme işlemlerini yönetir. Kodunuz için tam olarak tek bir LLM API'si gibi görünür.
+------------------+
| Uygulamanız |
+--------+---------+
| tek anahtar, tek temel URL
v
+--------+---------+
| LLM ağ geçidi |
| kimlik doğr. |
| yönlendirme |
| hız sınırlama |
| kullanım ölçümü |
+--+-----+----+----+
| | |
v v v
Sağlayıcı A B C
(GPT-4o) (DeepSeek) (Qwen)Önemli tasarım kararı, ağ geçidinin gelen tarafında OpenAI uyumlu protokolü konuşmasıdır. Bu, mevcut SDK kodunuzun yeni bir istemci kitaplığına ihtiyaç duymadığı anlamına gelir. Temel URL'yi ve anahtarı değiştirirsiniz ve normal chat.completions.create çağrılarını yazmaya devam edersiniz.
Tek anahtar, tek uç nokta, birçok model
İşte istemci tarafındaki tüm entegrasyon:
from openai import OpenAI
client = OpenAI(
base_url="https://api.token8341.com/v1",
api_key="sk-one-key-for-everything",
)
for model in ["gpt-4o", "claude-3-5-sonnet", "deepseek-chat", "qwen-max"]:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Reply with the word 'ok'"}],
)
print(model, "->", resp.choices[0].message.content)Aynı anahtar katalogdaki her modeli yetkilendirir. Dört hesap oluşturmanıza veya dört bakiye takip etmenize gerek yoktur. Tek bir ölçümlü fatura ödersiniz ve kullanım modele göre ayrıştırılır, böylece token'ların gerçekte nereye gittiğini görebilirsiniz.
Ağ geçidi ayrıca yönlendirmeyi bir kod değişikliği yerine yapılandırma kararı haline getirir. Yüksek hacimli hat için ucuz bir model ve zorlu hat için en gelişmiş bir model mi istiyorsunuz? Bu, tek bir yerdeki eşlemedir:
ROUTES = {
"summarize": "deepseek-chat",
"reason": "qwen-max",
"frontier": "gpt-4o",
}Ve yedekleme, çok sağlayıcılı bir entegrasyon yerine sıradan kontrol akışı haline gelir:
def call_with_fallback(prompt, primary, backup):
try:
return ask(primary, prompt)
except Exception:
return ask(backup, prompt)Bir ağ geçidine ne zaman ihtiyacınız var, ne zaman yok
İhtiyacınız yoksa, bir ağ geçidi üstlenmemeniz gereken bir ek yüktür. Tek bir sağlayıcı ve tek bir model kullanıyorsanız ve yedekleme gereksiniminiz yoksa, doğrudan anahtar daha basittir ve doğru seçim budur. Kritik yola fazladan bir atlama ve fazladan bir sağlayıcı eklemenin bir maliyeti vardır.
Ağ geçidi, aşağıdakilerden en az biri doğru olduğunda yerini hak eder:
•İki veya daha fazla model kullanıyorsanız ve aralarında serbestçe geçiş yapmak istiyorsanız.
•Bir sağlayıcı çöktüğünde veya hız sınırına takıldığında yedeklemeye ihtiyacınız varsa.
•Tek bir fatura ve modele göre harcamayı görebileceğiniz tek bir yer istiyorsanız.
•Yeniden dağıtım yapmadan canlı trafikte modelleri A/B test etmek istiyorsanız.
Bunlardan herhangi biri geçerliyse, operasyonel tasarruflar fazladan atlamanın maliyetini fazlasıyla karşılar. İyi işletilen bir ağ geçidinin gerçek ek gecikmesi birkaç milisaniyedir; model çıkarım süresinin yanında kaybolacak kadar küçüktür.
Yönetilen mi, kendi barındırılan mı?
Kasıtlı olarak verilmesi gereken bir karar, kendi ağ geçidinizi mi çalıştıracağınız yoksa birini mi kiralayacağınızdır. LiteLLM ve one-api gibi kendi barındırılan yönlendiriciler mükemmeldir ve yönlendirme tabloları, anahtarlar ve günlükleme üzerinde tam kontrol sağlar. Ayrıca çalıştırmanız, izlemeniz, yamamanzı ve yüksek kullanılabilirlikte tutmanız gereken bir hizmet verirler ki bu tam olarak kurtulmaya çalıştığınız operasyonel yüktür.
Yönetilen bir ağ geçidi bu dengeyi tersine çevirir. İç işleyiş üzerindeki kontrolü bırakırsınız ve onları işletmek zorunda olmama kazanımını elde edersiniz: başka biri uç noktayı ayakta tutar, üst kaynak anahtarlarını döndürür ve sağlayıcı kesintilerini absorbe eder. Küçük bir ekip için bu genellikle doğru anlaşmadır. Kadrosunda bir platform grubu bulunan daha büyük bir ekip için, sırf denetlenebilirlik adına kendi barındırma buna değebilir. Her iki durumda da, gelen sözleşmeyi OpenAI uyumlu tutun ki seçim tersine çevrilebilir kalsın.
SiCore TokenWorks bu fikir etrafında inşa edilmiştir: tek bir API anahtarı, https://api.token8341.com/v1 adresinde tek bir OpenAI uyumlu uç nokta ve GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark ve Pangu'yu kapsayan bir katalog; ölçümlü faturalandırma ve modele göre ayrıştırılmış kullanım ile.