LiteLLM ile Kendi LLM Gateway Sunucunuzu Kurun

Self-hosted LLM gateway nedir

LiteLLM, kendi sunucunuzda barındırdığınız açık kaynaklı bir LLM gateway'idir: tüm uygulamalarınızın çağrı yaptığı ve gelen her isteği ilgili sağlayıcıya ileten tek bir HTTP uç noktasıdır. LLM, büyük dil modeli (large language model) anlamına gelir. Gateway, OpenAI chat completions API (uygulama programlama arayüzü) ile uyumludur; bu nedenle OpenAI ile iletişim kurabilen her istemci kütüphanesi, base URL ve anahtar (key) üzerinde yapılacak iki değişikliğin ardından bu gateway ile çalışabilir.

Bu dolaylı katmanın temel amacı budur. Uygulamalarınız artık sağlayıcı kimlik bilgilerini tutmaz. Bir modeli değiştirmek, beş farklı serviste kod değişikliği yapmak yerine sunucudaki yapılandırma dosyasında tek satırlık bir işleme dönüşür. Her çağrı tek bir süreç üzerinden geçtiği için, bütçe kısıtlaması uygulayabileceğiniz ve harcamaların kaydını tutabileceğiniz merkezi bir noktanız olur.

Sistem çalışır hale geldiğinde şunlara sahip olursunuz:

• Tek bir uç nokta. Uygulamalar https://gateway.example.com/v1 adresini hedefler ve bulk veya strong gibi sizin belirlediğiniz bir model adını talep eder.
• Sanal anahtarlar. Her uygulama, kendi model izin listesine ve harcama limitine sahip özel bir anahtar alır. Diğerlerini etkilemeden birini iptal edebilirsiniz.
• Yedekleme (Fallbacks). Başarısız olan bir çağrı veya çok büyük bir istem (prompt), otomatik olarak farklı bir model üzerinden tekrar denenir.
• Log kaydı. Her istek, maliyetini içeren bir satır olarak yazılır; böylece "bu harcamayı hangi uygulama yaptı" sorusunun bir yanıtı olur.

Ağ geçidini neden kendiniz çalıştırmalısınız

Yönetilen bir yönlendirici, her isteğin ortasında başka birinin süreci bulunan aynı yapıdadır. Bunu kendiniz çalıştırdığınızda, sağlayıcı anahtarlarınızı ve istem metinlerinizi kontrolünüz altındaki bir kutuda tutarsınız. Bunun maliyeti gerçektir: Artık her uygulamanın bağımlı olduğu bileşeni siz yönetiyorsunuz. Bu kılavuzun son bölümü bu maliyet hakkındadır, çünkü çoğu yazının dışarıda bıraktığı kısım budur.

Gereksinimler

• Docker ve Compose eklentisi kurulu, Ubuntu 24.04 çalıştıran bir VPS (sanal özel sunucu).
• Makine dışındaki istemciler ağ geçidine TLS (taşıma katmanı güvenliği) üzerinden erişecekse, sunucuya yönlendirilmiş bir alan adı.
• En az bir sağlayıcı API anahtarı.

Ağ geçidi çıkarım (inference) işlemi yapmaz. İstekleri iletir ve yanıtları geri akıtır; bu nedenle CPU yükü model boyutundan ziyade istek hacmine göre değişir. 1 vCPU'lu bir sunucu, birkaç dahili uygulamayı sorunsuz bir şekilde çalıştırır. Ağ geçidi her istek için bir harcama satırı yazdığından, zamanla büyüyen tek bileşen veritabanıdır.

Önce config.yaml dosyasını yazın

Yapılandırma dosyası, istemcilerin hangi modelleri talep edebileceğini belirler. Dört üst düzey bölüm önemlidir: model_list, litellm_settings, router_settings ve 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, istemcilerinizin gönderdiği isimdir. litellm_params.model ise provider/model olarak yazılan gerçek modeldir. Modellerinizi tedarikçi ismine göre değil, yaptıkları işe göre adlandırın. bulk talep eden bir uygulama, gelecek ay bulk modelini farklı bir modelle değiştirmeye karar verdiğinizde çalışmaya devam eder.

api_key: os.environ/ANTHROPIC_API_KEY, LiteLLM'e ilgili değişkeni çalışma zamanında okumasını söyler. Değişkenin gerçek değeri dosya içinde asla yer almaz; bu durum, config.yaml dosyasını commit ettiğiniz için önemlidir.

İki girdi, kasıtlı olarak aynı strong ismini paylaşır. Birden fazla dağıtım aynı model_name değerini taşıdığında, yönlendirici bunları birbirinin yerine kullanılabilir olarak görür ve ilki başarısız olduğunda diğerini dener. strong, bir sağlayıcının sorun yaşadığı saatlerde bu şekilde ayakta kalır.

num_retries: 2, yeniden denenebilir bir hata durumunda aynı dağıtımı tekrar dener. Bir yedekleme (fallback) mekanizması yalnızca bu denemeler tükendikten sonra devreye girer. cooldown_time: 30 ile birlikte kullanılan allowed_fails: 3, 3 kez başarısız olan bir dağıtımı 30 saniyeliğine rotasyondan çıkarır; böylece 500 hatası döndüren bir sağlayıcı, her istekte tekrar denenmekten kurtulur.

fallbacks ve context_window_fallbacks farklı tetikleyicilere sahiptir ve ikincisi, insanların atladığı ancak oldukça faydalı olan kısımdır.

• fallbacks, birincil çağrı başarısız olduğunda tetiklenir.
• context_window_fallbacks, sağlayıcı isteği modelin bağlam penceresinden (context window) daha uzun olduğu gerekçesiyle reddettiğinde tetiklenir; böylece çok büyük bir istem, hata döndürmek yerine yeterli kapasiteye sahip başka bir modele yönlendirilir.

Ayrıca, sağlayıcının içerik politikası gereği reddettiği durumlar için content_policy_fallbacks mevcuttur. Bunu yalnızca bu çağrıları yönlendirebileceğiniz mantıklı bir hedefiniz varsa ayarlayın.

LiteLLM uygulamasının Docker Compose ile VPS üzerinde dağıtılması

Üç dosya barındıran bir dizin oluşturun: config.yaml, docker-compose.yml ve .env. Upstream hızlı başlangıç kılavuzu latest etiketini çeker. Bunun yerine bir sürüm etiketi sabitleyin; böylece docker compose up -d tarihinde yapacağınız işlem size bugün sunduğu ağ geçidinin aynısını sunar ve geri alma işlemi tek satıra iner.

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, .env dosyasını burada iki kez okur. Birincisi, ${POSTGRES_PASSWORD} değişkenini compose dosyası içinde yerine koymak için; ikincisi ise env_file aracılığıyla tüm değişkenleri container içine aktarmak için.

v1.95.0, Ağustos 2026 itibarıyla güncel sürümdü. Projenin sürümler sayfasına bakın ve dağıtım yaptığınız sırada güncel olan sürümü sabitleyin. Her sürüm bir imza yayınlar, böylece güvenmeden önce imajı doğrulayabilirsiniz:

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

Port satırı 127.0.0.1:4000:4000 şeklindedir ve portu yalnızca loopback arayüzünde yayınlar. Bunun yerine 4000:4000 yazarsanız ağ geçidiniz tüm internete açık hale gelir. Çünkü Docker, iptables FORWARD zincirine kendi kurallarını ekler ve bu kurallar ufw kurallarından önce değerlendirilir; bu nedenle ufw deny 4000 bunu engellemez. Self-hosted bir ağ geçidinin açık kalmasının en yaygın yolu budur: Docker'ın bir container portunu ufw kurallarını atlayarak nasıl yayınladığına bakın. Dışarıdan gelen trafik bunun yerine reverse proxy üzerinden ulaşmalıdır.

Sağlayıcı anahtarlarını imajın dışında tutun

.env dosyası tüm gizli bilgileri barındırır. Çalışma zamanında ortam değişkeni olarak aktarılır, bu nedenle asla imajın içine gömülmez ve hiçbir zaman commit edilmez.

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

İki adet LiteLLM anahtarını gerçek rastgelelik ile oluşturun ve ardından dosya erişimini kısıtlayın:

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

LITELLM_MASTER_KEY yönetici kimlik bilgisidir. Yönetim API'sinin kimlik doğrulamasını sağlar ve /ui adresindeki Admin UI için paroladır. Hiçbir uygulama bu bilgiyi saklamamalıdır.

LITELLM_SALT_KEY, veritabanında saklanan sağlayıcı kimlik bilgilerini şifreler. Bir kez ayarlayın ve öyle bırakın. Daha sonra değiştirirseniz, halihazırda saklanan kimlik bilgileri şifresi çözülemez hale gelir; bu durumda ağ geçidi normal şekilde başlar ancak sağlayıcılara yapılan her çağrı kimlik doğrulama hatası verir.

STORE_MODEL_IN_DB=True, config.yaml dosyasına dokunmadan Admin UI üzerinden model eklemenize ve düzenlemenize olanak tanır. Bu kullanışlıdır ancak doğruluk kaynağınızı ikiye böler. Hangisinin yetkili olduğuna karar verin ve bu kararı config dosyasının yanına not edin.

Anahtarları yapılandırma dosyasının dışında tutma mantığı, onları bir aracıya (agent) verdiğiniz araçların dışında tutma mantığıyla aynıdır. Sağlayıcı gizli bilgilerini yapay zeka aracılarından uzak tutma bu modeli, env dosyaları ve Docker Compose içindeki gizli bilgiler ise teknik işleyişi ele alır.

Sistemi ayağa kaldırın ve ilk başlatma sürecini izleyin:

docker compose up -d
docker compose logs -f litellm

Çalıştığından emin olun

Kimlik doğrulaması gerektirmeyen iki adet ve kimlik doğrulaması gerektiren bir adet sonda bulunmaktadır; bu sondalar farklı nedenlerle başarısız olurlar.

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

/health/liveliness kimlik doğrulaması gerektirmez ve süreç çalışırken "I'm alive!" yanıtını verir. /health/readiness da kimlik doğrulaması gerektirmez. Bu uç nokta, "status": "healthy" ve db alanlarını içeren bir JSON nesnesi döndürür; veritabanına ulaşılamadığında ise 503 hatası verir. İzleme aracınızı readiness uç noktasına yönlendirin; çünkü liveliness, tek bir sanal anahtarı bile çözümleyemeyen bir ağ geçidinde dahi yeşil kalmaya devam eder.

Kimlik doğrulaması gerektiren kontrol, sağlayıcılarla iletişim kuran sondadır:

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

Bu sonda, healthy_endpoints ve unhealthy_endpoints dizileriyle yanıt verir. unhealthy_endpoints içinde bir kimlik doğrulama hatasıyla bekleyen bir model, .env içindeki sağlayıcı anahtarının yanlış veya eksik olduğu anlamına gelir; bu, şu an tespit etmeniz gereken hata türüdür. background_health_checks: true ayarlı olduğu için, proxy bu sondaları kendi başına her health_check_interval saniyede bir çalıştırır ve /health son sonucu döndürür; bu nedenle uç noktayı sorgulamak, her seferinde sağlayıcılarınıza bir test isteği göndermez.

Sanal anahtarlar ve anahtar bazlı bütçeler

Her uygulama, ana anahtara karşı oluşturulmuş kendi özel anahtarına sahiptir.

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

Yanıt, sk- ile başlayan bir key alanı içerir. Uygulamanın aldığı ve erişebildiği tek veri bu dizidir.

• models, bu anahtarın neleri talep edebileceğine dair bir izin listesidir. Yukarıdaki anahtar yalnızca bulk talebinde bulunabilir, başka hiçbir şey isteyemez.
• max_budget: 5 ve budget_duration: "30d", 30 günlük hareketli dönem başına beş ABD doları tutarında bir bütçe sınırı belirler; bu sınır aşıldığında anahtar çalışmayı durdurur.
• rpm_limit ve tpm_limit, yalnızca bu anahtara özel olarak dakika başına istek ve dakika başına token sınırlarını belirler.
• key_alias, altı hafta sonra harcama günlüklerinde göreceğiniz tanımlayıcıdır. Bunu her zaman ayarlayın.

Bütçe tükendiğinde, çağrı HTTP 401 hatasıyla başarısız olur ve şu gövde yapısını döndürür:

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

Durum kodunun bu şekilde olması kafa karıştırıcıdır. İstemci kütüphaneleri 401 kodunu bir kimlik doğrulama sorunu olarak raporlar; bu nedenle yığın izini (stack trace) inceleyen geliştirici, anahtarın geçerli olup olmadığını kontrol etmeye başlar. Yanıt gövdesini durum koduyla birlikte günlüğe kaydedin, aksi takdirde bütçe tükenmesi her seferinde bozuk bir kimlik bilgisi gibi görünecektir.

Anahtarları aynı yönetim API'si üzerinden inceleyebilir ve ayarlayabilirsiniz:

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

Ağ geçidinde uygulanan bir bütçe, sorun yaşayan şey bizzat aracının kendisi olsa bile geçerliliğini korur; bu nedenle bu mekanizma, bir VPS üzerindeki yapay zeka aracıları için maliyet kontrolü sisteminin temelini oluşturur.

Toplu işleri düşük maliyetli bir modele yönlendirme

İstemciyi ağ geçidine (gateway) yönlendirin. Base URL, anahtar ve model adı şu şekildedir:

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

Herhangi bir OpenAI istemci kütüphanesi aynı şekilde çalışır: base_url değerini https://gateway.example.com/v1 olarak, api_key değerini ise sanal anahtar olarak ayarlayın.

config.yaml dosyasındaki yönlendirme politikası, çağrıyı yapan tarafın haberi olmadan uygulanır. bulk için gelen bir istek, düşük maliyetli modele gider. Eğer bu çağrı yeniden denemelerden sonra başarısız olursa, istek strong üzerinde tekrar denenir. Eğer istem bulk için çok uzunsa, context_window_fallbacks hata döndürmek yerine isteği strong adresine gönderir. Sınıflandırma geçişi veya özetleme birikimi gibi toplu işler varsayılan olarak düşük maliyetle çalışır ve yalnızca zorlu istekler daha yüksek maliyet oluşturur.

Ağ geçidinin araç kullanan aracı (agent) sistemleri için önem kazandığı nokta burasıdır. Aynı VPS üzerinde çalışan bir MCP (model context protocol) sunucusu ve onu yöneten aracı, tek bir uç noktaya işaret edebilir; böylece arkadaki model, herhangi bir yeniden dağıtım (redeployment) gerektirmeden değiştirilebilir.

Yedekleme mekanizmasının devreye girdiği nasıl anlaşılır?

Bu, hiçbir şeyin bozuk görünmemesi nedeniyle maliyet yaratan bir hata modudur. Başarılı bir yedekleme (fallback), normal bir yanıt gövdesiyle birlikte HTTP 200 döner. Ucuz modeliniz bir gün boyunca kapalı kalabilir, her çağrı sessizce pahalı olan model tarafından karşılanabilir ve elinizdeki ilk kanıt fatura olur.

Kanıt, yanıt başlıklarında (response headers) mevcuttur. Bunları talep edin:

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, istemcinin ne talep ettiğini gösterir. x-litellm-model-id ise yanıtı veren dağıtımdır. Bu ikisi uyuşmadığında bir yedekleme gerçekleşmiş demektir.
• x-litellm-attempted-fallbacks ve x-litellm-attempted-retries bunları sayar. Sağlıklı bir çağrıda her ikisi de 0 değerindedir.
• x-litellm-response-cost, o tekil çağrının ABD doları cinsinden maliyetidir.
• x-litellm-call-id, aynı çağrıyı loglarınızda bulmak için kullandığınız tanımlayıcıdır.

Her istekte x-litellm-attempted-fallbacks değerini kaydedin ve 0 değerinden saptığında uyarı verin. Bu tek sayı, çalışan bir yönlendirme politikası ile sessizce "her zaman pahalı modeli kullan" haline gelmiş bir yönlendirme politikası arasındaki farktır.

Bunun tam sürümü izlemedir (tracing) ve kendi kurulumunu hak eder: izleme ajanı çağrıları için self-hosted Langfuse. LiteLLM geri çağırma (callback) işlevini içerir, bu nedenle bağlantıyı kurmak iki satır kod ve kimlik bilgilerinden ibarettir.

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

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

failure_callback ve success_callback değerlerini ayarlayın. Bunu atlarsanız, elinizde kalan tek izler hiçbir şeyin ters gitmediği durumlara ait olanlardır. Bunlardan bağımsız olarak, LiteLLM her istek için Postgres içine bir harcama satırı yazar ve /ui adresindeki Yönetici Arayüzü bu tabloyu okur. Trafikle birlikte büyüdüğü için küçük bir disk üzerinde izleyin.

Gateway'i bir reverse proxy arkasına konumlandırma

Sunucu dışından hiçbir trafik 4000 numaralı porta doğrudan erişmemelidir. TLS termination işlemini nginx veya Caddy üzerinde gerçekleştirin ve trafiği loopback adresine yönlendirin.

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

Bu satırlardan ikisi genellikle göz ardı edilir. proxy_buffering off, streaming completion işlemi bir dizi server-sent events (SSE) olduğu için önemlidir; nginx üzerinde buffering etkin olduğunda yanıt tamamlanana kadar parçalar tutulur, bu nedenle istemci hiçbir veri almadan bekler ve sonunda tüm yanıtı tek seferde alır. proxy_read_timeout 600s, uzun süren üretim süreçleri nginx'in varsayılan 60 saniyelik zaman aşımını aşabileceği için önemlidir; bu süre aşıldığında istemci 504 hatası alır ve hata günlüklerinde upstream timed out (110: Connection timed out) while reading response header from upstream kaydı oluşur.

Sertifika için, nginx üzerinde Let's Encrypt ile Certbot kullanımı en kısa yoldur. Eğer sunucu halihazırda birden fazla container barındırıyorsa, birden fazla Compose uygulaması önünde Traefik kullanımı yönlendirme ve sertifika işlemlerini tek bir noktadan yönetmenizi sağlar.

Ağ geçidi artık tek bir hata noktasıdır

Kurduğunuz yapının gerçeklerini göz önünde bulundurun. Sahip olduğunuz tüm uygulamalar artık tek bir VPS üzerindeki tek bir container'a bağımlıdır. Bu yapı çalışmadığı sürece, sağlayıcılar tamamen sağlıklı olsa bile hiçbir model çağrılamaz. Bu durumdan dört sonuç çıkar.

• Hatalı bir yapılandırma her şeyi aynı anda devre dışı bırakır. restart: unless-stopped bir çökme durumunda yeniden başlatma yapar ve config.yaml dosyasını ayrıştıramayan bir container'ı sürekli olarak yeniden başlatır. Her yapılandırma değişikliğinden sonra docker compose logs litellm dosyasını okuyun ve yapılandırma değişikliklerini bunları izleyecek vaktiniz olduğunda yapın.
• Postgres istek yolunda yer alır. Sanal anahtar sorgulama ve harcama kaydı işlemleri bu veritabanını kullanır. /health/readiness üzerinden 503 hatası almanız, ağ geçidinin çalıştığını ancak bu işlemlerin hiçbirini yapamadığını gösteren bir uyarıdır.
• Tek bir örneği büyütmek yerine örnek sayısını artırarak ölçeklendirin. Projenin kendi kılavuzu, tek bir veritabanını paylaşan birden fazla örnek ile her örnek için bir worker (--num_workers 1) kullanılmasını önerir. Bir yük dengeleyicinin arkasındaki iki küçük ağ geçidi, tek bir container'a olan bağımlılığı ortadan kaldırır. Ancak veritabanı bağımlılığını ortadan kaldırmazlar.
• Yeniden oluşturamayacağınız verileri yedekleyin. Bu veriler config.yaml ve .env dosyaları ile birlikte veritabanının bir pg_dump yedeğidir. LITELLM_SALT_KEY dosyasının kaybedilmesi, dump içindeki şifrelenmiş sağlayıcı kimlik bilgilerini kullanılamaz hale getirir; bu nedenle env dosyası ve dump aynı yedekleme işine dahil edilmelidir: restic ile sunucu dışı depolamaya yedekleme.

Yükseltme işlemi, image etiketini düzenleyip docker compose up -d komutunu çalıştırmaktan ibarettir. LiteLLM varsayılan olarak başlangıçta prisma migrate deploy komutunu çalıştırır, bu nedenle yeni container ilk açılışında veritabanı şemasını günceller. Etiketi değiştirmeden önce dump alın; çünkü eski image'ı geri yüklemek, halihazırda çalışmış olan bir migrasyonu geri almaz.

FAQ

LiteLLM her çağrıya belirgin bir gecikme ekler mi?

Proje, Ağustos 2026 tarihli README dosyasında, saniyede 1000 istekte 95. yüzdelik dilimde 8 ms gecikme süresi bildirmektedir. Bu veriyi bir üretici değeri olarak kabul edin. Gecikme sürenizi asıl etkileyen faktör, uygulamalarınız ile ağ geçidi arasındaki ağ mesafesidir; çünkü her çağrıya bir gidiş-dönüş süresi eklemiş olursunuz. Ağ geçidini, onu çağıran uygulamalarla aynı bölgede çalıştırın ve ardından gerçek bir yanıt üzerinde x-litellm-overhead-duration-ms başlığı ile kendi ek yükünüzü ölçün.

Nginx'i öne koyduktan sonra akış (streaming) neden çalışmayı durdurdu?

Çünkü Nginx varsayılan olarak yukarı akış (upstream) yanıtlarını arabelleğe alır ve bir akış tamamlanması, sunucu tarafından gönderilen bir dizi olaydan oluşur. proxy_buffering açıkken Nginx parçaları toplar ve yalnızca yanıt bittiğinde serbest bırakır; bu nedenle istemci sessizce bekler ve ardından tüm yanıtı tek seferde alır. Location bloğunda proxy_buffering off; ayarını yapın. Aynı blokta proxy_read_timeout değerini yükseltin, aksi takdirde uzun süren bir üretim işlemi Nginx'in 60 saniyelik varsayılan süresini aşar ve istemci 504 hatası alır.

Sanal bir anahtarın bütçesi tükendiğinde ne olur?

Çağrı, HTTP 401 hatası ve ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07 biçiminde bir gövde ile başarısız olur. 401 kodu bir tuzaktır: istemci kütüphaneleri bunu bir kimlik doğrulama hatası olarak rapor eder, bu nedenle kullanıcılar mesajı okumak yerine anahtarın geçerli olup olmadığını kontrol etmeye başlar. Yanıt gövdesini durum koduyla birlikte günlüğe kaydedin. Anahtarın gerçek durumunu ana anahtara karşı /key/info?key=sk-... ile doğrulayın ve bütçe çok düşük ayarlanmışsa /key/update ile limiti yükseltin.

Ağ geçidi, barındırılan modellerin yanı sıra yerel bir modele de yönlendirme yapabilir mi?

Evet, bu model_list içinde bir giriş daha oluşturur. api_base ile birlikte ollama_chat/ önekini kullanın; örneğin api_base: http://ollama:11434 ile birlikte model: ollama_chat/llama3.1. Bir container içinden localhost o container'ı ifade eder, bu nedenle Docker ağındaki Compose servis adını veya ana makinenin adresini kullanın, asla 127.0.0.1 kullanmayın. Yerel modeli ayağa kaldırmak ayrı bir iştir: bkz. Ollama ile VPS üzerinde LLM self-hosting.