Cara Hos Sendiri LiteLLM Sebagai Gateway LLM

Fungsi gateway LLM yang dihoskan sendiri

LiteLLM ialah gateway LLM sumber terbuka yang anda hoskan sendiri: satu endpoint HTTP yang dipanggil oleh semua aplikasi anda, yang kemudiannya memajukan setiap permintaan kepada penyedia yang sepatutnya menjawab permintaan tersebut. LLM bermaksud large language model. Gateway ini menggunakan API (application programming interface) chat completions OpenAI, jadi mana-mana pustaka klien yang sudah berhubung dengan OpenAI boleh berfungsi dengannya selepas dua perubahan: base URL dan kunci.

Satu lapisan indirection itulah tujuannya. Aplikasi anda tidak lagi menyimpan kelayakan penyedia. Menukar model hanya menjadi satu baris dalam fail konfigurasi pada pelayan dan bukannya perubahan kod dalam lima servis. Oleh sebab setiap panggilan melalui satu proses, anda mempunyai tempat untuk menetapkan bajet dan tempat untuk menyimpan rekod perbelanjaan.

Berikut adalah apa yang anda miliki sebaik sahaja ia berjalan:

• Satu endpoint. Aplikasi menyasarkan https://gateway.example.com/v1 dan meminta nama model yang anda cipta, seperti bulk atau strong.
• Kunci maya. Setiap aplikasi mendapat kuncinya sendiri dengan senarai kebenaran model dan had perbelanjaan tersendiri. Anda boleh membatalkan satu kunci tanpa menjejaskan kunci yang lain.
• Fallback. Panggilan yang gagal atau prompt yang terlalu besar akan dicuba semula secara automatik menggunakan model yang berbeza.
• Rekod log. Setiap permintaan menulis satu baris yang mengandungi kosnya, jadi persoalan "aplikasi mana yang membelanjakannya" mempunyai jawapan.

Mengapa mengendalikan gateway sendiri

Router terurus mempunyai bentuk yang sama dengan proses pihak lain yang berada di tengah-tengah setiap permintaan. Mengendalikannya sendiri memastikan kunci pembekal dan teks prompt anda kekal pada kotak yang anda kawal. Kosnya adalah nyata: anda kini mengendalikan komponen yang bergantung kepada setiap aplikasi. Bahagian terakhir panduan ini adalah mengenai kos tersebut, kerana ia merupakan bahagian yang sering ditinggalkan oleh kebanyakan penulisan.

Keperluan anda

• Sebuah VPS (virtual private server) yang menjalankan Ubuntu 24.04, dengan Docker dan pemalam Compose dipasang.
• Nama domain yang menghala ke pelayan tersebut, jika mesin di luar kotak akan mencapai gateway melalui TLS (transport layer security).
• Sekurang-kurangnya satu kunci API pembekal.

Gateway ini tidak menjalankan inferens. Ia memajukan permintaan dan menstrim jawapan kembali, jadi beban CPU-nya mengikut volum permintaan dan bukannya saiz model. Kotak 1 vCPU mampu menampung beberapa aplikasi dalaman tanpa masalah. Perkara yang akan berkembang ialah pangkalan data, kerana gateway menulis satu baris perbelanjaan bagi setiap permintaan.

Tulis config.yaml terlebih dahulu

Fail konfigurasi menentukan model yang boleh diminta oleh pelanggan. Empat bahagian peringkat atas adalah penting: model_list, litellm_settings, router_settings dan 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 ialah nama yang dihantar oleh pelanggan anda. litellm_params.model ialah model sebenar, ditulis sebagai provider/model. Namakan model anda berdasarkan tugas dan bukannya berdasarkan vendor. Aplikasi yang meminta bulk akan terus berfungsi apabila anda memutuskan pada bulan hadapan bahawa bulk sepatutnya menjadi model yang berbeza.

api_key: os.environ/ANTHROPIC_API_KEY memberitahu LiteLLM untuk membaca pemboleh ubah tersebut semasa runtime. Kunci literal tidak akan muncul dalam fail, yang penting kerana config.yaml ialah fail yang anda commit.

Dua entri berkongsi nama strong, secara sengaja. Apabila lebih daripada satu deployment membawa model_name yang sama, router menganggapnya sebagai boleh tukar ganti dan mencuba yang lain apabila yang pertama gagal. Begitulah cara strong bertahan apabila satu penyedia mengalami gangguan perkhidmatan.

num_retries: 2 mencuba semula deployment yang sama sekiranya berlaku ralat yang boleh dicuba semula. Fallback hanya akan dicetuskan selepas percubaan semula tersebut habis digunakan. allowed_fails: 3 dengan cooldown_time: 30 mengeluarkan deployment daripada putaran selama 30 saat sebaik sahaja ia gagal sebanyak 3 kali, supaya penyedia yang memulangkan ralat 500 berhenti dicuba pada setiap permintaan.

fallbacks dan context_window_fallbacks mempunyai pencetus yang berbeza, dan yang kedua adalah yang berguna yang sering dilangkau oleh orang ramai.

• fallbacks dicetuskan apabila panggilan utama gagal.
• context_window_fallbacks dicetuskan apabila penyedia menolak permintaan kerana ia lebih panjang daripada tetingkap konteks model tersebut, supaya prompt yang terlalu besar dihantar ke model yang mempunyai ruang untuknya dan bukannya memulangkan ralat kepada pemanggil.

Terdapat juga content_policy_fallbacks, untuk penyedia yang menolak atas alasan polisi kandungan. Tetapkannya hanya jika anda mempunyai tempat yang munasabah untuk menghantar panggilan tersebut.

Menggunakan LiteLLM pada VPS dengan Docker Compose

Cipta direktori yang mengandungi tiga fail: config.yaml, docker-compose.yml dan .env. Panduan permulaan pantas (quickstart) huluan menarik tag latest. Tetapkan (pin) tag keluaran sebaliknya, supaya docker compose up -d pada bulan hadapan memberikan anda gateway yang sama seperti hari ini, dan supaya proses rollback hanya memerlukan satu baris arahan.

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 membaca .env sebanyak dua kali di sini. Sekali untuk menggantikan ${POSTGRES_PASSWORD} di dalam fail compose itu sendiri, dan sekali melalui env_file untuk menghantar setiap pemboleh ubah ke dalam kontena.

v1.95.0 merupakan keluaran semasa pada Ogos 2026. Semak halaman keluaran projek dan tetapkan versi yang terkini semasa anda melakukan deployment. Setiap keluaran menerbitkan tandatangan, jadi anda boleh menyemak imej tersebut sebelum mempercayainya:

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

Baris port ialah 127.0.0.1:4000:4000, yang menerbitkan port pada antara muka loopback sahaja. Tulis 4000:4000 sebaliknya dan gateway anda boleh dicapai dari seluruh internet, kerana Docker menambah peraturannya sendiri dalam rantaian iptables FORWARD dan peraturan tersebut dinilai sebelum peraturan ufw, jadi ufw deny 4000 tidak akan menghalangnya. Ini adalah cara paling lazim bagaimana gateway yang dihoskan sendiri terdedah kepada umum: lihat bagaimana Docker menerbitkan port kontena terus melepasi ufw. Trafik dari luar sebaliknya tiba melalui reverse proxy.

Pastikan kunci penyedia tidak dimasukkan ke dalam imej

Fail .env menyimpan setiap rahsia. Ia dihantar sebagai persekitaran semasa masa jalan (run time), jadi ia tidak pernah dibakar ke dalam imej dan tidak pernah dikomitkan.

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-...

Jana dua kunci LiteLLM dengan rawak sebenar, kemudian kunci fail tersebut:

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

LITELLM_MASTER_KEY ialah kelayakan pentadbir. Ia mengesahkan API pengurusan dan merupakan kata laluan untuk UI Pentadbir di /ui. Tiada aplikasi yang sepatutnya menyimpan kelayakan ini.

LITELLM_SALT_KEY menyulitkan kelayakan penyedia yang disimpan dalam pangkalan data. Tetapkan sekali dan biarkan ia begitu. Jika anda menukarnya kemudian, kelayakan yang telah disimpan tidak dapat dinyahsulit, jadi gateway akan bermula seperti biasa tetapi setiap panggilan kepada penyedia tersebut akan gagal semasa pengesahan.

STORE_MODEL_IN_DB=True membolehkan anda menambah dan mengedit model daripada UI Pentadbir tanpa menyentuh config.yaml. Ini memudahkan, tetapi ia memecahkan sumber kebenaran (source of truth) anda kepada dua bahagian. Tentukan yang mana satu adalah autoritatif dan catatkan keputusan tersebut bersebelahan dengan konfigurasi.

Sebab yang memastikan kunci tidak dimasukkan ke dalam fail konfigurasi adalah sama dengan sebab yang memastikan kunci tidak dimasukkan ke dalam alatan yang anda berikan kepada ejen. Memastikan rahsia penyedia tidak diberikan kepada ejen AI merangkumi corak tersebut, dan fail env dan rahsia dalam Docker Compose merangkumi mekanismenya.

Jalankan ia dan perhatikan but pertama:

docker compose up -d
docker compose logs -f litellm

Semak sama ada ia benar-benar berfungsi

Terdapat dua ujian tanpa pengesahan dan satu ujian dengan pengesahan, dan kesemuanya gagal atas sebab yang berbeza.

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

/health/liveliness tidak memerlukan pengesahan dan menjawab "I'm alive!" semasa proses sedang berjalan. /health/readiness juga tidak memerlukan pengesahan. Ia mengembalikan objek JSON dengan "status": "healthy" dan medan db, atau ralat 503 apabila pangkalan data tidak dapat dicapai. Halakan pemantauan anda kepada readiness, kerana liveliness kekal hijau pada gateway yang tidak dapat mencari kunci maya tunggal.

Ujian dengan pengesahan ialah ujian yang berhubung dengan penyedia:

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

Ia menjawab dengan tatasusunan healthy_endpoints dan unhealthy_endpoints. Model yang berada dalam unhealthy_endpoints dengan ralat pengesahan bermakna kunci penyedia dalam .env adalah salah atau tiada, iaitu kegagalan yang ingin anda cari sekarang. Kerana background_health_checks: true ditetapkan, proksi menjalankan ujian ini setiap health_check_interval saat secara automatik dan /health mengembalikan hasil terakhir, jadi melakukan polling tidak menghantar permintaan ujian kepada penyedia anda setiap kali.

Kunci maya dan bajet bagi setiap kunci

Setiap aplikasi mendapat kuncinya sendiri, yang dijana berdasarkan kunci induk.

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
  }'

Respons tersebut membawa medan key yang bermula dengan sk-. Rentetan itulah yang diterima oleh aplikasi, dan ia merupakan satu-satunya perkara yang akan diperoleh oleh aplikasi tersebut.

• models ialah senarai putih bagi perkara yang boleh diminta oleh kunci ini. Kunci di atas hanya boleh meminta bulk dan tiada yang lain.
• max_budget: 5 dengan budget_duration: "30d" ialah lima dolar AS bagi setiap 30 hari bergulir, selepas itu kunci akan berhenti berfungsi.
• rpm_limit dan tpm_limit mengehadkan permintaan seminit dan token seminit untuk kunci ini sahaja.
• key_alias ialah perkara yang akan anda kenali dalam log perbelanjaan enam minggu kemudian. Sentiasa tetapkannya.

Apabila bajet habis, panggilan akan gagal dengan HTTP 401 dan badan respons dalam bentuk ini:

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

Kod status inilah yang menjadikannya mengelirukan. Pustaka klien melaporkan 401 sebagai masalah pengesahan, jadi pembangun yang membaca surih tindanan (stack trace) mula menyemak sama ada kunci tersebut sah. Log badan respons di sebelah kod status, jika tidak, kehabisan bajet akan kelihatan seperti kelayakan yang rosak setiap kali.

Periksa dan laraskan kunci melalui API pengurusan yang sama:

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}'

Bajet yang dikuatkuasakan di pintu masuk (gateway) tetap berkesan walaupun perkara yang tidak kena ialah ejen itu sendiri, itulah sebabnya ia menjadi tulang belakang kepada kawalan kos untuk ejen AI pada VPS.

Menghantar tugasan pukal ke model kos rendah

Halakan klien ke gateway. URL asas, kunci, nama model:

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."}]
  }'

Mana-mana pustaka klien OpenAI berfungsi dengan cara yang sama: tetapkan base_url kepada https://gateway.example.com/v1 dan api_key kepada kunci maya.

Polisi penghalaan daripada config.yaml kini terpakai tanpa pengetahuan pemanggil. Permintaan untuk bulk akan pergi ke model kos rendah. Jika panggilan tersebut gagal selepas percubaan semula, permintaan itu akan dicuba semula terhadap strong. Jika prompt terlalu panjang untuk bulk, context_window_fallbacks akan menghantarnya ke strong dan bukannya mengembalikan ralat. Tugasan pukal seperti proses klasifikasi atau tunggakan ringkasan berjalan secara murah secara lalai, dan hanya permintaan yang sukar akan menelan kos lebih tinggi.

Di sinilah gateway membuktikan kepentingannya dengan ejen yang menggunakan alatan. Sebuah pelayan MCP (model context protocol) pada VPS yang sama dan ejen yang menggerakkannya kedua-duanya boleh menghala ke satu endpoint yang sama, supaya model di sebaliknya boleh ditukar tanpa perlu menggunakan semula (redeploy) mana-mana komponen.

Bagaimanakah anda tahu fallback telah berlaku?

Ini ialah mod kegagalan yang menelan kos, kerana tiada apa-apa yang kelihatan rosak. Fallback yang berjaya akan mengembalikan HTTP 200 dengan badan respons biasa. Model murah anda boleh terhenti selama sehari, setiap panggilan diservis secara senyap oleh model yang mahal, dan bukti pertama yang anda perolehi ialah invois.

Bukti tersebut wujud dalam pengepala respons (response headers). Dapatkan maklumat tersebut:

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 ialah perkara yang diminta oleh klien. x-litellm-model-id ialah deployment yang menjawab permintaan tersebut. Apabila kedua-duanya tidak sepadan, fallback telah berlaku.
• x-litellm-attempted-fallbacks dan x-litellm-attempted-retries mengira jumlahnya. Pada panggilan yang sihat, kedua-duanya adalah 0.
• x-litellm-response-cost ialah kos bagi satu panggilan tersebut dalam dolar AS.
• x-litellm-call-id ialah pengecam yang anda gunakan untuk mencari panggilan yang sama dalam log anda.

Rekodkan x-litellm-attempted-fallbacks pada setiap permintaan dan berikan amaran apabila nilainya bukan lagi 0. Nombor tunggal itu adalah perbezaan antara polisi penghalaan (routing policy) yang berfungsi dengan polisi penghalaan yang secara senyap telah bertukar menjadi "sentiasa gunakan model yang mahal".

Versi penuh bagi perkara ini ialah tracing, dan ia memerlukan persediaan tersendiri: Langfuse yang dihoskan sendiri untuk tracing panggilan ejen. LiteLLM menyediakan callback tersebut, jadi menyambungkannya hanya memerlukan dua baris kod berserta kelayakan (credentials).

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

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

Tetapkan failure_callback serta success_callback. Jika anda melangkau langkah ini, satu-satunya trace yang anda simpan hanyalah trace yang tidak mengalami sebarang masalah. Secara berasingan daripada semua ini, LiteLLM menulis baris perbelanjaan bagi setiap permintaan ke dalam Postgres dan UI Pentadbir pada /ui membaca jadual tersebut. Ia akan berkembang mengikut trafik, jadi pantau saiznya pada cakera yang kecil.

Letakkan gateway di belakang reverse proxy

Tiada apa-apa di luar pelayan yang sepatutnya mencapai port 4000. Lakukan TLS termination dalam nginx atau Caddy dan halakan trafik ke alamat 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;
}

Dua daripada baris tersebut sering ditinggalkan oleh pengguna. proxy_buffering off penting kerana penyiapan penstriman adalah siri server-sent events, dan dengan buffering yang aktif, nginx akan menahan ketulan data sehingga respons tamat, menyebabkan klien menunggu dalam senyap sebelum menerima segala-galanya serentak. proxy_read_timeout 600s penting kerana penjanaan yang lama akan melebihi had lalai 60 saat nginx, dan apabila ini berlaku, klien akan menerima ralat 504 manakala log ralat merekodkan upstream timed out (110: Connection timed out) while reading response header from upstream.

Untuk sijil, Certbot dengan Let's Encrypt pada nginx ialah laluan yang paling pantas. Jika pelayan sudah pun mengendalikan beberapa kontena, Traefik di hadapan berbilang aplikasi Compose menguruskan penghalaan dan sijil di satu lokasi.

Gateway kini menjadi titik kegagalan tunggal

Jujurlah dengan apa yang telah anda bina. Setiap aplikasi yang anda miliki kini bergantung pada satu kontena di satu VPS. Apabila ia tidak berfungsi, tiada apa yang boleh memanggil mana-mana model, termasuk penyedia yang berada dalam keadaan sihat sepenuhnya. Empat perkara berikut timbul daripada situasi ini.

• Konfigurasi yang salah akan melumpuhkan segala-galanya serentak. restart: unless-stopped akan memulakan semula proses yang ranap, dan ia akan memulakan semula kontena yang tidak dapat menghuraikan config.yaml, berulang kali. Baca docker compose logs litellm selepas setiap perubahan konfigurasi, dan lakukan perubahan konfigurasi apabila anda mempunyai masa untuk memantaunya.
• Postgres berada dalam laluan permintaan. Carian kunci maya dan rekod perbelanjaan kedua-duanya menggunakannya. /health/readiness yang mengembalikan ralat 503 adalah amaran anda bahawa gateway sedang berjalan tetapi tidak dapat melakukan kedua-dua tugas tersebut.
• Skalakan dengan menambah instans, bukan dengan membesarkan satu instans. Panduan projek itu sendiri adalah satu worker bagi setiap instans (--num_workers 1) dengan beberapa instans berkongsi satu pangkalan data. Dua gateway kecil di belakang load balancer akan menghapuskan isu kontena tunggal tersebut. Ia tidak menghapuskan pangkalan data.
• Sandarkan apa yang anda tidak boleh jana semula. Ini merujuk kepada config.yaml dan .env, bersama-sama dengan pg_dump pangkalan data. Kehilangan LITELLM_SALT_KEY akan menyebabkan kelayakan penyedia yang disulitkan di dalam dump tersebut menjadi tidak berguna, jadi fail env dan dump tersebut perlu berada dalam tugasan sandaran yang sama: sandaran restic ke storan luar pelayan.

Proses naik taraf adalah dengan menyunting tag imej dan menjalankan docker compose up -d. LiteLLM menjalankan prisma migrate deploy semasa permulaan secara lalai, jadi kontena baharu akan memigrasikan skema pangkalan data pada but pertama. Lakukan dump sebelum anda menukar tag, kerana mengembalikan imej lama tidak akan membatalkan migrasi yang telah pun dijalankan.

FAQ

Adakah LiteLLM menambah latensi yang ketara pada setiap panggilan?

Projek ini menerbitkan angka 8 ms pada persentil ke-95 dengan 1000 permintaan sesaat, seperti yang dinyatakan dalam README pada Ogos 2026. Anggap itu sebagai angka daripada vendor. Angka yang sebenarnya mengubah latensi anda ialah jarak rangkaian antara aplikasi anda dan gateway, kerana anda telah menambah satu pusingan perjalanan (round trip) pada setiap panggilan. Jalankan gateway di rantau yang sama dengan aplikasi yang memanggilnya, kemudian ukur overhead anda sendiri dengan header x-litellm-overhead-duration-ms pada respons sebenar.

Mengapa penstriman berhenti berfungsi selepas saya meletakkan nginx di hadapan?

Ini kerana nginx menimbal (buffer) respons upstream secara lalai dan penyiapan penstriman adalah satu siri peristiwa yang dihantar pelayan (server-sent events). Dengan proxy_buffering diaktifkan, nginx mengumpul cebisan data dan hanya melepaskannya apabila respons selesai, jadi klien menunggu dalam senyap dan kemudian menerima keseluruhan jawapan sekaligus. Tetapkan proxy_buffering off; dalam blok location. Tingkatkan proxy_read_timeout dalam blok yang sama, kerana penjanaan yang panjang akan melebihi had lalai 60 saat nginx dan klien akan menerima ralat 504.

Apa yang berlaku apabila kunci maya (virtual key) kehabisan bajet?

Panggilan gagal dengan HTTP 401 dan badan respons dalam bentuk ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07. Ralat 401 adalah perangkapnya: pustaka klien melaporkannya sebagai kegagalan pengesahan, jadi pengguna mula menyemak sama ada kunci itu sah dan bukannya membaca mesej tersebut. Log badan respons bersama-sama dengan kod status. Sahkan kedudukan sebenar kunci dengan /key/info?key=sk-... berbanding kunci induk, dan naikkan had dengan /key/update jika bajet ditetapkan terlalu rendah.

Bolehkah gateway menghalakan trafik ke model tempatan selain model yang dihoskan?

Ya, dan ia merupakan satu lagi entri dalam model_list. Gunakan awalan ollama_chat/ dengan api_base, contohnya model: ollama_chat/llama3.1 bersama-sama dengan api_base: http://ollama:11434. Dari dalam kontena, localhost bermaksud kontena itu sendiri, jadi gunakan nama servis Compose atau alamat hos pada rangkaian Docker, jangan sekali-kali menggunakan 127.0.0.1. Menyediakan model tempatan adalah tugas yang berasingan: lihat mengehos sendiri LLM dengan Ollama pada VPS.