Dette er andre del av serien om Databricks-kostnader. Har du ikke lest første del, som handler om kostnadsmodell, systemtabeller og tagging, kan det være en fin start.

Hva er nytt med AI?

Prinsippene fra del 1 gjelder fortsatt: kostnaden følger faktisk forbruk, og systemtabeller og tags viser hva som driver regningen. AI gir likevel tre nye utfordringer:

• Forbruket måles i tokens, og prisen varierer mye mellom modeller.
• En del av kostnaden faktureres av eksterne leverandører.
• Agenter kan skape mye forbruk på kort tid.

Databricks beskriver eksponentielt voksende kostnader som et problem nesten alle møter når AI-verktøy tas i bruk i stor skala.

Unity Gateway og Unity Catalog

Unity Catalog håndterer identitet, tilganger, lineage og revisjon for data og AI-ressurser. Unity Gateway håndhever kontrollene når AI faktisk brukes. Alle AI-kall går gjennom gatewayen. Hver tjeneste er et objekt i katalogen og har et fullt navn på formen catalog.schema.modelservice

Det betyr at tilgang til modeller styres på samme måte som tilgang til tabeller. AI-kostnadene havner i de samme systemtabellene som ble beskrevet i del 1.

1. Oversikt over hvor pengene går

Modeller i Databricks. Gatewayen beriker system.billing.usage med tjenestenavn, modellen som faktisk svarte, brukeren eller service principalen som sendte kallet, og tjenestens tags.

Eksterne leverandører. Her finnes et estimat i dollar per time i system.aigateway.external_model_spend. Estimatet bygger på tokenforbruk og leverandørens publiserte priser og kan justeres med en prismultiplikator. Som med list_prices i del 1 er dette et estimat og ikke fakturaen. For leverandørtypen Custom beregnes det ikke noe estimat.

Kostnadsfordeling. I tillegg til tjeneste-tags kan request tags gi fordeling helt ned på applikasjon eller funksjon.

2. Riktig modell for oppgaven

I del 1 var et poeng at det lønner seg å optimalisere kostnaden for hele workloaden, ikke bare prisen på ressursen. For AI handler det om kostnad per oppgave, ikke per token.

Trafikkfordeling. En tjeneste kan fordeles på opptil fem modeller med vekter, noe som gir mulighet for A/B-testing og gradvis utrulling. Klientene kan fortsette å kalle det samme tjenestenavnet.

Smart Routing. Funksjonen velger automatisk den rimeligste modellen som klarer oppgaven. I Databricks’ interne tester kostet den omtrent 65 % av det en ledende modell som Opus 5 koster per oppgave. På offentlige benchmarks var besparelsen 56 %. Det er verdt å kjenne til at funksjonen bare støtter system.ai-tjenester, og at den i Claude Code og Codex forutsetter CLI-en ug.

Nye modeller. En nyere modell er ikke alltid et bedre kjøp. Stripe valgte for eksempel bort Opus 4.7, fordi kvaliteten knapt økte mens kostnaden steg. Det kan derfor lønne seg å teste modeller før de rulles ut.

3. Forbruk innenfor rammene

Grenser. Det er mulig å sette grenser for forespørsler (QPM) og tokens (TPM) per minutt for tjeneste, bruker og gruppe. Ved overskridelse returneres HTTP 429.

Budsjetter. Månedlige terskler kan settes felles, per bruker og med individuelle unntak. Ved hver terskel kan man velge varsling, blokkering eller begge deler (kostnadsstyring).

Nedgradering fremfor stopp. Erfaringer fra store virksomheter viser at harde stopp sjelden fungerer godt som hovedverktøy, fordi de går ut over produktiviteten. Et alternativ er smart defaults, som anbefaler en rimeligere agent og modell når en gitt andel av budsjettet er brukt.

Tidsforsinkelse. Budsjettene bygger på estimater i nær sanntid, og forespørsler som allerede er i gang, får fullføre. Forbruket kan derfor gå noe over terskelen. Til sammenligning kommer usage-poster normalt innen omtrent 12 timer. Det kan derfor være lurt å legge varslingsterskelen godt under blokkeringsterskelen.

4. Færre skjulte tokens

Brukerens egen forespørsel utgjør bare en liten del av det som sendes til modellen. Det er konteksten agenten henter inn selv som driver kostnaden.

Med gatewayen kan kodeagentenes modeller, MCP-servere, skills og kostnadspolicyer konfigureres sentralt, og sporinger med verktøykall samles inn. Hos Databricks ga tuning av agent- og cache-innstillinger nesten 50 % færre genererte tokens, uten tap av kvalitet.

Hvordan komme i gang

En mulig rekkefølge kan være:

1. All AI-trafikk samles i gatewayen, og tjenestene tagges etter samme skjema som i del 1.
2. De dyreste kombinasjonene av tjeneste og modell identifiseres i Cost Analysis-dashbordet.
3. TPM-grenser og månedsbudsjetter settes opp med varsling og smart defaults.
4. En rimeligere modell A/B-testes på den dyreste tjenesten, og Smart Routing tas i bruk for kodeagenter.

Vil du lese mer?

• Del 1: Hva koster egentlig Databricks og hvordan får du kontroll?
• Analyze Unity Gateway cost – systemtabeller, eksterne estimater og SQL-eksempler.
• Control spending – budsjetter, smart defaults og Smart Routing.
• Apply rate limits – nivåer og prioritetsregler.
• Managing AI Coding Costs at Scale – erfaringer fra Databricks, Stripe, Coinbase, Uber og Ramp.