AI-gatewayar: Kong AI Gateway, Portkey och LiteLLM i produktion

När en organisation går från ett enstaka LLM-experiment till flera appar som alla anropar modeller uppstår samma frågor: vem håller koll på kostnaden, hur byter vi leverantör utan att skriva om koden, vad händer när en modell går ner, och hur sätter vi gränser per team? En AI-gateway är ett lager mellan era appar och modell-API:erna som svarar på just de frågorna. Kong AI Gateway, Portkey och LiteLLM är tre populära alternativ - men de har olika tyngdpunkt och passar olika mognadsgrader.

Jag har infört gateways i organisationer med många modellanrop och även avrått från dem där de bara hade lagt till ett lager utan nytta. Här är en uppriktig jämförelse, inklusive när inget av dem behövs. En sak är värd att slå fast direkt: en gateway löser ett organisatoriskt problem minst lika mycket som ett tekniskt. Den blir intressant när flera team och flera appar ska samsas om samma modeller, budgetar och nycklar - inte när en ensam app pratar med en ensam leverantör.

Vad en AI-gateway gör

Oavsett produkt löser en gateway i grunden samma saker, även om de gör det olika väl:

• Enhetligt gränssnitt: ett API mot flera leverantörer, så att byte blir en konfigurationsfråga.
• Failover och routing: automatiskt omdirigera när en modell är nere eller långsam.
• Kostnadskontroll: mäta och sätta tak per app, team eller nyckel.
• Caching och rate limiting: minska kostnad och skydda mot överbelastning.
• Observerbarhet: loggar och mätvärden på ett ställe.

LiteLLM: lätt att börja med

LiteLLM är ofta enklast att komma igång med. Det ger ett enhetligt gränssnitt mot ett stort antal leverantörer och går att köra som ett tunt lager eller en fristående proxy. För team som mest vill kunna byta modell utan att röra koden och få grundläggande kostnadsöversikt är det ett pragmatiskt val. Baksidan är att de mer avancerade styrnings- och säkerhetsfunktionerna är mindre utbyggda än hos en fullfjädrad gateway.

Portkey: byggt för LLM-drift

Portkey är specifikt byggt kring LLM-drift och har genomtänkta funktioner för routing, failover, caching, försök igen och observerbarhet, med ett gränssnitt för att följa upp användning. För team vars huvudsmärta är just driftsäkerhet och kostnadsöversikt på AI-trafiken är det ofta det mest direkt användbara av de tre. Det är samtidigt en extra leverantör i kedjan, vilket man bör väga in.

Just observerbarheten är ofta det som gör skillnad i praktiken. När någon på ledningen frågar varför AI-kostnaden steg förra månaden vill man kunna svara med en uppdelning per app och funktion, inte med en gissning. En gateway som samlar den datan på ett ställe gör den frågan enkel att besvara och gör det möjligt att sätta in åtgärder där de faktiskt biter - vilket knyter direkt an till det jag skriver om kostnadsoptimering. Den som väger Portkey mot ett eget bygge bör fråga sig om man verkligen vill bygga och underhålla den uppföljningen själv.

Kong AI Gateway: för dem som redan har Kong

Kong AI Gateway bygger på den etablerade Kong-plattformen för API-hantering och lägger AI-specifika funktioner ovanpå. Den stora fördelen uppstår om ni redan kör Kong för era övriga API:er - då får ni AI-trafiken under samma styrning, säkerhet och drift som resten. Men för ett team utan befintlig Kong-investering är det ett tungt fundament att dra in bara för LLM-anrop, och då skulle jag titta på något lättare först. Här är alltså Kong sällan min rekommendation om ni inte redan är på plattformen.

Min rekommendation - och när ingen gateway behövs

För de flesta som precis börjat skala räcker LiteLLM eller Portkey beroende på om tyngdpunkten är enkelhet eller drift. Kong vinner i en specifik situation: ni har redan Kong. Och det viktigaste ärliga rådet: har ni en enda app med måttlig trafik mot en leverantör behöver ni ingen gateway alls - ett tunt eget abstraktionslager räcker och slipper ett extra beroende i den kritiska vägen. Jag inför en gateway när det finns flera konsumenter och ett verkligt behov av central styrning, inte i förebyggande syfte.

Att avgöra var den gränsen går för just er, och välja rätt verktyg, är en av de saker jag hjälper till med inom AI Engineering. Caching och routing genom gatewayen hänger dessutom tätt ihop med kostnadsoptimering, som jag fördjupar i en egen artikel.

Bygga själv eller köpa in

Frågan jag oftast får är om man inte lika gärna kan bygga gatewayen själv. Svaret är att man kan - de grundläggande funktionerna är inte raketforskning - men man ska veta vad man ger sig in på. Ett eget lager börjar litet och rimligt, men sedan ska det underhållas: nya leverantörer ska stödjas, failover ska faktiskt fungera under last, och uppföljningen ska byggas ut. Det blir lätt ett internt projekt som ingen egentligen äger. Min tumregel är att bygga själv när behovet är litet och specifikt, och köpa in när det vuxit till generell infrastruktur som flera team förlitar sig på. Att betala för en mogen produkt är ofta billigare än att underhålla en halvfärdig egen.

Säkerhet och en enda felkälla

En gateway centraliserar era API-nycklar, vilket är bra för kontroll men gör lagret till en kritisk punkt: går gatewayen ner stannar all AI-trafik. Jag designar därför alltid för det - hälsokontroller, en plan för reträtt, och tydlig loggning så att problem syns direkt. En strukturerad hantering av svar och fel, i linje med structured outputs, gör lagret pålitligare.

Relaterat

• Evals för LLM-appar: Bygga test-suiter som faktiskt fångar regressioner
• Voice AI för kundtjänst: OpenAI Realtime + Twilio i svensk produktion
• Structured outputs med OpenAI och Anthropic: JSON-schema i LLM-svar

Ett exempel på en gateway-införing som sänkte kostnaden och förenklade leverantörsbyte finns bland mina kundcase.

Vill du ta det vidare?

Undrar ni om ni har vuxit ur ett eget abstraktionslager och behöver en riktig gateway? Boka ett förutsättningslöst samtal så bedömer vi ert behov innan ni inför ny infrastruktur.