Databricks viser hvor skjør LLM-inferens blir i stor skala

Databricks har publisert en teknisk gjennomgang av LLM-inferens i stor skala. Den er verdt å lese som en driftsrapport, ikke som en leverandørblogg.

Hovedpoenget er enkelt: når språkmodeller flyttes fra piloter til produksjon, blir inferens en kritisk tjeneste. Den må tåle lasttopper, modellfeil, køer, timeouts, kostnadspress og krav til svartid. Det holder ikke at modellen svarer pent i en test.

Databricks peker på tre områder: lastbalansering, robusthet i inferenslaget og ytelsesoptimalisering. Det er klassisk plattformarbeid. Forskjellen er at nyttelasten er dyr, treg og probabilistisk.

LLM-er trenger SRE, ikke bare prompts

Mange AI-prosjekter feiler ikke fordi modellen er for svak. De feiler fordi tjenesten rundt modellen er for svak.

En chatbot som stopper i demo er irriterende. En agent som stopper midt i en kundereise, et saksbehandlingsløp eller en intern kodeprosess, skaper reell driftsrisiko. Hvis virksomheten ikke vet om problemet skyldes modellkapasitet, rate limits, dårlig ruting, overbelastet GPU, en treg embedding-tjeneste eller et tredjeparts-API, blir feilsøking fort teater.

Derfor må LLM-inferens behandles som en produksjonsplattform. Den trenger SLO-er, målinger, retry-regler, fallbacks, kostnadstak og klare eskaleringsløp.

En enkel labtest bør måle mer enn kvalitet på svar:

for concurrency in 1 10 50 100; do
  run_eval           --model production-router           --requests 1000           --concurrency $concurrency           --measure p50,p95,p99,error_rate,cost_per_1k
done

Hvis testen bare ender med en gjennomsnittlig svartid, er den for svak. Ledelsen trenger p95 og p99, feilandeler, kostnad per oppgave og hva som skjer når én modell eller region ikke svarer.

Ruting blir et styringsspørsmål

Når flere modeller, regioner og kapasitetsklasser brukes samtidig, blir ruting en del av risikostyringen.

Hvilke oppgaver kan sendes til en billigere modell? Hvilke krever sterkere modell og bedre logging? Når skal systemet degradere til en enklere flyt i stedet for å vente? Når skal en bruker få beskjed om at handlingen må godkjennes eller kjøres senere?

Dette er ikke bare tekniske valg. Det påvirker kundeopplevelse, compliance, kostnader og sikkerhet.

For CIO-er og plattformteam betyr Databricks-innlegget at AI-infrastruktur må budsjetteres som en varig driftsflate. Det er ikke nok å kjøpe tilgang til en modell. Man må bygge eller kjøpe kontrollplanet rundt bruken.

FinOps møter modellkvalitet

LLM-inferens har en ubehagelig egenskap: bedre svar koster ofte mer, men billigere svar kan skape skjult etterarbeid.

Derfor bør FinOps ikke bare måle tokenkostnad. Den bør måle kostnad per løst oppgave, per godkjent agenthandling og per kundesak uten manuell eskalering. En billig modell som dobler behovet for kontroll, er ikke billig.

Det samme gjelder robusthet. En fallback til en mindre modell kan være riktig for oppsummering, men feil for juridisk vurdering, kodeendring eller sikkerhetshendelser. Ruting må forstå kontekst, ikke bare trafikk.

Den praktiske lærdommen

Databricks skriver for et teknisk publikum, men lederlærdommen er bredere: AI-produksjon er drift.

Organisasjoner som vil bruke agenter og LLM-er i kjerneprosesser, må spørre om de har en inferensplattform som tåler misbruk, feil, kostnadssjokk og trafikkøkning. De må kunne forklare hvem som eier oppetid, hvem som eier modellvalg, og hvem som kan stoppe en dyr eller risikabel flyt.

Den neste bølgen av AI-prosjekter vil ikke vinnes av dem med flest demoer. Den vil vinnes av dem som gjør modellbruk kjedelig, målbart og robust.

Kilder og medier

• Primærkilde: Databricks, "Reliable LLM Inference at Scale", publisert 27. mai 2026: https://www.databricks.com/blog/reliable-llm-inference-scale
• Databricks beskriver lastbalansering, inferensrobusthet og ytelsesoptimalisering som nødvendige deler av produksjonsklar LLM-infrastruktur.
• Thumbnail: OpenAI Image 2 / hogby.ai via Codex OAuth.