SageMaker Inference 2026 kort fortalt
AWS har samlet årets hidtidige lanceringer for SageMaker Inference. Der er 13 nye funktioner, fordelt på to veje til drift: fuldt managed SageMaker endpoints og Kubernetes-native SageMaker HyperPod Inference. Kernen er praktisk: hvordan kører man store sprogmodeller stabilt, til en pris man tør budgettere, og med metrikker der afspejler virkelige brugerkrav. Det handler om varme containere, cache, autoscaling og signaler helt ned på token-niveau.
AWS’ egen opsummering beskriver udfordringerne nøgternt: modeller i størrelsesordenen adskillige tiere til hundredvis af gigabyte, latenstid målt i tokens pr. sekund, kolde starter i minutskala, begrænset GPU-kapacitet og monitorering uden de token-signaler, der styrer brugeroplevelsen. Det er drift.
Hvorfor generativ inference er særligt hårdt
Når en container på mange hundrede gigabyte skal hentes, pakkes ud, initialiseres og læsse weights i GPU-hukommelsen, knirker det. AWS beskriver kolde starter i minutter og krav om throughput i tokens/s frem for millisekunder pr. request. GPU-kapacitet er ikke elastisk som CPU—køer opstår hurtigt. Traditionel monitorering viser CPU, RAM og GPU-udnyttelse, men ikke TTFT (time to first token), inter-token latency eller KV-cache-hitrate, som afgør brugeroplevelsen.
To veje til produktion: Endpoints vs HyperPod
Amazon tilbyder to klare veje. Endpoints: fuldt managed, hvor AWS står for GPU-provisionering, autoscaling via CloudWatch og en OpenAI-kompatibel API. Man deployer via Console, SDK eller CLI. Det er hurtigt at komme i gang, og man “forbruger pr. instans” i stedet for pr. token.
HyperPod Inference: Kubernetes-native kontrol over dedikerede GPU-klynger. Her bruger teams kubectl, Terraform, Console, CLI eller SDK, og skalerer med Karpenter, KEDA og CloudWatch. Man får mere granulær kontrol—node-niveau adgang, valg af frameworks, AMI-styring—men tager også en større del af driftsansvaret. API-mæssigt er det åbent: HTTP, gRPC og mulighed for egen load balancer. Det passer til hybrid- og multi-cloud samt “train-to-serve” setups, hvor hele livscyklussen ligger i Kubernetes.
Forskelle der betyder noget i praksis
Valget er ikke bare kulturkamp mellem DevOps og platform. Det rammer budgetmodeller, compliance og værktøjskæden. Endpoints giver enkel forbrugslogik pr. instans, hurtig integration og mindre ops. HyperPod giver protokolvalg, finstyring af autoscaling-logik og mulighed for at køre tættere på metal, men kræver governance omkring AMIs, nodepools, patching og change management. Skalering via Karpenter og KEDA kan reagere raffineret på køer og tokens/s, men det kræver tid og kompetence.
Tradeoff’et er klart: færre knapper og hurtigere time-to-value på endpoints; flere knapper og mere performance-frihed på HyperPod. AWS adresserer begge lejre med samtidige forbedringer i 2026.
De 13 lanceringer i 2026
Årets funktioner er grupperet på tværs af de to veje. På endpoints: Inference recommendations, Capacity Aware Inference, OpenAI API support, Container Caching, Observability, Async Inference, Inline Payloads, Prefix-Aware Routing. På HyperPod-siden: en Simplified Operator, Tiered KV Cache, Data Capture, Performance Features, Disaggregated Prefill and Decode og Model Caching. Nedenfor er essensen og hvad man bør tjekke, før man planlægger en migration.
– Inference recommendations: automatisk valg af instanstyper, serveringscontainer og optimeringsindstillinger. AWS beskriver en tretrinsproces med filtrering, optimering (inkl. spekulativ decoding) og benchmark. Pointer: god til teams uden massiv intern benchmarkkapacitet. Åben post: resultater er leverandørdrevne; lav egne sanity-checks på repræsentative workloads, især for tail-latency.
– Capacity Aware Inference: failover mellem instansfamilier ved mangel, så man ikke sidder fast i “ingen kapacitet”. Giver højere tilgængelighed under spidsbelastning. Tjek prisaftryk ved fallback, og hvordan SLO’er vægtes, hvis ydeevnen skifter mellem GPU-typer.
– OpenAI API support: gør det lettere at pege eksisterende klienter mod SageMaker endpoints. Praktisk ved migrationer. Men kompatibel er ikke identisk. Tjek edge cases for streaming, tool-calling og batch før en større omlægning.
– Container Caching: forvarmer og genbruger containerlag, så kolde starter ikke altid begynder fra nul. Kræver disciplin i CI/CD: tynde images, lagdeling og pinned base-images. Vær opmærksom på sikkerhed og signering af images.
– Observability: nye signaler målrettet generativ inference. Forvent TTFT, inter-token latency, tokens/s, cache-hitrate og evt. skemaer for prompt vs. completion. Sigt efter eksport til jeres eksisterende APM, ikke kun silo-dashboards.
– Async Inference: aflaster synkrone pathways og udjævner spidsbelastninger. Giver mening til lange jobs eller batch. Kontrollér dead-letter-håndtering og retry-politikker, så API’er ikke drukner i ukontrollerede køer.
– Inline Payloads og Prefix-Aware Routing: hurtigere datapaths ved små nyttelaster og routing, der kender promptens natur før decode. Småt, men kan flytte P90 i praksis. Begrænsning: kræver at applikationen leverer de nødvendige hints korrekt—ellers ingen gevinst.
– Simplified Operator (HyperPod): færre moving parts i Kubernetes-operatoren. Gør det nemmere at rulle ud, opgradere og fejlfinde. Husk stadig change windows og et afprøvet rollback-scenarie.
– Tiered KV Cache (HyperPod): splitter KV-cachen mellem hurtig GPU-hukommelse og langsommere lag, så længere kontekster ikke eksploderer i prisen. Tjek latenskonsekvenser og evictions under pres. Der er sjældent én magisk indstilling—det er tuning.
– Data Capture (HyperPod): systematisk logging af prompts/outputs og metrikker til analyse. Jura og privacy skal ind over. Maskér tidligt, ikke sent.
– Performance Features (HyperPod): samlebetegnelse for kerneoptimeringer. Kræver læsning af release notes for at se, hvad der er standard vs. opt-in.
– Disaggregated Prefill and Decode (HyperPod): adskiller prefill (promptindlæsning) fra decode (generering), så man kan udnytte GPU’er bedre og reducere hot-path-konkurrence. Kan give pænere gennemløb under belastning. Kræver moden routing og batchning.
– Model Caching (HyperPod): forlæns indlæsning af weights og hurtigere skift mellem modeller. Godt til multi-model tjenester. Tjek GPU-memory budget og eviction-politik, så en ny model ikke skubber den vigtigste ud.
Hukommelse, formater og kvantisering
For at forstå hvorfor cache og kolde starter fylder, er en simpel tommelfingerregel nyttig: vægthukommelse ≈ antal parametre × bit pr. vægt ÷ 8. En 70B-model i 16-bit lander omkring 140 GB bare i weights. Dertil kommer KV-cache og runtime-overhead. Det er ren aritmetik.
Ukvantiserede modeller leveres ofte i 16-bit weights og typisk i pytorch_model.bin eller model.safetensors. Sikkerhedsnote: .bin/.pt kan indeholde pickle og dermed køre kode ved load, mens safetensors er designet til at undgå det—en header plus rå tensorbuffere uden eksekverbar kode. De fleste kvantiserede varianter bruger også safetensors som container; kvantiseringen ligger i tensorindholdet og konfigurationen, ikke i filendelsen.
Vigtig sondring: containerformat vs. kvantiseringsmetode. Containers (safetensors, GGUF, PyTorch .bin) beskriver, hvordan tensorer ligger på disken. Kvantiseringen (GPTQ, AWQ, bitsandbytes NF4 m.fl.) bestemmer hvor mange bits en vægt bruger. Forvekslingen skaber ofte fejl i build-pipelines—et formatvalg er ikke automatisk også et kvantiseringsvalg.
Praktisk implikation: vælg containerformat ud fra sikkerhed og værktøjsstøtte, vælg kvantisering ud fra mål for latenstid, kvalitet og hukommelse. Og tjek at jeres inference-runtime faktisk understøtter kombinationen, især i HyperPod-miljøer, hvor bibliotekskompatibilitet kan variere.
Caching, prefill og decode i praksis
Container Caching reducerer tiden til at spinde en model op, men ændrer ikke vægtenes størrelse. Tiered KV Cache adresserer den voksende context-længde ved at placere dele af cachen i langsommere, men billigere hukommelse. Disaggregated Prefill and Decode forsøger at udnytte GPU’er bedre ved at separere arbejdsfaserne. Tilsammen angriber de kernen i kolde starter og varm ydeevne.
Der er ingen gratis frokost. Caching kræver disciplin i image-lag og signering. Tiered KV kræver tuning mod jeres faktiske promptprofiler. Og disaggregated prefill/decode kræver routing, der ikke bliver en flaskehals. Planlæg tid til eksperimenter, før I lover SLO’er eksternt.
Observability, SLI’er og autoscaling
Hvis token-latenstid er det, brugeren mærker, så er TTFT og inter-token latency jeres SLI’er. Føj gennemløb i tokens/s, KV-cache-hitrate, model load-tid, image-lag-hitrate og batch-størrelse til metrikpakken. Skeln mellem prefill- og decode-tid, så alarmer ikke fyrer i blinde.
I autoscaling er tempoet afgørende. CloudWatch-baseret skalering på endpoints er enkel, men grovkornet. Karpenter og KEDA kan reagere på køer og tilpassede signaler—godt til bursts. Det kræver operationelle playbooks: warm pools, prewarming før events og en klar strategi for fallback, når GPU-typer ikke er ledige.
Omkostninger og forbrugsmodeller
Endpoints forbruges pr. instans, ikke pr. token. Det ændrer regnestykket i forhold til token-prisede API’er. Budgetter skal skifte fra “forbrug per kald” til “kapacitet pr. tidsenhed med udnyttelsesgrad”. Det kan være billigere eller dyrere—afhænger af batchning, udnyttelse og spidsbelastningens varighed.
Regneeksempler er sjældent direkte sammenlignelige på tværs af leverandører. Man skal kende egen promptlængde, svarlængde, batchning og SLA. Offentlige, neutrale prisbenchmarks mangler; teams må typisk lave en mini-PoC med produktionslignende trafik og måle effektiv pris pr. 1.000 tokens ved mål-SLA.
Hvornår giver HyperPod bedst mening
Behov for gRPC, custom load balancing, node-nær styring, tætte koblinger til træningsklynger eller hybrid/multi-cloud peger mod HyperPod. Også ved særlige krav til kvantisering, low-level CUDA-tuning eller minutiøs styring af skalering. Man får fleksibilitet, men også ansvar: AMI’er, driver- og runtime-kompatibilitet, sikkerhedsopdateringer, cluster lifecycle.
Hvis målet er hurtig time-to-first-prod, lav ops og standardprotokoller, peger billedet mod endpoints. Det ene udelukker ikke det andet: flere vælger endpoints til de stabile, forudsigelige workloads og HyperPod til de krævende, performancefølsomme eller regulatorisk specielle.
Rapporterede huller og åbne spørgsmål
Der mangler uafhængige performance-benchmarks for features som Container Caching, Tiered KV Cache og Disaggregated Prefill/Decode. Hvor meget TTFT falder i sekunder, ikke i procenter, ville være guld. Priser: by-instance er tydeligt, men praktiske break-even-eksempler mod tokenpricing er sjældne i det åbne.
Kompatibilitet i HyperPod med populære kvantiseringer (GPTQ, AWQ m.fl.) afhænger af runtime-biblioteker og versionsmatricer. Dokumentation er spredt. Og så er der driften: hvor stor er overhead’en ved node-level ansvar? Opgraderinger, driver-mismatch, recovery fra knudefejl—der er brug for flere gennemprøvede standardprocedurer i det offentlige rum.
Så hvad flytter nålen i dag
Tre ting skiller sig ud nu: Container Caching (hurtigere spin-up, hvis CI/CD er i orden). Tiered KV Cache (kontrolleret context-længde uden at sprænge GPU’er—med tuning). Og Disaggregated Prefill/Decode (bedre udnyttelse under pres, men kræver god routing). Inference recommendations kan spare uger for teams, der ellers famler i matrixen af instanser og indstillinger.
Andre funktioner er poleringer oven på eksisterende behov: OpenAI-kompatibilitet sænker friktion, Observability giver synlighed i det rigtige lag, og Async Inference passer til batch og baggrundsarbejde. Samlet set er det en modenhedspakke, ikke en sølvkugle.
Næste skridt for engineering teams
– Kør en målrettet PoC: én model, tre repræsentative prompts, målinger af TTFT, inter-token latency og tokens/s med og uden Container Caching. Notér kapacitetsprofilen over én uge, ikke én time.
– Valider kvantisering og formater: vælg safetensors som standardcontainer af sikkerhedshensyn, test en 4- eller 8-bit kvantisering op mod kvalitetsscorer og latenstid. Tjek at jeres runtime understøtter netop den metode.
– Definér SLI/SLO for generativ drift: TTFT, inter-token latency, P90/P99, KV-hitrate. Bind alarmer til brugeroplevelse, ikke kun GPU-udnyttelse.
– Træf et bevidst valg om vej: endpoints for hastighed og enkelhed, HyperPod for kontrol og specialbehov. Vælg ikke begge uden en klar begrundelse for driftskompleksitet.
Konklusionen er jordnær: forskellen mærkes først i hænderne. Og når alarmen går kl. 02, fordi en model blev kold på den forkerte knude.
