Därför ska avtalet och fakturan vara era
När en leverantör eller konsult använder sitt eget konto går er data under deras avtal med AI-leverantören, och kostnaden blir en rad på någon annans faktura. Tar samarbetet slut slutar applikationen att fungera den dag nyckeln dras tillbaka. Med ett eget konto godkänner ni leverantörens villkor direkt, väljer de alternativ för databehandling som erbjuds företagskunder, ser förbrukningen på er egen faktura och kan lämna en nyckel till den som bygger nästa sak. Både OpenAI och Anthropic har API-konton för organisationer, med flera medlemmar och roller.
Där nycklar aldrig ska ligga
En API-nyckel i frontendkod är offentlig. Allt som körs i webbläsaren eller följer med en mobilapp kan läsas av den som tittar, och automatiska skannrar letar hela tiden efter läckta nycklar i öppen kod. Nycklar hör inte heller hemma i repot, inte ens i ett privat repo, eftersom historiken sparas och repon kopieras, delas och görs publika av misstag. Detsamma gäller chattmeddelanden, ärenden och delade dokument. En nyckel som hamnat på något av de ställena ska återkallas och ersättas, inte bara tas bort ur filen.
Där nycklar ska ligga
Nycklar hör hemma på serversidan, i miljövariabler eller en tjänst för hemligheter, och läses bara av den kod som anropar leverantören. Lokalt betyder det en .env-fil som står i .gitignore, i drift hostingplattformens lagring för hemligheter eller ett eget valv. Varje miljö får en egen nyckel, så att ett testsystem kan stängas av utan att produktionen påverkas. Anropar flera applikationer AI kan en gateway hålla leverantörsnycklarna och dela ut egna nycklar per applikation, som beskrivs i vad en AI-gateway är.
En nyckel per projekt, inte en för allt
Både OpenAI och Anthropic låter er dela upp förbrukningen: OpenAI i projekt och Anthropic i workspaces, var och en med egna nycklar och egna förbrukningssiffror. När varje applikation och miljö har en egen nyckel syns det vad som driver kostnaden, skadan av en läcka begränsas och en nyckel kan återkallas utan att allt annat stannar. Namnge nycklarna efter det som använder dem, skriv ner vem som skapade dem och ta bort nycklar som inte används längre. En enda delad nyckel för hela företaget gör allt det omöjligt.
Kostnadsgränser hos leverantören och i en gateway
Det första skyddet är gränsen ni sätter i leverantörens konsol, för organisationen och, där det erbjuds, per projekt eller workspace. Den är grov men pålitlig, eftersom den gäller oavsett vad som händer i er egen kod. Det andra skyddet är tak närmare applikationen: budgetar per projekt, kund eller funktion, rate limits per nyckel och larm innan en gräns nås. En gateway som ModelHarbour kombinerar båda, med budgettak, rate limits och en webhook när en budget närmar sig taket, plus ett hårt tak satt hos leverantören.
Det här styr vad förbrukningen kostar
Leverantörerna tar betalt per token, de bitar av text som modellerna läser och skriver, med olika priser för indata och utdata, och utdata kostar oftast mer. Valet av modell betyder mest: de största modellerna kan kosta många gånger mer per token än de små, och en liten modell räcker ofta för sortering, extraktion och korta svar. Därefter kommer promptens längd, eftersom en lång systemprompt eller ett stort dokument betalas vid varje anrop. Promptcache sänker priset för indata som upprepas mellan anrop, och batchgränssnitt är billigare för arbete som kan vänta. Aktuella priser står på varje leverantörs prissida.
Följ förbrukningen över tid
Ett plötsligt kostnadshopp brukar komma från en loop, ett omförsök utan gräns, en prompt som har vuxit eller en ny funktion som anropar modellen vid varje sidvisning. Titta i början på förbrukningen per nyckel varje vecka, och jämför det applikationen själv har räknat med det leverantören fakturerar. En skillnad mellan de två är den tidigaste signalen om att något anropar modellen utanför er kontroll.