08 aug. 2025·8 min
Jeff Dean: Ingenjören som hjälpte till att skala AI på Google
En praktisk genomgång av Jeff Deans karriär och systemen som hjälpte Google att skala AI—MapReduce, Bigtable och lärdomar om modern ML-infrastruktur.
En praktisk genomgång av Jeff Deans karriär och systemen som hjälpte Google att skala AI—MapReduce, Bigtable och lärdomar om modern ML-infrastruktur.
Jeff Dean är viktig för AI av en enkel anledning: många av de "genombrott" människor förknippar med modern maskininlärning blir först användbara när de kan köras tillförlitligt, upprepade gånger och billigt på enorma datamängder. Mycket av hans mest inflytelserika arbete ligger i glappet mellan en lovande idé och ett system som kan betjäna miljoner användare.
När team säger att de vill "skala AI" balanserar de vanligtvis flera begränsningar samtidigt:
AI i skala handlar mindre om en enda modell och mer om en löpande fabrik: pipelines, lagring, distribuerad exekvering, övervakning och väldefinierade gränssnitt som låter många team bygga utan att krocka.
Detta är inte en kändisprofil eller ett påstående om att en person "uppfann" Googles AI. Googles framgång kom från stora grupper av ingenjörer och forskare, och många projekt skrevs och byggdes tillsammans.
Istället fokuserar detta inlägg på ingenjörsmönster som dyker upp i de välkända systemen Jeff Dean hjälpte bygga eller forma—MapReduce, Bigtable och senare arbete kring ML-infrastruktur. Målet är att extrahera idéer du kan använda: hur man designar för fel, hur man standardiserar arbetsflöden och hur man gör experiment till rutin snarare än hjälteinsatser.
Om du bryr dig om att leverera maskininlärning som överlever verklig trafik och verkliga begränsningar är systemperspektivet berättelsen—och Jeff Deans karriär är en användbar tråd att följa.
Jeff Dean anslöt till Google när företaget fortfarande definierade vad "produktion" betydde på det öppna internet: ett fåtal tjänster, en snabbt växande användarbas och en förväntan att sökresultat visas direkt—varje gång.
Sökeransens Google stod inför begränsningar som låter bekanta för alla som jobbar med skalning:
Detta tvingade fram ett praktiskt förhållningssätt: anta att fel kommer ske, designa för återhämtning och gör att prestanda fungerar på systemnivå—inte genom att hand-tunera en server.
Eftersom en sökfråga berör många maskiner multiplicerades små ineffektiviteter snabbt. Det trycket gynnade mönster som:
När Google senare expanderade till storskalig databehandling och maskininlärning förblev dessa prioriteringar konsekventa: förutsägbar prestanda, driftssäkerhet och design som tolererar partiella fel.
Ett återkommande tema kopplat till Deans påverkan är hävstång. Istället för att lösa varje nytt skalningsproblem från början investerade Google i interna byggstenar—delade system som låter många team leverera snabbare med färre experter.
Denna plattformsmentalitet blir avgörande när du har dussintals (sedan hundratals) team. Det handlar inte bara om att göra ett system snabbt; det handlar om att göra hela organisationen kapabel att bygga snabba system utan att uppfinna grunderna varje gång.
När en arbetsbelastning växer ur en enda maskin är den första flaskhalsen sällan "mer CPU." Det är glappet mellan vad du vill beräkna och vad ditt system säkert kan koordinera. Träning och serving av AI-system belastar allt på en gång: beräkning (GPU/TPU-tid), data (genomströmning och lagring) och tillförlitlighet (vad händer när något ofrånkomligen fallerar).
En enskild server som fallerar är ett irritationsmoment. I en fleet är det normalt. När jobb sprids över hundratals eller tusentals maskiner börjar du träffa förutsägbara smärtpunkter: stragglers (en långsam arbetare stoppar alla), nätverkskontention, inkonsekventa data-läsningar och kaskader av retries som förstärker det ursprungliga problemet.
Sharding delar data och arbete i hanterbara bitar så ingen maskin blir en flaskhals.
Replikering håller flera kopior så fel inte blir driftstopp eller dataförlust.
Felutlöst design antar partiella fel och designar för återhämtning: starta om uppgifter, tilldela om shards, verifiera resultat.
Backpressure förhindrar överbelastning genom att bromsa producenter när konsumenter inte hinner med—kritiskt för köer, pipelines och träningsinput.
I skala är en plattform som många team kan använda korrekt mer värdefull än ett skräddarsytt högpresterande system som bara dess författare kan drifta. Tydliga standarder, konsekventa API:er och förutsägbara felmodeller minskar oavsiktlig komplexitet—särskilt när användarna är forskare som itererar snabbt.
Du maximerar sällan alla tre. Aggressiv caching och asynkron bearbetning förbättrar prestanda men kan komplicera korrekthet. Strikt konsistens förbättrar korrekthet men kan minska genomströmningen. Operabilitet—felsökning, metrik, säkra utrullningar—bestämmer ofta om ett system överlever kontakt med produktion.
Denna spänning formade den infrastruktur Jeff Dean hjälpte popularisera: system byggda för att skala inte bara beräkning, utan också tillförlitlighet och mänsklig användning samtidigt.
MapReduce är en enkel idé med outsized påverkan: dela ett stort datapjobb i många små uppgifter ("map"), kör dem parallellt över ett kluster, och kombinera partiella resultat ("reduce"). Om du någonsin räknat ord över miljontals dokument, grupperat loggar per användare eller byggt sökindex har du redan gjort den mentala versionen av MapReduce—bara inte i Googles skala.
Innan MapReduce innebar bearbetning av internet-skala dataset ofta skräddarsydd distribuerad kod. Den koden var svår att skriva, bräcklig att drifta och lätt att göra fel i.
MapReduce antog något avgörande: maskiner kommer att falla, diskar kommer dö, nätverk kommer krångla. Istället för att betrakta fel som sällsynta undantag behandlade systemet dem som rutin. Uppgifter kunde köras om automatiskt, mellanresultat kunde återskapas och det övergripande jobbet kunde ändå bli klart utan att en människa vaktade varje kraschen.
Denna fel-först-mentalitet spelade roll för ML senare, eftersom stora träningspipelines beror på samma ingredienser—massiva dataset, många maskiner och långkörande jobb.
MapReduce gjorde inte bara beräkning snabbare; det standardiserade den.
Team kunde uttrycka databehandling som ett upprepningsbart jobb, köra det på delad infrastruktur och förvänta sig konsekvent beteende. Istället för att varje grupp uppfann sina egna klusterskript, övervakning och retry-logik förlitade de sig på en gemensam plattform. Det gjorde experiment snabbare (kör om ett jobb med ett annat filter), gjorde resultat enklare att reproducera och minskade behovet av ”hjälteingenjörer”.
Det hjälpte också data att bli en produkt: när pipelines var pålitliga kunde man schemalägga dem, versionera dem och överlämna utdata till downstream-system med förtroende.
Många organisationer använder nu system som Spark, Flink, Beam eller molnbaserade ETL-verktyg. De är mer flexibla (streaming, interaktiva frågor), men MapReduces kärnlektioner gäller fortfarande: gör parallellism till standard, designa för retries och investera i delade pipeline-verktyg så team lägger tiden på datakvalitet och modellering—inte på att hålla klustret vid liv.
Maskininlärningsframsteg handlar inte bara om bättre modeller—det handlar om konsekvent leverans av rätt data till rätt jobb i rätt skala. På Google gjorde systemmentaliteten som Dean förstärkte lagring till en förstklassig del av ML- och analysthistorien. Bigtable blev en av nyckelbyggstenarna: ett lagringssystem designat för massiv genomströmning, förutsägbar latens och operativ kontroll.
Bigtable är en wide-column store: istället för att tänka i rader och ett fast kolumnset kan du lagra gles, föränderlig data där olika rader kan ha olika "former." Data delas i tablets (radsintervall) som kan flyttas mellan servrar för att balansera belastning.
Denna struktur passar vanliga storskaliga åtkomstmönster:
Lagringsdesign påverkar tyst vad teams genererar för features och hur pålitligt de kan träna.
Om din databas stödjer effektiva range-scans och versionerad data kan du bygga om träningsset för ett specifikt tidsfönster eller reproducera ett experiment från förra månaden. Om läsningar är långsamma eller inkonsekventa blir featuregenerering bräcklig och team börjar "sampla runt" problem—vilket leder till snedvridna dataset och svårdebuggade modellbeteenden.
Bigtable-liknande åtkomst uppmuntrar också ett praktiskt angreppssätt: skriv råa signaler en gång och härled flera feature-vyer utan att duplicera allt i ad hoc-databaser.
I skala ser lagringsfel inte ut som ett stort avbrott—de ser ut som små, ständiga friktioner. Klassiska Bigtable-lärdomar översätts direkt till ML-infrastruktur:
När dataåtkomst är förutsägbar blir träning förutsägbar—och det förvandlar ML från forskning till en pålitlig produktkapabilitet.
Att träna en modell på en maskin handlar mest om "hur snabbt kan boxen beräkna?" Att träna över många maskiner lägger till en svårare fråga: "hur får vi flera hundra eller tusen workers att agera som en sammanhållen träningskörning?" Det gapet gör distribuerad träning ofta krångligare än distribuerad databehandling.
Med system som MapReduce kan uppgifter köras om och rekonstrueras eftersom output är deterministisk: kör samma input igen och du får samma resultat. Neural nätverks-träning är iterativ och stateful. Varje steg uppdaterar delade parametrar och små timingskillnader kan ändra träningsbanan. Du delar inte bara upp arbete—du koordinerar ett rörligt mål.
Flera problem dyker upp direkt när du skalar ut träningen:
Inom Google bidrog arbete kopplat till Jeff Dean till att föra system som DistBelief från en spännande forskningsidé till något som kunde köras upprepade gånger på riktiga fleets med förutsägbara resultat. Den viktiga förändringen var att behandla träning som en produktionsarbetsbelastning: tydlig felhantering, klara prestandamått och automatisering kring schemaläggning och övervakning.
Det som överförs till de flesta organisationer är inte exakt arkitektur—det är disciplinen:
När Google Brain flyttade maskininlärning från ett fåtal forskningsprojekt till något många produktteam ville ha, var flaskhalsen inte bara bättre modeller—det var koordinering. En delad ML-plattform minskar friktion genom att förvandla enstaka "hjältearbetsflöden" till paved roads som hundratals ingenjörer tryggt kan använda.
Utan gemensamt verktyg byggde varje team om samma grund: dataextraktion, träningsskript, utvärderingskod och deployments-lim. Den dupliceringen skapade inkonsekvent kvalitet och gjorde det svårt att jämföra resultat mellan team. En central plattform standardiserar det tråkiga så team kan lägga tid på problemet de löser istället för att lära om distribuerad träning, datavalidering eller produktionsutrullning.
En praktisk delad ML-plattform täcker ofta:
Plattformsarbete gör experiment upprepningsbara: konfigurationsdrivna körningar, versionerad data och kod, och experimentspårning som dokumenterar vad som ändrades och varför en modell förbättrades (eller inte). Detta är mindre glamoröst än att uppfinna en ny arkitektur, men det förhindrar att "vi kan inte reproducera förra veckans vinst" blir normalt.
Bättre infrastruktur skapar inte automatiskt smartare modeller—men den höjer lägsta nivån. Renare data, konsekventa features, trovärdiga utvärderingar och säkrare deployments minskar dolda fel. Med tiden betyder det färre falska vinster, snabbare iteration och modeller som beter sig mer förutsägbart i produktion.
Om du bygger denna typ av paved road i en mindre organisation är kärnan densamma: minska koordinationskostnaden. En praktisk strategi är att standardisera hur appar, tjänster och databaserade arbetsflöden skapas från början. Till exempel är Koder.ai en vibe-coding-plattform som låter team bygga webb, backend och mobilapplikationer via chat (React för webben, Go + PostgreSQL på backend, Flutter på mobil). Använd med eftertanke kan verktyg som detta snabba upp kringliggande produkt- och plattformsytor—adminkonsoler, data-review-appar, experimentdashboards eller servicewraps—samtidigt som koden kan exporteras, distribueras och rullas tillbaka när du behöver produktionskontroll.
TensorFlow är ett tydligt exempel på vad som händer när ett företag slutar se ML-kod som en samling enstaka forskningsprojekt och börjar paketera den som infrastruktur. Istället för att varje team uppfinner datapipelines, träningsloopar och deployments-lim kan ett delat ramverk göra "standardvägen" för ML snabbare, säkrare och lättare att underhålla.
Inom Google var utmaningen inte bara att träna större modeller—det var att hjälpa många team att träna och leverera konsekvent. TensorFlow förde en uppsättning interna praxis till ett upprepningsbart arbetsflöde: definiera en modell, kör den på olika hårdvaror, distribuera träning vid behov och exportera till produktion.
Den här typen av paketering minskar koordinationskostnaden. När team delar samma primitiva får du färre skräddarsydda verktyg, färre dolda antaganden och fler återanvändbara komponenter (metrik, inputbearbetning, serving-format).
Tidiga TensorFlow lutade mot beräkningsgrafer: du beskriver vad som ska beräknas och systemet bestämmer hur det körs effektivt. Den separationen gjorde det lättare att rikta mot CPU, GPU och senare specialiserade accelerators utan att skriva om varje modell.
Portabilitet är den tysta superkraften. En modell som kan flyttas mellan miljöer—notebook → kluster → produktion—minskar "fungerar här, går sönder där"-kostnaden som bromsar team.
Även om ditt företag aldrig open-source:ar något hjälper ett "öppet verktygs"-tänkesätt: tydliga API:er, delade konventioner, kompatibilitetsgarantier och dokumentation som antar nya användare. Standardisering ökar hastigheten eftersom onboarding blir enklare och felsökning mer förutsägbar.
Det är lätt att överdriva vem som "uppfann" vad. Den överförbara lärdomen är inte nyhet—det är påverkan: välj ett par kärn-abstraktioner, gör dem brett användbara och investera i att göra standardvägen enkel.
Deep learning bad inte bara om "fler servrar." Det bad om en annan sorts dator. När modellstorlekar och dataset växte blev allmänna CPU:er flaskhalsen—bra på flexibilitet, ineffektiva för den täta linjäralgebran i neurala nät.
GPUs visade att massivparallella chip kunde träna modeller mycket snabbare per krona än CPU-flottor. Den större förändringen var kultur: träning blev något du optimerar för (minnesbandbredd, batchstorlekar, parallellismstrategi), inte bara något du kör och väntar på.
TPUs tog idén längre genom att optimera hårdvaran för vanliga ML-operationer. Resultatet var inte bara snabbare träning—det var förutsägbarhet. När träningstiden krymper från veckor till dagar (eller timmar) blir iterationslooparna tajtare och forskning börjar likna produktion.
Specialiserad hårdvara lönar sig bara om mjukvarustacken kan hålla den upptagen. Därför spelar kompilatorer, kernels och schemaläggning roll:
Med andra ord: modellen, runtime och chipet är en och samma prestandaberättelse.
I skala blir frågan genomströmning per watt och utnyttjande per accelerator-timme. Team börjar rättdimensionera jobb, packa arbetsbelastningar och välja precision/parallellism-inställningar som når nödvändig kvalitet utan att slösa kapacitet.
Att driva en accelerator-fleet kräver också kapacitetsplanering och reliabilitetsarbete: hantera knapp hårdvara, hantera preemption, övervaka fel och designa träning för att återhämta sig graciöst snarare än att starta om från början.
Jeff Deans inverkan på Google handlade inte bara om att skriva snabb kod—det handlade om att forma hur team fattar beslut när system blir för stora för att någon enskild person fullt ut ska förstå dem.
I skala dikteras inte arkitektur av en enda ritning; den styrs av principer som dyker upp i designgranskningar och vardagliga val. Ledare som konsekvent belönar vissa avvägningar—enkelhet framför listighet, tydligt ägandeskap framför "alla äger det", tillförlitlighet framför enstaka snabbvinster—sätter tyst standardarkitekturen för hela organisationen.
En stark granskningskultur ingår i det. Inte "gotcha"-granskningar, utan granskningar som ställer förutsägbara frågor:
När dessa frågor blir rutin bygger team system som är lättare att drifta—och lättare att vidareutveckla.
En återkommande ledarskapsrörelse är att behandla andra människors tid som den mest värdefulla resursen. Mantrat "gör det lätt för andra" förvandlar individuell produktivitet till organisatorisk genomströmning: bättre standarder, säkrare API:er, tydligare felmeddelanden och färre dolda beroenden.
Så här vinner plattformar internt. Om paved road verkligen är smidig följer adoption utan tvång.
Design-dokument och klara gränssnitt är inte byråkrati; de är hur du förmedlar avsikt över team och tid. Ett bra dokument gör oenighet produktiv ("Vilket antagande är fel?") och minskar omarbete. Ett bra gränssnitt ritar gränser som låter flera team leverera parallellt utan att trampa varandra på tårna.
Om du vill ha en enkel startpunkt, standardisera en lättviktig mall och håll den konsekvent över projekt (se blog/design-doc-template).
Att skala människor innebär att rekrytera för omdöme, inte bara teknisk trivia, och att handleda för operativ mognad: hur man debuggar under press, hur man förenklar ett system säkert och hur man kommunicerar risk. Målet är ett team som kan drifta kritisk infrastruktur lugnt—för lugna team gör färre irreversibla misstag.
Jeff Dean-historien förenklas ofta till en "10x-engineer"-narrativ: en person som skriver kod snabbare än alla andra och ensam uppfinner skalning. Det är inte det användbara.
Den överförbara lärdomen är inte rå produktion—det är hävstång. Det mest värdefulla arbetet är det som gör andra ingenjörer snabbare och systemen säkrare: tydliga gränssnitt, delade verktyg, färre fallgropar och design som åldras väl.
När folk pekar på legendarisk produktivitet förbises ofta dolda multiplikatorer: djup systemförtrogenhet, disciplinerad prioritering och en bias mot förändringar som minskar framtida arbete.
Ett par vanor återkommer i team som skalar:
Dessa vanor kräver inte Google-stor infrastruktur; de kräver konsekvens.
Hjältenarrativ kan dölja den verkliga anledningen till att något fungerade: noggranna experiment, stark granskningskultur och system designade för fel. Istället för att fråga "Vem byggde det?", fråga:
Du behöver inte specialhårdvara eller planet-skala data. Välj en högpåverkanskork—långsam träning, sköra pipelines, smärtsamma deploys—och investera i en liten plattformsförbättring: standardiserade jobbmallar, en delad metrikpanel eller en lättviktig "golden path" för experiment.
En underskattad accelerator för små team är att förkorta "infrastruktur-UI"-gapet. När interna verktyg tar lång tid att bygga undviker team att bygga dem—och betalar sedan kostnaden i manuella operationer för evigt. Verktyg som Koder.ai kan hjälpa dig att snabbt leverera omgivande produkt- och plattformsytor (ops-konsoler, dataset-etiketteringsappar, review-flöden) med snapshots/rollback och deployment/hosting som stödjer iterativ plattformsengineering.
Jeff Deans arbete är en påminnelse om att "skala AI" mest handlar om upprepningsbar ingenjörskonst: göra enstaka modellvinster till en pålitlig fabrik för data, träning, utvärdering och deployment.
Börja med de tråkiga bitarna som multiplicerar varje framtida projekt:
De flesta skalningsproblem är inte "vi behöver fler GPU:er." Vanliga hinder är:
Datakvalitetsskuld: etiketter driver, definitioner ändras och saknade värden kryper in. Fixa med ägarskap och SLA:er, inte hjältedåd.
Utvärderingsluckor: team förlitar sig på en offline-metrik och blir överraskade i produktion. Lägg till slice-baserad rapportering (region, enhet, kundsegment) och definiera go/no-go-gränser.
Deployment-drift: träning använder en featureberäkning, serving en annan. Lös med delad feature-kod, end-to-end-tester och reproducerbara builds.
Välj infrastruktur- och arbetsflödesstandarder som minskar koordinationskostnad: färre skräddarsydda pipelines, färre dolda dataantaganden och klarare promotionsregler. Dessa val multiplicerar sig—varje ny modell blir billigare, säkrare och snabbare att leverera.
"Skala AI" betyder att göra ML upprepningsbart och pålitligt under verkliga begränsningar:
Det liknar mer att bygga en löpande fabrik än att finjustera en enskild modell.
Därför att många ML-idéer bara blir värdefulla när de kan köras tillförlitligt, upprepade gånger och billigt på enorma mängder data och trafik.
Påverkan ligger ofta i “mellanlagret”:
I fleet-skala är fel normalt, inte undantag. Vanliga första brytpunkter inkluderar:
Att designa för återhämtning (retries, checkpoints, backpressure) är ofta viktigare än maximal enkelmaskinprestanda.
MapReduce gjorde storskalig batchbearbetning standard och överlevbar:
Moderna verktyg (Spark/Flink/Beam och moln-ETL) har fler funktioner, men den hållbara lärdomen är densamma: gör parallellism och retries till standard.
Bigtable är en wide-column-databas designad för hög genomströmning och förutsägbar latens. Nyckelidéer:
För ML gör förutsägbar dataåtkomst träning och experiment återupprepbara och pålitliga.
Val av lagring formar vad du kan träna på på ett tillförlitligt sätt:
Stabil lagring avgör ofta om ML blir en produktkapabilitet eller ett återkommande problem.
Träning är stateful och iterativ, så koordinering blir svårare:
En praktisk strategi: mät end-to-end-tid, förenkla topologin först och lägg till optimeringar efter att du hittat den verkliga flaskhalsen.
En delad plattform förvandlar "hjältearbetsflöden" till paved roads:
Det minskar duplicering och gör resultat jämförbara mellan team, vilket oftare höjer iterationshastigheten mer än enskilda modellknep.
Standardisering minskar kostnaden för koordinering:
Lärdomen: välj ett litet set stabila abstraktioner, dokumentera dem väl och gör standardvägen enkel.
Du kan applicera principerna utan Google-skala resurser:
För att snabbt synka team kan verktyg som Koder.ai hjälpa till att leverera adminytor, dataset-etiketteringsverktyg och review-flöden med snapshots/rollback och deployment-funktioner.