Jeff Dean: Правило 1% для разработки в AI

Коротко

Джефф Дин фиксирует: AI дорос до уровня junior-инженера, а агентные системы теперь крутятся не час-два, а днями и неделями над одной задачей. Узкое место сместилось с обучения на инференс, и специализированное низколатентное железо, наследник TPU, даст выигрыш в десятки раз. Основатель выигрывает не там, где общие модели уже что-то умеют на 20%, а там, где они проваливаются на 0-1%: либо через доступ к приватным данным, либо через узкую точную модель уровня AlphaFold. Дефицитный навык эпохи агентов не написание кода, а вкус: выбор задачи и чёткая спецификация того, что ты хочешь. Энергия стала единицей измерения всего: перенос данных стоит в тысячу раз дороже самой арифметики, и это тихо решает, какие продукты вообще возможны.

Главный тезис

Модель это лишь один кусок системы: настоящая работа и настоящее преимущество лежат вокруг неё, в контекст-инжиниринге, оркестрации агентов и в выборе задачи, над которой вообще стоит их запускать.

Ключевые идеи

• 1:08: прогноз годичной давности про уровень junior-инженера попал точно; модели заметно выросли на длинных agent-based задачах по коду
• 1:18: Дин недооценил скорость: способность решать всё более сложные задачи росла быстрее, чем он думал, и не только в коде
• 1:51: прогноз на 2027: автоматизация самих ML-систем, которые улучшают себя через циклы автономных экспериментов и декомпозицию на подзадачи
• 2:31: автоматический цикл экспериментов работает везде, где есть измеримая цель, не только в ML, но в науке и инженерии
• 3:42: момент «it fits in memory» сегодня это низкоэнергетическое железо под инференс: латентность решает всё, специализация бьёт GPU/TPU
• 4:51: ложное убеждение зала: агенты работают час-два; на деле для ряда доменов они крутятся днями и неделями над очень сложной задачей
• 8:11: TPU родился из napkin-math про распознавание речи и дал в 30-80 раз выше энергоэффективность и в 20-30 раз ниже латентность против CPU/GPU той эпохи
• 7:45: TPU это по сути обобщённый движок низкоточной плотной линейной алгебры, специализация ровно настолько, чтобы не переспециализироваться под меняющиеся алгоритмы
• 12:49: арифметика стоит ~1 пикоджоуль, а перенос данных из HBM в процессор в тысячу раз дороже, отсюда вообще берётся батчинг
• 16:41: модель лишь один кусок системы; вокруг retrieval, инструменты, память, оркестрация, и контекст модель видит куда яснее, чем размазанные по параметрам training-данные
• 19:13: модель чинят снаружи не подкруткой весов, а навыками и гайдлайнами, self-improving цикл настройки харнесса
• 23:34: агенты слетают с рельсов, уходя за пределы распределения; лечится скиллами-подсказками и мульти-агентным поиском по пространству решений
• 28:47: правило выбора задачи: бери то, где модель проваливается на 0-1%; 20% это сигнал, что способность уже прорастает и общие модели догонят
• 34:03: когда весь код пишут агенты, дефицитным становится вкус: какую задачу вообще выбрать
• 32:38: агенты умеют писать код, поэтому важность чёткой спецификации выросла, а не упала; перевод кода между языками работает идеально именно потому, что спека там абсолютная

Почему это важно

Разговор задаёт карту для основателей на 2026 год, и её чертит человек, который построил TPU и Gemini внутри Google, компании, что кодизайнит всё от транзистора до продукта. Google и фронтир-лабы будут наращивать общие модели и инфраструктуру, выжигая целые ниши; но остаются два коридора, где команда из двух-трёх человек побеждает: приватные данные, к которым у общей модели нет доступа, и узкие точные модели под домен вроде AlphaFold, где генералист слаб. Проигрывает тот, кто строит на способности, которую фронтир подтянет за 6-12 месяцев. Выигрывает тот, кто читает узкое место как энергетическое или data-IO, а не «проблему модели», и у кого хватает вкуса выбрать задачу, которая реально изменит мир.

Идеи

• Прогресс в распознавании речи 2013 года: дип-лернинг вдвое срезал error rate, это эквивалент 20 лет прогресса за несколько месяцев возни с моделью и данными.
• TPU спроектировали как general-purpose движок линейной алгебры именно потому, что ML-алгоритмы ещё эволюционировали; переспециализация убила бы его до появления трансформеров.
• Трансформер изобрели позже TPU, но TPU оказался под него идеален, потому что не был заточен под конкретную архитектуру.
• Батчинг это не свойство обучения, а способ амортизировать тысячекратную стоимость переноса данных; при батче размера 1 ты платишь полную цену IO.
• Для низкой латентности батчинг вреден, поэтому инференс требует другого железа, чем обучение.
• Дин сейчас думает больше про инференс, чем про обучение: там нужна очень низкая латентность и много места для специализации.
• Представь латентность в 50 раз лучше: это меняет не скорость, а сам набор возможных продуктов.
• AI это по сути задача сжатия: если ты по-настоящему понял данные, ты можешь сжать их с потерями и восстановить.
• Skill, написанный Дином и Санджаем, учит модель гонять микробенчмарки, менять код, мерить прирост и итерировать, то есть оптимизировать код «как Джефф Дин».
• Документ Performance Hints на 30 страниц, скормленный модели в сжатом виде, поднимает её способность рассуждать о производительности кода.
• Мысленный эксперимент: чип с 20 ошибками в день вместо одной за миллион лет; ненадёжные транзисторы плюс избыточные пути сигнала как в мозге.
• Аналогия с распределёнными системами: надёжное хранилище строят из ненадёжных дисков через репликацию и Reed-Solomon, но на уровне транзистора так не делают.
• Параллель с нейроморфными вычислениями: сигналы в мозге тоже ненадёжны, важное дублируется по нескольким путям.
• Большинство мысленных экспериментов проваливается, потому что 50 лет делали так не просто так; но пересматривать допущения раз в какое-то время полезно.
• MapReduce родился из желания отделить простую суть задачи (URL → язык страницы) от размазанного вокруг кода параллелизации и чекпоинтинга.
• Neural-аппроксиматор дорогого симулятора density functional theory: вместо ночи расчёта ответ в 300 000 раз быстрее и почти так же точно, скрининг 10 миллионов молекул за обед.
• Рецепт улучшения моделей сегодня (идея → мелкие эксперименты → масштабирование → интеграция) можно почти полностью автоматизировать, убрав человека из цикла.
• Метрика, которую стоит оптимизировать: открытия на единицу вложенного компьюта.
• Дистилляция (2014, с Хинтоном и Виньялсом) получила отказ на NeurIPS с рецензией «вряд ли окажет значимое влияние»; теперь это индустриальный стандарт и основа Gemini Flash.
• Организация мировой информации закрыта Google; организация твоей личной информации открыта, и туда у общей модели нет доступа.
• Способ прокачать вкус: записать, что покажется важным за 12 месяцев, вернуться через год и свериться, что реально выстрелило.
• Скорость валидатора важнее его точности: ускоренный приблизительный evaluator меняет саму скорость научного цикла.
• Крупные модели видят примерно в 1000 раз больше данных, чем человек к 18 годам, и всё равно уступают ему во многом.
• Континуальное обучение и радикально более data-эффективные алгоритмы, обучающиеся на собственных действиях, названы одними из самых интересных нерешённых задач.
• Совет по найму: искать людей с комплементарными навыками, низким эго и с которыми тебе в радость проводить время над сложной задачей.
• Карьеру инженера стоит видеть как пояс инструментов, куда постоянно добавляешь новые техники.
• Тест выбора задачи: если лучший возможный исход случится, мир станет заметно лучше или скажет «прикольно, ну и ладно»?

Инсайты

• Специализация железа работает, когда специализируешься ровно настолько, чтобы поймать драматический выигрыш, но не привязаться к алгоритму, который через год сменится.
• Узкое место системы часто лежит не в модели, а в физике переноса данных; правильная диагностика первична по отношению к любой оптимизации.
• По мере того как написание кода дешевеет до нуля, ценность смещается вверх по стеку: к постановке задачи и к суждению о том, что вообще стоит делать.
• Спецификация не устарела с приходом агентов, а стала важнее, потому что агент, в отличие от умного человека, реже переспросит и чаще додумает не то.
• Устойчивое конкурентное преимущество живёт там, где общая модель проваливается полностью, а не там, где она слабовата; частичный успех генералиста это прогноз твоего поражения.
• Приватные данные и узкая специализация это два структурных убежища от давления фронтир-моделей.
• Автоматизация научного метода упирается не в генерацию гипотез, а в скорость их проверки; ускорь evaluator, и меняется вся эпистемология домена.
• Рекурсивное самоулучшение ML это не магия, а тот же человеческий цикл экспериментов, у которого убрали человека и обнулили латентность петли.
• Надёжность можно строить на любом масштабе поверх ненадёжных частей; вопрос лишь, на каком уровне абстракции ставить механизмы избыточности.
• Оценка новизны экспертами систематически промахивается мимо инженерной ценности, потому что рецензент судит о фундаментальности, а не о применимости в проде.
• Вкус это не мистика, а накопленная выборка исходов; его можно тренировать, ведя учёт своих прогнозов и сверяя их с реальностью.
• Data-эффективность человека против модели намекает, что текущая парадигма масштабирования данных не финальная, а промежуточная.

Фреймворки

Как основателю выбрать задачу (по Дину):

1. Возьми то, чем ты искренне увлечён и что считаешь полезным миру, это критерий номер один.
2. Проверь, что умеют текущие общие модели в этом домене: успех на 0-1% хороший знак, на 20% плохой.
3. Ищи либо доступ к данным, которых у общей модели нет, либо узкий домен под точную специализированную модель.
4. Взвесь долговечность: догонит ли фронтир эту способность за 6-12 месяцев или на это уйдут годы.

Три способа растить вкус: опыт множества прошлых задач; ведение списка прогнозов на 12 месяцев со сверкой через год; безумные мысленные эксперименты, оспаривающие общепринятые допущения.

Оркестрация автоматизированной науки: высокоуровневая цель → декомпозиция на подзадачи → каждая подзадача это автоматический цикл экспериментов с быстрым evaluator → сборка решений подзадач обратно в общее решение.

Цитаты

«AI is at the level of a junior engineer»: 0:44 AI на уровне junior-инженера

«depending on exactly your definition of junior engineer, it seems pretty spot on»: 1:08 смотря как точно ты определяешь junior-инженера, но попадание довольно точное

«you can get them to run for days or weeks and do really, really complicated tasks»: 4:51 их можно заставить работать днями и неделями над очень-очень сложными задачами

«imagine what you could do with something where the latency is 50x better»: 4:30 представь, что бы ты сделал при латентности в 50 раз лучше

«if you truly understand the data, you should be able to compress it really well»: 15:54 если ты по-настоящему понял данные, ты сможешь сжать их очень хорошо

«the model is really only one piece of what you're trying to do»: 16:41 модель это лишь один кусок того, что ты пытаешься сделать

«as soon as you get a little bit off the distribution of things it knows how to do, its performance will suddenly start to degrade»: 23:07 чуть вышел за распределение того, что модель умеет, и её качество резко проседает

«look for something where the model succeeds 0% or 1% of the time, not 20%»: 28:47 ищи то, где модель успешна в 0-1% случаев, а не в 20%

«it's really having incredibly good taste in what you ask your agents to work on»: 34:03 дело в очень хорошем вкусе в том, над чем ты просишь агентов работать

«the importance of specifying what it is you want has actually gone up»: 32:39 важность спецификации того, чего ты хочешь, и правда выросла

«you build reliable large-scale distributed file systems out of unreliable parts»: 37:47 надёжные распределённые файловые системы строят из ненадёжных частей

«what would happen if you tried to build a system out of transistors that might have 20 errors per day, rather than one every million years»: 38:32 что если строить систему из транзисторов с 20 ошибками в день вместо одной за миллион лет

«It's unlikely to have significant impact»: 48:49 Вряд ли окажет значимое влияние

«even if you get rejected, keep going»: 49:51 даже если тебя отвергли, продолжай

«effectively you want to optimize your discoveries per unit of compute input»: 47:38 ты хочешь оптимизировать открытия на единицу вложенного компьюта

«they probably see 1,000 times as much data as a human does by the age of 18»: 56:03 они видят примерно в 1000 раз больше данных, чем человек к 18 годам

«will the world be a lot better in some way or will the world go, eh, that's kind of cool, but whatever»: 52:48 станет ли мир заметно лучше или скажет «прикольно, ну и ладно»

«you always want to be adding new tools to that tool belt»: 54:48 всегда добавляй новые инструменты в свой пояс

Факты

• В 2001 году поиск Google работал на жёстких дисках; Дин и Санджай подсчитали, что индекс целиком влезет в RAM всех их машин, и за несколько дней выкатили в прод версию поиска в памяти, что и сделало Google быстрым.
• Прогноз про уровень junior-инженера был дан в мае 2025 на AI Ascent, примерно за год до этого разговора.
• В 2013 году, когда распознавание речи в Google заработало на дип-лернинге, оно вдвое срезало error rate, эквивалент 20 лет прогресса за несколько месяцев.
• Napkin-math по речи: если каждый пользователь говорит с телефоном 3 минуты в день, Google пришлось бы удвоить парк серверов, это и породило TPU.
• TPU через пару лет дал в 30-80 раз выше энергоэффективность и в 20-30 раз ниже латентность против CPU/GPU той эпохи.
• Одна арифметическая операция стоит около 1 пикоджоуля, перенос данных из HBM в процессор примерно в 1000 раз дороже.
• Дин написал знаменитый список «latency numbers every engineer should know» (задержки кэш-промаха, disk seek, сетевой пакет Калифорния-Нидерланды), ставший «библией» инженеров распределённых систем.
• Санджай и Дин несколько месяцев назад опубликовали 30-страничный документ Performance Hints, он бесплатен и доступен.
• Skill для оптимизации написан Дином и Санджаем несколько недель назад для их работы над низкоуровневыми библиотеками, чьи структуры данных крутятся на миллионах процессов в Google.
• Neural-аппроксиматор симулятора квантовой химии (density functional theory), сделанный коллегами Дина около десяти лет назад, дал ускорение в 300 000 раз при почти той же точности; ночь расчёта превратилась в скрининг 10 миллионов вариантов за обед.
• AlphaFold приведён как пример узкой модели под свёртку белков, а не общей.
• Дистилляцию Дин, Джефф Хинтон и Ориол Виньялс описали в статье 2014 года; она получила отказ на NeurIPS и была выложена на arXiv.
• Gemini Flash делается дистилляцией из более крупной Pro-модели и входит в число лучших в своём классе по размеру и скорости.
• Дин пришёл в Google в 1999 году, когда это был стартап на 20 человек.
• Возможные домены для узких точных моделей, названные Дином: материаловедение и проектирование чипов.

Источники

• MapReduce, Bigtable, TensorFlow, TPU, Gemini проекты Дина, упомянуты в интро.
• Performance Hints 30-страничный документ Дина и Санджая о трюках производительности, публично доступен.
• «Latency numbers every engineer should know» список Дина.
• AlphaFold узкая модель для свёртки белков.
• AlphaChip система разводки чипов.
• AlphaEvolve система, предлагающая и отбирающая работающие решения.
• Статья о дистилляции (2014) Дин, Джефф Хинтон, Ориол Виньялс; на arXiv.
• Санджай Гемават постоянный соавтор Дина (поиск в RAM, MapReduce, Performance Hints, skill оптимизации).
• Gemini, Gemini Flash / Pro модели Google.

Рекомендации

• Возьми опубликованный документ Performance Hints, скорми модели в сжатом виде, и она станет лучше рассуждать о производительности кода, он бесплатен, попробуйте.
• Веди список из того, что покажется важным на горизонте 12 месяцев, вернись через год и сверься, это тренирует вкус.
• Выбирая задачу, спроси себя: если случится лучший исход, мир станет заметно лучше или пожмёт плечами.
• Даже после отказа продолжай, дистилляцию отвергли, а она стала стандартом индустрии.

Итог

Модель это не продукт, а деталь: выигрывает тот, у кого хватит вкуса выбрать задачу, которую общие модели ещё проваливают, и хватит точности объяснить агентам, чего именно он хочет.