Vi har ägnat det senaste decenniet åt att bygga upp hela finops-avdelningar enbart för att kunna tyda vad molnfakturan egentligen innebar. Precis när vi hade lärt oss att sluta låta overksamma beräkningsinstanser stå påslagna införde generativ AI ett oändligt mycket mer ogenomskinligt och snabbföränderligt utgiftslager.
Chocken över AI-kostnaderna har spridit sig som en långsam orkan över hela branschen. Bortsett från den kraftiga kostnadsökningen för stora språkmodeller (LLM) är det djupare arkitektoniska problemet tillskrivningen: vart går pengarna egentligen, och exakt vilket värde tillför de verksamheten?
När API-anrop är inbäddade i lager av automatiserade agenter och promptmallar blir din applikation en svart låda som förbrukar kapital för att generera tokens. Om en funktionsmotor bränner tusentals dollar i månaden bara för att få en LLM att spotta ut artigheter eller bearbeta data av lågt värde, är det inte innovation – det är en öppen brunnslock, en gapande skuld. Arkitektonisk mognad innebär att man behandlar tokens som vilken annan begränsad resurs som helst.
Lyckligtvis finns det några bra verktyg vi kan använda för att kontrollera AI-utgifterna. Här är de fem viktigaste verktygen för att tämja odjuret.
Modellrouting
Använd inte en spikpistol om en häftstift räcker.
De mest kraftfulla modellerna, som den senaste Claude Opus, är några av de mest sofistikerade mjukvarusystemen som någonsin har byggts. De klarar av extremt komplexa och subtila användningsfall. De är också glupska odjur när det gäller beräkningskraft (och därmed kostnader). De är ofta överdimensionerade.
Vi börjar naturligtvis med den mest kraftfulla modellen vi har när vi prototyper och skissar på API:er och krav. Det beror på att vi befinner oss i ”få det att fungera”-läget och inte vill brottas med modellens begränsningar. Men för produktion är det absolut nödvändigt att hitta den minst kraftfulla modellen vi kan använda.
Ibland kan vi lösa detta genom att finjustera modellvalet och manuellt ta reda på vad som fungerar. Men i större företagsarkitekturer kan vi övergå till ett villkorligt routningslager. Ramverk som RouteLLM eller Semantic Router kan dynamiskt dirigera enkel klassificering, grundläggande textanalys och detektering av användarintentioner till snabba och billiga verktygsmodeller som GPT-4o mini eller Claude 3 Haiku.
Du kan också använda avancerade AI-gateways för dirigering och kostnadsfördelning. På infrastrukturnivå ger det dig fullständig kontroll att integrera denna logik i en dedikerad AI-API-gateway (som Kong, Cloudflare AI Gateway eller Portkey). En mogen gateway gör det möjligt att implementera ”kaskadrouting” för att automatiskt gå över till en billigare eller öppen källkodsmodell om din primära LLM når begränsningar i antal förfrågningar eller drabbas av latensspikar. Ännu viktigare är att en AI-API-gateway centraliserar din telemetri och tar bort ”svarta lådan”, så att du kan tillämpa fasta tokenbudgetar per användare eller per mikrotjänst. I grund och botten bygger du en lastbalanserare för kognitiva uppgifter.
Naturligtvis medför AI-gateways också ytterligare komplexitet och kostnader, och dessa faktorer måste vägas in i ekvationen. Men i slutändan finns det en modell som är rätt dimensionerad för just ditt projekt. Du kan spara en hel del genom att dirigera förfrågningar till en modell som är tillräckligt bra.
En sidokommentar: En annan trend inom modelldirigering är ”återföring av beräkningsresurser”. Det innebär att man kör modeller (ofta open source-modeller) på lokal hårdvara, istället för att hyra generativa AI-ändpunkter i molnet. Detta medför alla avvägningar och fördelar som gäller för andra lokala alternativ.
Semantisk cachelagring
I konventionella webbappar är cachning ett löst problem. Man placerar Redis framför databasen, kopplar en exakt sökfråga till en cachelagrad datamängd, och så är det klart. Men stora språkmodeller bryter mot traditionell cachelagring eftersom mänskligt språk är oändligt varierande. ”Hur återställer jag mitt lösenord?” och ”Jag har glömt mina inloggningsuppgifter” är helt olika strängar, men förmedlar identiska avsikter.
Om du förlitar dig på alltför exakt matchning kommer din träff-frekvens i praktiken att vara noll, och du kommer att betala det fulla tokenpriset för varje variant av formuleringen.
Här kommer semantisk cachning in. Det är som ett reguljärt uttryck för betydelse. Istället för att hasha den råa textsträngen kör du den inkommande prompten genom en snabb inbäddningsmodell och gör en likhetssökning mot tidigare besvarade prompter. Du definierar en konfidensgräns (till exempel 0,92), och om den uppfylls levererar du det cachade svaret (och kringgår därmed LLM och dess kostnad helt).
Effekten på arkitekturen är tvåfaldig. För det första minskar en träff i den semantiska cachen din inferenskostnad för den frågan till exakt noll. För det andra minskar svarets latens från sekunder till millisekunder. Du kan implementera detta med hjälp av specialbyggda ramverk som GPTCache, eller, om du föredrar en smalare infrastruktur, genom att använda pgvector i din befintliga PostgreSQL-databas för att lagra och matcha inbäddningarna.
Precis som dynamisk routning kräver dock semantisk cachelagring en noggrann arkitektonisk avvägning. Du byter genereringskostnader för inbäddningar mot sökkostnader. För att kontrollera cachen måste du fortfarande tokenisera prompten, anropa en kostnadseffektiv modell (som text-embedding-3-small) och utföra en vektorsökning.
Du riskerar också den mycket påtagliga faran med semantisk utplåning. Att finjustera likhetströskeln är en känslig konst. Ställer du in den för lågt börjar din applikation leverera allmänna, återanvända svar på nyanserade användarfrågor. För öppna, kreativa och generativa AI-applikationer är semantisk cachning praktiskt taget värdelös. Men för implementeringar av RAG (Retrieval-Augmented Generation), kundsupportbotar och interna kunskapsbaser där användarna ställer samma 20 frågor på tusen olika sätt är det den mest effektiva kostnadsbesparande åtgärden du kan vidta.
Promptcachning
Semantisk cachning lagrar svaret på en given avsikt. Promptcachning lagrar den data som behövs för att sätta frågan i sitt sammanhang. När användaren matar in en prompt skickas den till den generativa AI-ändpunkten. Men istället för att din applikation upprepade gånger måste samla in och skicka den omfattande kontextinformationen som behövs för att sätta in prompten i sitt sammanhang – från en RAG-pipeline, en databas eller annan källa – finns den informationen redan laddad i kontextcachen. Modellen tillämpar helt enkelt den nya frågan på de cachade uppgifterna, vilket drastiskt minskar både din latens och dina inmatningskostnader.
Kärnidén bakom promptcachning är att AI-motorn själv behåller de relevanta kontextuella uppgifterna för inkommande promptar. Tokens som cachas på detta sätt får en enorm rabatt (50-90 procent) jämfört med råa inmatningstokens. Men detaljerna kring hur detta hanteras varierar mellan olika leverantörer.
För Open AI sker promptcachning automatiskt, men det krävs att du är uppmärksam på hur din app använder slutpunkterna för att kunna dra nytta av dem. Open AI tillämpar en lägsta tröskel på 1 024 token. Ännu viktigare är att det krävs en exakt prefixmatchning, byte för byte, med start från token noll. Om du infogar en dynamisk variabel (som en tidsstämpel eller ett användar-ID) högst upp i dina systeminstruktioner, ogiltigförklarar du omedelbart cachen och får betala fullt pris för varje token som följer.
Vissa andra leverantörer, som Anthropic Claude och Google Gemini, använder explicit cachelagring. Du måste medvetet bygga in cachen i din arkitektur, antingen genom att anropa en dedikerad API-ändpunkt för att ladda upp det statiska dokumentet (kontextdata) med en definierad livslängd, eller genom att infoga strikta brytpunkter för cachekontroll i din JSON-payload. Explicit cachelagring kräver ofta att man betalar en ”skrivpremie” i förskott, men det gör att du kan hålla dina tunga RAG-data aktiva i minnet i timmar istället för minuter.
Promptdisciplin och omrankning
Bara för att en modell kan hantera enorma mängder token betyder det inte att den bör göra det.
Eftersom modellerna nu kan ta emot en till två miljoner tokens i en enda prompt finns det en frestelse att med brute force-metoder tvinga användningsfall till underkastelse genom att dumpa hela PDF-filen, hela kodbasen eller de senaste tre årens loggar i datapaketet och låta LLM sortera ut det.
Detta är ett finops-misstag. Du betalar för varje enskild token du skickar. Dessutom, ur ett tekniskt perspektiv, leder överfyllning av kontextfönstret till det mycket reella ”muddy middle”-problemet (även kallat ”context rot”), där modellen tappar upplösningen i mitten av innehållet. När datamängden växer försämras prestanda och noggrannhet.
Lösningen är en strikt RAG-diet. Naiva RAG-implementeringar kan hämta de 20 bästa resultaten från en vektordatabas och blint sammanfoga dem i prompten. En mogen arkitektur kräver en mer skoningslös filtreringsprocess innan dessa tokens någonsin når den kostsamma LLM:en.
Det är här omrankning blir avgörande. Omrankning tar det sammanställda promptkontexten och ser till att det är effektivt strukturerat innan det når LLM:en. Istället för att skicka råa sökresultat direkt till din primära modell inför du en liten, högeffektiv korskodare (som Cohere Rerank eller en öppen källkods-BGE-modell). Du kastar ut ett brett nät i din billiga vektordatabas för att hämta 50 potentiella träffar, och skickar dem sedan vidare till omrankaren för att bedöma deras faktiska relevans mot användarens specifika prompt. Omrankaren skär bort allt överflödigt på ett skoningslöst sätt, vilket gör att du endast skickar de tre eller fyra mest relevanta delarna vidare till den kostsamma frontier-modellen.
Kort sagt byter du ut en massiv, dyr LLM-kontextbelastning mot ett litet, billigt omrankingssteg. Den arkitektoniska matematiken här är nästan alltid en övertygande vinst. Även om en cross-encoder kan lägga till 100 millisekunder i latens till pipelinen, minskar den rutinmässigt antalet prompt-tokens med 80 procent eller mer, samtidigt som den ökar noggrannheten i den slutliga genereringen. I strategin för generativ AI är att ge din LLM mindre att läsa en av de åtgärder som ger störst avkastning.
Begränsningar i svaren
Som standard är LLM:er artiga, konversationsinriktade och ordrika. Om du ber en modell om data vill den desperat börja med ”Självklart! Här är den JSON du begärde” och avsluta med ”Hör gärna av dig om du behöver något mer!”
I ett webbgränssnitt är detta charmigt. I en applikations API-arkitektur är det en läcka i finops-skrovet. Genereringstokens (utdata) prissätts nästan alltid 3 till 5 gånger högre än prompttokens (indata). Varje artighet förbrukar din dyraste resurs.
För att tygla LLM-svar krävs strikt tillämpning på API-nivå. För det första måste max_tokens behandlas som en hård brytare för att förhindra okontrollerade genereringsloopar, inte som ett formateringsverktyg. (Att förlita sig på max_tokens för att förkorta svar resulterar ofta bara i avkortad, oanalyserbara JSON.) För det andra, använd stoppsekvenser (stop_words). Om din modell endast behöver generera en SQL-fråga tvingar inställningen av en stoppsekvens för Markdown-slutetiketten (“`) eller ordet ”Explanation:” modellen att bryta anslutningen så fort beräkningsarbetet är klart.
Moderna API:er erbjuder också strukturerade utdata (eller strikt JSON-läge), vilket tvingar modellen att följa ett fast schema som du definierar. Genom att kombinera detta med systemprompter med nolltolerans (”Leverera ENDAST giltig JSON. Utelämna all konversationstext och artigheter. Underlåtenhet att göra detta kommer att förstöra systemet”) tvingar du LLM:en att bete sig som en traditionell API-ändpunkt snarare än en chattbot.
Balansen i arkitekturen här ligger i att undvika att försämra modellens resonemangsförmåga genom att strikt begränsa dess indata. LLM:er har inget internt arbetsminne, de ”tänker” genom att iterera över tokenutdata. Om du tvingar en modell att lösa ett komplext logiskt problem och mata ut ett enda booleskt värde (sant eller falskt) utan att ge den utrymme att först resonera, kommer dess noggrannhet att sjunka drastiskt. Målet med finops är egentligen inte att tvinga fram ett minimalt antal ord; det är att säkerställa att varje resurskrävande utdatatoken utför faktiskt beräkningsarbete (som resonemang i tankekedjor).
Att effektivt utnyttja generativ AI för att tillgodose användarnas behov är den första utmaningen. Den andra är att se till att ekonomin inte undergräver det hårda arbetet. De fem nycklarna som diskuteras här bör ge dig alla verktyg du behöver för att säkerställa att tekniken och kostnadskontrollen samverkar.