newsmode
search
Меню
arrow_back Назад

NVIDIA's AI Engineers: Agent Inference at Planetary Scale and "Speed of Light" — Nader Khalil (Brev), Kyle Kranen (Dynamo)

auto_awesomeКраткое саммари

В выпуске подкаста Latent Space гости из NVIDIA — Nader Khalil (Brev) и Kyle Kranen (Dynamo) — рассказывают о том, как NVIDIA, превратившись в корпорацию стоимостью $4,4 трлн, продолжает двигаться со скоростью стартапа. Nader описывает историю поглощения Brev — инструмента для мгновенного доступа разработчиков к GPU — и культуру «SOL» (Speed of Light), введённую Jensen Huang: принцип определения теоретического предела скорости любого процесса и работы от него. Kyle объясняет архитектуру Dynamo — фреймворка инференса масштаба дата-центра, поддерживающего SGLang, TRT-LLM и vLLM, с ключевыми оптимизациями вроде disaggregation (разделения prefill и decode), динамического масштабирования через Kubernetes-компонент Grove и балансировки стоимости, задержки и качества. Обсуждаются пределы длины контекста, совместное проектирование моделей и железа (model-hardware co-design), а также безопасность агентов: принцип «два из трёх» (доступ к файлам, интернет, исполнение кода). Участники прогнозируют появление агентов, способных автономно работать более 24 часов, и подчёркивают важность CLI-интерфейсов для взаимодействия LLM с инфраструктурой.

ИИ-инженеры NVIDIA: агентный инференс планетарного масштаба и «скорость света» — Nader Khalil (Brev), Kyle Kranen (Dynamo)

Присоединяйтесь к Kyle, Nader, Vibhu и swyx в прямом эфире на NVIDIA GTC на следующей неделе!

Теперь, когда билеты на AIE Europe почти распроданы, наше внимание переключается на Майами и World's Fair!


Бесспорный лидер среди производителей ИИ-ускорителей вырос более чем в 10 раз за это «ИИ-лето»:

И теперь это мегакорпорация стоимостью $4,4 трлн… которая каким-то образом по-прежнему движется как стартап. Нам повезло иметь уникальные отношения с нашими первыми гостями из NVIDIA: Kyle Kranen, который выступил с отличным докладом об инференсе на первом World's Fair и является одним из ведущих архитекторов NVIDIA Dynamo (фреймворк инференса масштаба дата-центра, поддерживающий SGLang, TRT-LLM, vLLM), и Nader Khalil, друг swyx со времён нашего совместного пребывания в Celo в The Arena, который привлекал разработчиков на GTC ещё до того, как NVIDIA обратила на них внимание:

Nader рассказывает о том, как NVIDIA Brev радикально снизил порог входа для разработчиков, позволяя быстро запустить топовый GPU, а Kyle объясняет NVIDIA Dynamo как движок инференса масштаба дата-центра, оптимизирующий обслуживание через масштабирование наружу (scale out) с использованием таких техник, как разделение prefill/decode, планирование и оркестрация на базе Kubernetes, в рамках компромиссов между стоимостью, задержкой и качеством.

Мы также погружаемся в концепцию «SOL» (Speed of Light) Jensen — подход к срочности, основанный на первых принципах, — обсуждаем пределы длинного контекста и совместное проектирование модели/железа, внутренние API моделей (https://build.nvidia.com), а также предстоящие сессии по Dynamo и агентам на GTC.

Полный видеоподкаст на YouTube

Таймкоды

00:00 Основы безопасности агентов00:39 Приветствие подкаста и гости07:19 Поглощение и сдвиг в DevEx13:48 Культура SOL и введение в Dynamo27:38 Почему Scale Out побеждает29:02 Объяснение пределов Scale Up30:24 От ноутбука к мульти-ноде33:07 Компромиссы стоимости, качества и задержки38:42 Disaggregation — Prefill vs Decode41:05 Масштабирование Kubernetes с Grove43:20 Длина контекста и совместное проектирование57:34 Безопасность и агенты58:01 Модель разрешений агентов59:10 Build Nvidia Inference Gateway01:01:52 Хакатоны и мечты об автономности01:10:26 Локальные GPU и масштабирование инференса01:15:31 Долгоживущие агенты и размышления о Сан-Франциско

Транскрипт

Основы безопасности агентов

Nader: Агенты могут делать три вещи. Они могут получать доступ к вашим файлам, они могут получать доступ к интернету, и теперь они могут писать собственный код и выполнять его. Вы буквально позволяете агенту делать только два из этих трёх. Если он может получить доступ к вашим файлам и может писать собственный код, вам не нужен доступ в интернет, потому что это полная уязвимость, верно?

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

Но при этом, знаете, какие точки контроля мы можем начать защищать?

swyx: Хорошо.

Приветствие подкаста и гости

swyx: Добро пожаловать в подкаст Lean Space в студии Chromo. Приветствуем всех гостей. Мы вернулись с нашим приглашённым ведущим Viu. С возвращением. Рад, что ты снова с нами. И наши друзья Netter и Kyle из Nvidia. Добро пожаловать.

Kyle: Да, спасибо, что пригласили.

swyx: Да, спасибо. Вообще-то я даже не знаю ваших должностей.

Я знаю, что ты вроде архитектор чего-то в Dynamo.

Kyle: Да. Я один из инженерных лидеров [00:01:00] и архитекторов Dynamo.

swyx: А ты директор чего-то там, и разработчики, разработческие технологии.

Nader: Да.

swyx: Ты тот самый «developers, developers, developers»-парень в Nvidia.

Nader: Опенсорс, агентный маркетинг, Brev.

swyx: И типа

Nader: Devrel-инструменты и прочее.

swyx: Да. Был

Nader: в фокусе.

swyx: И мы как бы записываем это перед Nvidia GTC, которая приезжает в город, опять, или захватывает город, на которой мы все будем. И мы немного поговорим о ваших сессиях и всём таком. Да.

Nader: Мы невероятно воодушевлены.

Истории о стендах на GTC

swyx: Одно из моих любимых воспоминаний о Nader — ты всегда устраиваешь маркетинговые трюки, и когда ты был в Brev, у тебя была эта доска для сёрфинга, с которой ты пришёл на GTC, и NVIDIA, видимо, настолько прониклась, что купила вас.

Расскажи, как это было? Что это было?

Nader: Да, да, мы... Наш логотип был «шака». Мы всегда старались оставаться верными себе. Знаете, некоторые стартапы пытаются притвориться более крупной и зрелой компанией, чем они есть. И на самом деле это Evan Conrad из SF Compute сказал нам: вы, ребята, как бы предыдущий

swyx: гость.

Да.

Nader: Потрясающе. Правда? Потрясающе. Да. Он просто сказал: ребята, вас двое в комнате. Зачем вы [00:02:00] притворяетесь, что это не так? И тогда мы решили: окей, давайте сделаем логотипом «шака». Мы принесли сёрфборды на свой стенд на GTC, и энергия была великолепная. Да. Ещё и пальмы. Они,

Kyle: они на самом деле торчали над стенками, так что стенд Brev было видно.

О, это так смешно. И

Nader: больше ни у кого,

Kyle: просто издалека.

Nader: О, так ты помнишь это с тех

Kyle: пор? Да, я помню это до поглощения. Я подумал: о, эти ребята выглядят круто.

Nader: Чувак. Это имеет смысл, потому что мы зарегистрировались буквально в последний момент, и у нас был последний стенд. Он был далеко в углу. И я переживал, что никто не придёт.

Поэтому у нас были пальмы. Мы реально пришли с сёрфбордами. Мы даже попросили одну из наших инвесторов привести свою собаку, и она просто ходила с собакой вокруг, пытаясь привлечь народ к нашему стенду. Да.

swyx: Steph.

Kyle: Да. Да, она лучшая.

swyx: Знаете, как организатор конференций, мне это нравится.

Правда? Все, кто спонсирует конференцию, приходят, оформляют стенд. Они такие: мы меняем будущее ИИ или что-то в этом роде, какая-то дженерик-хрень, а нет — на самом деле выделяйтесь, делайте весело, верно? И люди помнят это спустя три года.

Nader: Да. Да. Знаете, что смешно?

Я пришлю вам этот клип, если хотите вставить [00:03:00], но моя жена, тогда ещё невеста, училась в медицинском, и она приехала нам помочь, потому что для нас это был большой момент. Мы купили этот Cricut — это такой виниловый принтер, — потому что как ещё нам подписать сёрфборд?

Итак, мы купили сёрфборд — к счастью, удалось оплатить корпоративной картой. Мы купили Cricut, и на нём было что-то вроде «файнтюнинг для предприятий» или что-то такое, что мы наклеили на сёрфборд. И вот час ночи, день перед GTC. Она помогает мне клеить эти виниловые стикеры.

И она говорит: ну ты и... Типа: если ты это провернёшь, ты сукин сын. И вот, практически сразу после поглощения я склеил это с музыкой объявления о поглощении. Отправил в семейный групповой чат. О.

swyx: Да. Нет, ну, она сделала правильный выбор. Это было, по сути, историей создания Launchable — мы, это было, и, может, стоит объяснить, что такое Brev, и

Nader: Да.

Да. Brev — это просто инструмент для разработчиков, который делает получение GPU максимально простым. Мы подключаем кучу разных источников GPU. Основная идея: как быстро мы можем дать вам SSH-доступ к GPU. И каждый раз, когда мы общались с пользователями, они хотели GPU. Они хотели A100. И если вы зайдёте на любую [00:04:00] страницу провижининга облака, обычно это три страницы форм, и где-то в формах есть выпадающий список.

А в выпадающем списке — какой-то странный код, который вы знаете как означающий A100. И я помню, подумал: каждый раз, когда кто-то говорит, что хочет A100, текст, который они мне говорят, запрятан где-то в углу. И мы подумали: а что, если самый крупный текст будет тем, что пользователь запрашивает?

И когда вы заходите на Brev, там просто большие чипы GPU с нужным вам типом с

swyx: красивыми анимациями, над которыми ты работал до того, как можно было просто промптом сделать. Но раньше-то. Да. Да. Это были ручной работы, ремесленный код.

Nader: Да. Я на самом деле очень гордился этим, потому что я сделал это в Figma.

Да. И потом я долго пытался понять, как перевести это из Figma в React. И по сути это просто SVG, и у меня есть все стили, и когда вы меняете чип — активный он или нет, — меняется SVG-код, и это как будто анимация, но мы просто замедлили transition, и это просто JavaScript-функция, которая меняет базовый SVG.

Да. Вот так я в итоге разобрался, как перенести это из Figma. Но да, это было ремесленное дело. [00:05:00]

Kyle: Кстати, о маркетинговых трюках — он на самом деле использовал эти SVG, или что-то подобное, чтобы сделать открытки.

Nader: О да. Типа

Kyle: подарочная карта GPU. Да. Он раздавал их повсюду. Это было моё первое впечатление от этого.

Nader: Одного.

Да.

swyx: Да, да, да.

Nader: Да.

swyx: Кажется, у меня до сих пор одна осталась.

Nader: Они отлично выглядят.

Kyle: Да.

Nader: У меня их ещё куча в гараже, только без этикеток. Нам стоит честно вернуть их. Но я нашёл эту старую типографию, буквально за углом на Van Ness. Это семейное заведение Сан-Франциско в третьем поколении.

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

Дедушка, отец и сын, и сын был примерно моего возраста. Ну,

swyx: это как святая троица.

Nader: Смешно, потому что мы взяли тот же SVG и просто напечатали его, и это фольгированная печать — они делают форму, как инверсию A100, потом кладут фольгу [00:06:00] и прессуют её в бумагу.

И я помню, когда мы их получили, он сказал: эй, не забывайте о нас. Видимо, первые визитки ранних Apple и Cisco были сделаны там. Он сказал: да, к нам приходят стартапы, но когда они вырастают, они уходят куда-то ещё. И я на самом деле, мы обсуждали с маркетингом, не использовать ли их для чего-то, надо бы вернуться и сделать открытки.

swyx: Да, да, да. Знаете, я помню, будучи очень-очень маленьким инвестором Brev, я думал: зачем мы тратим время на эти трюки с GPU? Ну, как типичный облачно-железячный человек, ты заходишь в AWS, выбираешь T5 XL или что-то такое из списка, смотришь на характеристики — зачем анимировать этот GPU?

Но я думаю, это просто показывает уровень заботы, который пронизывает весь Brev, и да. И теперь, и ещё,

Nader: и NVIDIA. Думаю, то, что меня больше всего поразило, когда мы пришли — это уровень страсти у каждого. Знаете, общаешься с Kyle, общаешься с каждым вице-президентом, которого я встречал в NVIDIA, и все погружены так глубоко в детали.

Помню, это было почти год назад, и мой VP спрашивает: эй, [00:07:00] что такое Cursor? Ты его используешь? Если да, то почему? Я удивился, а он скачал Cursor и просил помочь ему разобраться. И я подумал, что это... ну, просто показать ему, зачем мы это используем.

Уровень заботы и страсти, который есть у каждого, и признательность за момент. Это очень уникальное время. Так что реально круто видеть, как все это ценят.

swyx: Да.

Поглощение и сдвиг в DevEx

swyx: Одну вещь я хотел сделать, прежде чем перейдём к исследовательским темам и тому, над чем работает Kyle, — рассказать историю поглощения.

Не так много людей проходили через поглощение NVIDIA. Каково это? Ну, да, просто что хочешь рассказать.

Nader: Это безумный опыт. Знаете, для нас самым воодушевляющим было то, что наша цель — просто упростить жизнь разработчикам.

Мы хотели найти доступ к GPU, упростить это. И ещё, кстати, к вопросу о Launchable. Launchable — это развёртывание в один клик любого софта поверх GPU. И нам очень понравилось в NVIDIA то, что мы как будто получили намного больше ресурсов, чтобы делать всё это.

Знаете, [00:08:00] цель NVIDIA — сделать всё максимально простым для разработчиков. Так что была отличная синергия. Когда дело касается поглощения, думаю, степень совпадения духа продуктов определяет успех поглощения.

И во многих отношениях это ощущается как дом. Для нас это отличный результат. Мне нравится brev.nvidia.com. Вам стоит попробовать, это

Kyle: главная страница для GPU.

Nader: Да. Да. Если хотите GPU,

Kyle: идёте туда, получаете

swyx: и внутри компании это растёт очень быстро.

Я не помню. Ты называл какую-то статистику.

Nader: Да, да, да. Жаль, точных цифр не помню, но внутри и снаружи рост очень быстрый. Мы работаем с кучей партнёров, кучей клиентов и ISV: если у вас есть решение, работающее на GPU, и вы хотите, чтобы люди быстро его использовали, мы можем упаковать его в launchable и сделать запуск в один клик.

Если вы просто хотите песочницу для запуска — вот, например, OpenClaw. Огромный момент. Очень волнительно. И мы ещё поговорим об этом, но внутри люди хотят это запускать, и мы знаем, что нужно быть очень осторожными с точки зрения безопасности. Позволять ли этому работать в корпоративной сети?

Рекомендация от службы безопасности была: запускайте это на Brev, оно [00:09:00] в виртуальной машине, в облаке, вне корпоративной сети. Изолировано. Это наша позиция внутри и снаружи — как запускать что-то вроде OpenClaw, пока мы разбираемся, как это делать безопасно.

Но да,

swyx: Думаю, ещё вы как бы оказались нужной командой в нужное время, когда NVIDIA начала серьёзно вкладываться в developer experience или как это ни назови. Да. UX или я не знаю, как это называть — софт. Очевидно, NVIDIA всегда инвестировала в софт, но это другая аудитория.

Да. Это

Nader: более широкая

Kyle: база разработчиков.

swyx: Да. Верно.

Nader: Да. Да. Знаете, смешно, это как бы не то что...

swyx: Так как это называется внутри? Что это такое, о чём люди должны знать?

Nader: Ну, типа developer experience

swyx: или, да, да. Это просто developer experience, или есть какая-то более широкая стратегия?

Nader: В NVIDIA?

NVIDIA всегда хочет создавать хороший developer experience. Дело в том, что многие технологии просто очень сложные. Это не... Знаете, я думаю, то, что реально растёт — ИИ переживает грандиозный момент, не [00:10:00] потому что дата-сайентисты в 2018 были тихими, а сейчас стали громкими.

Пирог стал больше, верно? Появилась целая куча новых аудиторий. Моя мама интересуется, что она делает. Моя сестра сама научилась программировать. Я вообще думаю, что ИИ — это великий уравнитель, и мы видим более технически грамотное общество.

Все учатся программировать. Оправдания больше нет. И создание хорошего UX означает, что нужно действительно понимать, кто ваш конечный пользователь. А когда конечный пользователь — это настолько разнообразная аудитория, приходится практически заново изобретать подход. Да. Нужно

Kyle: и ещё — реально строить больше developer UX, верно?

Потому что появились новые уровни базы разработчиков. Хакеры, которые строят поверх OpenClaw, например, никогда не использовали GPU. Они не знают, что такое CUDA. Они просто хотят запустить что-то.

Nader: Да.

Kyle: Нужен новый UX, который не просто «как запрограммировать что-то в CUDA и запустить».

А потом, когда глубокое обучение набрало обороты, мы создали Torch и прочее, но в последнее время количество [00:11:00] слоёв в этом стеке разработчика просто взорвалось, потому что ИИ стал повсеместным. Все используют его по-разному. Да. Это

Nader: движется быстро во всех направлениях.

Вертикально, горизонтально.

Vibhu: Да. Вы даже довели это до уровня железа — DGX Spark, знаете, это по сути та же система, что и просто бросить задачу на большой GPU-кластер.

Nader: Да, да, да. Потрясающе. Blackwell.

swyx: Да. Мы видели превью на прошлогоднем GTC, и это было одно из самых успешных видео, одно из лучших по охвату.

Надеемся, это побьёт рекорд.

Nader: Это было

swyx: на самом деле, скрестим пальцы

Nader: Да.

DGX Spark и удалённый доступ

Nader: Даже когда Grace Blackwell или DGX Spark только появлялся — участвовать в этом с самого начала в плане developer experience. И это возвращается к тому, о чём ты

swyx: говорил. Ты участвовал.

Nader: Да.

swyx: Mars.

Nader: Да. Да. В общем, мне просто пришло письмо, нас включили в процесс, и внезапно — да, было реально смешно, потому что я ещё новенький после поглощения, и мне приходит письмо от кучи инженерных VP про новый аппаратный GPU-чип, точнее не чип, а GPU-систему, которую мы выпускаем.

И я такой: окей, круто. Теперь я занимаюсь этим для UX, и думаю: что я тут [00:12:00] буду делать? На первой встрече я просто тихо сидел и слушал, как инженерные VP обсуждают, чем может быть этот бокс, что он может делать, как его использовать. И помню, одна из первых идей была типа: первое, что кто-то захочет сделать — это взять два таких и запустить Kubernetes-кластер поверх них.

И я подумал: о, кажется, я понимаю, зачем я здесь. Я сказал: первое, что мы делаем — это простой SSH в машину. И потом, просто сужая масштаб: тот, кто хочет запустить Kubernetes на двух Spark, имеет гораздо более высокий порог боли, чем тот, кто покупает и хочет запустить OpenClaw прямо сейчас, верно?

Если вы сможете сделать это максимально простым, всё остальное станет легче. Есть инструмент NVIDIA Sync. Он делает SSH-подключение очень простым. Если подумать: у вас есть Mac или PC, ноутбук, и вы покупаете этот GPU и хотите его использовать — вы должны использовать его как GPU в облаке, верно?

Но есть куча трений в том, как реально попасть туда. Это часть [00:13:00] ценностного предложения Brev — CLI, который оборачивает SSH и делает его простым. Наша цель — доставить вас в эту машину максимально легко. И мы только что запустили на CES, это ещё в раннем доступе.

Мы устраняем шероховатости, но к GTC должно быть готово. Вы можете зарегистрировать свой Spark в Brev. И теперь, если вы

swyx: типа удалённо управляемое, да, локальное железо. Единая панель управления. Да. Да. Потому что Brev и так уже умеет управлять другими облаками, верно?

Vibhu: Да, да. И вы используете Spark на Brev тоже, верно?

Nader: Да. Но да, именно. Вы настраиваете его дома, запускаете команду, и он по сути появляется в вашем аккаунте Brev, а потом вы берёте ноутбук в Starbucks или кафе и продолжаете использовать свой Spark как любой другой облачный узел на Brev.

Да. Да. Это как заранее настроенный мини-дата-центр

swyx: у вас

Nader: дома. Да, именно.

swyx: Да. Да.

Vibhu: Маленький дата-центр.

Nader: Маленький, размером с

Vibhu: телефон.

Культура SOL и введение в Dynamo

swyx: Ещё одна вещь перед тем, как перейдём к Kyle. У тебя столько историй про Jensen, и я обожаю их выуживать. Моя любимая пока — SOL. Что такое S-O-L?

Nader: SOL — это, наверное, [00:14:00] из всех уроков, которые я усвоил, мой самый любимый.

Kyle: Он останется с тобой навсегда.

Nader: Да. Да. Знаете, в стартапе всё экзистенциально, верно? Мы теряли деньги. Мы были на грани потери зарплаты, нам пришлось сокращать команду, потому что деньги закончились. И из-за этого ты постоянно заставляешь себя понять корневую причину всего.

Если тебе дают дату, если тебе дают сроки, ты точно знаешь, почему именно такие дата или сроки. Ты давишь на каждую границу и не просто принимаешь «нет» просто так. И когда начинаешь добавлять слои, когда становишься гораздо более крупной организацией, SOL — это, по сути, что говорит физика, верно?

Скорость света движется с определённой скоростью. Если свет движется медленнее, значит, что-то на пути. Так что прежде чем наслаивать реальность обратно — почему это нельзя доставить к такой-то дате — давайте сначала поймём физику. Каков теоретический предел того, как быстро это может быть?

А потом уже скажите мне почему. Потому что иначе люди начнут говорить, почему что-то нельзя сделать. Но на самом деле цель любого великого лидера — создать ощущение срочности. [00:15:00] Это бесконечное

Kyle: создание мотивирующих событий, верно?

Nader: Да.

Kyle: Да. SOL — это термин, который NVIDIA использует для создания мотивирующего события.

Ты говоришь: вот готово. Как мы к этому приходим? Что минимально необходимо, максимально достаточно, чтобы добраться именно сюда? И это помогает мгновенно пробиться сквозь кучу шума.

swyx: Да.

Kyle: Мгновенно.

swyx: Одно мне непонятно: только Jensen может использовать карту SOL? Типа, о, нет, нет, нет.

Не каждый же может вот так отсечь всю чушь, потому что это Jensen, а может ли кто-то другой сказать: нет, типа

Kyle: рядовые инженеры используют это.

Nader: Да. Каждый, я думаю, дело не столько в том, чтобы убрать чушь. Это скорее: дайте мне корневое понимание, верно? Если ты говоришь мне, что что-то займёт три недели, — ну, а каковы первые принципы?

Да, первые принципы. Типа, а почему три недели? В чём реальный предел, почему это займёт три недели? Если, допустим, ты хочешь купить новый компьютер, и тебе говорят, что он придёт через пять дней, каков SOL?

Ну, SOL — это: я могу зайти в Best Buy и купить его для тебя. Верно? Значит, всё, что дольше — и практично ли это? Будем ли мы так [00:16:00] обеспечивать всех в компании ноутбуками? Очевидно, нет. Так что это SOL, а дальше: окей, если нужно больше десяти, могут появиться причины.

И вот так мы начинаем наслаивать реальность обратно.

swyx: То есть это Paul Graham — «делай то, что не масштабируется». Да. И это ещё то, что сейчас называют «обладать агентностью». Да.

Kyle: Кстати, есть интересный второй аспект SOL, связанный с железом, который не всплывает для всех подразделений. SOL используется культурно, как в

swyx: NVIDIA для всего.

Я ещё копаю — думаю, это может иногда раздражать. Типа кто-то постоянно тебя SOL-ит, а ты такой: ребят, нам нужна стабильность. Нам нужно, блин, планировать. Да.

Kyle: Это интересный баланс.

Nader: Да. Я сталкиваюсь с этим прямо с Alec, верно? У нас новая конференция, нам нужно запустить, у нас есть цели, что мы хотим запустить к конференции, и, да.

В конце концов, где это

swyx: GTC?

Nader: Ну, вот мы сделали это для CES, для GTC DC до этого, делаем для GTC San Jose. Каждый раз у нас новый момент. И мы хотим что-то запустить. Да. И мы хотим сделать это на SOL, и это значит, что нужна определённая [00:17:00] приоритизация.

И это действительно сложно. Нужно быть осторожным с тем, что ты продвигаешь. Стабильность важна, и это должно учитываться в SOL. SOL — это не «построй всё и пусть ломается». Это часть разговора. Поэтому, когда ты наслаиваешь детали, одна из них может быть: мы можем это построить, но тогда оно не будет стабильным по таким-то причинам.

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

Итак: давайте доведём до точки, где люди хотя бы могут поэкспериментировать. Это было на стенде, в кейноуте Jensen, а потом давайте доработаем все сетевые нюансы. И это непросто. Так что это может подождать. Вот так мы это расслоили.

Да. Но

Kyle: Речь не о том, что тебе не нужно делать поддержку или операционную работу. Скорее [00:18:00] это подчёркивает, что прогресс инкрементален, верно? Какова минимальная вещь, до которой мы можем добраться? И дальше есть SOL для каждого следующего компонента.

Но есть SOL, чтобы добраться до стартовой линии. И обычно именно так его и спрашивают. На другой стороне — SOL родился из железячной культуры NVIDIA. SOL — это буквально: если бы мы запустили ускоритель или GPU на полной скорости без каких-либо других ограничений, насколько быстро мы смогли бы выполнить программу.

swyx: Да. Да. Верно.

Kyle: Итак

swyx: в обучении это, знаете, потом работаешь в обратном направлении до какого-то процента MFU, например.

Kyle: Да, отличный пример. Есть SOL по MFU, а есть то, что практически достижимо.

swyx: Круто. Перейдём к стороне Kyle?

Kyle, ты приходишь больше из мира data science. И я всегда, когда встречаю кого-то, кто работал с табличными данными, графовыми нейросетями, временными рядами — это такие, знаете, когда я хожу на NeurIPS, на ICML, по задним залам. Всегда есть маленькая группка людей, занимающихся графами.

Да. Маленькая группка табличных людей. [00:19:00] И там почти никого. И это такое, знаете, что я имею в виду: это важная и интересная работа, если вам важно решать те задачи, которые они решают.

Kyle: Да.

swyx: Но все остальные только про LLM всё время.

Kyle: Да. Это как чёрная дыра, верно?

Достиг ли горизонт событий уже NeurIPS?

swyx: Но знаете, это тоже трансформеры. Да. И это тоже интересные вещи. В общем, я хотел немного остановиться на этом бэкграунде, прежде чем перейдём к Dynamo непосредственно.

Kyle: Да, конечно. Я пришёл в NVIDIA другим путём. Я присоединился шесть лет назад, семь, если считать стажировку.

Я пришёл в NVIDIA сразу после колледжа. И первое, за что я взялся, было не то, чем я занимался на стажировке — вроде тяжёлого распознавания объектов для автономных автомобилей. Я переключился на рекомендательные системы — подумал, это популярно. И

swyx: да, он делал и Rexi

Kyle: тоже.

Да, Rexi. Да. В то время это были табличные данные: таблицы с характеристиками аудитории и товаров, и нужно понять, какой пользователь [00:20:00] соответствует какому товару, или, практичнее, какой товар какому пользователю. И тогда мы пытались перевести рекомендательные системы, которые исторически были CPU-ориентированными, в формат, хорошо работающий на GPU. С тех пор это реализовано — есть куча библиотек, работающих на GPU. Популярные модели вроде Deep Learning Recommendation Model от Meta и Wide and Deep от Google были сильно ускорены на GPU за счёт быстрой HBM на чипах, особенно для векторных поисков.

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

Так что я погрузился в это в [00:21:00] NVIDIA и активно занимался этим около двух лет.

swyx: Да. И кое-что я узнал от Brian Zaro — что в NVIDIA можно просто выбрать свой путь.

Kyle: О боже, да.

swyx: Что нетипично для большой корпорации. Да. Обычно у тебя есть своя полоса, и ты на ней остаёшься.

Nader: Думаю, для парня из стартапа, наверное, поэтому мне нравится быть в большой компании — миссия здесь начальник. Да. Миссия —

swyx: начальник.

Nader: Да. Это как большая игра в пикап-баскетбол. Знаете, если хочешь поиграть, приходишь на площадку и говоришь: мы будем играть, нам нужны трое.

Да. И просто находишь своих троих. Честно, каждая новая инициатива ощущается именно так. Да.

Vibhu: Это ещё и видно, верно? NVIDIA выпускает state-of-the-art в каждой области. Да. Ладно, ожидаешь фундаментальных моделей с NeMo, потом внезапно Parakeet — голосовая модель.

Просто появляется ещё одна, голосовая. Ещё

Kyle: голосовая команда всегда выдавала результат.

Vibhu: Да. Всегда в каждой области появляется статья, датасет. И это ещё связано с тем, что NVIDIA обязана делать: нужно делать чипы за годы до их реального выпуска.

Верно? Нужно знать, нужно реально [00:22:00] фокусироваться. И

Kyle: процесс проектирования начинается за

Vibhu: именно,

Kyle: три-пять лет до выхода чипа на рынок.

Vibhu: Да. Мне интересно, как это устроено изнутри? У вас есть специализированные команды. Люди находят интерес, погружаются, и это подпитывает прогнозы.

Внутренняя кухня NVIDIA наверняка безумная, верно? Да. Да. Вы же. Даже не продавая другим, у вас есть собственные прогнозы, куда всё движется. Да. И они очень обоснованные. Верно?

Kyle: Да. Это реально интересно. Есть две вещи, которые NVIDIA делает очень хорошо.

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

Nader: Я работал в крупной компании пару лет до стартапа, и там было очень странно писать за пределы цепочки, [00:23:00] если вы понимаете. Да. Переписки в NVIDIA — это мош-питы.

swyx: Ого,

Nader: там просто 60 человек, все вперемешку. И это,

swyx: они такие хаотичные, reply all, тебя

Nader: о, это безумие.

Это безумие. Они просто

Kyle: помогают. Знаете, дают максимум

Nader: контекста. Но на самом деле, это забавно — раньше я думал: зачем отправлять имейлы? У нас есть Slack. Теперь я абсолютно противоположного мнения. Мне жаль всех, кто мне пишет в Slack, потому что я ужасно отвечаю.

swyx: Ты теперь

Nader: максишь имейл. Имейл — это вообще другое дело. Имейл идеален, потому что важные треды всплывают обратно, верно? Да, да. А Slack этого не делает. У меня просто казино мигает слева, и я не знаю, какой тред откуда. А ещё — тема письма, можно вести рабочие треды.

Думаю, когда вы маленькие, не 40 000 человек, Slack работает отлично, но есть точка перелома. Когда-то это станет хаосом, и вы предпочтёте имейл, потому что можно вести рабочие треды.

Можно включить больше девяти человек в тред.

Kyle: Можно форкать ветки.

Nader: Можно [00:24:00] форкать, что очень удобно. И это часть того, как можно предложить план. Можно также просто начать — честно, импульс — единственная власть, верно? Если можешь просто начать делать немного прогресса и показать кому-то что-то, что он может попробовать.

Думаю, это самый эффективный способ продвинуть что-либо. И это работает и в NVIDIA, и вообще.

Kyle: Да, есть ещё одна концепция, которая активно обсуждается в NVIDIA — идея бизнеса на ноль миллиардов долларов. Создание рынков — это для NVIDIA большая тема.

Типа,

swyx: о, хочешь пойти и начать бизнес на ноль миллиардов?

Kyle: Jensen говорит: мы абсолютно готовы инвестировать в рынки на ноль миллиардов долларов. Нам всё равно, приносит ли это доход. Нам важно знать этот рынок. Мы думаем, он будет важен в будущем. Он может быть на ноле какое-то время.

Возможно, я немного перевираю его слова, но суть такая. Приведу пример. NVIDIA работает над автономным вождением очень давно.

swyx: Типа машина NVIDIA.

Kyle: Нет, они

Vibhu: использовали Mercedes, верно? Они ездят вокруг штаб-квартиры, и, кажется, только недавно получили лицензию. Теперь их начинают активно [00:25:00] использовать.

Десять лет можно было видеть Mercedes с логотипами NVIDIA.

Kyle: Если вы в южной части Санта-Клары, на самом деле с юга. Да. Так что, бизнесы на ноль миллиардов — это реально. Jensen,

swyx: ну ладно, смотрите, машины — это не рынок на ноль миллиардов. Но да, пример не самый удачный.

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

Kyle: где исследования. Исследования в NVIDIA очень идеологически свободны.

Они могут заниматься тем, что их интересует.

swyx: А ты был официально в research?

Kyle: Я никогда не был в research официально. Я всегда был в инженерии. Я в подразделении Deep Learning Algorithms, которое по сути занимается тем, как заставить всё, что связано с глубоким обучением, работать быстро.

swyx: Звучит чертовски круто.

Vibhu: И я думаю, многое из этого недооценено. Временные ряды — на этой неделе Google выпустил статью TimeFF. Да. Новая статья по временным рядам. Symantec ID [00:26:00] начал применять трансформеры и LLM к рекомендательным системам. Да. И когда думаешь о масштабе компаний, внедряющих это — рекомендации Amazon, поиск Google, — это огромный масштаб.

Kyle: Да.

Vibhu: И нужна скорость?

Kyle: Да. Да. Да. Кстати, есть забавный момент, который замкнул для меня круг. Amazon Ads недавно выступали с докладом, где рассказали об использовании Dynamo для генеративных рекомендаций, и это было невероятно — как будто катарсис. Я такой: о боже. Я вытеснил то, над чем работал.

Вы теперь используете LLM для того, что я делал пять лет назад.

swyx: Да. Потрясающе. Давайте сразу к Dynamo. Может, представишь сверху вниз.

Kyle: Думаю, на данный момент многие знакомы с термином «инференс». Забавно: я прошёл путь от инференса как нишевой темы до того, что обсуждается в обычных лентах Twitter.

Это

Nader: на билбордах

Kyle: теперь. Да. Очень странно. Едешь и видишь рекламу инференса на шоссе 101. Инференс в масштабе становится всё важнее. У нас бывают моменты, вроде [00:27:00] OpenClaw, где агенты потребляют огромное количество токенов, но производят невероятные результаты.

Есть много аспектов масштабирования во время тестирования: можно использовать больше инференса, чтобы получить лучший результат, чем при коротком инференсе. Это рассуждения, запросы, добавление агентности модели — возможность вызывать инструменты и использовать навыки.

Dynamo появился в NVIDIA, потому что я и ещё несколько человек обсуждали эти концепции. Знаете, есть движки инференса вроде vLLM, SGLang, TensorRT-LLM — они работают с одной копией, одной репликой модели, верно?

Почему Scale Out побеждает

Kyle: Одна версия модели. Но когда вы реально обслуживаете запросы в масштабе, нельзя просто масштабировать вверх эту реплику, потому что возникают проблемы производительности. Есть предел масштабирования вверх. Поэтому нужно масштабировать наружу — если использовать терминологию Kubernetes.

Мы поняли, что есть огромный потенциал оптимизации при масштабировании наружу и построении систем для инференса масштаба дата-центра. Dynamo — это движок инференса масштаба [00:28:00] дата-центра, который сидит поверх фреймворков вроде vLLM, SGLang и TensorRT-LLM и просто ускоряет всё за счёт эффекта масштаба.

У вас есть KV-кеш во всех этих машинах — уникальный, — и вы хотите максимизировать попадания в кеш. Или вы хотите применить новые техники инференса, вроде disaggregation, которую Dynamo представил миру в марте — не изобрёл, это было в академических работах раньше.

Но мы одни из первых фреймворков, которые начали это поддерживать. И мы хотим объединить все эти техники в модульный фреймворк, который позволяет ускорить инференс в масштабе.

Nader: Кстати, мы с Kyle подружились в мой первый день в NVIDIA, и мне всегда нравилось, потому что он всегда учит меня

swyx: новому.

Да. Кстати, поэтому я хотел поставить вас двоих вместе. Я подумал: да, это будет

Kyle: хорошо. Мы очень разные, но мы часто [00:29:00] общались. Кстати, ты спросил: почему нельзя просто масштабировать вверх?

Nader: Да.

Объяснение пределов Scale Up

Nader: Модель, ты сказал — реплики модели.

Kyle: Да. Масштабирование вверх означает выделение больше

swyx: тяжелее?

Kyle: Да, тяжелее. Делать вещи мощнее. Добавлять больше GPU. Больше CPU. Масштабирование наружу — это поставить барьер и сказать: я дублирую свою модель или микросервис и реплицирую его множество раз.

Обрабатывать нагрузку. Причина, по которой нельзя масштабировать вверх бесконечно — есть аппаратные и алгоритмические ограничения. Вот хороший тривиальный пример. Допустим, у вас H100. Максимальный домен NVLink для H100, для большинства DGX H100 — это восемь GPU, верно?

Если масштабируете выше, придётся решать, как GPU общаются через InfiniBand — всё ещё очень быстро, но не так быстро, как NVLink.

swyx: Это примерно на порядок, типа в сотни раз, или

Kyle: примерно на порядок.

Да. Окей.

swyx: Не ужасно.

Kyle: [00:30:00] Да. Мне нужно вспомнить характеристики, но, кажется, около 500 гигабайт в секунду однонаправленно для NVLink и около 50 гигабайт в секунду однонаправленно для InfiniBand. Зависит от поколения.

swyx: Я просто хочу объяснить это людям, которые не знакомы с этими уровнями и скоростями передачи

Vibhu: и всем таким.

Конечно.

От ноутбука к мульти-ноде

Vibhu: Ещё, может, на пару шагов назад — большинство людей хорошо знают: можно использовать на ноутбуке Ollama, vLLM, можно просто запустить инференс там. Можно запустить на

можно запустить на этом

Vibhu: ноутбуке.

Потом доходит до: модели стали большими, верно? GLM 5, размер удвоился. Что делать, когда 128 ГБ памяти — можно запустить на Spark. Потом нужно переходить на несколько GPU. Да. Мульти-GPU — там есть поддержка. Теперь, если я компания и у меня нет

лучших исследователей для этого. Но мне нужно перейти [00:31:00] на мульти-ноду, верно? У меня много серверов. И тут проблемы эффективности, верно? У вас может быть несколько узлов по восемь H100, но как это делать эффективно?

Kyle: Да. Как их организовать? Как выбрать способ представления модели?

Да, именно. Это сложный вопрос. Все спрашивают: как масштабировать? Я хочу запустить GLM 5, которая только вышла. Новых моделей за последнюю неделю было штук четыре, кстати.

swyx: Знаете почему? DeepSeek.

Kyle: Без комментариев. О. Да, но GLM 5, верно?

У нас есть эта новая модель, она большая, и нужно разобраться с масштабированием и вверх, и наружу, верно? Потому что нужно найти правильное представление. Каждый решает это по-своему. Будем чётко это понимать. Каждый находит свой путь.

Nader: Мне кажется, во многом ИИ и ML — именно такие. Люди думают, что это простой рецепт. Был твит пару месяцев назад: почему файнтюнинг как сервис не взлетел? Может, это был я. Может, ты. Да. Но люди хотят, чтобы это был простой рецепт.

Но даже если посмотреть на ML-модель и конкретно

Kyle: на вас. Да,

Nader: да.

Kyle: И модель, [00:32:00]

Nader: ситуация — там столько тюнинга. Когда видишь модель с таким-то количеством экспертов в MoE — почему именно столько? Они просто перебрали варианты, и этот оказался лучше.

Когда дело касается обслуживания инференса, у вас куча решений, и всегда можно сделать что-то более оптимальным. Но это внутренняя калибровка и аппетит к продолжению калибровки.

Vibhu: Да. И это не значит, что никто не пытается — вот Tinker от Thinking Machines, знаете?

Да. RL как сервис. Да, верно. Это ещё сложнее, когда пытаешься обучить большую MoE-модель. Мы не лучшие в обучении MoE при pre-training. Мы видели это с Llama 3, верно? Они обучены таким разреженным образом, потому что Meta знает, что будет много инференса.

Они опенсорсят это, но оно очень заточено под инфраструктуру Meta. Они хотят много инференса. Теперь вопрос: допустим, вы хотите обслуживать чат-приложение, кодинг-копилот. Вы делаете слой RL, обслуживаете модель для X пользователей.

Это чат-модель, кодинг-модель? Dynamo, возвращаясь к этому,

Kyle: это [00:33:00] как бы, да, простите. Мы отвлеклись. У каждого свой путь.

Компромиссы стоимости, качества и задержки

Kyle: И мне нравится думать об этом через три оси. Какая модель вам нужна? Какая точность?

Я обсуждал это с Nader раньше. Есть три оси. Первая — качество, которое вы можете обеспечить: достаточно ли вы точны или можете ли выполнить задачу с достаточно высокой производительностью. Да. Есть стоимость. Можете ли вы обслуживать модель или рабочий процесс?

Потому что это уже не просто модель, это рабочий процесс. Это мульти-турновое взаимодействие с агентом — достаточно ли дёшево. И можете ли вы обслуживать достаточно быстро? Мы видим, как все три фактора работают: новые модели от OpenAI, которые быстрее, есть быстрые версии моделей.

Можно менять объём размышлений, чтобы влиять на качество, верно? Генерировать больше токенов, но при более высокой стоимости и задержке. И когда вы начинаете путь к размещению модели, вы думаете о трёх вещах. Какую модель нужно обслуживать?

Сколько раз нужно её вызвать? Какова длина входной последовательности, [00:34:00] как выглядит рабочий процесс поверх неё? Какой SLA, какой SLA по задержке нужно выдержать? Потому что обычно это константа — вы знаете SLA, который нужно выдерживать, и ищете самый дешёвый вариант, удовлетворяющий всем ограничениям.

Обычно вы начинаете с этого и делаете экспериментирование по нескольким типовым конфигурациям. Меняете размер тензорного параллелизма — формы параллелизма.

Vibhu: Нужно ещё глубже начать. Сначала — какая модель.

Kyle: Да, конечно,

конечно.

Kyle: Это многоэтапный процесс проектирования, потому что, как ты сказал, можно выбрать модель поменьше, но делать больше масштабирования во время тестирования, и она сравняется по качеству с большой моделью. Или добавить обвязку.

Так что да, это гораздо глубже. Но с точки зрения производительности — когда вы определились с моделью, вы смотрите на неё и говорите: у меня эта модель, мне нужна такая скорость. Какая правильная конфигурация?

Nader: Вы видели недавно — была статья [00:35:00] буквально пару дней назад: если запустить один и тот же промпт дважды, получаешь почти вдвое лучше. Просто попробуй

ещё раз.

Nader: Да, именно.

Vibhu: И результат гораздо лучше. Да. Но ключевое — вы даёте контекст неудачной попытки, верно? Да. Делает попытку. И это давно уже базовый совет. Просто попробуй ещё раз. Ты пробовал ещё раз? Весь совет

Nader: в жизни.

Vibhu: Это статья от Google, если не ошибаюсь?

Да,

Vibhu: да. Кажется, семь страниц, короткая. Да. Да. Название очень милое. Просто — попробуй ещё раз. Дай контекст,

Kyle: мультишот. Просто: эй, возьми чуть больше, возьми чуть больше информации, попробуй, провались. Провались.

Vibhu: И эта базовая концепция зашла довольно глубоко.

Есть, например, self-distillation RL, где ты делаешь self-distillation, RL, учитываешь прошлые неудачи, и это даёт сигнал. Люди пробуют — попробуй ещё раз. Недостаточно сильный сигнал.

swyx: Для слушателей — Vibhu и я ведём второй YouTube-канал для нашего клуба статей. О, это круто.

Vibhu как раз разбирал это. Да. Здорово. Self-distillation и всё такое — вот почему он [00:36:00] в теме.

Nader: Надо посмотреть.

swyx: Да. Это просто хорошая практика — каждому нужен клуб статей, где вы вместе читаете статьи, и социальное давление заставляет.

Nader: Мы, мы,

там

Nader: есть большая инференс-

Kyle: группа чтения

Nader: в NVIDIA. Мне каждый раз стыдно. Он выкладывает в наш чат.

swyx: Один из

Nader: ваших ребят,

swyx: активно в этом, я забыл. Eshan? Да, да.

Kyle: Eshan в моей команде, кстати. Забавно. Между нами был переход сотрудника. Eshan работал у Nader в Brev, а теперь он в моей команде.

Он был

Nader: нашим руководителем ИИ. А потом, когда мы пришли, и

swyx: потому что я всегда ищу: можно ли запустить ещё один подкаст, который делает только это? Да. И Eshan — я пытался подтолкнуть его: может, тут что-то есть? Я имею в виду, новые техники инференса появляются каждый день.

Типа, это как

Kyle: вы бы удивились, сколько блог-постов появляется. И если

swyx: был период: Medusa, Hydra, Eagle, знаете,

Kyle: теперь у нас новые формы декодирования, новые формы спекулятивного декодирования, или новые,

swyx: чему

Kyle: вы

Vibhu: рады? И это захватывает, когда вы выпускаете что-то вроде Nemotron.

Помню статью про Nemotron 3, [00:37:00] объём пост-тренинга, количество токенов, на которых GPU-богатые могут дотренировать. И это была гибридная модель state space, верно? Да.

Kyle: Она co-designed для железа.

Vibhu: Да, совместно спроектирована с железом. И одна из проблем всегда была: state space модели не масштабируются так хорошо при конвертации или что-то с производительностью.

А вы такие: нет, просто продолжайте обучать. И Nemotron многое из этого демонстрирует. Да.

Nader: Ещё крутая штука в Nemotron — он был выпущен послойно, как и Dynamo. По сути, были выпущены данные pre-training и post-training, рецепты, как это делать. Да. Сама модель выпущена. Полная модель. Вы просто получаете выгоду от того, что мы включили GPU. Но есть компании вроде ServiceNow — они взяли датасет и обучили свою модель, и мы были очень рады и отметили эту работу.

Zoom

Vibhu: другое. Zoom — это CGI, кажется. И ещё: многие модели не выпускают базовые версии. И вот — почему файнтюнинг не взлетел?

Знаете, можно обучать самому. Да,

Kyle: конечно.

Vibhu: Вы выпускаете базовую модель, кажется, вы выпускаете вообще всё.

Nader: Думаю, я знаю [00:38:00]

swyx: про базовые. По сути

Vibhu: без базовых

swyx: базовые можно использовать для снятия ограничений.

Vibhu: Да. Базовые можно использовать для снятия ограничений.

swyx: Да.

Vibhu: Safety-тренинг.

swyx: Мы полностью разобрали Dynamo? Не знаю, обсудили ли мы. Что,

Nader: Чего бы мне хотелось — ты упоминал три оси. Разложи это: что такое prefill, decode, и какие оптимизации даёт Dynamo?

Kyle: Да. Отличный вопрос. Итак, по проблеме трёх осей: есть три вещи, определяющие, можно ли что-то сделать с инференсом — стоимость, качество, задержка, верно? Dynamo должен предоставить вам среду выполнения, позволяющую крутить рычаги, двигаться по фронту Парето — той поверхности, которая определяет, возможно ли это с сегодняшним инференсом и ИИ.

Nader: Даёт вам рычаги.

Kyle: Да, именно. Даёт рычаги.

Disaggregation — Prefill vs Decode

Kyle: И одна вещь, которую мы активно используем в современном инференсе и которая становится общеизвестной — это концепция disaggregation. Исторически модели размещались с одним движком инференса. И этот движок [00:39:00] переключался между двумя фазами.

Есть prefill, где вы читаете последовательность и генерируете KV-кеш — по сути набор векторов, представляющих последовательность. А потом используете этот KV-кеш для генерации новых токенов — это decode. И несколько блестящих исследователей в разных статьях пришли к выводу, что если разделить эти две фазы, вы получаете преимущества.

Преимущества в том, что, во-первых, не нужно беспокоиться о синхронном пошаговом планировании. Движок инференса работает так: делает один шаг, завершает его, потом начинает планировать следующий. Это не полностью асинхронно. Проблема в том, что prefill и decode очень различаются по требованиям к ресурсам и иногда по времени выполнения.

Prefill мог блокировать шаги decode, потому что вы ещё делали prefill и не могли планировать, так как шаг должен завершиться. Так вы убираете эту проблему планирования и ещё позволяете [00:40:00] разделить работу на два разных типа пулов.

Prefill обычно — и это меняется с архитектурой модели — ограничен вычислениями, когда последовательность достаточно длинная. На стороне decode, поскольку вы делаете полный проход по всем весам и всей последовательности при каждом шаге декодирования, и у вас нет квадратичных вычислений KV-кеша, обычно узкое место — память, потому что вы извлекаете линейный объём памяти и выполняете линейный объём вычислений, в отличие от prefill, где извлекается линейный объём памяти, а вычисления квадратичные.

Знаете,

Nader: забавно, Exo Labs сделали отличную демку, где для DGX Spark, у которого намного больше вычислительной мощности, можно делать ресурсоёмкий prefill на DGX Spark, а decode — на Mac. Да. И вот

Vibhu: это быстрее.

Nader: Да. Да.

Kyle: Так можно. Можно делать стратификацию по машинам.

Nader: Да.

Kyle: А с нашими будущими поколениями железа мы фактически анонсировали — с Rubin — новый ускоритель, [00:41:00] специально для prefill. Он называется Rubin CPX. Итак

Масштабирование Kubernetes с Grove

Nader: У меня вопрос: при масштабировании наружу — проще ли это с Dynamo? Ведь когда нужна новая нода, можно выделить её под prefill или decode.

Kyle: Да. У Dynamo есть Kubernetes-компонент под названием Grove, который позволяет делать это сумасшедшее специализированное масштабирование. У него есть представление... не хочу слишком глубоко в Kubernetes, но раньше для запуска мульти-нодной работы использовался другой подход.

Он называется Leader Worker Set. Это часть стандарта Kubernetes, и Leader Worker Set — отличная штука. Она служила людям долгое время. Но одна из сложностей — представить набор случаев, когда у вас мульти-нодная реплика с парой, верно?

Prefill и decode — два разных типа, и как второй этап, у них есть соотношение, которое меняется со временем. Prefill и decode — разные вещи по мере изменения нагрузки, верно? Объём необходимого prefill может меняться. [00:42:00] Объём decode тоже может меняться.

Допустим, вы начинаете получать безумно длинные запросы. Вероятно, prefill масштабируется сильнее из-за квадратичного роста.

swyx: Да.

Для слушателей: prefill — это длинный вход. Decode — это длинный выход, например, верно?

Kyle: Да. Decode — decode забавный, потому что количество генерируемых токенов масштабируется с длиной выхода, но объём работы на каждом шаге масштабируется с количеством токенов в контексте.

swyx: Да.

Kyle: Так что оба масштабируются и от входа, и от выхода.

swyx: Это правда.

Kyle: Но на стороне prefill/decode, если

вдруг объём работы на стороне decode остаётся примерно тем же или немного растёт, а prefill резко увеличивается — вам не нужно, чтобы соотношение оставалось прежним. Вы хотите, чтобы оно менялось со временем. Dynamo имеет набор компонентов, которые, во-первых, говорят, как масштабировать.

Они говорят, сколько prefill-воркеров и decode-воркеров, по их мнению, вам нужно, а также предоставляют API планирования для Kubernetes, позволяющий представить и реализовать это планирование на [00:43:00] вашей реальной инфраструктуре, на вычислительных ресурсах.

Nader: Не буду врать. Немного неловко за свою гордость SVG-функцией ранее.

swyx: Нет, это было

Nader: было

реально

Kyle: мило. Я,

swyx: мне

Nader: всё это

swyx: всё инженерия. Всё инженерия.

Kyle: Технически.

swyx: Одна вещь, которая мне интересна — при всём, что вы видите на системном уровне, всё это. И мы масштабируем в распределённых системах.

Длина контекста и совместное проектирование

swyx: Один вопрос, который сейчас актуален — есть ли какой-то SOL, верхний предел. По длине контекста, скажем так, или как вам удобнее это разбить.

Nader: Да.

swyx: Я думаю: ну да, можно использовать гибридные архитектуры и добавить state space модели, сколько хочешь.

Но всё ещё выглядит очень attention-тяжело.

Kyle: Да. Длинный контекст — это attention-тяжело. У нас есть гибридные модели,

swyx: возьмём, и большинство моделей останавливаются на миллионе контекста, и всё. Да. Последние два года это потолок.

Kyle: Да. Совместное проектирование модели, железа и контекста, которое мы видим сейчас, — [00:44:00] это суперинтересно.

Это моя тайная страсть. Мы видим модели вроде Kimi или GPT-OSS. Я упоминаю их, потому что знаю конкретные вещи о них. Выходит Kimi 2, интересная модель. Архитектура в стиле DeepSeek — MLA. По сути DeepSeek, масштабированный немного иначе и, очевидно, обученный иначе.

Но они рассказывали, почему сделали определённые архитектурные решения для контекста. У Kimi больше экспертов, но меньше attention-голов, и, кажется, немного меньшая размерность attention. Нужно проверить. Неважно. Но они обсудили это подробно в блог-посте на Zhihu — это вроде нашего

swyx: Reddit. Да.

Kyle: В Китае. Китайский Reddit.

swyx: Да.

Kyle: Это невероятный блог-пост. Все ML-люди [00:45:00] в GPU-мире, кого я знаю, — очень блестящие. Но создатели Kimi K2 реально подробно рассказали об этом на Zhihu.

И они пишут: мы провели эксперимент. Attention масштабируется с количеством голов, очевидно. Если у вас 64 головы вместо 32, работы вдвое меньше. Масштабирование по-прежнему квадратичное, но работы вдвое меньше. И они сделали очень конкретный обмен в своей архитектуре: что, если дать больше экспертов — то есть использовать больше памяти.

Но сохранить количество активируемых экспертов прежним. Увеличить разреженность экспертов — отношение активируемых к общему числу меньше — и уменьшить количество attention-голов.

Vibhu: Для контекста: до этого тренд был — делать модели более разреженными.

Никто особо не трогал головы. Просто имели больше,

Kyle: ну, они неявно сделали её более разреженной.

Vibhu: Да, да. Для Kimi — да,

Kyle: да.

Vibhu: Они тоже сделали разреженнее. Но в целом тренд был на уровне: есть коэффициент разреженности. Нужно больше параметров, меньше активных — это разреженность. [00:46:00]

Но из статей лабораторий вроде Moonshot, DeepSeek видно, что они идут на уровень: помимо числа экспертов, можно менять количество attention-голов и attention-слоёв. Да. И всё это возвращается к совместному проектированию железа и модели, что по сути

Kyle: совместное проектирование железа, модели и контекста.

Vibhu: Да.

Kyle: Если бы вы обучали модель для очень короткого контекста или для задач с суперкоротким контекстом, вы бы спроектировали её так, что вас не волнует масштабирование attention, потому что оно не достигло точки, где квадратичная кривая берёт верх.

Nader: Как вы выделяете attention или контекст как отдельную часть совместного проектирования? Я бы подумал, что hardware-model co-design — это и есть hardware-model-context co-design.

Kyle: Потому что обвязка и контекст, создаваемый обвязкой, становятся частью модели.

Когда она обучена с этим,

Vibhu: типа, к концу обучения вы делаете длинный контекст, но не меняете архитектуру в процессе обучения. Да.

Kyle: Ну, можно попробовать.

swyx: Вы говорите, [00:47:00] все обучают обвязку внутри модели.

Kyle: Я бы сказал, в какой-то степени, или

swyx: есть совместное проектирование для обвязки. Я знаю, что в небольшом объёме, но, кажется, не все пошли на полную с этим.

Kyle: Думаю, важно интернализировать обвязку, в которой модель будет работать, в саму модель.

swyx: Да. Интересно. Хорошо. Bash — это универсальная обвязка.

Kyle: Верно? Приведу пример. Если можно обучить с обвязкой и вы используете эту обвязку для всего, разве вы не просто обучите с обвязкой, чтобы получить лучшее качество?

swyx: Ну, я могу привести контраргумент.

Да, конечно. Вы хотите предоставить универсально полезную модель, чтобы другие подключали свои обвязки, верно? Если вы

Kyle: Да. Обвязки могут быть опенсорсными, верно?

swyx: Да. То есть, по сути, это то, что происходит с Codex.

Kyle: Да.

swyx: Но вам может понадобиться другой инструмент поиска, и, возможно, его нужно назвать иначе, или

Nader: не знаю, насколько люди продвинулись в этом, но можно ли

обучить модель, есть ли сравнения — обучать модель [00:48:00] для обвязки или пост-тренинг для

swyx: Я думаю, это одно и то же. Одно и то же. Ладно. Просто дополнительный пост-тренинг. Я

Nader: понял.

swyx: И Cognition делает это, Cursor делает это — нужно, если ваш инструмент немного отличается, либо подогнать свой инструмент под тот, для которого обучали.

Либо отменить их обучение для их инструмента и затем — о, это — переобучить. Да. Это очень раздражает, и типа,

Kyle: Я бы надеялся, что в итоге мы достигнем определённого уровня обобщения в обучении новым

swyx: инструментам. Это не AGI-уровень, это реально тупо — типа: выучи мой инструмент, блин.

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

Просто не работает.

Nader: Забавно: мы всегда хотим увидеть тренд, который можем предсказать, но каждый раз что-то новое приходит как прыжок. Я не знаю, как мы перейдём от одного к двум, но, думаю, скорее всего [00:49:00] мы прорвёмся через это благодаря какому-то новому

Kyle: Да.

Есть интересная формализация этого. Есть эссе, довольно любопытное, от Leopold Aschenbrenner, называется Situational Awareness.

swyx: Окей? Да.

Kyle: Он вводит концепцию «расковывателя» (unhobbler), верно? Leopold в этом эссе описывает: я хочу достичь

определённого уровня интеллекта, и думаю, что до него четыре порядка величины вычислений, данных и обучения. И он говорит: дата-центры могут масштабироваться вот настолько, данные — вот настолько.

Но одно из того, что делает оставшуюся часть роста на порядки возможной — это «расковыватели», научные открытия, сделанные во время поиска архитектуры или обучения, которые радикально влияют на возможности масштабирования. Хороший пример: [00:50:00] мы видим много моделей, и это, вероятно, очень маленький «расковыватель».

Но важный для производительности. Мы видим много моделей, обученных с multi-token prediction нативно в pre-training.

По DeepSeek — в их статье написано: мы решили, что это помогло обеспечить более стабильную сходимость. Есть маленькие «расковыватели».

А есть довольно большие. Архитектурно у нас были разные типы attention. Одна из проблем — много KV, но люди нашли разные формы: group query attention и MLA (multi-head latent attention) у DeepSeek, которые уменьшают нагрузку KV на модель и позволяют увеличивать контекст.

swyx: Да. И это было очень существенно для DeepSeek.

Kyle: Да. Для контекста: полная длина контекста DeepSeek, кажется, 128 000 токенов или может быть 256 000 с расширением RoPE. Весь этот контекст, кажется, 128 000, помещается в 8 гигабайт. Раньше KV-кеш Llama 4 или 5B [00:51:00] аналогичного размера занимал 40 или 80 гигабайт в той же точности.

swyx: Да.

Kyle: Так что такие «расковыватели» реально уменьшают размер этого. И я не удивлюсь, если мы увидим возможность прорваться к 10 миллионам, 20 миллионам, 100 миллионам контекста благодаря появлению нового «расковывателя».

swyx: Понятно.

Kyle: И это просто наука.

swyx: Значит, больше алгоритмов глубокого обучения — вот что я

Kyle: слышу.

Да. Больше алгоритмов глубокого обучения.

swyx: Да,

Kyle: я бы мог на самом деле... играя в пикап-баскетбол.

swyx: И у него есть

Kyle: возможность. Я мог бы привести пример — теорию, не теорию-теорию, а что-то теоретическое. «Расковыватель»,

Nader: который тебя воодушевляет, или

Kyle: ну, и «расковыватель», который я не видел, так что это может быть тупиком и не сработать.

Но мне было бы очень интересно увидеть модель, которая делает prefill и decode по-разному. Модель, которая делает prefill локально — по документам, по кускам, — а потом decode глобально по всей последовательности, потому что логически мне не кажется, что KV обязательно должны быть ассоциативными [00:52:00] между документами, не имеющими взаимной связи.

Но это накладывает большую нагрузку на decode и чистый attention в фазе decode для установления этих связей, поскольку KV к тому моменту статичен. Есть и другие интересные техники. Но если это получится:

если prefill станет локальным, а decode останется глобальным, вы решите проблему квадратичного масштабирования prefill, потому что у вас много маленьких кусков, которые prefill-ятся независимо.

swyx: Хорошо. Ладно. Подождём и посмотрим, но я думаю, это будет захватывающе.

Kyle: Скрестим пальцы.

swyx: Да, скрестим пальцы.

Да. Да.

Vibhu: Меня воодушевляет prefill и decode на разном железе. Типа да. Покупка, верно? Можем ли мы декодировать на GR? Можем ли получить суперскорость?

Kyle: Не думаю, что мне можно это комментировать.

swyx: Mark собирается стрелять в нас стрелами.

Nader: У него духовая трубка, он в комнате, просто

Kyle: типа,

Nader: засыпайте.

Да. Да.

swyx: Но

Nader: я очень рад видеть, как команда приходит, и мне повезло поработать с некоторыми людьми из GR. Так что, знаете, да, я,

swyx: я знаю Sonny, [00:53:00] мы приглашали его на ту же

Kyle: конференцию, на которой

swyx: ты был.

Nader: Да.

swyx: И вы, ребята, будете вести сессии на GTC.

Не знаю, хотите ли вы — это хорошее место для рекламы.

Kyle: Да, да, да. Я не могу говорить о сессиях, связанных с LPU, на GTC. Понятия не имею. О, нет, это было,

swyx: нет. Твои

Kyle: на стороне GR. Да. Я использую ассоциативное NVIDIA. На стороне NVIDIA Dynamo мы проводим много сессий.

Для тех, кто не знает, — можно искать все сессии GTC онлайн, просто зайдите на сайт GTC. Не помню URL, но зайдите. Загуглите. Да. И найдите Dynamo — увидите все сессии. Их около 20. Несколько ведёт команда Dynamo.

Несколько — люди, которые используют Dynamo и хотят показать результаты. Но есть две, которые меня особенно воодушевляют. Первая — общий туториал по Dynamo. Я выступаю с Harry, нашим главным продукт-менеджером Dynamo.

Мы рассказываем, как использовать Dynamo для лучшей производительности и куда мы видим развитие Dynamo. [00:54:00] И есть ещё одна сессия с нашей командой агентов в NVIDIA — о будущем агентов в продакшен-инференсе. Мы говорим о новом горизонте с агентами, потому что обвязки придают структуру вызовам.

Если сравнить прошлое и настоящее в том, как работают вызовы LLM: раньше, когда были чат-боты, каждый вызов был очень разным. Практически никакой структуры. В разговоре могла быть неявная структура из-за мульти-тернового общения.

Но агенты имеют обвязку, которая следует правилам, верно? Она напрямую структурирует контекст. И вы это видите — был интересный твит о том, как Claude Code структурирует свой контекст, чтобы получить максимум попаданий в кеш.

Кажется, это написал один из PM Claude Code.

И структура, которую обвязка может придать, [00:55:00] идёт рука об руку с совместным проектированием инференса. Так что я провожу доклад — не помню название и номер сессии, но можете найти меня по имени на сайте GTC — о том, как мы ускоряем агентов и какие конкретные оптимизации для агентов мы видим в Dynamo и в инференсе вообще.

swyx: Да. У Claude Code, кажется, только один PM, это Wo, а остальные — Devrel, Boris. Может, это был Devrel. Да, именно. Давайте перейдём к агентам. Это была последняя часть нашей запланированной дискуссии. Как мы ещё не говорили про агентов с вами?

Ну, мы планировали: я хотел связных разделов, или

Vibhu: ну, есть же большая новость, верно? Масштабное развёртывание NVIDIA. Да, NVIDIA

swyx: использует всё. Мы используем Cursor и Claude Code,

Vibhu: но это довольно серьёзное развёртывание, верно?

Это десятки тысяч людей.

Nader: Точно. Да.

Vibhu: Что? Это,

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

[00:56:00] И если она упрощает жизнь, она распространяется как лесной пожар.

Kyle: Часто Jensen получает это и говорит: давайте заставим это работать. Да. По всей компании. Давайте заставим это работать прямо сейчас.

Nader: Честно, если бы я был стартапом, классный хак: если у вас есть что-то, что экономит время NVIDIA, они распространят это на пару человек, и дальше то же самое.

Верно? Распространится как лесной пожар. Окей.

Vibhu: Осторожно, а то имейл завалят стартапы. Ну,

Nader: надо знать нужного человека. Но нет, я, да, мне нравится Codex. Это было невероятно весело. Да. Использую и лично, и на работе. Было

Да, не знаю. Было здорово видеть раскатку. Кое-что забавное. В тот день, когда мы получили доступ к Codex и Claude Code, я нашёл одного человека — его зовут Carlos — в компании. Он написал CLI для Outlook.

Kyle: О да.

Nader: CLI для почты. И это было, я

Kyle: использую его.

Nader: Да, может, недель четыре-пять назад.

Когда я получил доступ к Codex, я установил CLI, там был скилл, и я просто попросил пройтись по всем моим имейлам — они очень захламлены. Так что если я не ответил на ваше письмо — извините. Я попросил дать мне резюме, [00:57:00] выделить эскалации, которые нужно посмотреть, поместить треды, на которые стоит ответить, в папку, а всё остальное заархивировать.

И он сделал. Так что если я пропустил ваше письмо, это потому что оно не попало,

swyx: значит, мне нужно вставить prompt injection в письмо. Да, да. Лучше просто звоните по FaceTime. Да. Мой SLA самый быстрый в FaceTime.

Nader: Но это была магия. И я отправил это в большой тред на 500 человек. Куча людей попробовала.

Я начал звонить по FaceTime всем, кому мог в компании, чтобы помочь настроить.

swyx: Да. Этот конкретный пример — вы же работаете с довольно конфиденциальными письмами.

Nader: Да.

swyx: Был ли обзор безопасности?

Безопасность и агенты

swyx: Потому что один парень сделал это для себя, но это же не предназначено для всех.

Nader: Команда безопасности NVIDIA невероятна.

Респект им. Они прогрессивны и понимают, что это

Kyle: реально важная технология, и её нужно внедрять. Если подумать: в крупной компании ваш ноутбук обычно сильно ограничен, если

Nader: доступ только к определённым вещам.

У инженеров NVIDIA этих ограничений нет. Ожидается, что вы понимаете риски, когда пробуете что-то. Поэтому [00:58:00] мы очень быстро подключили безопасность к тому, что делали.

Модель разрешений агентов

Nader: Мы много думаем об этом, особенно с OpenClaw, верно? Знаете, агенты могут делать три вещи.

Да. Агенты могут делать три вещи. Они могут получать доступ к файлам, к интернету, и теперь могут писать код и выполнять его. Вы буквально позволяете агенту делать только два из трёх. Если он может получить доступ к файлам и писать код, вам не нужен доступ к интернету, потому что это полная уязвимость, верно?

Если у него есть доступ к интернету и файловой системе, вы должны знать полный объём его возможностей. Иначе может быть внедрён вредоносный код или что-то подобное. Мы много думаем о том, как одновременно дать этому развиваться — это явно будущее.

Но при этом — какие точки контроля мы можем начать защищать?

swyx: И есть ли какая-то директива типа: у нас корпоративный аккаунт или соглашение с OpenAI, мы используем модели OpenAI здесь, или выбирайте что хотите.

Nader: Нет, нет. Я бы никогда не поместил данные компании в модель, которая не является нашей или даже... самая строгая безопасность.

Да. Да. Мне нравится, как

swyx: это устроено. Знаете, очевидно, вы можете запускать свои [00:59:00] модели. NeMo и, верно, у нас есть внутренний кластер, так что, конечно, случайным образом.

Kyle: Да.

swyx: Да.

Nader: Думаю, мы первые клиенты Dynamo. Поехали!

Build Nvidia Inference Gateway

Kyle: Кстати, забавная история о том, как я получил опыт, который определил, что нужно для Dynamo.

Есть сайт build.nvidia.com, а также infra.nvidia.com. Он позволяет людям пробовать модели. Даёт API-сервис. Можно вызвать модель через REST API и получить ответ. Я управлял модельной стороной, и в одно время это было самым крупным развёртыванием инференса в NVIDIA, и, возможно, до сих пор является. С тех пор я передал это другим, и они великолепно справляются. Это чрезвычайно

Nader: недооценённый ресурс. build.nvidia.com. Там можно получить любую из этих опенсорс-моделей. Есть ограничение по запросам, но это бесплатно. Идеально для хакеров, чтобы

Kyle: и SLA на запуск моделей в первый день — около суток.

Да.

Kyle: Они невероятно хороши в том, чтобы [01:00:00] найти правильный способ размещения модели и запустить её как можно скорее после выхода.

swyx: Ты этим управлял?

Kyle: Да, я управлял этим давно. Изначально это называлось NVIDIA AI Playground, потом AI Foundation. Да. А потом Build NVIDIA.

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

Но я занимался: как доставить модель до кремния? А ещё работал с продуктовой командой, определяя, какие модели важны — очень давно.

Да. Да. Есть ещё промежуточный уровень, верно? Для хакера — попробуй что угодно.

Есть консоль Brev, есть Dynamo, были ещё NIM, верно?

Kyle: Да.

Помню, у них был свой момент славы год-два назад. Они всё ещё?

Nader: Да. NIM — это инференс... я думаю, это аббревиатура. [01:01:00] Просто название. Но NIM — это способ для предприятий взять любую из наших технологий и запустить с поддержкой и всем прочим.

Это включает Dynamo. Включает, не знаю, все наши другие оптимизации, упакованные для Enterprise. Да.

swyx: В общем, ты получил кучу опыта, управляя внутренним инференс-шлюзом и площадками для экспериментов.

Kyle: Да, получил. И ещё создал первый внутренний NVIDIA VS Code.

Мы называем его NV Code.

swyx: Это было расширение.

Kyle: Да, сначала это был форк VS Code.

swyx: Мы шутили — абсолютно нет. Это было давно, типа: надо сделать четвёртый хакатон по форкам VS Code. Уже четыре. Лучший форк VS Code. Мы,

мы делали хакатон — как заработать миллиард, там был кто-то из VS Code, и он был типа готов поучаствовать, и я такой,

swyx: о, вам стоит это сделать.

Вот и всё. Потом крутой штукой стал хакатон по форкам Chrome.

Chrome.

swyx: И нет, нет, IDE больше не в моде.

Nader: Я видел, как это называется?

Хакатоны и мечты об автономности

Nader: Я разговаривал с Joseph из Roboflow, и они партнёрствуют с Chrome. Мы обсуждали, как с новой моделью Alpha Mayo — NVIDIA только что [01:02:00] выпустила опенсорс. Те Mercedes, которые вы видели, — знаешь?

swyx: Да.

Nader: Выпущены. Мы опенсорсили модель автономного вождения. Да, и мы думали: можно ли на хакатоне сделать беспилотную машину? У меня старая машина. Давайте просто попробуем.

swyx: Берём,

Nader: отвезём её, типа, обучим с камерой, среди бела дня. Посмотрим, дадим всем — сколько камер нужно?

Одна, две,

swyx: три, четыре. Не знаю. Пять, шесть.

Nader: Не знаю. Но мы попробуем, присоединяйтесь.

swyx: Можем даже

Nader: устроить гонку. Первый, кто автоматизирует своё

swyx: вождение. За выходные. У нас есть трек автономности на World's Fair. Waymo были там. Да.

NVIDIA присылала людей на это. Не потому, что у них не было модели вождения тогда.

Nader: Да.

swyx: Да. Это круто.

Да. Comma тоже имеет версию этого. Comma — у них опенсорсное вождение. Они делали весёлый хакатон по

swyx: этому. И я реально хочу Tesla с тесловским уровнем автопилота.

Да.

swyx: Но в формате Smart Car — двухместный. По сути инвалидная коляска с [01:03:00] крышей.

И их только производят, но спрос упал. Они, нет, поняли это, наверное, лет пять назад. Да. Правда?

swyx: Да.

Они были сняты с производства.

Kyle: Мне кажется, кто-нибудь купит бренд, и он возродится.

swyx: Я бы купил, типа

Kyle: наверное. Кто-нибудь услышит это и купит

swyx: вашу машину. Да. Да. Безумие. Mercedes, потому что, кажется, 10 Mercedes, Mercedes — я думаю, Mercedes их производил.

Не знаю. Мне кажется, они владеют брендом, и вы выкупите

swyx: — может, ваша мечта сбудется. Окей.

Мы выходим за рамки, и каждый раз, когда я пытаюсь припарковаться в Сан-Франциско, мне нужен Smart Car, потому что 20% парковок в Сан-Франциско рассчитаны только на Smart Cars.

Nader: Да. Правда?

swyx: Ну, это торговый центр.

Nader: Тут даже было поздно, пытаясь... Это от человека, который, по сути, вообще

Kyle: не водит.

Nader: Вот где Vespa была лайфхаком. Да, точно. Знаете, что стало с Vespa? Раньше у меня был жёлтый [01:04:00] Vespa. Я оставил его у хакер-хауса, когда мы уезжали. Он просто стоял. И где-то месяц назад его нет. Я сегодня заметил.

Не знаю. Можно... На самом деле это кража. Вы забыли про него.

swyx: Да.

Nader: И оставили.

swyx: Да. Да. Нет, наверное, его увезли как брошенный объект. Кстати, о хакатонах — хочу отдать должное самому короткому в мире хакатону. Давайте. Вы делали его дважды. Будете

Nader: несколько раз? Да. На GTC будет один.

У нас куча заданий, которые мы ещё не анонсировали. Приходите со своим агентом и пытайтесь пройти эти

Kyle: задания. Это как идея хакатона на ноль минут — вы просто приносите агента, и нажимаете кнопку «старт». Кодить нельзя. Работает только агент.

Это хороший скрытый имейл, верно?

Kyle: Да.

Вы делаете банку? Делаете

Kyle: Было бы круто увидеть от Cognition или кого-то ещё: приходите с агентом. Бросьте его.

Потому что вы не знаете, вы как супервизор.

Ну, допустим, [01:05:00] управлять браузером, заказать пиццу. Посмотрим, как оценить, знаете.

swyx: И

Kyle: вы не знаете, какое

swyx: задание.

Kyle: Да. Не знаешь задание. Или даже не знаешь критериев оценки, и потом тебе дают критерии. Типа: попробуй максимум.

Здорово. Это превращается в обеденную вечеринку. Отличный бизнес. Видите,

Kyle: в общем, забавная история.

Агентный UX и CLI повсюду

Kyle: Кстати, у нас в NVIDIA есть несколько человек — мы работали с безопасностью, чтобы приблизить агентов к вычислениям. Теперь у нас есть штуки, где можно сказать Dynamo: запусти эксперименты на таком-то кластере, прямо сейчас, поставь в очередь, и когда получишь — отправь такую нагрузку. И мы реально смогли решать задачи за один заход.

Раньше с Dynamo нужно было подбирать конфигурации — мы частично автоматизируем это, но нужна хорошая начальная конфигурация. И у нас просто агент полностью решает это за один заход: получает вычисления, запускает [01:06:00] пару экспериментов.

Говорит: вот лучшее, вот фронт Парето. Запускай это. И мы отдаём это людям — быстрее всего, что у них есть.

Nader: Агентный UX и агентный маркетинг суперважны. Мы много думаем об этом. Alec переделывает весь Brev CLI, чтобы можно было просматривать все доступные типы вычислений.

Не знаю, скоро ли, но потом можно будет смотреть, какие GPU доступны, и провижинить прямо оттуда. Можно пайпить все команды. И это возвращает к Outlook CLI: если кодинг-агенты. Забавно. Мне кажется, кодинг-агенты были гораздо эффективнее агентов общего назначения.

И большая часть причины — у них просто есть доступ к терминалу, как ты сказал, а значит — ко всему, что вы установили. Он может запускать. Он пишет код, компилирует, если ошибки — исправляет, запускает тесты — всё через терминал.

И вот, для идеи — что меня воодушевляет в CLI: мы теперь строим CLI для всего бизнеса. Slack CLI, Workday CLI. Да. Я и для себя сначала сделал. Правда? Да. Мы собираемся [01:07:00] всё это опенсорсить.

И да, все CLI для бизнес-приложений. Мы были бы рады, если кто-то подхватит это и создаст, не знаю, Open CLI Foundation или что-то такое. NVIDIA с удовольствием поддержит любого, кто этим занимается.

Каждый Devrel-инструмент должен иметь хорошую поддержку CLI на данном этапе.

Да. Когда-то главное было — чтобы ваша документация была доступна для LLM, верно? Хорошая LLM-совместимая документация. Нет, теперь всему нужен CLI.

Nader: Да. Забавно, верно? Вычисления начались с терминала, с шелла, но мы решили, что это не эмпатично к людям. Построили красивые интерфейсы, а теперь LLM навигируют наши интерфейсы.

И по иронии — теперь мы не эмпатичны к машине.

swyx: Да.

Nader: Да. Просто дайте LLM доступ к шеллу.

swyx: Одна вещь, которая меня немного напрягает: зачем строить CLI? Почему нельзя просто выставить API?

Kyle: У меня есть интересный ответ. Есть несколько причин.

Портативность — одна из проблем. Иногда API не обнаруживаемы или недоступны [01:08:00] из некоторых сред. Есть элемент локальности: CLI — это буквально ваше взаимодействие с локальной системой, что немного отличается.

Можно и через API, но вот вопрос: в чём разница между CLI и MCP? Они занимают одну и ту же нишу: вызываешь, оно что-то делает в системе, и всё. Я думаю, что в pre-training просто огромный объём

О, хорошо. Данных командной строки. Да.

Да. Даже если забыть обучение с обвязкой — просто объём документации по CLI versus API для навигации по файловой системе через командную строку — он огромен.

Nader: Да. Да.

Kyle: Верно.

Nader: Думаю, есть ещё пара вещей. Во-первых, твоя интуиция верна: CLI — это просто обёртка над API,

swyx: верно? Функционально

Nader: функционально, верно? Да. И это удобно, потому что, во-первых, вы очень конкретны и даже педантичны в том, что определено, и это хорошо — вы описываете пространство задачи.

Вы знаете, какие [01:09:00] сетевые вызовы делаются — не произвольные, предопределённые, что важно с точки зрения безопасности. А если бы вы писали кучу API-запросов, модель бы, наверное, использовала Python? Мне нравится, что CLI — это просто дефисы, это универсально. И не нужно проверять переменные окружения. Если версии Python разные — будет ли одна и та же модель писать разный код?

Скорее всего, да. Так что CLI — это как единый стандарт, верно? Да. Для людей. Да. Нет, я думаю — принимать эти решения заранее, а не на лету.

swyx: Последнее на тему агентов, я думаю — ко-локация или как это назвать. Один паттерн, который я отслеживаю в этом году. Я всегда думаю, какая тема года. Прошлый год — точно кодинг-агенты. Этот год — точно кодинг-агенты, выходящие из песочницы и расширяющиеся в мир. Определённо. Итак

Vibhu: вы арендуете человека?

swyx: Да. Да.

Я на этой платформе.

swyx: Правда? [01:10:00]

Я стою $5 000. Сделаю что угодно. Правда? Вроде да. Мне нужно, ну

swyx: забрать мою покупку из Costco.

Но лучшая часть — только агент может меня забронировать, знаете?

Да.

swyx: Это очень

Kyle: обычно типа,

swyx: это просто ещё одна биржа труда. Mechanical Turk был этим.

У меня странная история, почему я это сделал. Возвращаясь к вашему примеру — дать агенту доступ к вычислениям, верно? Да. Вы в NVIDIA GPU-богатые. Да, я подключил.

Nader: Он этого не стесняется.

Локальные GPU и масштабирование инференса

У меня 24/7 работает агент, подключённый к RunPod.

Он не выключает инстансы. И я такой: я промптил, я давал инструкции — выключай, когда закончишь. Он отвечает: мне нужно держать тёплым, скоро понадобится. И ужасно оценивает время — они понимают: 45 минут. Через 45 минут выключу.

45 минут человеческого времени — это три минуты агентского, так что он типа: загружаю, жду, оставлю включённым на всю ночь. И Moo хорошо выключает после неактивности. Я держал его на локальном сервере — две GPU. Он просто работает. У меня теперь обогреватель дома. Осторожно.

[01:11:00] По сути, знаете, им всё равно — концепция денег не важна. Просто жги. Мне нужно. Полезно.

Nader: И ещё один DGX Spark будет очень кстати. Я считаю его суперполезным для агентов, потому что покупаешь один раз, подключаешь, и они могут работать. Сейчас будет реклама NVIDIA.

Kyle: Хорошо. Карты Blackwell RTX 6000 Pro — только Pro, кажется, $8 000. Немного дешевле. Ну, намного дешевле дата-центровских карт.

Vibhu: Да.

Kyle: И у неё 96 гигабайт VRAM. Так что если вы и ваша команда хотите запустить локального агента дома.

Ощущение такое: хм. У неё значительный объём VRAM. Я думал купить и поставить в подвал, но соседи бы меня возненавидели.

Это просто одна двух-трёхслотовая GPU. В основном,

Kyle: да, это PCIe.

Да, это

Kyle: PCIe GPU. Можете купить. Главное отличие от игровых RTX — это Blackwell Pro, профессиональная GPU, и у неё [01:12:00] много VRAM, значит можно запускать довольно большие модели.

Можно поставить четыре таких в систему, для максимальной конфигурации — это зверь.

Kyle: Мощный. Можно запустить — это 96 гигов, или что-то около того? 96 — ну, на системном уровне.

Но они тоже медленные. Производительность будет ниже по сравнению с API-типа,

Kyle: о да, это правда. Опять же, главный урок: эффект масштаба позволяет получить и скорость, и пропускную способность.

Приведу пример. Есть оптимизация Wide EP. Не буду подробно, но она активно использовалась для максимизации инференса DeepSeek. Есть отличные материалы от NVIDIA и Semi Analysis о том, почему Wide EP важен. Для MoE-моделей это по сути необходимо, и уровень параллелизма — 32.

Это выходит за барьер восьми. И реально важно иметь NVLink [01:13:00] для обслуживания в масштабе. Я не помню точное улучшение стоимости по сравнению с Hopper, но для этой системы — примерно в 35 раз дешевле за токен для большой части кривой.

Да. Что безумно.

swyx: Да.

Kyle: И это нормализовано на GPU, очевидно, потому что стоимость GPU — часть общей стоимости.

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

Да. Разные промпты, локально и так далее. Например, одна вещь, которую делает Claude — перед началом поиска запускает быструю модель контекста, просто для поиска по кодовой базе. Это лучше индексации [01:14:00] во многих случаях, не во всех, и нужно индексировать для некоторых вещей. Но идея, что агенты должны управлять субагентами и, возможно, запускать их близко к инференсу.

Не знаю, архитектурно ли это возможно или даже

Kyle: Да, мы думаем об этом для Dynamo. Это наша главная тема года.

swyx: Потому что если вы заложите это в свой продукт, гораздо больше людей будут его использовать. Сейчас это скорее теоретически, потому что

вы платите много за координацию туда-обратно. Да.

Vibhu: Думаю, в итоге это ускорит. На базовом уровне: спекулятивное декодирование — запускаете маленькую модель, две инстанции, но это не

swyx: один пример. Да.

Kyle: Да. Но с агентами немного иначе.

Агенты — это не спекулятивное декодирование. Я бы обобщил этот тренд так: это год «система как модель». Вместо одной модели у вас система моделей и компонентов, работающих вместе, чтобы эмулировать чёрный ящик модели.

Когда вы делаете API-вызов к чему-то, что является мульти-агентной системой внутри, снаружи это всё ещё выглядит как вызов модели. Вы получаете

swyx: гранты, но под капотом.

Kyle: Да, под капотом. Это как [01:15:00] миллиард разных моделей. И это много сложности, с Dynamo и другими библиотеками NVIDIA мы помогаем управлять

Nader: этой сложностью.

Да. Забавно, потому что для CES мы выпустили модельный маршрутизатор для DGX Spark — локальная модель на Spark и фундаментальная модель, и маршрутизатор решает, куда отправлять запросы. Это больше не «или-или».

Используйте лучшее из доступного. Есть хорошая пост-тренинговая модель, работающая на

swyx: этих. Это также функциональность Brev — управление Spark.

Kyle: О, это было бы круто. О да,

swyx: я бы хотел. Фича-реквест. Вот так.

Долгоживущие агенты и размышления о Сан-Франциско

Kyle: У меня вопрос: как долго, по-вашему, агенты будут работать?

Потому что я обдумываю: что будет, когда, я

всегда будет

Kyle: это

даже влияет на prefill/decode, верно? Codex по сравнению с Claude Code работает гораздо дольше над задачами. Может работать 6, 7, 8 часов.

Я запускаю на ночь.

Kyle: Да.

Возвращаюсь, у меня простенький логгер, и бывают моменты, когда агент решает: углублюсь в исследование — и [01:16:00] съедает 80 000 токенов. Ещё заход, ещё. Просто прожигает токены. Ну, так оно устроено.

В конце концов он решает длинную задачу. И я думаю, эти расходы будут только расти. Да.

Nader: Да, спрос на токены ненасытен, и каждое улучшение только увеличивает наш спрос. Забавно, верно? Если у вас есть коллега, и вы просите его сделать задачу, а он спрашивает: мне сэкономить усилия и не сильно думать?

Я такой: ни за что.

Мне нравилось: можно дать четыре попытки, верно? Да. Оригинальный Codex до приложения. Зачем один вызов — дай четыре попытки? Просто используй все токены. Попробуй ещё. Попробуй ещё. Это

Kyle: типа Meta Index, верно?

Штука, которая отслеживает, как долго модели могут работать. Я ожидаю логлинейный, если не логсуперлинейный рост. До конца года мы увидим агента, способного работать более 24 часов с сохранением самосогласованности всё это время.

Я бы ещё указал, что разные домены имеют [01:17:00] разные потребности, верно?

На потребительском уровне меня немного раздражают 20 минут на базовый запрос. Конечно, можно оптимизировать 6–8 часов. Но я не вижу, как буду отправлять агентов на неделю. Для GPU-ядер, медицины, биологии — да, в тех доменах отправляй много. Так что это будет зависеть от домена, потому что нужно ещё и настраивать.

Kyle: Один забавный пример — налоговая декларация. Верно. Налоги. Да. Хорошо. Да.

Nader: Сделай правильно. Интересно, может ли это стать чем-то вроде спекулятивного декодирования — когда агент ночью предугадывает, что вы будете промптить завтра, и предзагружает.

swyx: Да, можно

так.

Nader: Да. Правда? Предсказание ветвлений.

swyx: О, ну нет, это слишком низкоуровнево, но да. Извините. Да, да, да. Один вопрос: мы записали часть с людьми из METR. С Sarah, прямо здесь. Их график — это эквивалентные [01:18:00] человеческие часы работы, а не время, в течение которого агенты автономны.

И это огромная разница, верно? Человеческая работа — пять часов, агентская — 30 минут. На самом деле 30 минут, а не пять часов. Тот график, который вы видите — это их оценка эквивалентной замены человеческого труда. Anthropic выпустил более свежий график.

Он показал автономность Claude Code по их продакшен-трафику — от 20 до 45 минут. Вот примерно где мы сейчас. Да. Да, это реалистичные цифры. Хотя, конечно, есть экспериментальные сетапы, где можно просто промптить агента продолжать, когда он останавливается.

И, очевидно, это может длиться как угодно долго.

Nader: Мне кажется

по моему

Nader: опыту. Да. 20–40 минут кажется правильным для Codex или Claude Code. Но вот, я всегда пытаюсь — если хочу запустить новый проект с нуля, я часто начинаю повторять, и он завершится, и я снова, да, да.

Запускаю, как из нового V3-агента. Он открывает браузер, кликает, находит баги и продолжает работать. Мой максимум — больше часа. Эй, я работаю.

Думаю, [01:19:00] прежде чем мы увидим суперкдолго работающих агентов, произойдёт скачок эффективности.

Конечно, можно потратить час и пойти неправильными путями, но хочется быть эффективнее, умнее в рассуждениях, верно? Так что, думаю, время сначала снизится, а потом снова вырастет. Не стоит масштабировать неоптимизированные системы просто так. При всей моей любви к «используй все токены» — они дорогие.

Переход от обычных моделей к рассуждающим — это дополнительная стоимость, верно? Вы платите за кучу токенов, и нет смысла масштабировать неоптимизированное. Всегда есть этот баланс.

Nader: Да.

Но увидите обе стороны.

Nader: Да. 2023 год был суперзахватывающим.

Если вы были в Сан-Франциско, вы понимали: окей, это будет огромный, меняющий мир момент, но казалось, что больше никто ещё не знал. А может, 2022?

swyx: Да, да. Я бы сказал, RU был твит, где все были в SF с 2021 по 2023. Да.

Понимали, каково быть поздно-ранним.

Nader: Точно. 2021 — тогда я создал первый аккаунт в OpenAI. Да, пошло. [01:20:00] Это было безумие. Помню, было так смешно, потому что в то время SF переживал не лучшие времена. И ощущение было такое: концентрация основателей в городе выросла, потому что соседи, которые раньше занимались всяким, — все уехали.

Единственные, кто остался в городе — люди, которые реально хотели строить. Техника дешевела. Да. Аренда тоже. Мне жаль всех, кто сейчас ищет жильё. Но Celo — у них был огромный офис.

swyx: Блокчейн. Да, заняли старое здание Casper.

Nader: Да. У них был шоурум и задний склад. Огромный офис. И

swyx: он прямо напротив OpenAI в Mission.

Nader: Да. Это была

оригинальная Arena.

swyx: Я назвал Arena из-за этого.

Nader: Да. Да. И это было очень захватывающе, потому что Voiceflow, кажется, Minify.

Да. Minify, Brev были там. Вы были там. Помню. Именно там ты купил домен AI Engineer.

swyx: Да. Я не знал, чем буду заниматься в ИИ. Хочу что-то делать,

Nader: но это был крутой момент, когда мы все были в одном пространстве, и [01:21:00] не знаю.

Это было реально классное сообщество, особенно на таком раннем этапе.

swyx: Да. И ты достал мне ранний доступ к Cruise. О да. Был период, когда и Cruise, и Waymo были бесплатными. Да, всегда.

Если у тебя был доступ. Они и сейчас дешёвые. Cruise снова открылся.

swyx: Да. Теперь Zoox.

Zoox — это Zoox-робо-такси. Да. Точно. Да.

Nader: О. Ну да. И классно, что у вас студия так близко к Celo. Да. Скалодром за углом. Было типа, 2000. О да. Отличный квартал.

swyx: Круто. Да. И ваше партнёрство с Brev.

Одна вещь, которую я пытаюсь делать с подкастом — доносить атмосферу Сан-Франциско до всего мира и, может, дать... да.

Nader: Да. Мой любимый доклад был в городе, и

swyx: да, выступай и стримь. Знаю. Очень хорошо.

Nader: Да. И, думаю, быть в Сан-Франциско — это когда все кажутся очень поддерживающими.

Иногда мне кажется, что город верит в тебя больше, чем ты сам. И, не знаю, помнишь ли — я помню, [01:22:00] как опубликовал свой первый блог-пост, познакомился с тобой в Twitter, и ты случайно уделил мне час. И вроде как помог мне с написанием контента для разработчиков.

Я старался не быть рекламным и не пиарить себя. И из-за этого убрал всю индивидуальность из поста. И ты вернул это. Сказал: людям нормально слышать, чем ты занимаешься. Не нужно стесняться. И я помню — это реально помогло мне понять наш голос и не прятаться от него.

Так что всегда благодарен. Эй, теперь ты вкладываешь свой голос буквально во всё. Это на самом деле огромное преимущество — быть

Kyle: искренним в том, что тебе важно.

swyx: Да. Да. Представьте: какой-то инфраструктурный чувак пишет: можешь дать обратную связь на блог-пост? И он скучный, и ты такой.

Нашёл: выглядит интересно. Созвонимся. И встречаешь этого парня. Да, верно. Столько энергии, просто будь собой. Но люди приучены писать определённым образом в школе. И они не видят более широкой перспективы.

И

Nader: много нужно разучить.

Kyle: Писательство.

Писательство — это мышление. Все мыслят по-разному. [01:23:00] Так что пишите по-своему.

swyx: Да. Да.

Kyle: Пишите по-своему.

swyx: Круто. Спасибо, что поговорили с нами. Очень широкая, но увлекательная дискуссия. Мне нравится — вы как молодые лица NVIDIA, с такой энергией, но и с глубиной, и я думаю, люди многое узнают из этого выпуска.

Спасибо.

Nader: Было потрясающе. Спасибо вам. За всё, что вы делаете — доклады, подкаст и всё остальное. Увидимся на GTC. Круто. Спасибо. Здорово. Спасибо. Спасибо.

Обсуждение этого выпуска

Latent.Space