Vad en AI-gateway gör
Utan gateway anropar varje applikation OpenAI, Anthropic eller en annan leverantör direkt, med sin egen nyckel och sitt eget sätt att logga. Med en gateway anropar applikationerna i stället en enda endpoint, och gatewayen skickar vidare varje förfrågan till rätt leverantör och modell. På vägen kan den kontrollera vem som anropar, räkna tokens, stoppa en förfrågan som skulle spräcka en budget, logga vad som hände och skicka tillbaka svaret. Många gatewayer har ett OpenAI-kompatibelt API, så befintlig kod och befintliga bibliotek fortsätter att fungera när basadressen och nyckeln byts.
API-nycklarna på ett ställe
Leverantörsnycklarna är den känsligaste delen av en AI-lösning: den som har en kan dra på sig kostnader på ert konto. En gateway håller leverantörsnycklarna på ett ställe, krypterade, och ger i stället varje applikation eller team en egen nyckel till gatewayen. Läcker en sådan nyckel kan den återkallas utan att leverantörsnyckeln eller de andra applikationerna påverkas. Det blir också tydligt vilket system som gjorde vilka anrop, vilket spelar roll när en faktura växer. Guiden om egna API-nycklar och kostnadstak går djupare in på var nycklar ska ligga.
Loggar, kostnadstak och larm
Leverantörerna visar förbrukning per nyckel eller projekt, men sällan så som verksamheten behöver den: per kund, per funktion eller per avdelning. En gateway loggar varje anrop med modell, antal tokens, kostnad och svarstid, så att siffrorna kan delas upp hur man vill. Ovanpå loggarna kommer budgettak och rate limits per projekt, och larm innan ett tak nås. En automation som hamnat i en loop och anropar en modell tusentals gånger stannar då vid taket, i stället för att dyka upp på nästa faktura.
Styrning mellan modeller och leverantörer
Modellerna byts ut snabbt, och det som är bäst för en uppgift i dag är kanske inte bäst om ett halvår. Med en gateway ber applikationen om ett alias, till exempel en snabb modell för klassificering och en starkare för textutkast, och gatewayen avgör vilken leverantör och modell som ligger bakom. Att byta modell blir en ändring i konfigurationen i stället för i koden. Fallback-kedjor skickar förfrågan vidare till en annan modell eller leverantör när den första ligger nere eller är överbelastad, och en svarscache kan ge ett sparat svar på en identisk förfrågan utan ett nytt anrop.
Data i EU och personuppgifter
När prompterna innehåller personuppgifter eller affärshemligheter spelar det roll var de behandlas. Flera leverantörer erbjuder endpoints eller regioner i EU, men varje applikation måste ställas in för att använda dem, och ett enda misstag skickar datan någon annanstans. En gateway kan upprätthålla regeln centralt: ett projekt som är märkt för EU når bara EU-endpoints, oavsett vad applikationen ber om. Det ersätter inte det juridiska arbetet enligt GDPR, men det gör en policy till något som kontrolleras vid varje anrop.
När ni inte behöver en gateway
En enda applikation mot en leverantör, med små volymer och en utvecklare som håller koll på fakturan, klarar sig bra utan. Leverantörens egen konsol ger nycklar per projekt, förbrukningssiffror och kostnadsgränser, och det räcker ofta för en pilot. En gateway börjar löna sig när det finns flera applikationer eller team, mer än en leverantör, kunder vars förbrukning måste hållas isär eller krav på var datan behandlas. Den är ännu en komponent att driva, så den ska lösa ett problem ni har.
Så gör ModelHarbour
ModelHarbour är Anno Ones egen AI-gateway. Kunden behåller avtalet och fakturan hos OpenAI, Anthropic eller Azure, och nycklarna lagras krypterade och används bara av en minimal relay-tjänst. Den har en OpenAI-kompatibel endpoint med streaming, modellalias, fallback-kedjor och svarscache. Budgettak, rate limits och en webhook varnar när en budget närmar sig taket, tillsammans med ett hårt tak satt hos leverantören. Projekt i EU-läge får bara använda EU-endpoints, och plattformen körs själv i EU. Att bygga in AI i era egna processer beskrivs under AI och automation.