AWS gjør LLM-drift målbar før agentene tar av

AWS har publisert en ny teknisk modell for hvordan store språkmodeller bør overvåkes når de kjøres i produksjon på Amazon SageMaker AI. Poenget er enkelt, men viktig: Det holder ikke lenger å måle oppetid, latency og feilkoder. En LLM kan være teknisk frisk og samtidig levere svakere, dyrere eller mer risikable svar enn i går.

I innlegget viser AWS en observability-stack for LLM-inferens der to typer signaler samles i samme styringsbilde. Den ene siden er klassisk drift: forespørsler, latency, feilrate, GPU- og CPU-bruk, minne, skalering og kostnad per modell. Den andre siden er kvalitet: relevans, sikkerhet, faglig tone, evalueringslatency og samlede kvalitetspoeng.

Dette er ikke en liten detalj for plattformteam. Det er et tegn på at enterprise-AI går inn i en ny fase. Mange virksomheter har allerede brukt måneder på piloter, Copilot-varianter og interne chatløsninger. Neste runde handler om arbeidsflyter, agenter og modeller som påvirker kundedialog, saksbehandling, utvikling og operasjonelle beslutninger. Da blir spørsmålet ikke bare om modellen svarer. Spørsmålet er om den svarer riktig nok, billig nok og stabilt nok til at virksomheten tør å bygge prosesser rundt den.

AWS beskriver løsningen med SageMaker AI-endepunkter og inference components som vertslag for flere modeller på delt infrastruktur. Hver modell kan få egne målinger, egen trafikkstyring og egne skaleringsregler. Amazon CloudWatch brukes som sentral målelager, mens Amazon Managed Grafana samler drifts- og kvalitetsdata i dashboards. Enhanced metrics fra SageMaker gir per-modell og per-GPU-innsyn. Egne kvalitetsmålinger kan publiseres til en separat CloudWatch-namespace.

Det siste er den strategiske biten. Mange bedrifter har overvåket AI som om det var et vanlig API. Det fungerer dårlig. Et vanlig API feiler gjerne med 500-feil, timeout eller feil responstid. En språkmodell kan feile mykere. Den kan bli mindre relevant fordi promptene endrer seg. Den kan gi mer usikre svar etter at brukeradferden flytter seg. Den kan være dyrere enn planlagt fordi tokenforbruket øker. Den kan fortsatt se grønn ut i tradisjonell driftsovervåking.

AWS peker derfor på to kontrollnivåer som må bygges sammen. Først må teknologimiljøene vite om GPU-ene er under- eller overutnyttet, hvilke modeller som driver kostnad, og om autoskalering faktisk virker. Deretter må produkt-, risiko- og governance-miljøene vite om kvaliteten holder seg over definerte terskler. I eksempelet vises målinger for composite quality score, safety score, relevance score og professional tone score. Kvaliteten vurderes blant annet med LLM-as-judge-mønster og evalueringsrubrikker.

For norske CIO-er og CISO-er er konsekvensen praktisk. AI-plattformen må inn i samme styringsregime som annen kritisk infrastruktur, men med nye mål. Det betyr budsjetter på modellnivå, ikke bare skyregning på konto. Det betyr SLA-er som dekker kvalitet og sikkerhet, ikke bare tilgjengelighet. Det betyr alarmer som kan varsle når en modell begynner å svare dårligere, ikke bare når endepunktet går ned.

Dette blir særlig viktig når agenter tar mer av arbeidsflyten. En agent som gjør ett oppslag og skriver et sammendrag kan tolerere noe manuell kontroll. En agent som oppdaterer CRM, starter bestillinger, prioriterer saker eller foreslår sikkerhetstiltak må kunne måles gjennom hele løpet. Hvis modellen bak blir tregere, dyrere eller svakere, må virksomheten oppdage det før feilen blir en kundesak eller en revisjonsmerknad.

AWS-innlegget er også et signal om leverandørmodning. Skyaktørene forsøker nå å flytte AI-drift fra utviklernotebooks og enkeltstående API-kall til porteføljestyring. Det passer godt med presset fra økonomi og risikostyring. Styrene spør hva AI koster. CISO spør hvor feilene oppdages. CIO spør om organisasjonen kan skalere uten å lage en ny jungel av modeller, dashboards og manuelle sjekklister.

Den korte anbefalingen er å behandle LLM-observability som en plattformkapabilitet, ikke som et prosjektvedlegg. Start med tre spørsmål: Hvilke modeller kjører i produksjon, hvem eier kvalitetsmålet, og hvor raskt oppdages avvik? Hvis svaret ligger i Slack-tråder, regneark eller tilfeldige tester, er AI-driften fortsatt umoden.

Dette er ikke bare en AWS-sak. Samme mønster gjelder uansett om modellene kjøres i SageMaker, Bedrock, Azure, Vertex AI eller egne Kubernetes-miljøer. De som får kontroll på målingene tidlig, får bedre forhandlingsposisjon mot leverandører, bedre kostnadsstyring og færre overraskelser når agentene flyttes fra pilot til linjedrift.

Kilder og medier

Primærkilde: AWS Machine Learning Blog, «Comprehensive observability for Amazon SageMaker AI LLM inference: From GPU utilization to LLM quality», publisert 29. mai 2026: https://aws.amazon.com/blogs/machine-learning/comprehensive-observability-for-amazon-sagemaker-ai-llm-inference-from-gpu-utilization-to-llm-quality/

Kildekreditering: AWS Machine Learning Blog / Amazon Web Services.

Thumbnail: OpenAI Image 2 / hogby.ai