AWS har annonceret en praktisk vejledning og et open‑source FLOPs Meter‑toolkit til Amazon SageMaker, der gør det muligt at måle beregninger (FLOPs) under finjustering af store sprogmodeller. Det er presserende, fordi EU AI Act fra 2. august 2025 gør FLOPs‑baserede tærskler centrale for, om I forbliver “downstream user” eller ender som GPAI‑udbyder med fuldt ansvar. Det er teknisk – og konsekvenserne rammer både udvikling og compliance her og nu.
Vi har siddet i maskinrummet hos kunder, hvor fine‑tuning kører i SageMaker Training jobs og nedskalerer automatisk, så snart træningen slutter. Effektivt, men målinger forsvandt også med clusteret. Den slags huller bliver dyre nu: FLOPs‑dokumentation er ikke længere nice‑to‑have, men grundlag for jeres juridiske placering.
Hvad loven kræver i praksis
EU AI Act indfører, ifølge AWS’ gennemgang, en FLOPs‑baseret vurdering af finjustering af LLM’er. Klassifikationen afgør, om I stadig er bruger af en eksisterende model, eller om I bliver GPAI‑udbyder med dertil hørende forpligtelser. En central grænse er den såkaldte one‑third‑regel, altså cirka 30 procent af base‑modellens pretraining‑compute. Bruges der mere i finjusteringen, antager lovgiver, at modellen ændrer sig så grundlæggende, at den må betragtes som en ny model med nye risici.
Hvis I ikke kender pretraining‑compute for base‑modellen, anvendes en standardtærskel på 3,3×10^22 FLOPs. Er modellen i den tunge ende – det, AWS beskriver som “systemic risk” med pretraining på eller over 10^25 FLOPs – og I mangler tallet, bruges en højere fast tærskel på 3,3×10^24 FLOPs. Kender I derimod et dokumenteret pretraining‑tal på mindst 10^23 FLOPs, gælder den relative 30 procent‑grænse. Tallene og scenarierne er refereret direkte fra AWS’ blog, som samler dem i en praktisk beslutningsvej.
Hvad AWS stiller til rådighed
SageMaker Training jobs kører som managed workloads med provisionering, skalering, distribueret træning og automatisk decommissioning. AWS peger samtidig på integration med CloudTrail og CloudWatch som rygraden for governance og audit. Nyheden er, at et Fine‑Tuning FLOPs Meter‑toolkit kan kobles ind i jeres eksisterende træningsopskrifter og levere audit‑klare output. Kilde: AWS’ egen gennemgang og GitHub‑repoet, der huser recipes og værktøjet.
Det er ikke et magisk flag, der gør alt for jer, men det er brikken, der manglede: uden konsistent telemetry bliver 30 procent til gæt. Og gæt er en dårlig compliance‑strategi.
Sådan virker FLOPs Meter teknisk
I praksis måler værktøjet FLOPs under træningen og vurderer automatisk, hvilken tærskel der gælder, baseret på inputs. Det vigtigste input er miljøvariablen PRETRAIN_FLOPS. Sætter I den med et dokumenteret tal fra modelleverandøren, bruger meteret den relative 30 procent‑grænse, hvis tallet er ≥ 10^23 FLOPs. Er tallet ukendt eller under 10^23, falder I ned på standardgrænsen 3,3×10^22 FLOPs. Og hvis modellen vurderes i den systemiske kategori (≥ 10^25 FLOPs) uden dokumenteret tal, anvendes 3,3×10^24 FLOPs.
Meteret placeres i jeres fine‑tuning recipes, typisk der hvor træningsloopet i Hugging Face/DeepSpeed eller FSDP kører. Det udstiller målinger løbende og kan skrive dem ud til logs, som I derefter sender videre til CloudWatch eller en ekstern SIEM. AWS’ dokumentation lover audit‑klare rapporter. Vores erfaring: gem også rådata, ikke kun en opsummering.
Hverdagens konsekvenser for drift
Det her ændrer CI/CD for ML. I skal instrumentere træningsjobs, sikre at målinger flushes før compute slukkes, og versionere både kode, data‑snit og FLOPs‑telemetry som artefakter. Multi‑node træning kræver, at delmålinger fra hver worker samles, valideres og signeres før clusteret går ned. Vi har set logs, der døde i netværksskiftet mellem node 0 og S3 – det ligner tabte beviser.
Cost attribution strammes også. Når I måler FLOPs per job, bliver der spurgt om kroner per FLOP per team. Det kræver entydige tags på jobs og datasets. Og governance: der skal være en linje fra træningskørsel til risikovurdering, så audit ikke ender i Slack‑udtræk og god tro.
Compliance‑arbejdsgange og ansvar
Hvem bestemmer, hvilken tærskel I kører efter? Typisk: udviklere og MLOps vælger instrumentering og sikrer målinger; procurement og legal indhenter dokumenteret PRETRAIN_FLOPS fra leverandører; risk/compliance udsteder politikker for, hvornår en finjustering må starte, og hvilke dokumenter der skal foreligge ved afslutning. Det er en kæde, ikke én persons opgave.
De artefakter, der skal være på plads, er mere end en talrapport. Vi anbefaler en kort risikovurdering per træningsjob, en audit‑zip med logs og FLOPs‑opsummering samt leverandørdokumentation, der underbygger PRETRAIN_FLOPS, hvis I bruger den relative grænse. Når kilder modsiger hinanden, så dokumentér afvigelsen og jeres beslutning. Myndigheder går efter sporbarhed, ikke historier.
Tradeoffs og kendte svagheder
Når FLOPs‑måling fejler, hvad gør man så? I praksis vil I indimellem falde tilbage til standardtærsklen, hvis PRETRAIN_FLOPS ikke kan skaffes eller målinger er ufuldstændige. Det er konservativt og kan kvæle et roadmap, hvis der planlægges mange kundespecifikke finjusteringer tæt på grænsen. Vi har set overhead i distribuerede opsætninger, hvor partial‑målinger ikke blev samlet, og dermed manglede bekræftet total. Der er performance‑omkostninger og fejlkilder.
Der er også tekniske hjørner, som dokumentationen ikke dækker fuldt ud: sparsity under træning, kvantisering on‑the‑fly, eller PEFT med frosne vægte. Tæller alt ens? AWS’ materiale antyder en generel tilgang, men forklarer ikke alle specialscenarier. Notér usikkerheden i auditpakken.
Sådan får I FLOPs‑måling ind i SageMaker‑pipelines
Gå trinvist: tilføj FLOPs Meter som et skript i jeres træningscontainer; sæt miljøvariabler (fx PRETRAIN_FLOPS hvis kendt), og aktiver logging‑hooks til at sende løbende målinger til CloudWatch. Sørg for en afsluttende “finalize”‑fase, der samler distributed metrics, skriver et samlet manifest til S3 og først derefter frigiver clusteret.
CI/CD‑mæssigt betyder det en ny gate: build – data snapshot – træning – FLOPs‑verificering – promotion. Uden den gate risikerer I at promovere en model uden et dokumenteret FLOPs‑grundlag – ofte fordi compute allerede er slukket, når man kommer i tanke om det.
En 90‑dages plan der faktisk kan gennemføres
De første 30 dage: discovery. Kortlæg alle fine‑tuning jobs, hvor de kører, hvilke containere, og hvor logging ender. Identificér hvor PRETRAIN_FLOPS kan skaffes kontraktuelt. Lav et proof‑of‑instrumentation på ét modelspor, ikke alle.
Dag 31‑60: telemetry og automatisering. Rul FLOPs Meter ud på de største træningsopgaver først. Tilføj CloudWatch‑export, og lav en lille datamodel til audit‑pakkens metadata. Indfør en stopregel: ingen promotion uden FLOPs‑manifest.
Dag 61‑90: governance. Få en kort policy godkendt, opret skabeloner til risikovurdering og audit‑zip, og træn to hold i at bruge dem. Test også recovery: dræb en node midt i træningen, og se om målingerne stadig kommer ud konsistent.
To scenarier fra virkeligheden, næsten
En stor bank med 70B‑basemodel. Antag base‑pretraining er estimeret til 1,5×10^24 FLOPs (et tal, AWS’ blog bruger som eksempel for Llama‑3‑70B). Med et dokumenteret tal gælder den relative tærskel på 30 procent, altså ca. 4,5×10^23 FLOPs. Banken planlægger en flerugers domæne‑tilpasning på 128 A100‑GPU’er. Med et groft skøn på 1,5×10^21 FLOPs per døgn i deres setup (afhænger af batch‑størrelse, sequence‑længde og precision), er de over tærsklen efter cirka 300 døgn – det gør de ikke. Men med aggressiv curriculum, øget seq‑længde og 8‑bit aktiveringstræning kan de stadig nærme sig en ikke‑triviel andel. Pointen: når man regner på det og logger rigtigt, har man ofte margin – men kun hvis pretraining‑tallet er dokumenteret. Uden det falder de ned på 3,3×10^22 FLOPs, og grænsen nås langt hurtigere.
En SaaS‑startup med 8B‑model. De kender ikke pretraining‑compute fra leverandøren. Standardtærsklen 3,3×10^22 FLOPs gælder. Med 16 H100 på en 48‑timers finjustering og moderat sekvenslængde kan de, alt efter pipeline, ligge i omegnen 10^21–10^22 FLOPs. Én ekstra runde RLHF eller længere sekvenser kan tippe dem over. I praksis løser de det ved at skifte til adapter‑baseret træning med lavere compute, logge alt ud af SageMaker via CloudWatch og fastholde en hård intern grænse pr. release‑cyklus.
Hvad vi ved, og hvad vi kun tolker
Direkte fra AWS: at EU AI Act kobler FLOPs til klassifikation af fine‑tuning, at datoen 2. august 2025 markerer indfasning af nye GPAI‑krav, at one‑third‑reglen anvendes som afgrænsning, at SageMaker integrerer med CloudTrail/CloudWatch, og at FLOPs Meter‑toolkittet findes som open source til brug i SageMaker‑workflows. Vi henviser her til AWS’ blog og GitHub‑repoet.
Vores fortolkning: de operationelle konsekvenser for CI/CD, målingernes skrøbelighed i distribuerede jobs og behovet for nye politikker og cost‑tags. Det bygger på Snillds erfaringer i projekter, ikke på officiel lovtekst. Hvor loven er uklar – fx hvordan FLOPs præcist opgøres ved sparsitet eller PEFT – markerer vi usikkerhed. Følg kommende vejledninger fra EU‑Kommissionen for at bekræfte praksis.
Rapporteringshuller værd at følge
Der mangler stadig offentlig juridisk fortolkning, der eksplicit bekræfter one‑third‑reglens anvendelse i alle scenarier. AWS’ blog er praktisk, men ikke lov. Vi savner også systematiske data for, hvor ofte modeludbydere faktisk leverer præcise PRETRAIN_FLOPS til kunder. Vores erfaring: sjældent og ofte med brede intervaller.
Teknisk dokumentation for FLOPs‑måling i edge‑cases er tynd: sparsity, kvantisering under træning, mixed precision med aggressive kernels. Og vi har ingen dokumenterede cases på håndhævelse eller sanktioner målrettet FLOPs‑rapportering endnu. Hold øje.
Små råd fra maskinrummet
Få PRETRAIN_FLOPS i kontrakten, ellers hav en plan for standardtærsklen. Sæt en pre‑flight i jeres pipeline, der tjekker for miljøvariabler og validerer, at FLOPs‑hooks er aktive. Eksportér både løbende metrics og en afsluttende opsummering til S3, og spejl dem til jeres SIEM. Test nedlukningsstierne – vi har tabt metrics, fordi autoscaling var for ivrig.
Det mest tidskrævende er ikke at skrive to linjer kode, men at blive enige om, hvad der er “godt nok” bevis. Her bør legal og MLOps sidde sammen 30 minutter om ugen, tjekke én audit‑zip og justere kravene. Korte møder. Ingen slides – bare logs.
Konklusion
FLOPs‑måling i SageMaker er reelt et krav, hvis I vil undgå uventet GPAI‑omklassificering. AWS har leveret et brugbart toolkit og tydelige integrationspunkter. Resten er disciplin: instrumentér, log, gem og beslut. Gør FLOPs‑manifestet til en promotion‑betingelse på linje med tests.
Man mærker forskellen, når en revision spørger efter tallene, og I kan åbne S3 og vise dem. Ikke perfekt poleret – bare til at stole på.
