AWS skitserer nu en konkret vej til driftssikker LLM-inference. I en ny gennemgang præsenterer AWS fem resilience-mønstre for generativ AI på Amazon Bedrock, suppleret af et GitHub-projekt, der demonstrerer en “crawl, walk, run”-rejse fra første failover til gateway-orkestrering på tværs af modeller og udbydere (kilde: AWS ML Blog, id 2162; GitHub, id 2165). Timingen er rigtig: mange skal netop nu flytte PoC’er i hænderne på rigtige brugere, hvor infrastrukturen skal kunne holde til produktionstryk.
Hvorfor resilience er akut
Det overrasker stadig, hvor ofte teams undervurderer modelkvoter. En enkelt spidsbelastning kan lamme kapaciteten i timevis. AWS nævner eksplicit quota exhaustion, geo-distribution for tilgængelighed og noisy-neighbor i multi-tenant miljøer som problemer, mønstrene adresserer (kilde: 2162). Ignorerer man dem, bliver de til langvarige hændelser.
Fire arkitektoniske dimensioner, der styrer alt
AWS peger på fire styrende dimensioner for LLM-inference i produktion: tilgængelighed, svartid, omkostning og throughput (kilde: 2162). Man kan ikke maksimere alle på én gang, så eksplicit prioritering er nødvendig.
– Tilgængelighed: Holder svar i gang under model-, Regions- eller udbyderfejl via failover, geografisk spredning og kvote-isolering.
– Svartid: Ikke kun gennemsnit. TTFT (første token) og TTLT (sidste token) afgør oplevelsen. Høj TTFT føles som en app, der ikke reagerer.
– Omkostning: Per token, per forespørgsel og effekten af routingvalg. Multimodel-routing kan løbe løbsk uden rammer.
– Throughput: Hvor mange samtidige anmodninger eller tokens per sekund systemet kan håndtere, uden at ramme kvoter. Uden korrekt kø- og kapacitetsstyring bygger backlog op hurtigt.
De fem mønstre AWS peger på
AWS beskriver fem praktiske mønstre, der starter med indbyggede Bedrock-funktioner og ender i en gateway, der kan styre flere modeller og udbydere (kilde: 2162). Blogindlægget sætter rammen, mens GitHub-projektet viser udvalgte implementeringer (kilde: 2165).
1) Cross-Region inference på Amazon Bedrock: En Bedrock-profil kan automatisk rute kald til en passende Region inden for fx EU eller US. Det øger samlet throughput, reducerer throttling og muliggør automatisk failover ved spidsbelastninger (kilde: 2162). Latens kan stige lidt, men tilgængeligheden forbedres.
2) AWS-konto-sharding for kvote-isolering: Placer teams eller produkter i separate AWS-konti, så kvoteudtømning i én konto ikke påvirker de andre. AWS fremhæver isolering som modtræk mod quota exhaustion og noisy-neighbor (kilde: 2162). GitHub-repoet omtaler det som et eksplicit trin (kilde: 2165).
3) Geografisk distribution og styret routing: Fordel trafikken efter tilgængelighed, ventetid og efterspørgsel med simple policies. Det reducerer risiko ved Regions-fejl og spidsbelastninger (kilde: 2162). Kræver bevidste valg om datalokalitet.
4) Model- og leverandørdiversitet via gateway: En LLM-gateway muliggør intelligent routing på tværs af Bedrock-modeller og andre udbydere, central håndhævelse af rate limits og policies. GitHub-projektet bruger LiteLLM som reference og peger på AWS’ Solutions Guidance for en mere enterprise-parat gateway på ECS\/EKS (kilde: 2165).
5) Intelligent fallback og cost-aware policies: Ved fejl eller kvoteproblemer kan gateway eller applikationslag skifte til en alternativ model\/udbyder. AWS fremhæver, at dette både øger tilgængelighed og hjælper omkostningsstyring via smart routing (kilde: 2162). Detaljerede cost-regler er ikke fuldt udfoldet i bloggen.
Crawl, walk, run i praksis
GitHub-repoet demonstrerer, hvordan man indfører mønstrene trin for trin — start simpelt, og byg derefter gateway- og policy-lag på (kilde: 2165). “Crawl” er at slå cross-Region til og få basale metrikker på plads. “Walk” tilføjer konto-sharding, isolation og simple fallback-regler. “Run” er en centraliseret gateway med multi-model-routing, enterprise-policies og styring af throughput og omkostninger.
Det er en brugbar ramme, men den kræver forarbejde: IAM-roller, tags til omkostningsallokering og ensartet logstruktur. Uden det bliver overgangen mellem trinene uklar, og hændelser sværere at fejlfinde.
Byggeklodser, der gør forskellen
– Circuit breakers: Stopper hurtigt kald til en model\/Region, der fejler, så tråde ikke hænger. Det forkorter hændelser.
– Autoscaling: Skaler gateway- og orkestreringslaget, så kvoter og køer ikke bliver flaskehalse. Tænk på både compute, forbindelser og tråde.
– Model-caching: Cacher prompts, embeddings eller tokenstreams, hvor det er forsvarligt, for at stabilisere TTFT og TTLT.
– Observability: CloudWatch til metrikker og alarmer, strukturerede logs med “request id” og “model id\/version”, sporbarhed til fallback-beslutninger. TTFT, TTLT, p95\/p99, throttles og error rates som faste dashboards. AWS fremhæver TTFT\/TTLT som centrale mål for svartid (kilde: 2162).
Sådan sætter man det første mønster op
Første skridt er typisk cross-Region routing via Bedrock-profil. Overordnet trin-for-trin:
- IAM og Region-opsætning: Giv de nødvendige tilladelser til Bedrock i kilderegionen, og lad profilen få adgang til relevante målregioner i den valgte geografi (AWS beskriver profiler bundet til fx EU eller US, kilde: 2162).
- CloudWatch metrikker: Overvåg TTFT, TTLT, throttles, p95\/p99 latency, fejlrate og andelen af kald, der failer over til anden Region. Sæt alarmer for throttling og TTFT-spikes.
- Logning: Strukturér logs med korrelation mellem brugerflow og Bedrock-kald, så man kan spore beslutninger ved failover.
- Test: Simulér spidsbelastning og kontrolleret Regions-nedbrud, og verificér at routing flytter sig. Gør det planlagt i dagtimerne frem for midt i en hændelse.
Konto-sharding i drift
Når teams indfører konto-sharding for kvote-isolering, følger nye driftsbeslutninger:
- Overvågning: Enten centraliser alarmer og dashboards på tværs af konti, eller kør lokalt med klare eskaleringsregler. Vælg én model og stå ved den.
- Logindsamling: Saml strukturerede logs i et fælles data lake- eller SIEM-setup, ellers forsvinder signaler under hændelser.
- Incident response: Fordel ansvar pr. konto, men hold en tværgående “major incident”-kanal. Kvoteproblemer følger ikke organisationsbokse.
AWS peger på kvote-isolering og noisy-neighbor som motiver for mønstret (kilde: 2162). GitHub uddyber det i den samlede strategi (kilde: 2165). Det er lavpraktisk, men effektivt.
Tradeoffs der bider
Man får højere tilgængelighed med cross-Region og udbydermix, men latens kan stige, og omkostninger kan løbe. AWS beskriver samspillet mellem dimensionerne — især at georouting kan koste på svartid (kilde: 2162). Mål det, gæt ikke.
– Latency vs. availability: Brug en geoprofil og sæt en TTFT-grænse, hvor failover stoppes, hvis rejsen bliver for lang. Lidt ekstra ventetid kan være acceptabelt, men ikke hele sekunder.
– Omkostninger ved multi-model routing: Definér cost caps per feature eller kundesegment, ellers ender den dyreste model som default.
– Quota exhaustion: Konto-sharding hjælper, men kræver disciplin i capacity planning og i runbooks for nødsituationer.
– Multi-tenant noisy-neighbor: AWS beskriver problemet, men ikke konkrete isolationsteknikker uden for Bedrock (pod scheduling, nodereservation) i materialet (kilde: 2162). Kør efter egne Kubernetes-politikker, hvis gatewayen ligger på EKS.
Roadmap 30\/90\/180 dage
Et praksisnært forslag, baseret på AWS’ mønstre og Snillds rådgivning om byggeklodser (kilde: 2162, 2165; Snilld-anbefaling, 2163):
- 30 dage: Aktiver Bedrock cross-Region-profiler i relevant geografi. Etabler baseline observability: TTFT, TTLT, p95\/p99, throttles, error rate, cost per request. Sæt alarmer.
- 90 dage: Indfør circuit breakers på klientside\/gatewaylag. Etabler autoscaling for gateway\/orkestrering. Start konto-sharding for mindst ét kritisk produkt til kvote-isolering.
- 180 dage: Implementér LLM-gateway med multi-model routing og simple cost-aware regler. Definér enterprise-policies for rate limits, fallback og audit-logging. Overvej AWS’ Solutions Guidance for robust deployment på ECS\/EKS (kilde: 2165).
Operativ træning, governance og compliance
Her går AWS-materialet mindre i dybden, så nedenstående er Snillds anbefalinger til organisatoriske tiltag (kilde: 2163):
- SLO\/SLA-workshop: Sæt konkrete mål for tilgængelighed, TTFT p95\/p99 og maksimal fejlrate. Dokumentér undtagelser ved failover.
- Cost governance: Obligatoriske cost allocation tags, månedlige reviews og klart ejerskab af omkostningsdrivere i routing.
- Runbooks: Model-failover, kvoteudtømning, Regions-incident, gateway-degradering. Hold dem korte, versionsstyrede og testede.
- Model-livscyklus: Versionsstyring, regressions-tests på prompts og kontrol af output-konsistens ved opgraderinger.
- Compliance: Vurder datalokalitet ved cross-Region routing. AWS skriver, at profiler normalt er bundet til en geografi som EU\/US (kilde: 2162), men juridiske krav kan være strammere. Dokumentér fallback-beslutninger for audit.
Hvad AWS ikke siger højt
Der er huller, som teams selv skal udfylde. Ikke som kritik, men fordi lokale målinger er nødvendige:
- Manglende tal: Ingen kvantitative benchmarks for latenser eller pris under spidsbelastning. Test i eget miljø (kilde: 2162; rapporteringsgab).
- Output-konsistens ved modelskift: Bloggen nævner modeltilgængelighed og nye releases, men ikke en metode til at bevare konsistens. Brug versionering og regressions-tests (rapporteringsgab).
- SLO\/SLA-detaljer: Der er ikke defineret konkrete mål, fx TTFT p95 under failover (rapporteringsgab). Uden dem bliver “resilient” svært at styre.
- Omkostningsscenarier: Ingen priseksempler på multi-model eller cross-Region under forskellig trafik (rapporteringsgab). Lav egne budgetmodeller.
- Multi-tenant isolation uden for Bedrock: AWS peger på noisy-neighbor, men ikke specifikke Kubernetes-teknikker (rapporteringsgab). Platformteams må selv definere disse.
- Multi-cloud interoperabilitet: Standarder for auth og netværk på tværs af udbydere er ikke gennemgået (rapporteringsgab). Forvent ekstra integrationsarbejde ved flere skyer.
Hvad det betyder i hverdagen
Det praktiske resultat: Teams kan flytte fra skrøbelige PoC’er til platforme, der klarer produktionsstød. Bedrock cross-Region automatiserer en stor del af failover-arbejdet (kilde: 2162). En gateway ovenpå giver styring, auditspor og bedre omkostningskontrol (kilde: 2165). Men det kræver klare SLO’er, korrekt måling af TTFT og alarmer, der faktisk er aktive.
Og en vigtig detalje: En god gateway hjælper ikke, hvis inputvalidering og timeouts er for lempelige. Stramme timeouts, tydelige fejlbeskeder og en fallback-model, der er tilstrækkelig god, gør forskellen, når noget fejler.
Konklusion
Næste skridt: Prioritér de fire dimensioner, definér 2–3 SLO’er, slå cross-Region-profiler til, og få TTFT\/TTLT ind som første dashboards. Byg videre derfra. Man kan mærke forskellen, når det er i drift.
