Energiregningen gemt i modeldesign
Måleren i hjørnet
Den første nyttige samtale om AI-energi starter sjældent med et modelkort. Den starter med en måler. Et eller andet sted i bygningen, ofte i et rum, der aldrig er blevet beskyldt for indretningsdesign, bliver elektricitet omdannet til varme, latenstid, fakturaer og lejlighedsvis nyttigt arbejde. Dashboardet ovenpå kalder det måske intelligens. Facilities-teamet kalder det belastning. Begge har ret, men kun én af dem får en regning med tal, der skal betales.
AI-energi diskuteres ofte som et datacenterproblem. Bedre køling, bedre chips, renere strøm, smartere planlægning, mere effektive racks. Alt det betyder noget. Infrastrukturfolk har i lang tid presset nyttigt arbejde ud af watt, som regel uden den applaus, der gives til den model, der i øjeblikket bærer kronen. Men en overraskende stor del af energiregningen skrives, før arbejdsbyrden når datacentret. Den skrives i modeldesignet.
En modelarkitektur forpligter fremtidig energi. Det gør kontekstlængden også. Det gør også valget om at besvare ethvert spørgsmål med en stor generel model, når en mindre specialiseret rute ville være tilstrækkelig. Det gør også et retrieval-design, der flytter for meget tekst, en prompt-stil, der propper dokumenter ind i vinduet, fordi ingen gider bygge indeksering ordentligt, en afkodningsstrategi, der genererer unødvendige tokens, en serveringssti, der ikke kan batchbehandle, et præcisionsvalg truffet for komfortens skyld, og en evalueringskultur, der belønner benchmark-glans, mens den ignorerer driftsomkostninger.
Energiregningen gemmer sig der, fordi designvalg ser abstrakte ud. Et større kontekstvindue lyder som kapacitet. En større model lyder som hovedrum. Flere værktøjer lyder som fleksibilitet. Mere sampling lyder som kreativitet. Mere retrieval lyder som forankring. Hvert kan være nyttigt. Hvert beder også infrastrukturen om at udføre arbejde. Nogle gange er arbejdet det værd. Nogle gange brænder maskinen strøm af for at kompensere for et design, der ikke ville beslutte, hvor viden, hukommelse, routing og ansvar skulle bo.
Inference er, hvor design bliver en forbrugsregning
Træning får meget af opmærksomheden, fordi tallene er store, og klyngerne lyder filmiske. Inference er mindre dramatisk og ofte mere vedvarende. Det er det daglige arbejde med at servere spørgsmål, resuméer, klassifikationer, anbefalinger, søgninger, agenter og interne værktøjer. Hver anmodning kan være lille. Tilsammen bliver de den forbrugsregning, der følger produktet rundt som en meget punktlig revisor.
Inferensomkostningen formes af mængden af beregning, hukommelsesflytning, netværkstrafik, ledig kapacitet og gentagne forsøg, der er nødvendige for hvert brugbart svar. Udtrykket brugbart svar er vigtigt. Hvis et system genererer tre afsnit, hvor et enkelt felt ville være nok, er det ikke kun et brugeroplevelsesproblem. Det er energi brugt på ordrigdom. Hvis en arbejdsgang kalder en stor model fem gange, fordi processen ikke blev dekomponeret, er regningen designfeedback. Hvis en agent forsøger værktøjer i ringe, fordi tilstanden er vag, er varmen, der kommer ud af racket, delvist et styringsproblem iført et systembadge.
Store kontekstvinduer er et godt eksempel. De er værdifulde, når opgaven reelt kræver lang dokumentation. De er spild, når de bruges som erstatning for kildeudvælgelse. At smide en hel politikmanual ind i konteksten, fordi søgning er svag, er AI-ækvivalenten til at tage hele arkivskabet med til et møde, hvis et enkelt afsnit skulle blive relevant. Det fungerer, indtil nogen skal bære skabet. I computerværden ligner det at bære skabet hukommelsesbåndbredde, opmærksomhedsomkostning, latenstid og strømforbrug.
Bedre modeldesign spørger, hvilken information der skal være i vægte, hvad der skal være i søgning, hvad der skal være i værktøjer, hvad der skal cachelagres, hvad der skal beregnes lokalt, og hvad der skal afvises. Disse er energi-spørgsmål lige så meget som arkitekturspørgsmål. En afvisning kan spare energi, når opgaven er uden for rammen. En lille klassifikator kan dirigere arbejde, før en stor model vågner. Et godt indeks kan reducere konteksten. Et typet værktøj kan returnere en værdi uden at bede en sprogmodel om at fortælle sig gennem aritmetik, hvilket er nådigt for både watt og læsere.
Størrelse er ikke det samme som styrke
Den offentlige fantasi behandler stadig modelstørrelse som en simpel proxy for magt. Større må være bedre, eller i det mindste mere seriøst. Ingeniører ved, at historien er mindre ryddelig. En stor tæt model kan være fremragende, men den er ikke automatisk den rigtige driftsenhed til enhver opgave. Mange produktionsopgaver har snæver struktur: klassificér denne dokumenttype, udtræk disse felter, svar fra denne kilde, oversæt denne formular, diriger denne ticket, kontrollér denne politikbetingelse. At bruge maksimal generalitet til minimal tvetydighed er nogle gange som at varme suppe med en jetmotor. Teknisk muligt. Naboreaktioner varierer.
Mindre modeller, specialiserede hoveder, søgningsforstærkede designs, begrænsede dekodere, symbolske kontroller og klassiske algoritmer kan alle reducere energi, når de bruges det rigtige sted. Pointen er ikke lille for sin egen skyld. Pointen er opgaveegnethed. En kompakt model, der pålideligt besvarer én højvolumenopgave, kan være langt mere effektiv end en universel model, der bliver bedt om at lade som om enhver opgave er en roman. En regel-motor kan være bedre til deterministisk berettigelse. En databasespørgsmål kan være bedre til kendte fakta. Et søgeindeks kan være bedre til kandidatudvælgelse. En sprogmodel kan derefter gøre det, sprogmodeller er gode til: syntese, håndtering af tvetydighed, forklaring og udkast inden for rammer.
Blandings- og sparse-arkitekturer komplicerer billedet. At aktivere kun en del af en model kan reducere beregning, men routing, hukommelseslayout, batching og hardwareunderstøttelse afgør, om den teoretiske besparelse bliver reel. En elegant arkitektur på papir kan blive en trafikprop i produktion, hvis anmodninger spredes på tværs af eksperter, og hukommelsen ikke kan følge med. Effektivitet er ikke et slogan, du sætter på et papir. Det er en egenskab ved hele serveringsstien.
Derfor kræver energibevidst design måling i det miljø, hvor systemet skal køre. Benchmark-nøjagtighed alene er ikke nok. Tokens per joule, hukommelsestryk, latenstidsfordeling, batchbarhed, cache-hit-rate, netværkstrafik, kolde starter og fejlgentagelser betyder noget. Den bedste arkitektur er ikke den, der vinder et enkelt diagram. Det er den, der leverer den nødvendige kvalitet med mindst mulig undgåeligt arbejde under reel efterspørgsel.
Hukommelsesflytning er stille arbejde
Folk kan godt lide at tælle operationer. Hardware klager ofte over flytning. At flytte vægte, aktiveringer, nøgler, værdier, kildeblokke, indlejringer og logfiler på tværs af hukommelse og netværk bruger tid og energi. En model kan have imponerende regnekraft og alligevel være begrænset af, hvor meget data der skal flyttes for at holde den fodret. Brugeren ser en spinner. Infrastrukturen ser en leveringstjeneste for tal.
Modeldesign påvirker den flytning. Præcisionsvalg afgør, hvor mange bytes der rejser for hver værdi. Kvantisering kan reducere hukommelsesbåndbredde og kapacitetsbehov, men den skal testes mod opgaven, fordi et billigt forkert svar ikke er effektivitet. Kontekstlængde afgør, hvor meget tilstand der bæres gennem attention. Retrievaldesign afgør, hvor mange blokke der flytter ind i prompten. Caching afgør, om gentaget arbejde undgås. Lokalitet afgør, om data rejser på tværs af regioner, tjenester eller enheder, før et token vises.
Nogle af de bedste energibesparelser er uromantiske. Fastlås den rigtige modelversion. Undgå unødvendig prompt-boilerplate. Fjern gentagne instruktioner, der ikke gør noget. Brug strukturerede output i stedet for ordrig prosa, hvor arbejdsgangen har brug for felter. Cache stabile værktøjsresultater. Deduplikér dokumenter før indeksering. Udløb forældede indlejringer. Hold varme indekser tæt på serveringsstien. Batch kompatible anmodninger. Kompilér almindelige stier. Mål tokenoutput, ikke kun input. Det er ikke store gestus. Det er husholdning med et wattmeter.
Det vanskelige er, at mange teams ikke ser hukommelsesflytning som et produktproblem. De ser det som infrastrukturrør. Men brugerne betaler for det gennem latenstid, organisationer betaler gennem energi- og cloudregninger, og samfundet betaler gennem elnetspres. Hvis et produktdesign opmuntrer til lange prompter, gentagne kald, unødvendige forsøg og altid-tilgængelige generelle modeller, så er produktet en del af energisystemet. Elmåleren er ligeglad med, hvilken afdeling der traf beslutningen. Den har beundringsværdig ringe respekt for organisationsdiagrammer.
Energi lækker gennem stakken
Elregningen ligger ikke i et enkelt lag. Den lækker gennem stakken. Valg af træningsdata påvirker modelstørrelse og specialisering. Arkitekturvalg påvirker aktivering og hukommelse. Tokenizer- og kontekstvalg påvirker sekvenslængde. Retrievalvalg påvirker flytning og forankring. Promptvalg påvirker tokens. Afkodningsvalg påvirker outputlængde. Serveringsvalg påvirker batching og tomgangskapacitet. Hardwarevalg påvirker effektivitet. Overvågningsvalg påvirker, hvor hurtigt spild opdages. Hvis ingen ejer hele stien, bliver spild alle andres mindre problem, og måleren fortsætter sit stille arbejde.
Et stack-view hjælper, fordi det viser, hvor indsatser hører til. Hvis problemet er for stor kontekst, kan bedre hardware kun udskyde regningen. Hvis problemet er dårlig routing, kan kvantisering hjælpe mindre end en billig klassifikator foran. Hvis problemet er lav udnyttelse, kan arkitektur betyde mindre end batching og planlægning. Hvis problemet er forældet retrieval, bruges der energi på at generere polerede svar fra det forkerte materiale, hvilket er en tragisk brug af elektroner.
Der er selvfølgelig afvejninger. Energibesparelser må ikke gå ud over sikkerhed, tilgængelighed eller retfærdighed. En mindre model, der fejler i kanttilfælde, kan blot flytte omkostningen over på mennesker. Aggressiv caching kan servere forældede svar. Kvantisering kan skade sjælden sprogadfærd. En lokal rute kan reducere netværkstrafik, men øge duplikering. Disse afvejninger er reelle. Svaret er måling, ikke slogans. Mål kvalitet, energi, latenstid, fejlrettelse og menneskelig arbejdsbyrde sammen. En watt sparet ved at få personale til at reparere dårlige output er ikke en besparelse. Det er blot at outsource varmen til mennesker.
Det er derfor, modelenergi bør være en del af designreview. Ikke som en moralsk eftertanke, men som en ingeniøregenskab. Hvad er den forventede energi pr. nyttigt svar. Hvilke komponenter dominerer. Hvilke forespørgsler er outliers. Hvad er fallback-stien. Hvad sker der ved spidsbelastning. Hvad kan cachelagres. Hvilke opgaver bør undgå den store model. Hvilke beviser vil vise, at designet forbedres. Disse spørgsmål hører til ved siden af nøjagtighed og sikkerhed, ikke i et bæredygtighedsslide tilføjet af en person med et stockfoto af et blad.
Kontekstvinduet er ikke en springknap
Lang kontekst er blevet en fristende springknap for arkitektur. Hvorfor bygge omhyggelig retrieval, kildesortering, opsummering, adgangsfiltrering og dokumentstruktur, når modellen kan læse alt. Svaret er, at det at læse alt er arbejde. Vigtigere er det, at det at læse alt ofte er dårligere styring. Modellen modtager irrelevant materiale, følsomt materiale, forældet materiale og modstridende materiale og skal derefter beslutte, hvad der betyder noget, i et meget dyrt opmærksomhedsmønster.
God kontekstdesign er selektiv. Den behandler kontekstvinduet som knap arbejdshukommelse, ikke en lagerenhed med tillidsproblemer. Kildevalg bør ske før generering. Dokumenter bør opdeles i meningsfulde bidder, ikke skæres i vilkårlige stykker, fordi en biblioteksstandard så officiel ud. Metadata bør indeholde datoer, autoritet, følsomhed og omfang. Adgangsfiltre bør køre før retrieval. Opsummeringer bør cachelagres, når de er stabile. Modellen bør modtage de beviser, der er nødvendige for opgaven, ikke et kommunalt arkiv klædt i en prompt.
Dette er et energispørgsmål, fordi opmærksomhedsomkostningen vokser med sekvenslængden, og fordi lange prompter øger hukommelsesflytning, latenstid og fristelsen til at producere mere. En model med stor kontekst kan også give længere svar, fordi den har set mere materiale. Outputtet koster så også energi. Energibevidst systemdesign søger korte veje til nyttige svar. Det belønner ikke maskinen for at skrive en guidet rundvisning i beviserne, når arbejdsgangen har brug for ét beslutningsfelt og en årsagskode.
Der er også en evalueringsfælde. Langkontekstsystemer kan se imponerende ud i demoer, fordi de besvarer spørgsmål på tværs af store dokumenter. Produktionsbrug kan være domineret af små, gentagne, strukturerede spørgsmål. Hvis serveringsvejen behandler hver forespørgsel som et sjældent forskningspuslespil, vil energiregningen høfligt forklare forskellen mellem en demo og en tjeneste. Den vil bruge tal, fordi fakturaer er beundringsværdigt kortfattede.
Routing er en energikontrol
Routing er en af de mest undervurderede energikontroller i AI-systemer. Før en forespørgsel når frem til en stor model, kan systemet beslutte, om forespørgslen er inden for rammen, om der findes et cachelagret svar, om et deterministisk værktøj kan svare, om en lille model er nok, om der er brug for hentning, om et menneske skal håndtere det, eller om systemet skal afvise. Hver gren kan spare arbejde og forbedre kvaliteten, når den designes ærligt.
Dårlig routing gør det modsatte. Den sender hvert spørgsmål gennem den samme dyre vej. Den kalder værktøjer efter generering i stedet for før. Den beder en model om at klassificere noget, som et formularfelt allerede kender. Den beder om prosa, hvor en boolsk værdi ville være nok. Den gentager kald, fordi tilstand ikke føres videre. Den lader en agent udforske, fordi ingen har defineret opgavens afgrænsning. Det resulterende energiforbrug er ikke chippens skyld. Chippen gør, hvad den får besked på, med infrastrukturens trætte professionalisme overalt.
Energibevidst routing kræver konfidensgrænser, rammeregler, kontrol af kildens friskhed, cache-invalidering og menneskelig overdragelse. Den skal være gennemsigtig nok til, at operatører kan se, hvilken rute der blev valgt, og hvorfor. Den skal evalueres ikke kun på gennemsnitlig omkostning, men også på grænsetilfælde. En routingregel, der sparer energi på almindelige forespørgsler, men sender svære tilfælde i gentagne fejl, kan øge de samlede omkostninger efter support, gentagne forsøg og manuel reparation. Ruten skal vurderes ud fra nyttig fuldførelse.
Der er også en menneskelig dimension. God routing reducerer kognitiv belastning. Den giver simple tilfælde til simpel maskineri, strukturerede tilfælde til strukturerede systemer, tvetydige tilfælde til modeller og følsomme tilfælde til mennesker med beviser. Det er effektivt i den større forstand. Energieffektivitet og institutionel klarhed peger ofte i samme retning: bed ikke den mest generelle komponent om at bære ethvert ansvar, bare fordi den kan producere en sætning.
Lokalitet og efterspørgselsformen
Energi formes også af, hvor efterspørgsel møder udbud. Hvis data ligger ét sted, modeller et andet, logfiler et tredje og brugere et fjerde, kan hvert svar medføre netværksflytning og duplikeret lagring. Nogle gange er den fordeling nødvendig. Nogle gange er den et tilfældigt resultat af at købe tjenester i den rækkefølge, de blev moderne. Lokalitetsvalg påvirker latenstid, modstandsdygtighed, styring og energi sammen.
Edge- og lokal inferens kan reducere flytning for gentagne eller følsomme opgaver, men det kan også duplikere ressourcer og sænke udnyttelsen, hvis det anvendes blindt. Central servering kan forbedre udnyttelse og hardwareeffektivitet, men det kan øge netværksflytning og afhængighedskoncentration. Regionale designs kan balancere de to. Det rigtige svar afhænger af efterspørgselsformen: volumen, gentagelse, følsomhed, latenstidstolerance, kildens placering, spidsmønstre og fejltilstande.
Derfor er gennemsnit ikke nok. Den gennemsnitlige anmodning kan være billig, mens de øverste fem procent af anmodningerne dominerer energiforbruget. En lille gruppe af opgaver med lang kontekst kan bruge mere strøm end tusindvis af korte klassifikationer. Natlige batchjob kan skjule undgåelig genberegning. Agentforsøg kan blusse op under udfald i kilden. Energibevidst design ser på fordelingen, ikke kun gennemsnittet. Gennemsnittet er, hvor problemer går hen for at se respektable ud.
Efterspørgsel bør ændre design. Hvis brugere gentagne gange stiller det samme faktuelle spørgsmål, så cache eller udgiv svaret. Hvis de gentagne gange har brug for ét felt fra et dokument, så byg ekstraktion. Hvis de stiller brede spørgsmål, fordi grænsefladen skjuler struktur, så ret grænsefladen. Hvis agenter kalder værktøjer gentagne gange, fordi tilstanden er uklar, så redesign tilstanden. Hver gentagen watt er et designhint. Nogle hints er subtile. Den månedlige regning er ikke en af dem.
En energibevidst modelløkke
Det praktiske svar er ikke at gøre energi til det eneste mål. Det ville være tåbeligt og lejlighedsvis skadeligt. En mørk server er meget effektiv og ikke meget af en tjeneste. Opgaven er at inkludere energi i designløkken sammen med kvalitet, sikkerhed, latenstid, privatliv, modstandsdygtighed og vedligeholdbarhed. Mål nyttigt arbejde. Begræns opgaven. Vælg den mindste tilstrækkelige løser. Udrul med observerbarhed. Overvåg reel efterspørgsel. Revider design, når spild opstår.
Løkken har brug for et fælles sprog. Produktteams bør kende energiomkostningen ved designmønstre: lange prompter, gentagne kald, ordrige output, altid aktive agenter, ubegrænsede værktøjer. Ingeniører bør kende bruger værdien af ekstra beregning: færre fejl, bedre tilgængelighed, sikrere beslutninger, kortere menneskelig indsats. Driftsteams bør vide, hvilke arbejdsbelastninger der dominerer regningen. Governance-teams bør vide, hvornår energireduktioner ændrer risiko. Bæredygtighedsteams bør være i rummet, før systemet allerede har lært dyre vaner.
Dette handler ikke om skyld. Skyld er en dårlig profiler. Pointen er designforståelse. Når teams først ser, at energi er bundet af arkitektur, kan de vælge bedre. De kan beholde store modeller til opgaver, der har brug for dem, mindre modeller til afgrænsede opgaver, hentning til viden, værktøjer til deterministisk arbejde, caches til gentagelse, mennesker til dømmekraft og afvisning til nonsens. Resultatet er ofte billigere, hurtigere og klarere, hvilket er et anstændigt resultat for et emne, der begyndte med en elmåler i et trist rum.
Lektionen
Energiregningen for AI er ikke kun skjult i datacentret. Den er skjult i modeldesign: størrelse, arkitektur, kontekst, hentning, præcision, routing, lokalitet, caching, outputform, evaluering og afvisning. Hardwareeffektivitet betyder noget, men hardware indløser checks, som design allerede har skrevet.
God AI-infrastruktur begynder derfor tidligere end indkøb af acceleratorer. Den begynder med spørgsmålet om nyttigt arbejde. Hvilket svar er nødvendigt. Hvor meget sprog kræves der. Hvilken solver passer. Hvilken viden skal ligge i vægte, hentning, værktøjer eller regler. Hvilke anmodninger skal afvises. Hvilke beviser vil vise spild. Hvilke designvalg skaber undgåelig bevægelse. Hvilke kald til store modeller faktisk udfører arbejde for store modeller.
Energibevidst modeldesign er ikke askese. Det er præcision. Det bevarer kapacitet, hvor kapacitet betaler sig selv, og fjerner arbejde, hvor arbejde kun er vane. Resultatet er ikke blot en mindre regning. Det er ofte et bedre system: hurtigere, lettere at styre, lettere at skalere, lettere at forklare og mindre afhængigt af heroisk infrastruktur til at kompensere for doven design. Måleren i hjørnet fortalte sandheden hele tiden. Vi skulle bare læse den som arkitektur.