
LiteLLM Proxy-installation: Nycklar, Kostnader och Hastighetsbegränsningar
Ditt team delar OpenAI API-nycklar i Slack-DM:ar. Ingen vet vem som spenderade 4 000 kr förra tisdagen. Det finns ingen hastighetsbegränsning, ingen fallback när en leverantör går ner, och att byta från GPT-4o till Claude innebär att ändra kod på tolv ställen. Låter det bekant? En självhostad LLM-gateway löser allt det här, och LiteLLM-proxy är det mest populära alternativet med öppen källkod -- en enda OpenAI-kompatibel slutpunkt som dirigerar förfrågningar till 100+ LLM-leverantörer.
Den här guiden täcker hela LiteLLM proxy-installationen: Docker Compose med PostgreSQL, virtuella teamnycklar med budgetar, kostnadsspårning, hastighetsbegränsningar och anslutning av AI-IDE:er som Claude Code och Cursor. Om du utvärderar LLM-gateway-verktyg är det här den praktiska handledningen som tar dig från noll till produktion.
En viktig notering innan vi börjar: LiteLLM:s SDK (Python-biblioteket) och Proxyservern är olika saker. SDK:n är för en enskild utvecklare som anropar flera LLM-API:er från Python. Proxy:n är för team -- den sitter som en server mellan dina appar och LLM-leverantörer. Om du är en ensam utvecklare som skriver ett skript räcker SDK:n. Om du hanterar nycklar, budgetar och åtkomst för ett team behöver du proxy:n. Det är vad vi sätter upp här.
LiteLLM Proxy i Korthet
| Egenskap | Detaljer |
|---|---|
| Vad det är | OpenAI-kompatibel proxyserver för 100+ LLM-leverantörer |
| För vem | Team som hanterar flera LLM API-nycklar, budgetar och åtkomst |
| Licens | MIT (öppen källkod) |
| GitHub-stjärnor | 20 000+ |
| Leverantörer som stöds | OpenAI, Anthropic, Azure, AWS Bedrock, Google Vertex, Ollama och 100+ till |
| Nyckelfunktioner | Virtuella nycklar, kostnadsspårning, hastighetsbegränsning, modell-fallbacks, lastbalansering |
| Installationsmetoder | Docker, Docker Compose, pip, Kubernetes/Helm |
| Senaste stabila version | v1.83+ (undvik 1.82.7 och 1.82.8 -- se Felsökning) |
| Konfigurationsformat | config.yaml |
| Instrumentpanel | Inbyggt gränssnitt för kostnads- och användningsövervakning |
Så här jämförs driftsättningsmetoderna:
| Metod | Komplexitet | Bäst för | Installationstid |
|---|---|---|---|
docker run | Låg | Snabb testning, ensam dev | 60 sekunder |
| Docker Compose + Postgres | Medel | Team (2-50 personer) | 10-15 minuter |
| Kubernetes / Helm | Hög | Företag, autoskalning | 30-60 minuter |
| pip install | Låg | Endast lokal utveckling | 5 minuter |
För de flesta team är Docker Compose med PostgreSQL den gyllene medelvägen. Det är vad vi ska bygga -- men låt oss först få en proxy att köra på 60 sekunder.
Förutsättningar och Miljökonfiguration
Innan du börjar, se till att du har:
- Docker och Docker Compose installerat (Docker Desktop inkluderar båda)
- Minst en LLM API-nyckel (OpenAI, Anthropic eller en lokal Ollama-instans)
- Grundläggande terminal / CLI-kunskaper
Verifiera att Docker är redo och exportera dina API-nycklar:
# Kontrollera att Docker är installerat
docker --version
docker compose version
# Exportera dina LLM API-nycklar (lägg till i ditt shell-profil för persistens)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
# Valfritt: ange en huvudnyckel för din proxy (du behöver den senare)
export LITELLM_MASTER_KEY="sk-master-din-hemliga-nyckel"Det är allt. Ingen speciell Python-version, inga OS-specifika verktyg. Om Docker körs på din maskin är du redo.
Snabbstart -- Din Första LiteLLM-proxy på 60 Sekunder
Ett kommando för att starta en proxy med GPT-4o:
docker run -d \
--name litellm-proxy \
-p 4000:4000 \
-e OPENAI_API_KEY=$OPENAI_API_KEY \
-e LITELLM_MASTER_KEY=$LITELLM_MASTER_KEY \
ghcr.io/berriai/litellm:main-stable \
--model openai/gpt-4oTesta med curl:
curl http://localhost:4000/v1/chat/completions \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-4o",
"messages": [{"role": "user", "content": "Say hello from LiteLLM"}]
}'Eller testa från Python:
from openai import OpenAI
# Peka standard OpenAI SDK mot din proxy
client = OpenAI(
api_key="sk-master-din-hemliga-nyckel",
base_url="http://localhost:4000/v1"
)
response = client.chat.completions.create(
model="openai/gpt-4o",
messages=[{"role": "user", "content": "Say hello from LiteLLM"}]
)
print(response.choices[0].message.content)Vad hände just? Din kod pratar med localhost:4000 med hjälp av standard OpenAI SDK-formatet. Proxy:n tar emot förfrågan, vidarebefordrar den till OpenAI:s API med den riktiga nyckeln och returnerar svaret. Din programkod rör aldrig den faktiska API-nyckeln.
Det är grundtanken. Nu bygger vi en produktionskonfiguration.
Produktionskonfiguration med Docker Compose och PostgreSQL
Det enda docker run-kommandot fungerar för testning, men produktionsteam behöver beständig kostnadsspårning, virtuella nycklar och ordentlig databaslagring. Det innebär Docker Compose med PostgreSQL.
Docker Compose-filen
# docker-compose.yml
version: "3.9"
services:
litellm:
image: ghcr.io/berriai/litellm:main-stable
container_name: litellm-proxy
ports:
- "4000:4000" # Proxy API-port
volumes:
- ./config.yaml:/app/config.yaml # Montera din konfigurationsfil
environment:
- LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
- OPENAI_API_KEY=${OPENAI_API_KEY}
- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
- DATABASE_URL=postgresql://litellm:litellm_password@postgres:5432/litellm
- LITELLM_SALT_KEY=${LITELLM_SALT_KEY:-sk-salt-random-string}
command: --config /app/config.yaml --detailed_debug
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped
postgres:
image: postgres:16-alpine
container_name: litellm-db
environment:
POSTGRES_DB: litellm
POSTGRES_USER: litellm
POSTGRES_PASSWORD: litellm_password
volumes:
- litellm_pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U litellm"]
interval: 5s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
litellm_pgdata:LITELLM_SALT_KEY krypterar virtuella nyckeldata i databasen. Dokumentationen för LiteLLM:s produktionsbästa praxis rekommenderar att ange detta för alla teamdriftsättningar.
Starta Stacken
# Skapa en .env-fil med dina nycklar (committa inte detta till git)
echo "LITELLM_MASTER_KEY=sk-master-din-hemlighet" > .env
echo "OPENAI_API_KEY=sk-..." >> .env
echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
echo "LITELLM_SALT_KEY=sk-salt-$(openssl rand -hex 16)" >> .env
# Starta allt
docker compose up -d
# Kontrollera loggar
docker compose logs -f litellmVerifiera att Allt Fungerar
# Hälsokontroll
curl http://localhost:4000/health
# Testa en förfrågan
curl http://localhost:4000/v1/chat/completions \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "ping"}]}'Om du ser ett lyckat svar körs din produktionsstack. PostgreSQL lagrar all kostnadsdata, virtuella nycklar och användningsmätvärden beständigt över containeromstarter.
Slutsats: Docker Compose + PostgreSQL är den rekommenderade produktionskonfigurationen. Den ger dig beständig lagring, kostnadsspårning och virtuella nycklar med ungefär 10 minuters arbete. Docker-driftsättningsdokumentationen täcker Kubernetes och Helm om du behöver autoskalning senare.
Genomgång av Config.yaml -- En Verklig Multi-leverantörskonfiguration
De flesta handledningar visar en config.yaml med en modell. Så här ser en verklig teamkonfiguration ut med tre leverantörer, fallbacks och lastbalansering.
Konfigurationsfilen
# config.yaml -- Verklig multi-leverantörskonfiguration
model_list:
# Primär: OpenAI GPT-4o
- model_name: gpt-4o # Namnet som DIN kod använder
litellm_params:
model: openai/gpt-4o # Den faktiska leverantören/modellen
api_key: os.environ/OPENAI_API_KEY
# Sekundär: Anthropic Claude
- model_name: claude-sonnet
litellm_params:
model: anthropic/claude-sonnet-4-20250514
api_key: os.environ/ANTHROPIC_API_KEY
# Lokal: Ollama för utveckling / kostnadsfri testning
- model_name: local-llama
litellm_params:
model: ollama/llama3.1
api_base: http://host.docker.internal:11434
# Fallback: dirigera "gpt-4o" till Claude om OpenAI är nere
- model_name: gpt-4o
litellm_params:
model: anthropic/claude-sonnet-4-20250514
api_key: os.environ/ANTHROPIC_API_KEY
router_settings:
routing_strategy: least-busy # Lastbalansera över modeller med samma namn
num_retries: 3
retry_after: 5 # Sekunder mellan försök
fallbacks: [{"gpt-4o": ["claude-sonnet"]}]
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: os.environ/DATABASE_URLModellalias och Dirigering
Observera att gpt-4o förekommer två gånger i konfigurationen -- en gång pekar det mot OpenAI, en gång mot Anthropic. När din kod begär gpt-4o försöker LiteLLM OpenAI först. Om det misslyckas dirigerar fallbacks-inställningen automatiskt till Claude. Din programkod förändras inte alls.
Om du använder produktionsinfluensbackends som vLLM eller SGLang kan du lägga till dem på samma sätt -- ange bara api_base till din inferensserver.
Snabbreferens för Leverantörer
| Leverantör | Exempel model_name | Miljövariabel | Slutpunkt |
|---|---|---|---|
| OpenAI | openai/gpt-4o | OPENAI_API_KEY | Standard (api.openai.com) |
| Anthropic | anthropic/claude-sonnet-4-20250514 | ANTHROPIC_API_KEY | Standard |
| Ollama | ollama/llama3.1 | Ej nödvändig | http://localhost:11434 |
| Azure OpenAI | azure/gpt-4o | AZURE_API_KEY | Din Azure-slutpunkt |
| AWS Bedrock | bedrock/anthropic.claude-v2 | AWS-uppgifter | Din region |
Inställningen routing_strategy: least-busy fördelar förfrågningar över modeller med samma model_name. Om du har två OpenAI-nycklar (kanske olika organisationer med olika hastighetsbegränsningar), lista dem båda under gpt-4o och LiteLLM balanserar lasten.
Virtuella Nycklar -- Team-API-nycklar med Budgetar och Hastighetsbegränsningar
Det är här LiteLLM slutar vara "bara en proxy" och blir ett teamhanteringsverktyg. Virtuella nycklar låter dig ge varje teammedlem eller tjänst sin egen API-nyckel med utgiftsgränser och hastighetstak -- allt dirigerat genom ditt enda set av leverantörs-API-nycklar.
Skapa en Teamnyckel med Budget
# Skapa en virtuell nyckel med en budget på 500 kr/månad
curl http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"team_id": "frontend-team",
"max_budget": 50.0,
"budget_duration": "1mo",
"models": ["gpt-4o", "claude-sonnet"],
"metadata": {"purpose": "frontend AI features"}
}'Svaret ger dig en ny nyckel som sk-team-abc123.... Ge den till frontend-teamet. De kan använda den precis som en OpenAI-nyckel, men den är begränsad till $50/månad och har bara åtkomst till de modeller du angav.
Ange Hastighetsbegränsningar
# Skapa en nyckel med hastighetsbegränsningar: 100 förfrågningar/minut, 50K tokens/minut
curl http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"team_id": "backend-team",
"max_budget": 200.0,
"budget_duration": "1mo",
"rpm_limit": 100,
"tpm_limit": 50000,
"models": ["gpt-4o", "claude-sonnet", "local-llama"]
}'Dokumentationen för virtuella nycklar täcker varje parameter. Du kan också ange budgetar och hastighetsbegränsningar per användare för ännu mer detaljerad kontroll.
Övervaka Nyckelanvändning
import requests
# Kontrollera en nyckels aktuella utgifter och begränsningar
response = requests.get(
"http://localhost:4000/key/info",
headers={"Authorization": f"Bearer {MASTER_KEY}"},
params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Spenderat: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM använt: {info['rpm_limit_used']} / {info['rpm_limit']}")Behöver du återkalla en komprometterad nyckel? Ett API-anrop:
curl -X POST http://localhost:4000/key/delete \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"keys": ["sk-team-abc123..."]}'Slutsats: Virtuella nycklar gör LiteLLM till ett teamverktyg, inte bara en personlig proxy. Utan dem lägger du bara till ett hopp mellan din kod och LLM:en. Med dem har du åtkomstkontroll, budgetupprätthållande och användningsattribution -- det slag av saker som håller din ekonomichef från att få panik.
Kostnadsspårning och LiteLLM-instrumentpanelen
När PostgreSQL är anslutet spårar LiteLLM automatiskt kostnaden för varje förfrågan. Du behöver inte konfigurera något -- det känner till priset per token för varje modell som stöds.
Instrumentpanelen
Gå till det inbyggda gränssnittet på http://localhost:4000/ui (logga in med din huvudnyckel). Du ser:
- Total utgift över alla team och nycklar
- Per-modell-uppdelning -- vilka modeller äter upp din budget
- Per-team-utgift -- vem använder vad
- Förfrågningsvolym över tid
För team som är seriösa om att minska LLM API-kostnader motiverar instrumentpanelen ensamt att köra proxy:n. Du kan också ansluta LiteLLM till externa AI-observabilitetsplattformar som Langfuse eller Helicone för djupare analyser.
Kostnadsjämförelse per Leverantör
Här är vad de stora modellerna kostar per miljon tokens (april 2026):
| Leverantör | Modell | Indata $/1M tokens | Utdata $/1M tokens |
|---|---|---|---|
| OpenAI | GPT-4o | $2,50 | $10,00 |
| OpenAI | GPT-4o mini | $0,15 | $0,60 |
| Anthropic | Claude Sonnet 4 | $3,00 | $15,00 |
| Anthropic | Claude Haiku 3.5 | $0,80 | $4,00 |
| Gemini 2.0 Flash | $0,10 | $0,40 | |
| Ollama | Llama 3.1 (lokal) | $0,00 | $0,00 |
När du ser dessa siffror i instrumentpanelen uppdelade per team blir samtalen om "borde vi använda en billigare modell för det här användningsfallet?" väldigt konkreta.
Slutsats: Kostnadsspårning ensamt motiverar proxy:n för alla team som spenderar mer än 1 000 kr/månad på LLM API:er. Du kan inte optimera det du inte kan mäta.
Ansluta AI-IDE:er -- Claude Code, Cursor och Continue
Här är något som de flesta LiteLLM-guider hoppar över helt: du kan även peka dina AI-kodningsverktyg mot proxy:n. En proxy, alla dina IDE-verktyg, enhetlig fakturering.
Claude Code
# Ange att Claude Code ska använda din LiteLLM-proxy
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-din-virtuella-nyckelDet är allt. Claude Code skickar förfrågningar till din proxy, som dirigerar dem till Anthropic (eller dit din konfiguration säger) medan kostnader spåras under din virtuella nyckel.
Cursor
I Cursors inställningar, lägg till en anpassad OpenAI-kompatibel slutpunkt:
{
"openai.apiBaseUrl": "http://localhost:4000/v1",
"openai.apiKey": "sk-team-din-virtuella-nyckel"
}Continue (VS Code)
I Continue:s config.json:
{
"models": [
{
"title": "GPT-4o via LiteLLM",
"provider": "openai",
"model": "gpt-4o",
"apiBase": "http://localhost:4000/v1",
"apiKey": "sk-team-din-virtuella-nyckel"
}
]
}Varför bry sig? För att nu går varje utvecklares IDE-användning genom proxy:n. Du får kostnadsspårning per person för AI-kodningsassistenter, hastighetsbegränsningar så att ingen av misstag bränner 5 000 kr i en kodningssession, och ett enda ställe att byta modell om du hittar ett bättre alternativ.
Felsökning av Vanliga Problem
"Konfigurationsfilen hittades inte"
Det innebär vanligtvis att sökvägen för volymmonteringen är fel i Docker. Se till att din config.yaml finns i katalogen du monterar från:
# Kontrollera att filen finns där du tror
ls -la ./config.yaml
# Volymmonteringen i docker-compose.yml bör matcha
# volumes:
# - ./config.yaml:/app/config.yaml"Anslutning nekad" till PostgreSQL
Docker-nätverkande fångar alla minst en gång. Om LiteLLM inte kan nå Postgres, kontrollera att:
- Tjänstenamnet i
DATABASE_URLmatchar Docker Compose-tjänstenamnet (postgres, intelocalhost) depends_onmedcondition: service_healthyär inställt (så att LiteLLM väntar tills Postgres är redo)- Båda tjänsterna befinner sig i samma Docker-nätverk (de är det som standard i Compose)
"Ogiltigt API-nyckelformat"
Den vanligaste förvirringen: din LITELLM_MASTER_KEY är för administratörssoperationer (skapa virtuella nycklar, komma åt instrumentpanelen). Virtuella nycklar (sk-team-...) är vad dina applikationer använder. Blanda inte ihop dem.
"Modell hittades inte"
Fältet model i din förfrågan måste matcha ett model_name i config.yaml. Om din konfiguration definierar gpt-4o men din kod begär openai/gpt-4o matchar det inte. Kontrollera exakt stavning.
Proxy:n startar men förfrågningar hänger sig
Vanligtvis ett brandväggs- eller portbindningsproblem. Verifiera att port 4000 är exponerad och inte blockerad:
# Kontrollera om porten lyssnar
docker port litellm-proxy
# Bör visa: 4000/tcp -> 0.0.0.0:4000Säkerhet: Undvik Versionerna 1.82.7 och 1.82.8
I mars 2026 drabbades LiteLLM-versionerna 1.82.7 och 1.82.8 av en leveranskedjehändelse. De komprometterade versionerna drogs tillbaka och en ren release skeppades på 1.83.0. Fäst alltid din Docker-avbild till en specifik version och kontrollera den officiella säkerhetsuppdateringen innan du uppgraderar. Om du är på 1.82.7 eller 1.82.8, uppdatera omedelbart.
Vilken LiteLLM-installationsmetod Bör Du Välja?
| Om du behöver... | Välj | Varför |
|---|---|---|
| Snabbt test, ensam dev som experimenterar | docker run en-rad | Noll konfiguration, körs på 60 sekunder |
| Team på 2-10 med kostnadsspårning | Docker Compose + PostgreSQL | Beständig data, virtuella nycklar, budgetgränser |
| Team på 10-50 med flera miljöer | Docker Compose + Redis-cache | Lägger till caching för upprepade promptar, bättre genomströmning |
| Företag med compliance / autoskalning | Kubernetes + Helm-diagram | Autoskalning, rullande uppdateringar, RBAC-integration |
| Lokal utveckling utan Docker | pip install litellm + CLI | Snabbast för Python-devs som testar lokalt |
Om du läser den här guiden för första gången, börja med Docker Compose + PostgreSQL. Du kan alltid migrera till Kubernetes senare -- config.yaml förblir densamma.
Vanliga Frågor
Vad är LiteLLM-proxy och hur fungerar det?
LiteLLM-proxy är en öppen källkod AI-gatewayserver som sitter mellan dina applikationer och LLM-leverantörer som OpenAI och Anthropic. Den exponerar en enda OpenAI-kompatibel slutpunkt, så din kod pratar med en URL medan proxy:n hanterar routing, nyckelhantering, kostnadsspårning och fallbacks bakom kulisserna.
Hur sätter jag upp LiteLLM-proxy med Docker Compose?
Skapa en docker-compose.yml med LiteLLM-proxy-avbilden och en PostgreSQL-databas, montera din config.yaml, ange dina API-nycklar som miljövariabler och kör docker compose up -d. Avsnittet "Produktionskonfiguration med Docker Compose" ovan innehåller en komplett fil som är redo att kopiera och klistra in.
Hur hanterar jag team-API-nycklar med LiteLLM?
Använd virtuella nycklar. Anropa slutpunkten /key/generate med din huvudnyckel för att skapa nycklar per team eller per användare. Varje virtuell nyckel kan ha sin egen månadsbudget, hastighetsbegränsningar (RPM och TPM) och modellåtkomstbegränsningar. Avsnittet "Virtuella Nycklar" täcker hela arbetsflödet.
Hur lägger jag till kostnadsspårning och hastighetsbegränsningar till mitt LLM API?
Anslut PostgreSQL till proxy:n (via DATABASE_URL) och kostnadsspårning sker automatiskt. För hastighetsbegränsningar, ange rpm_limit och tpm_limit när du genererar virtuella nycklar. Den inbyggda instrumentpanelen på /ui visar utgifter per team och per modell.
Är LiteLLM-proxy säkert att använda i produktion?
Ja, med ett förbehåll: undvik versionerna 1.82.7 och 1.82.8 som drabbades av en leveranskedjehändelse i mars 2026. Använd version 1.83.0 eller senare. Fäst din Docker-avbildsversion, ange LITELLM_SALT_KEY för kryptering och följ de officiella produktionsbästa praxis.
Vad är skillnaden mellan LiteLLM SDK och LiteLLM-proxy?
SDK:n är ett Python-bibliotek för att anropa flera LLM-API:er från din kod. Proxy:n är en fristående server som hela ditt team ansluter till. Använd SDK:n när du är en ensam dev som skriver ett skript. Använd proxy:n när du behöver delad åtkomstkontroll, kostnadsspårning och hastighetsbegränsning över ett team.
Kan jag använda LiteLLM-proxy med Ollama och lokala modeller?
Absolut. Lägg till en post i din config.yaml med model: ollama/llama3.1 och api_base: http://host.docker.internal:11434 (eller din Ollama-värd). Ditt team kan sedan komma åt lokala modeller via samma proxy-slutpunkt, vilket är utmärkt för utveckling och kostnadsfri testning.
Hur mycket kostar LiteLLM-proxy?
LiteLLM-proxy är gratis och öppen källkod (MIT-licens). Du är värd för det själv på din egen infrastruktur. De enda kostnaderna är din server (en liten VPS räcker för de flesta team) och LLM API-kostnaderna du redan betalar. BerriAI erbjuder också en hanterad molnversion om du inte vill vara värd för den själv.
Vilka leverantörer stöder LiteLLM?
Över 100, inklusive OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate och många fler. Den fullständiga listan finns på LiteLLM:s GitHub-förråd.
Hur uppdaterar jag LiteLLM-proxy säkert?
Fäst alltid en specifik version i din Docker-avbildstagg (t.ex. ghcr.io/berriai/litellm:v1.83.2-stable). Kontrollera ändringsloggen för brytande ändringar innan du uppgraderar. Använd aldrig latest i produktion. Och kontrollera alltid att den nya versionen inte finns på säkerhetsrådgivningslistan -- händelsen i mars 2026 visade att även betrodda paket kan komprometteras.
Slutvärdering och Nästa Steg
| Kategori | Rekommendation | Anteckningar |
|---|---|---|
| Snabbstart | docker run en-rad | Perfekt för första testningen |
| Teamkonfiguration | Docker Compose + PostgreSQL | Standard för 90 % av teamen |
| Konfiguration | Multi-leverantör med fallbacks | Förlita dig inte på en enda leverantör |
| Nyckelhantering | Virtuella nycklar per team | Budget + hastighetsbegränsning per nyckel |
| Kostnadssynlighet | Inbyggd instrumentpanel + Postgres | Mät innan du optimerar |
| IDE-integration | Peka Claude Code / Cursor mot proxy:n | Enhetlig fakturering för alla verktyg |
| Säkerhet | Fäst versioner, ange salt-nyckel | Undvik 1.82.7 och 1.82.8 |
Om ditt team spenderar pengar på LLM API:er och du inte har en proxy ännu, börja med Docker Compose + Postgres idag. Konfigurationen tar 15 minuter och du har kostnadssynlighet och åtkomstkontroll när du är klar.
När du väl är igång, utforska att lägga till guardrails i din LLM-pipeline för innehållsfiltrering och säkerhetskontroller. Proxy:n är grunden -- allt annat byggs ovanpå.