Jinsi ya kusanidi LiteLLM kama gateway ya LLM

Kazi ya gateway ya LLM unayojiendeshea mwenyewe

LiteLLM ni gateway ya LLM ya chanzo huria unayojiendeshea mwenyewe: ni HTTP endpoint moja ambayo programu zako zote huipigia simu, nayo husambaza kila ombi kwa mtoa huduma anayepaswa kulijibu. LLM inamaanisha large language model. Gateway hii hutumia OpenAI chat completions API (application programming interface), kwa hivyo maktaba yoyote ya mteja inayowasiliana na OpenAI hufanya kazi nayo baada ya mabadiliko mawili: base URL na ufunguo (key).

Safu hiyo moja ya upatanishi ndiyo msingi wa kazi hii. Programu zako huacha kuhifadhi vitambulisho vya watoa huduma. Kubadilisha model huwa ni mstari mmoja tu kwenye faili ya usanidi (config file) kwenye seva badala ya kubadilisha msimbo katika huduma tano tofauti. Na kwa sababu kila ombi hupitia mchakato mmoja, unakuwa na sehemu ya kuwekea bajeti na sehemu ya kuhifadhi rekodi ya matumizi.

Hivi ndivyo unavyopata mara tu inapokuwa inafanya kazi:

• Endpoint moja. Programu hulenga https://gateway.example.com/v1 na kuomba jina la model ulilobuni, kama vile bulk au strong.
• Virtual keys. Kila programu hupata ufunguo wake ikiwa na orodha yake ya model zinazoruhusiwa na kikomo chake cha matumizi. Unaweza kufuta ufunguo mmoja bila kugusa mingine.
• Fallbacks. Ombi lililofeli au prompt kubwa kupita kiasi hujaribiwa upya kwa kutumia model tofauti moja kwa moja.
• Rekodi iliyohifadhiwa. Kila ombi huandika mstari wenye gharama yake, kwa hivyo swali la "ni programu ipi ilitumia kiasi hicho" linapata jibu.

Kwa nini uendeshe gateway mwenyewe

Router inayodhibitiwa na mtoa huduma ina umbo sawa na ile unayoiendesha mwenyewe, lakini kuna mchakato wa mtu mwingine katikati ya kila ombi. Kujiendeshea mwenyewe kunahakikisha kuwa funguo za mtoa huduma na maandishi ya prompt yako yanabaki kwenye seva unayoimiliki. Gharama yake ni ya kweli: sasa wewe ndiye unayeendesha sehemu ambayo kila programu inategemea. Sehemu ya mwisho ya mwongozo huu inahusu gharama hiyo, kwa sababu ndiyo sehemu ambayo maandiko mengi huacha kuizungumzia.

Unachohitaji

• VPS (virtual private server) inayoendesha Ubuntu 24.04, ikiwa na Docker na Compose plugin iliyosakinishwa.
• Jina la domain linaloelekeza kwenye seva hiyo, ikiwa mashine zilizo nje ya seva hiyo zitafikia gateway kupitia TLS (transport layer security).
• Angalau API key moja ya mtoa huduma.

Gateway haiendeshi inference yoyote. Inasambaza maombi na kurudisha majibu kwa mtiririko, kwa hivyo mzigo wa CPU hufuata kiasi cha maombi badala ya ukubwa wa model. Seva yenye 1 vCPU inaweza kuhudumia programu kadhaa za ndani bila matatizo. Kinachoongezeka ni database, kwa sababu gateway huandika safu moja ya matumizi kwa kila ombi.

Andika config.yaml kwanza

Faili la usanidi huamua ni modeli zipi mteja anaweza kuomba. Sehemu nne za ngazi ya juu ni muhimu: model_list, litellm_settings, router_settings na general_settings.

model_list:
  - model_name: bulk
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: strong
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: strong
    litellm_params:
      model: openai/gpt-5.5
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  num_retries: 2
  request_timeout: 120
  allowed_fails: 3
  cooldown_time: 30
  json_logs: true
  set_verbose: false

router_settings:
  fallbacks: [{"bulk": ["strong"]}]
  context_window_fallbacks: [{"bulk": ["strong"]}]

general_settings:
  background_health_checks: true
  health_check_interval: 300

model_name ni jina ambalo wateja wako hutuma. litellm_params.model ni modeli halisi, iliyoandikwa kama provider/model. Taja modeli zako kulingana na kazi badala ya kulingana na muuzaji. Programu inayoomba bulk itaendelea kufanya kazi wakati utakapofanya uamuzi mwezi ujao kwamba bulk inapaswa kuwa modeli tofauti.

api_key: os.environ/ANTHROPIC_API_KEY huiambia LiteLLM kusoma kigezo hicho wakati wa utekelezaji. Ufunguo halisi hauonekani kamwe kwenye faili, jambo ambalo ni muhimu kwa sababu config.yaml ndilo faili unalolihifadhi kwenye mfumo wa udhibiti wa toleo (commit).

Ingizo mbili zinashiriki jina strong, kwa makusudi. Wakati zaidi ya deployment moja inabeba model_name sawa, router huichukulia kama inayoweza kubadilishana na nyingine na hujaribu ile nyingine wakati ya kwanza inaposhindwa. Hivyo ndivyo strong inavyoweza kuhimili wakati mtoa huduma mmoja anapokuwa na saa mbaya.

num_retries: 2 hujaribu tena deployment ileile wakati wa hitilafu inayoweza kurekebishika. Fallback huanza tu baada ya majaribio hayo kuisha. allowed_fails: 3 pamoja na cooldown_time: 30 huondoa deployment kwenye mzunguko kwa sekunde 30 baada ya kushindwa mara 3, ili mtoa huduma anayerudisha 500s aache kujaribiwa kwenye kila ombi.

fallbacks na context_window_fallbacks zina vichochezi tofauti, na ya pili ndiyo inayofaa ambayo watu huiruka.

• fallbacks huanza wakati ombi la msingi linaposhindwa.
• context_window_fallbacks huanza wakati mtoa huduma anapokataa ombi kwa sababu ni refu kuliko dirisha la muktadha la modeli hiyo, kwa hivyo prompt kubwa sana hupelekwa kwenye modeli yenye nafasi badala ya kurudisha hitilafu kwa mwombaji.

Pia kuna content_policy_fallbacks, kwa ajili ya mtoa huduma anayekataa kwa misingi ya sera ya maudhui. Iweke tu ikiwa una mahali pazuri pa kutuma maombi hayo.

Kusakinisha LiteLLM kwenye VPS kwa kutumia Docker Compose

Tengeneza saraka (directory) yenye faili tatu: config.yaml, docker-compose.yml na .env. Mwongozo wa kuanza haraka wa upstream huvuta tag ya latest. Badala yake, funga (pin) tag ya release fulani, ili docker compose up -d mwezi ujao ikupe gateway ile ile uliyopata leo, na ili uweze kurudi kwenye toleo la awali kwa mstari mmoja tu wa amri.

services:
  litellm:
    image: ghcr.io/berriai/litellm:v1.95.0
    restart: unless-stopped
    command: ["--config", "/app/config.yaml", "--num_workers", "1"]
    ports:
      - "127.0.0.1:4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml:ro
    env_file: .env
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
      POSTGRES_DB: litellm
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Compose inasoma .env mara mbili hapa. Mara ya kwanza ili kubadilisha ${POSTGRES_PASSWORD} ndani ya faili ya compose yenyewe, na mara ya pili kupitia env_file ili kupitisha kila variable ndani ya container.

v1.95.0 ndilo lilikuwa toleo la sasa mnamo Agosti 2026. Angalia ukurasa wa releases wa mradi huo na ufunge toleo lolote lililo la sasa wakati wa kusakinisha. Kila release huchapisha sahihi (signature), hivyo unaweza kukagua image kabla ya kuiamini:

cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/v1.95.0/cosign.pub ghcr.io/berriai/litellm:v1.95.0

Mstari wa port ni 127.0.0.1:4000:4000, ambao huchapisha port kwenye loopback interface pekee. Andika 4000:4000 badala yake na gateway yako itafikika kutoka kwenye mtandao mzima wa Internet, kwa sababu Docker huongeza sheria zake kwenye iptables FORWARD chain na hizo hutathminiwa kabla ya zile za ufw, kwa hivyo ufw deny 4000 haitaizuia. Hii ndiyo njia ya kawaida zaidi ambapo gateway inayojiendesha (self-hosted) huishia kuwa wazi: tazama jinsi Docker inavyochapisha port ya container kupita ufw. Trafiki kutoka nje hufika kupitia reverse proxy badala yake.

Weka funguo za mtoa huduma nje ya image

Faili la .env huhifadhi kila siri. Hupitishwa kama environment wakati wa kuendesha programu, kwa hivyo haijajumuishwa ndani ya image, na haijawahi kuingizwa kwenye version control.

LITELLM_MASTER_KEY=sk-REPLACE_ME
LITELLM_SALT_KEY=sk-REPLACE_ME_TOO
POSTGRES_PASSWORD=REPLACE_ME_AS_WELL
DATABASE_URL=postgresql://litellm:REPLACE_ME_AS_WELL@db:5432/litellm
STORE_MODEL_IN_DB=True
LITELLM_MODE=PRODUCTION
LITELLM_LOG=ERROR
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-proj-...

Tengeneza funguo mbili za LiteLLM kwa kutumia randomness halisi, kisha linda faili hilo:

printf 'sk-%s\n' "$(openssl rand -hex 32)"
chmod 600 .env

LITELLM_MASTER_KEY ni kitambulisho cha msimamizi. Huidhinisha API ya usimamizi na ndilo neno la siri kwa Admin UI katika /ui. Hakuna programu inayopaswa kulihifadhi.

LITELLM_SALT_KEY husimba kwa njia fiche vitambulisho vya mtoa huduma vilivyohifadhiwa kwenye database. Kiweke mara moja na usikibadilishe. Ukikibadilisha baadaye, vitambulisho vilivyohifadhiwa haviwezi kusomwa, kwa hivyo gateway itaanza kama kawaida lakini kila ombi kwa watoa huduma hao litafeli kwenye uthibitishaji.

STORE_MODEL_IN_DB=True hukuruhusu kuongeza na kuhariri models kutoka Admin UI bila kugusa config.yaml. Hiyo ni rahisi, lakini inagawanya chanzo chako cha ukweli katika sehemu mbili. Amua ni kipi kitakuwa na mamlaka ya mwisho na uandike uamuzi huo karibu na faili la config.

Sababu ya kuweka funguo nje ya faili la config ni ileile inayozizuia zisiingie kwenye zana unazompa wakala (agent). Kuweka siri za mtoa huduma nje ya mawakala wa AI kunaelezea muundo huo, na faili za env na siri katika Docker Compose kunaelezea mbinu za kiufundi.

Iwashe huduma na ufuatilie boot ya kwanza:

docker compose up -d
docker compose logs -f litellm

Thibitisha kuwa inafanya kazi kikamilifu

Kuna majaribio mawili yasiyohitaji uthibitisho na moja linalohitaji uthibitisho, na yote yanashindwa kwa sababu tofauti.

curl -s http://127.0.0.1:4000/health/liveliness
curl -s http://127.0.0.1:4000/health/readiness

/health/liveliness haihitaji uthibitisho na inajibu "I'm alive!" wakati mchakato unaendelea. /health/readiness pia haihitaji uthibitisho. Inarejesha kitu cha JSON chenye "status": "healthy" na sehemu ya db, au inarejesha 503 wakati database haipatikani. Elekeza ufuatiliaji wako kwenye readiness, kwa sababu liveliness inabaki kuwa kijani kwenye gateway ambayo haiwezi kutafuta ufunguo mmoja wa virtual.

Jaribio linalohitaji uthibitisho ndilo linalowasiliana na watoa huduma:

curl -s http://127.0.0.1:4000/health \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

Inajibu kwa safu za healthy_endpoints na unhealthy_endpoints. Model iliyopo kwenye unhealthy_endpoints yenye hitilafu ya uthibitisho inamaanisha kuwa ufunguo wa mtoa huduma katika .env si sahihi au haupo, ambayo ndiyo hitilafu unayotaka kuipata sasa. Kwa sababu background_health_checks: true imewekwa, proxy huendesha majaribio haya kila baada ya health_check_interval sekunde yenyewe na /health inarejesha matokeo ya mwisho, kwa hivyo kuipigia kura (polling) hakutumi ombi la majaribio kwa watoa huduma wako kila wakati.

Funguo pepe na bajeti kwa kila ufunguo

Kila programu hupata ufunguo wake, unaotengenezwa kulingana na ufunguo mkuu.

curl -s http://127.0.0.1:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "key_alias": "nightly-summariser",
    "models": ["bulk"],
    "max_budget": 5,
    "budget_duration": "30d",
    "rpm_limit": 60,
    "tpm_limit": 200000
  }'

Jibu hubeba sehemu ya key inayoanza na sk-. Mfuatano huo ndio programu hupokea, na ndicho kitu pekee ambacho programu hupata.

• models ni orodha ya kuruhusu (allowlist) ya kile ambacho ufunguo huu unaweza kuomba. Ufunguo ulio hapo juu unaweza kuomba bulk na si kitu kingine.
• max_budget: 5 pamoja na budget_duration: "30d" ni dola tano za Marekani kwa kila siku 30 zinazozunguka, baada ya hapo ufunguo huacha kufanya kazi.
• rpm_limit na tpm_limit huweka kikomo cha maombi kwa dakika na tokeni kwa dakika kwa ufunguo huu pekee.
• key_alias ndicho utakachotambua katika logi ya matumizi wiki sita baadaye. Kiweke kila wakati.

Bajeti inapoisha, mwito hushindwa na kutoa HTTP 401 na mwili wa ujumbe wa umbo hili:

ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07

Msimbo wa hali (status code) ndio unaofanya jambo hili kuwa gumu kueleweka. Maktaba ya mteja (client library) huripoti 401 kama tatizo la uthibitishaji, kwa hivyo msanidi programu anayesoma stack trace huanza kuangalia kama ufunguo ni halali. Ingiza mwili wa jibu kwenye logi karibu na msimbo wa hali, vinginevyo kuishiwa kwa bajeti kutaonekana kama kitambulisho kilichoharibika kila wakati.

Kagua na urekebishe funguo kupitia API ile ile ya usimamizi:

curl -s "http://127.0.0.1:4000/key/info?key=sk-..." \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

curl -s -X POST http://127.0.0.1:4000/key/update \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"key": "sk-...", "max_budget": 25}'

Bajeti inayotekelezwa kwenye gateway hudumu hata wakati kitu kilichoharibika ni wakala (agent) yenyewe, ndiyo maana ndiyo uti wa mgongo wa udhibiti wa gharama kwa mawakala wa AI kwenye VPS.

Tuma kazi nyingi kwa modeli ya bei nafuu

Elekeza mteja kwenye gateway. Base URL, ufunguo, na jina la modeli:

curl -s http://127.0.0.1:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-<the virtual key>" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "bulk",
    "messages": [{"role": "user", "content": "Say hello in five words."}]
  }'

Maktaba yoyote ya mteja wa OpenAI hufanya kazi kwa njia ile ile: weka base_url kuwa https://gateway.example.com/v1 na api_key kuwa ufunguo wa mtandaoni.

Sera ya uelekezaji kutoka config.yaml sasa inatumika bila mpigaji simu kujua. Ombi la bulk huenda kwenye modeli ya bei nafuu. Ikiwa ombi hilo litafeli baada ya majaribio yake ya kurudia, ombi hilo hujaribiwa tena dhidi ya strong. Ikiwa prompt ni ndefu sana kwa bulk, context_window_fallbacks huituma kwa strong badala ya kurejesha kosa. Kazi nyingi kama vile hatua ya uainishaji au muhtasari wa backlog huendeshwa kwa bei nafuu kwa chaguo-msingi, na maombi magumu pekee ndiyo yanayogharimu zaidi.

Hapa ndipo gateway inapopata thamani yake kwa mawakala wanaotumia zana. Seva ya MCP (model context protocol) kwenye VPS hiyo hiyo na wakala anayeiendesha wanaweza wote kuelekeza kwenye endpoint moja, kwa hivyo modeli iliyo nyuma yao hubadilika bila kuhitaji kupeleka upya yoyote kati yao.

Unajuaje kama fallback imetokea?

Hii ni hali ya hitilafu inayogharimu pesa, kwa sababu hakuna kinachoonekana kuharibika. Fallback iliyofanikiwa hurejesha HTTP 200 ikiwa na mwili wa kawaida wa majibu. Model yako ya bei nafuu inaweza kuwa chini kwa siku nzima, huku kila ombi likihudumiwa kimyakimya na ile ya gharama kubwa, na ushahidi wa kwanza ni ankara ya malipo.

Ushahidi upo, ndani ya response headers. Ziombe:

curl -s -D - -o /dev/null http://127.0.0.1:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-<the virtual key>" \
  -H 'Content-Type: application/json' \
  -d '{"model":"bulk","messages":[{"role":"user","content":"ping"}]}' \
  | grep -i '^x-litellm'

• x-litellm-model-group ni kile mteja alichokiomba. x-litellm-model-id ni deployment iliyojibu. Pale hizo mbili zinapokinzana, fallback imetokea.
• x-litellm-attempted-fallbacks na x-litellm-attempted-retries huhesabu matukio hayo. Katika ombi zima, zote mbili ni 0.
• x-litellm-response-cost ni gharama ya ombi hilo moja kwa dola za Marekani.
• x-litellm-call-id ni kitambulisho unachotumia kupata ombi lilelile kwenye log zako.

Rekodi x-litellm-attempted-fallbacks kwenye kila ombi na uweke tahadhari pale inapokoma kuwa 0. Namba hiyo moja ndiyo tofauti kati ya sera ya routing inayofanya kazi na sera ya routing ambayo imekuwa kimyakimya "tumia model ya gharama kubwa kila wakati".

Toleo kamili la hili ni tracing, na linastahili usanidi wake wenyewe: Langfuse inayojiendesha yenyewe kwa ajili ya kufuatilia wito wa agent. LiteLLM inakuja na callback, kwa hivyo kuiunganisha ni mistari miwili pamoja na vitambulisho.

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://langfuse.example.com

Weka failure_callback pamoja na success_callback. Ukiruka hatua hii, traces pekee utakazohifadhi ni zile ambazo hakuna kilichoharibika. Kando na haya yote, LiteLLM huandika mstari wa matumizi kwa kila ombi ndani ya Postgres na Admin UI iliyopo /ui husoma jedwali hilo. Hukua kulingana na trafiki, kwa hivyo iangalie kwenye diski ndogo.

Weka gateway nyuma ya reverse proxy

Hakuna kitu chochote nje ya seva kinachopaswa kufikia port 4000. Malizia TLS ndani ya nginx au Caddy na uelekeze trafiki kwenye anwani ya loopback.

location / {
    proxy_pass http://127.0.0.1:4000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 600s;
}

Mistari miwili kati ya hiyo ndiyo watu husahau kuiweka. proxy_buffering off ni muhimu kwa sababu streaming completion ni mfululizo wa server-sent events, na ukiwa na buffering, nginx hushikilia vipande hivyo hadi majibu yote yatakapokamilika; matokeo yake, mteja hukaa kimya kisha hupokea kila kitu kwa wakati mmoja. proxy_read_timeout 600s ni muhimu kwa sababu uzalishaji mrefu wa data hupita muda wa kawaida wa sekunde 60 wa nginx, na ikitokea hivyo, mteja hupata 504 wakati log ya makosa ikirekodi upstream timed out (110: Connection timed out) while reading response header from upstream.

Kwa ajili ya cheti, Certbot na Let's Encrypt kwenye nginx ndiyo njia ya haraka. Ikiwa seva tayari inahudumia containers kadhaa, Traefik mbele ya programu nyingi za Compose hushughulikia routing na vyeti katika sehemu moja.

Gateway sasa ni sehemu moja inayoweza kusababisha mfumo mzima kufeli

Kuwa mkweli kuhusu kile ulichokijenga. Kila programu unayomiliki sasa inategemea container moja kwenye VPS moja. Wakati ikiwa imezimika, hakuna kitu kinachoweza kuita modeli yoyote, hata kwa watoa huduma ambao wako katika hali nzuri kabisa. Mambo manne yanatokana na hili.

• Configuration mbaya huangusha kila kitu kwa wakati mmoja. restart: unless-stopped huanzisha upya mfumo baada ya kufeli, na huanzisha upya container ambayo haiwezi kusoma config.yaml, tena na tena. Soma docker compose logs litellm baada ya kila mabadiliko ya configuration, na fanya mabadiliko ya configuration wakati una muda wa kuifuatilia.
• Postgres iko kwenye njia ya maombi (request path). Utafutaji wa funguo pepe (virtual key) na kurekodi matumizi yote hutumia database hii. /health/readiness kurejesha 503 ni onyo lako kwamba gateway inafanya kazi lakini haiwezi kufanya yoyote kati ya hayo.
• Ongeza uwezo kwa kuongeza instances, si kwa kuifanya moja kuwa kubwa. Mwongozo wa mradi wenyewe ni worker mmoja kwa kila instance (--num_workers 1) huku instances kadhaa zikishiriki database moja. Gateway mbili ndogo nyuma ya load balancer huondoa container moja kama sehemu pekee ya kufeli. Haziwezi kuondoa database.
• Hifadhi (backup) kile ambacho huwezi kukitengeneza upya. Hiyo ni config.yaml na .env, pamoja na pg_dump ya database. Kupoteza LITELLM_SALT_KEY hufanya vitambulisho vya mtoa huduma vilivyosimbwa ndani ya dump hiyo kuwa visivyofaa, kwa hivyo faili la env na dump vinapaswa kuwa kwenye kazi moja ya backup: restic backups kwenye hifadhi ya nje ya seva.

Kupandisha toleo (upgrading) ni kuhariri image tag na kuendesha docker compose up -d. LiteLLM huendesha prisma migrate deploy wakati wa kuanza (startup) kwa chaguo-msingi, kwa hivyo container mpya hufanya migration ya schema ya database kwenye boot yake ya kwanza. Chukua dump kabla ya kubadilisha tag, kwa sababu kurudisha image ya zamani hakutengui migration ambayo tayari imeshafanyika.

FAQ

Je, LiteLLM huongeza latency inayoonekana kwenye kila ombi?

Mradi huu unachapisha takwimu ya 8 ms katika percentile ya 95 kwa maombi 1000 kwa sekunde, kama ilivyoelezwa kwenye README yake mnamo Agosti 2026. Ichukulie hiyo kama takwimu ya muuzaji. Namba inayobadilisha latency yako kihalisi ni umbali wa mtandao kati ya programu zako na gateway, kwa sababu umeongeza safari moja ya ziada (round trip) kwenye kila ombi. Endesha gateway katika region moja na programu zinazoiita, kisha pima overhead yako mwenyewe kwa kutumia header ya x-litellm-overhead-duration-ms kwenye response halisi.

Kwa nini streaming iliacha kufanya kazi baada ya kuweka nginx mbele?

Kwa sababu nginx hufanya buffering ya majibu ya upstream kwa chaguomsingi na streaming completion ni mfululizo wa server-sent events. Ikiwa proxy_buffering imewashwa, nginx hukusanya vipande hivyo na kuvitoa tu wakati response inapokamilika, hivyo mteja husubiri kimya na kisha kupokea jibu lote kwa wakati mmoja. Weka proxy_buffering off; kwenye location block. Ongeza proxy_read_timeout kwenye block hiyo hiyo, kwa sababu generation ndefu inaweza kuzidi muda wa chaguomsingi wa sekunde 60 wa nginx na mteja atapata 504.

Nini hutokea wakati virtual key inapoishiwa na bajeti?

Ombi linashindwa kwa HTTP 401 na body ya mfumo wa ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07. Hiyo 401 ndiyo mtego: maktaba ya mteja huripoti kama hitilafu ya uthibitishaji (authentication failure), kwa hivyo watu huanza kuangalia kama ufunguo ni sahihi badala ya kusoma ujumbe. Log body ya response pamoja na status code. Thibitisha nafasi halisi ya ufunguo kwa /key/info?key=sk-... dhidi ya master key, na ongeza kikomo kwa /key/update ikiwa bajeti iliwekwa chini sana.

Je, gateway inaweza kuelekeza kwenye local model pamoja na zile zilizopangishwa (hosted)?

Ndiyo, na hiyo ni ingizo moja zaidi katika model_list. Tumia prefix ya ollama_chat/ pamoja na api_base, kwa mfano model: ollama_chat/llama3.1 pamoja na api_base: http://ollama:11434. Kutoka ndani ya container, localhost inamaanisha container hiyo, kwa hivyo tumia jina la Compose service au anwani ya host kwenye Docker network, kamwe usitumie 127.0.0.1. Kuweka local model ni kazi tofauti: angalia kujihostisha LLM kwa kutumia Ollama kwenye VPS.