AWS ruller en markant udvidelse af observability ud i SageMaker for generative AI: over 100 nye, detaljerede inference-metrics og et SageMaker Insights-dashboard direkte i CloudWatch. Det lyder tørt, men er reelt forskellen på at stirre på en flad “model latency”-kurve og at se, hvor kø, GPU eller cache faktisk knækker. Kilden er AWS’ egen gennemgang af funktionaliteten og real-time-dokumentationen for endpoints, som begge peger på, at drift af LLM i produktion får et gear mere for dem, der bruger SageMaker.
Hvorfor betyder det noget nu? Fordi mange slås med P99-spikes, der rammer uden varsel, og hvor årsagen ligger et par lag nede. AWS’ blog nævner de sædvanlige syndere: GPU memory pressure, en mættet KV-cache, skæv trafik på tværs af Availability Zones eller en autoscaling-politik, der ikke nåede at reagere. Med nye metrics og et samlet Insights-dashboard i CloudWatch bliver det lettere at skelne mellem de scenarier på minutter i stedet for timer. Det er i hvert fald målet.
Hurtig faktasammenfatning
SageMaker tilbyder fuldt managed real-time hosting af ML-modeller og håndterer klargøring og skalering af endpoints. Det er dokumenteret i både blogindlægget og real-time-endpoint-dokumentationen. Endpoints udsender standardmetrics til CloudWatch som invocation counts, model latency og overhead latency. Nyt er dybden og bredden: AWS beskriver 100+ detaljerede metrics, et indbygget SageMaker Insights-dashboard i CloudWatch og to særligt relevante endpoint-arkitekturer for generativ AI: single-model endpoints (SME) og inference component (IC) endpoints.
IC fremhæves som det anbefalede valg i produktion for LLM-workloads, fordi man kan dele GPU-ressourcer på tværs af flere modeller, skalere uafhængigt pr. model og få høj tilgængelighed via kopier fordelt på tværs af AZs. Dokumentationen for real-time endpoints bekræfter autoscaling-understøttelsen og muligheden for enhanced metrics ned på instans- og container-niveau.
Hvad er nyt konkret
Ifølge AWS omfatter de nye metrics blandt andet GPU-sundhed, latency på token-niveau, pres på KV-cachen, trafikfordeling på tværs af Availability Zones, placering af inference components og cold-start-diagnostik. Det rammer netop de blinde vinkler, der gør fejlsøgning tung. Tokenvis latency viser, om forsinkelsen kommer ved de første tokens eller i halen. KV-cache-metrics gør det nemmere at fange, når kontekster fylder mere end planlagt, og cachen mister hitrate. Cold starts kan spores mere konkret end “det føltes langsomt her”.
Metrics leveres til CloudWatch via OpenTelemetry, og SageMaker Insights ligger som et forudbygget dashboard i CloudWatch-konsollen. AWS beskriver, at dashboardet bruger PromQL-forespørgsler over de nye målinger og viser oversigter på tre faner: Performance, Capacity og Reliability.
Arkitekturvalg får ny betydning
Single-model endpoints er simple: én model, én flåde af GPU-instanser. Nemme at forstå, men dyrere, når antallet af modeller vokser. Inference component-arkitekturen samler flere modeller på den samme instansflåde, men som hver deres “component” med egne ressourcekrav og egen skalering. Det er mønsteret, AWS anbefaler til produktion af generativ AI, for at bruge GPU’er bedre og undgå at drive en mini-flåde pr. model.
Konsekvenserne for observability er tydelige. Med IC skal man både se helbred for flåden og for hver component. Telemetri skal korreleres per component, ikke kun per endpoint. Routing og versionering spiller også ind: når flere modeller deler pool, kan en uventet belastning på én model trække gennemsnittet ned. Uden handlingsklare metrics på component-niveau famler man. Her lander de nye målinger.
Diagnosecases: P99-spikes og sandsynlige root causes
GPU memory pressure: Når hukommelsen presses, skrider alt. GPU-utilization og -memory-metrics er afgørende, sammen med token-level latency, der afslører, om forsinkelsen vokser lineært med promptstørrelse eller eksploderer ved bestemte længder. Playbook: skær midlertidigt i max prompt length, juster batch-politik, og skaler ud på komponenter, der rammer memory-thresholds. Brug desuden cold-start- og AZ-metrics til at sikre, at problemet ikke skyldes en enkelt zone med for små instanser.
KV-cache mætning: Når hit/miss og cache pressure går skævt, stiger latency ofte i halen. Se efter token-tail-kurver, stigende queue-depth per component og lavere cache-hit. Playbook: reducer kontekstlængde for hotspots, juster cache-eviction i applikationslaget, og skaler den specifikke component lodret eller vandret. AWS lover ikke automatisk eviction-styring; det kræver applikationslogik.
Ubalanceret AZ-trafik: Trafikken kan lande skævt i enkelte zoner. AZ-fordelingsmetrics og fejltyper for insufficient capacity hjælper. Playbook: genbalancér routing, sæt strammere max concurrency pr. AZ, og valider, at copy distribution faktisk er indlæst som planlagt. Hvis en AZ snævrer, kan P99 stikke af uden at den samlede flåde ser presset ud.
Autoscaling ikke trigget: Hvis skalering reagerer sent, vil queue-depth og per-component latency stige, uden at GPU’en nødvendigvis ser udsolgt ud med det samme. Playbook: sænk thresholds for relevante komponenter, forkort cooldown, og brug signaler tættere på token-latency i stedet for rå CPU/GPU. Dokumentationen bekræfter, at autoscaling er understøttet, men standardpolitikker kræver tuning til LLM-bursts.
Praktisk implementering: sådan får du det ind i driften
Aktivér detailed observability på nye og eksisterende endpoints via de trin, AWS beskriver i blogindlægget, og brug Insights-dashboardet som første kontrolpunkt. Forbind derefter CloudWatch til eksisterende observability via PromQL-kompatibilitet. Mange teams kan genbruge Grafana-opsætninger, men vær opmærksom på, at metriknavne, labels og sample-rater sjældent er 1:1 med egne standarder – der kræves mapping og test.
Metrikkerne du skal fokusere på først
Token-level tail-latency: vigtigste indikator for brugeroplevelse og P99-afvigelser – den skal alarmeres, ikke kun plottes. Per-instance GPU-utilization og GPU memory pressure: skiller compute-flaskehals fra hukommelsesknas. KV-cache hit/miss og pressure: hurtigste vej til at se, om prompts fylder for meget, eller cachen er for snæver. AZ-traffic distribution: afslører skæv belastning, der maskeres i gennemsnittet. Cold-start counts: viser, hvornår ny kapacitet faktisk er varmet op. Queue-depth per inference component: direkte input til autoscaling.
De er valgt, fordi de kan kobles til klare handlinger: skaler komponenten, skift batch-politik, trim kontekst eller rebalance routing. Kombinér dem i samme dashboard og lær deres korrelation at kende.
Alerting og autoscaling: hvad ændrer sig
Bedre metrics ændrer ikke kun observability, men også selve skaleringen. Med IC kan man sætte thresholds pr. komponent i stedet for pr. endpoint. Det reducerer over-skalering på rolige modeller og beskytter de travle. En praktisk tilgang er to lag af alarmer: en hurtig trigger på queue-depth og token-tail for at åbne ekstra kapacitet, og en langsommere på GPU/memory for at fastholde kapacitet, hvis presset varer ved.
Pas på thrashing: for hyppige skaleringshændelser giver fluktuerende omkostninger og ustabil kø. Sæt generøse cooldowns på komponenter, der leverer lange svar. Forudsigende skalering kan være nyttig, men baserer sig på historik, der ofte ændrer sig, når modeller eller prompts skifter. Test i staging med syntetisk last, og mål P95/P99 før og efter justeringer.
Integration med eksisterende observability stacks
AWS skriver, at man kan trække de nye metrics via et PromQL-kompatibelt endpoint i CloudWatch. Det åbner for Grafana og Datadog uden særskilte eksportere. Begrænsningen ligger i detaljerne: det kræver navnemapping, label-validering og forståelse for CloudWatch’ retention og sampling. Pas især på dashboards, der antager sekunders opløsning på alle serier; det kan blive dyrt – og give tomme paneler, hvis kilderne ikke følger samme rytme.
En praktisk vej er at starte med ét “golden dashboard” i Grafana med 10–12 metrikker via PromQL. Udvid derfra. Behold samtidig CloudWatch Insights som kilden til flådens helbred, fordi det allerede grupperer efter Performance, Capacity og Reliability.
Sikkerhed, dataprivatliv og compliance overvejelser
Kilderne beskriver metrics – ikke lagring af prompts eller indhold. Telemetrien handler om ydeevne, ressourceforbrug og infrastrukturadfærd. Teams bør stadig have faste retningslinjer for, hvad der sendes til metrics og logs, især i regulerede miljøer. Adgang til metric-visualiseringer i CloudWatch bør følge produktionsadgange, så kun relevante roller ser driftssignalerne.
Et åbent spørgsmål er multi-tenant-isolering i IC-scenarier. Kilderne går ikke i detaljer om, hvordan man isolerer adgang til component-specifikke metrics på tværs af teams, der deler samme flåde. Det bør håndteres via IAM-politikker og eventuelt miljøopdeling.
Begrænsninger og åbne spørgsmål
Det her løser ikke alt. Der er ikke token-level tracing på tværs af hele applikationslaget i multi-tenant IC som færdig løsning. Der er heller ikke dybere GPU-internals ud over de eksponerede metrics. Og cache-eviction-politikker kræver stadig applikationslogik og test. Blog og dokumentation lover ikke automatisk cache-styring.
Der mangler også uafhængige benchmarks for overhead og præcision. Hvor meget ekstra latency giver fuld detaljemetrics? Hvad koster det i CloudWatch ved høj QPS? Det er ikke belyst i kilderne. Derfor er konservativ udrulning med sampling og selektiv retention fornuftig praksis, indtil egne datapunkter foreligger.
Anbefalinger til trin-for-trin plan
1) Auditér nuværende endpoints: SME vs IC, aktuel autoscaling, nuværende metrics. Sæt mål for P99 og et maksbudget for CloudWatch. 2) Slå detailed observability til i staging på én repræsentativ tjeneste og aktiver SageMaker Insights. Bekræft, at Performance, Capacity og Reliability viser meningsfulde kurver. 3) Kortlist 10–12 kritiske metrics og byg ét operativt dashboard. Tilføj alerts på token tail, queue-depth og AZ-skævhed. 4) Justér autoscaling pr. komponent med klare thresholds og fornuftige cooldowns. Test syntetisk last, og gem resultater. 5) Kør en failover- og AZ-balance-test, så routing og copy distribution ikke først testes ved nedbrud.
Tidsforbrug? For et mellemstort team: 1–2 uger for første tjeneste, 3–5 uger for udrulning til de vigtigste endpoints. Hold det enkelt. For mange paneler dræner opmærksomheden. Og undgå at gemme alt i sekunders opløsning; vælg “golden signals” og mål resten grovere.
Konklusion med perspektiv
Det er et reelt fremskridt for observability i generativ AI på AWS. Ikke en sølvkugle – men en konkret pakke af metrics og et dashboard, der gør klassiske driftsfejl lettere at fange og beskrive. For dem, der kører LLM i skala på SageMaker, ligger gevinsten især i bedre P95/P99 og kortere MTTR, hvis – og kun hvis – det kobles til klare playbooks og skarpere autoscaling.
Konkurrenceperspektivet er værd at nævne: flere clouds tilbyder observability-funktioner, men graden af out-of-the-box-detaljer og PromQL-integration i CloudWatch er en reel differentiering ifølge AWS’ beskrivelse. Den praktiske forskel mærkes først, når en spike ruller ind: Enten har man data nok til at handle, eller også famler man.
