Regningen efter byggeriet: Hvad et AI-system reelt koster at drive

De fleste AI-budgetter stopper ved lanceringen. Tilbuddet dækker afdækning, udvikling, integration og en dato for idriftsættelse. Så kører systemet i to år, og ingen har skrevet ned, hvad de to år koster. Her er, hvad der faktisk lander på fakturaen.

Modelregningen er den del, du kan regne ud

Modelomkostninger afregnes per token — groft sagt per ord ind og per ord ud. Det gør dem forudsigelige, hvis du laver regnestykket én gang.

Tag en intern supportassistent, der håndterer 8.000 samtaler om måneden med seks turveksler hver. Det er 48.000 kald til modellen. Hvert kald bærer dine instruktioner, de fremsøgte dokumenter og samtalen indtil videre — lad os sige 5.000 tokens ind — og returnerer omkring 400 tokens ud. Du køber 240 millioner input-tokens og 19 millioner output-tokens om måneden. Til priser for en model i mellemklassen lander det tæt på 1.000 dollars om måneden, og prompt-caching af de gentagne instruktioner kan skære mærkbart i beløbet.

To ting overrasker folk. For det første dominerer input: du betaler for alt, hvad du sender, i hver turveksel, og lang kontekst er den vigtigste omkostningsknap, du selv kan dreje på. For det andet lægger genforsøg, evalueringskørsler og intern test 15-30 % oven i produktionstrafikken. Budgettér med bruttotallet, ikke det pæne.

Modelpriserne per token er faldet støt. Det samlede forbrug stiger som regel alligevel, fordi brugen vokser, og fordi nyere modeller bliver taget i brug til de sværere opgaver. Planlæg efter mængde, ikke efter takster.

De regninger, ingen skrev ind i tilbuddet

Modelomkostninger er sjældent den største post. Resten af driftsomkostningen er almindeligt driftsarbejde, som AI-systemer bare har brug for mere af:

• Menneskelig kontrol. Nogen læser en stikprøve af rigtige svar hver uge og vurderer, om kvaliteten holder. For et kundevendt system skal du regne med nogle få timer om ugen, permanent.
• Infrastruktur omkring modellen. Søgeindekser, vektordatabaser, logning og den pipeline, der holder jeres dokumenter opdaterede. Beskedent hver for sig, konstant tilsammen.
• Ændringsarbejde. Nye produkter, nye politikker, nye grænsetilfælde, som systemet håndterer dårligt. Forvent en lille, jævn strøm af justeringer frem for enkelte store releases.
• Ændringer hos leverandøren. Modeller udfases efter offentliggjorte tidsplaner. At migrere til en efterfølger betyder at teste alt det igennem igen, som den gamle var god til — typisk en gang om året.
• Compliance og dokumentation. Opbevaring, adgangsstyring og det revisionsspor, der kan dokumentere, hvad systemet fortalte en kunde i marts.

Kvalitetsforringelse er den post, der overrasker folk

Software fejler højlydt. AI-systemer forringes stille og roligt, og de lyder overbeviste hele vejen ned.

Din forretning ændrer sig først. Priser ændres, et produkt udgår, en politik bliver skrevet om. Systemet bliver ved med at svare ud fra den version, det fik — flydende og forkert — indtil nogen opdager det.

Så ændrer dine brugere sig. Når folk har lært, hvad systemet kan håndtere, skubber de ind i tilstødende områder, det aldrig blev skruet sammen til. Trafik, der lignede besvarelse af typiske spørgsmål, bliver til fortolkning af kontrakter, og den præcision, du målte ved lanceringen, beskriver ikke længere det, der foregår.

Dit indhold ændrer sig også. Fremsøgning, der virkede på tværs af 400 dokumenter, bliver vagere ved 4.000, fordi flere næsten-træffere skubber det rigtige svar ud af resultaterne.

Intet af det udløser en alarm. Det dukker op måneder senere som flere eskaleringer, faldende brug eller en klage fra en kunde, der handlede på noget, systemet sagde. På det tidspunkt koster rettelsen mere, end overvågningen ville have gjort.

Forsvaret er ustyrligt kedeligt og billigt: udtag 50 til 100 rigtige interaktioner om måneden, bedøm dem op mod, hvad en dygtig medarbejder ville have sagt, og følg scoren over tid. Én person, en halv dag, hver måned. Den ene vane fanger næsten alle fejlmønstrene ovenfor, mens de stadig er små.

Et budget, der overlever mødet med virkeligheden

Regn med en årlig driftsomkostning på 30-50 % af udviklingsomkostningen i de første to år. Under 20 % bliver systemet forsømt, og kvalitetskurven kommer til at vise det. Over 60 % er enten for meget efterladt ufærdigt i udviklingen, eller også er anvendelsen reelt mere ustabil, end den så ud.

Del tallet op i tre puljer: forbrug (modelomkostninger og infrastruktur, som skalerer med mængden), varetagelse (kontrol, overvågning, dokumentation — nogenlunde fast) og forandring (tilpasning til jeres forretning og jeres leverandørs køreplan). Puljerne opfører sig forskelligt, så et enkelt sammenblandet tal vil føre jer på afveje, første gang mængden fordobles.

Udpeg så en ejer. Et AI-system uden en navngiven ejer og en fast budgetlinje bliver ikke vedligeholdt; det bliver tolereret, indtil det stille og roligt bliver opgivet. Det er den reelle omkostning ved at springe denne øvelse over — ikke overforbrug, men at betale for et byggeri to gange.

Regn driftsomkostningen ud før byggeriet, ikke efter. Tallet ændrer ofte, hvad man beslutter sig for at bygge, og det er præcis det, det er til for. Det er den første beregning, vi laver sammen med en kunde, og af og til er det grunden til, at vi anbefaler et mindre system end det, de kom ind og bad om.