Самостоятельно разработанный ASIC OpenAI в сравнении с Rubin, TCO Jalapeño, пропускная способность на МВт и пикантные подробности
OpenAI последние пару лет тихо разрабатывала «Jalapeño» — чип для инференса, о котором было объявлено на Hot Chips. Слухи об успешном tapeout ходили уже некоторое время. Но теперь у нас есть подробности. OpenAI пригласила нас посмотреть на свой чип, приехать в их лаборатории, чтобы убедиться, насколько всё это реально, и провести бенчмаркинг с помощью нашего набора InferenceX.
В июне OpenAI представила программу разработки чипа в партнёрстве с Broadcom, создав его с нуля исключительно для инференса LLM. Работа над дизайном началась в середине 2024 года: от найма первых сотрудников команды до tapeout производства прошло около 16 месяцев — чрезвычайно быстрый цикл разработки ASIC.
Как правило, чипы первого поколения неконкурентоспособны, но OpenAI ломает эту тенденцию: её чип является лидером отрасли и превосходит каждый чип Nvidia, AMD и Google, который нам удалось протестировать, на нескольких ведущих моделях с открытым исходным кодом. OpenAI добивается этого благодаря экстремально тесному совместному проектированию аппаратного и программного обеспечения. Удивительно, но OpenAI не делает чрезмерную специализацию под какую-то конкретную часть инференса модели, а вместо этого сосредоточилась на создании универсального чипа, обеспечивающего высокую производительность во всех сценариях.
В этой статье мы подробно разберём архитектуру, программное обеспечение и результаты производительности Jalapeño в InferenceX.
Универсализированный чип для инференса
Все говорят, что чип OpenAI специализирован под модели OpenAI, но это неправильно: OpenAI создала универсальный чип для AI-инференса.
Сроки разработки просто безумные. Это показывает, что утверждения о том, что использование ИИ ускоряет проектирование чипов, реальны. Несмотря на столь быстрые сроки, OpenAI потратила много денег, принимала прагматичные проектные решения, а её команда просто невероятно сильна, поэтому это неудивительно.
Если просто посмотреть на спецификации, чип сразу становится серьёзным претендентом:
А использование HBM4 выделяет его как сопоставимый с флагманскими GPU NVIDIA и AMD:
Значительная часть медийного освещения этого чипа основывалась на нескольких вскользь сказанных OpenAI комментариях о том, что чип будет оптимизирован под их модели так, как другие чипы не будут. Это неправильно. Jalapeño — универсальный чип для инференса, способный запускать самые разные модели и самые разные нагрузки, включая наш бенчмарк InferenceX, который мы запускали вместе с инженерами OpenAI в лаборатории. В качестве шутки OpenAI даже показала нам Doom, работающий на её чипе: игру портировали на чип практически исключительно с помощью промптов Codex.
Ниже представлен наш главный результат по perf/W — пропускная способность токенов на МВт всей системы. Jalapeño разносит все остальные чипы. Всё это достигается без Multi Token Prediction (MTP), тогда как остальные чипы на графике используют лучшие конфигурации соответствующих SKU, причём все они используют MTP.
Jalapeño превосходит Blackwell по perf/W почти во всех сценариях, при этом не будучи настроенным под какую-либо конкретную точку кривой. Он превосходен не только в сценариях с низкой задержкой, но и в сценариях с высокой пропускной способностью. Более корректное сравнение «яблок с яблоками» — с результатами Single Token Prediction: здесь Jalapeño просто оставляет всех конкурентов далеко позади. В сценариях с низкой конкуррентностью Jalapeño демонстрирует выдающуюся интерактивность, достигая более 700 токенов в секунду на пользователя при concurrency 1 на модели DeepSeek R1.
Невероятно, но всё это достигается с помощью предсказания одного токена (STP), без speculative decoding и без разделения prefill/decode. Помимо DeepSeek R1, мы также увидели несколько других моделей, включая Kimi-K2.5 и GPT-OSS, которые работали примерно на уровне 1 400 ток/с/пользователя. Для всех моделей мы подтвердили, что результаты Jalapeño в GSM8k evals сопоставимы с результатами чипов Nvidia.
Есть несколько оговорок. Во-первых, все приведённые цифры предоставлены нам OpenAI. Мы лично проверили запуски InferenceX в лаборатории, но не запускали полный набор бенчмарков InferenceX и не видели результатов AgentX. AgentX — наш предпочтительный набор для сравнения производительности чипов благодаря длинному контексту и характеристикам multi-turn используемых датасетов, которые отражают поведение кэша в реалистичных production-workflow. Фреймворки, хорошо работающие на 8k1k, могут показывать худшие результаты на AgentX, поскольку реальные production-нагрузки сильнее нагружают такие компоненты, как роутеры, механизмы prefix cache, управление кэшем, инфраструктуру offload и т. д. Одноходовые 8k1k-тесты этого не проверяют. Подробнее об этом — в нашей статье об AgentX.
Во-вторых, мы считаем сравнение с Blackwell несколько неполным и несправедливым. На самом деле Jalapeño конкурирует с такими чипами, как Rubin, которые также используют HBM4. Системы Vera Rubin уже начинают поставляться клиентам, тогда как пройдёт ещё некоторое время, прежде чем у OpenAI появится что-либо кроме инженерных образцов Jalapeño.
Таким образом, производительность на самом деле следует сравнивать с Rubin, а не с Blackwell, и в некотором смысле мы ожидаем, что кастомный чип вроде Jalapeño превзойдёт Blackwell. Vera Rubin NVL72 обеспечивает 5,4× perf/MW по сравнению с GB200 NVL72, как мы описывали в нашей статье, анализирующей заявления NVIDIA о производительности при запуске совместно с CoreWeave в прошлом месяце. Ниже мы сравним Jalapeño с июльскими показателями Vera Rubin.
В-третьих, тестируемые модели не находятся на переднем крае открытого модельного фронтира. NVIDIA и AMD публиковали результаты на более крупных моделях, таких как DeepSeek V4 Pro и Kimi K3, используя AgentX. Чем больше модель и чем новее её релиз, тем сложнее портировать её на новый чип. При этом модели, которые OpenAI уже запустила на Jalapeño, отнюдь не маленькие.
Анализ производительности
OpenAI проектирует чип с приоритетом perf/W. Причина проста: в настоящее время OpenAI ограничена мощностью дата-центров, а не бюджетом или площадью, поэтому количество токенов на МВт имеет первостепенное значение. На Computex 2026 Дженсен сказал, что perf/W, надёжность и долгий срок службы являются ключевыми характеристиками будущих GPU. Цитируя его: «Если у вас есть 1 гигаватт мощности, то пропускная способность на ватт — это выручка». Он также отметил, что выбор неправильной архитектуры только потому, что чипы дешевле, не имеет смысла.
Это было подчеркнуто Nvidia во время выступления о Vera на Hot Chips 2026 при демонстрации того же графика выручки: «Сегодня дата-центр ограничен мощностью». Мощность имеет значение и определяет выручку.
Операторы не могут просто получить дополнительные МВт, потому что добавление GPU и увеличение мощности электросети происходят в совершенно разных временных масштабах. Энергетические ограничения дата-центров включают такие факторы, как подключение к энергосистеме, инфраструктура, мощность охлаждения и проектирование ИБП/резервной генерации. Задержки со стороны электросети неоднократно превышают сроки поставки оборудования и строительства, что приводит к необходимости BtM (behind-the-meter) — энергетических мощностей за счёт газовых турбин и локальных генераторов, построенных непосредственно на территории дата-центра. Такая мощность находится за счётчиком коммунальной компании, а не потребляется из общей сети. Это позволяет оператору запитать объект, не дожидаясь подключения к сети и модернизации инфраструктуры энергоснабжения — именно поэтому Colossus 2 компании xAI так сильно полагается на BtM, пока фактическое подключение к сети сильно отстаёт. Подробнее — в нашей Energy model.
Как мы писали в посте на X, tok/s/MW сводится к количеству токенов на джоуль, поскольку ватт — это джоуль в секунду. Таким образом, tok/s/MW является показателем эффективности системы и её способности преобразовывать энергию в токены.
В этом отношении Jalapeño выигрывает даже при сравнении с Rubin. Пропускная способность выходных токенов OpenAI Jalapeño на МВт при STP превосходит результаты Vera Rubin с MTP, опубликованные NVIDIA и CoreWeave в июле. Она также значительно превосходит результаты GB200 с MTP за 2025 год. Как мы упоминали в нашей статье о Vera Rubin, VR сравнивалась с результатами GB200 за 2025 год, поскольку это был сопоставимый этап раннего bring-up, а сравнение с GB200 2025 года позволяет зафиксировать зрелость программного обеспечения. Следуя этой логике, мы сравниваем последние результаты Vera Rubin за июль 2026 года, результаты GB200 за 2025 год и сегодняшние результаты Jalapeño. Это вполне корректное сравнение, поскольку это лучшие публичные показатели Rubin, а OpenAI выполнила tapeout своего чипа после Rubin. И OpenAI, и Rubin всё ещё находятся на раннем этапе зрелости, поэтому производительность продолжит расти.
По perf/TCO Vera Rubin и Jalapeño идут практически вровень, производя почти одинаковое количество выходных токенов на $. Однако, как уже упоминалось, результаты Jalapeño получены без speculative decoding, тогда как результаты Vera Rubin используют speculative decoding. Speculative decoding приводит к снижению стоимости токена примерно в 3–5 раз. Когда speculative decoding будет реализован на Jalapeño, это позволит Jalapeño обслуживать токены ещё более экономично. Разумеется, часть преимущества по TCO возникает из-за замены высоких маржинальных ставок Nvidia на более низкие (хотя всё ещё высокие) маржи Broadcom. Но не всё сводится к этому. Например, тот факт, что программы AI-ASIC Meta и Microsoft так и не вышли на полноценный старт, несмотря на гораздо более длительную работу над ними, показывает, что стоимость — лишь одна часть уравнения. Полную разбивку TCO Jalapeño см. в модели TCO AI Cloud от SemiAnalysis.
С архитектурной точки зрения OpenAI решила не разделять prefill и decode (PD) между отдельными пулами чипов. Draft-модель и основная модель используют одни и те же чипы и fabric — подход, который жертвует некоторой теоретической эффективностью ради практической эксплуатации. Мотивация заключается в том, что состав рабочей нагрузки со временем меняется: например, соотношение входных токенов, записи в кэш, чтения из кэша и выходных токенов существенно изменилось по мере прохождения трёх эпох моделей (знания, reasoning и agentic, как обсуждалось в нашей недавней статье). Поэтому заранее выбрать фиксированное количество гетерогенного кремния для prefill и decode может привести со временем к неэффективности. OpenAI выбирает однородный пул в этой архитектуре и старается сделать так, чтобы чип хорошо работал во всех сценариях.
И он действительно работает. На Kimi K2.5 (на которой основан Cursor Composer 2.5) Jalapeño достигает почти 700 ток/с/пользователя — более чем в 9 раз больше, чем следующий лучший чип с результатом 100 ток/с/пользователя.
С GPT-OSS ситуация ещё более разгромная. Пропускная способность Jalapeño при одинаковой интерактивности на МВт почти вдвое превышает максимальную точку GB200 и более чем в 50 раз — точку GB200 при concurrency 1. Для точек Jalapeño с более высокой concurrency используется EP8.
Эти результаты впечатляют! Однако мы должны придраться к деталям: это всего лишь 8k1k — значительно более простая рабочая нагрузка для оптимизации, и запусков AgentX пока нет. Как упоминалось в нашей статье об AgentX, multiturn-нагрузки с длинным контекстом нагружают гораздо больше аспектов serving stack, таких как роутеры и prefix cache. Чтобы добиться превосходства в agentic-нагрузках, требуется гораздо больше оптимизаций. Подробнее об этом — в статье об AgentX.
Разбираемся со спецификациями и архитектурой
Все эти результаты были получены на A0 stepping Jalapeño — всего через 9 месяцев после начала программы. Но уже существует B0 stepping, который сейчас находится на фабрике! B0 содержит оптимизации, обеспечивающие примерно 25% улучшения perf-per-watt по сравнению с более ранним кремнием A0. В частности, B0 stepping обеспечивает 13,4 PFLOPs MXFP4 на одном compute die размером с ретикл, произведённом по техпроцессу TSMC N3P. Для сравнения, один compute die Rubin аналогичного размера и на том же техпроцессе обеспечивает 17,5 PFLOPs плотного NVFP4.
Это выглядит гораздо достойнее с учётом того, что TDP Jalapeño составляет всего 700 Вт против 900–1 150 Вт у Rubin на один compute die. Поскольку Jalapeño ориентирован на инференс, а не на обучение, вполне понятно, что OpenAI не нужно повышать TDP для максимизации FLOPs. Но в любом случае приведённые выше цифры показывают, что Jalapeño обеспечивает достойные пиковые теоретические FLOPs.
При прямом сравнении с другими ускорителями Jalapeño имеет наивысшую пропускную способность HBM на ватт и наивысшие FLOPs на ватт, сопоставимые с конфигурацией Rubin Max-Q на 1 800 Вт:
Внешний I/O обеспечивается I/O-чиплетом N3E с 32 линиями 800G SerDes для вычислительной fabric: 24 линии (600 ГБ/с) используются для локального scale-up внутри стойки, а 8 линий (200 ГБ/с) — для глобального scale-up, представляющего собой многостоечный домен из 2 048 XPU. PCIe Gen 5 используется для системного I/O и подключения x86 host CPU.
Jalapeño будет поставляться с HBM4, что делает этот чип одним из относительно ранних пользователей этой технологии после Nvidia и AMD, опережая даже уже устоявшиеся программы TPU и Trainium. Поскольку один из ключевых архитектурных принципов Jalapeño заключается в максимальном использовании пропускной способности HBM, выбор чего-либо кроме лучшей HBM противоречил бы этой цели. В результате на один package приходится 15,4 ТБ/с пропускной способности памяти — больше, чем у всех остальных поставляемых ускорителей, использующих HBM3E. Пропускная способность 15,4 ТБ/с показывает, что HBM4 может достигать скорости 10 Гбит/с на pin, что даёт ей небольшое преимущество над 9,6 Гбит/с, которых Nvidia добивается от HBM4 в Rubin. Вероятно, HBM поставляет Samsung.
OpenAI выполнила tapeout Jalapeño в ноябре 2025 года; точнее, это был tapeout дизайна CoWoS, а не только кремния верхнего die. Через 9 месяцев после tapeout в ноябре 2025 года и всего через 3 месяца bring-up на реальном кремнии OpenAI уже добилась очень хороших результатов с Jalapeño. Это особенно впечатляет, учитывая, что команда начинала с нуля в отношении программного стека.
Тем временем tapeout CoWoS Rubin был завершён в октябре 2025 года, на месяц раньше, однако единственные ранние результаты, которые мы видели, исходят от инженерных образцов CoreWeave. Nvidia не позволила нам протестировать и опубликовать бенчмарки так же, как это сделала OpenAI, что указывает на незрелость программного обеспечения её чипа. Преимущество CUDA потенциально мертво, учитывая, насколько быстро OpenAI способна запускать новые модели на собственном кремнии.
Они всё ещё далеки от оптимального состояния, и в целом мы видим, что Jalapeño выдаёт лучшие показатели. Мы не считаем, что аппаратное обеспечение Nvidia хуже; скорее, bring-up программного обеспечения Jalapeño продвигается быстрее, чем у Nvidia. Это говорит о силе совместного проектирования hardware/software — главной области, в которой сильная команда ASIC из frontier AI lab может превзойти более устоявшихся производителей merchant silicon. Парадоксальным образом старт с нуля также мог помочь OpenAI, поскольку позволил принимать архитектурные решения с чистого листа, не беспокоясь об обратной совместимости или старых версиях программного обеспечения.
Хотя у OpenAI уже есть инженерные образцы Jalapeño, производство в настоящее время запланировано на постепенное наращивание в течение 2027 года, причём большая часть выпуска приходится на конец следующего года. Подробнее об объёмах поставок и ASP см. в Accelerator Model от SemiAnalysis.
Достаточно сказать, что OpenAI Jalapeño — это настоящий ASIC для массового производства.
Если сравнить сроки с Rubin, сроки Jalapeño выглядят поразительно быстрыми. Как показано ранее, результаты Jalapeño превосходят Rubin, несмотря на стартовое преимущество Rubin.
Архитектура Jalapeño
Теперь перейдём непосредственно к архитектуре. Matrix engine чипа использует числовые форматы MXFP и weight-stationary systolic array, аналогичный TPU. Однако при прямом сравнении с TPU он поддерживает меньшие формы/размерности, то есть не имеет странных провалов производительности, возникающих при матричном умножении неудобной формы на больших systolic array.
Также имеются 64-битные scalar cores и векторные ядра FP32/INT32. OpenAI также инвестировала в резервирование на уровне tray и реализовала yield harvesting на уровне ядер и каналов. По утверждению компании, помощь ИИ в проектировании чипа обеспечила сокращение площади SIMD на 8% и площади matrix engine на 10% в процессе разработки. Хотя точные условия process/voltage/temperature (PVT) не уточнялись, также было сказано, что блоки, созданные с помощью ИИ, улучшили timing и энергопотребление по сравнению с первоначальными блоками.
Архитектура Jalapeño сосредоточена на устранении перемещения KVCache и весов, а также фиксированных задержек и накладных расходов, чтобы сделать возможным приближение к пиковым FLOPs/пропускной способности даже для небольших batch size или форм по сравнению с другими ускорителями.
Ядра и HBM разделены на slices, причём каждый core slice имеет низколатентное локальное представление собственного участка HBM. Синхронизация между slices происходит по выделенной высокоскоростной collective network. Эта минимальная иерархия памяти уже даёт Jalapeño большое потенциальное преимущество перед GPU, где обращения к памяти должны проходить через сложную систему памяти, создавая большие задержки, которые необходимо амортизировать или скрывать на более крупных формах.
Такой выбор возможен благодаря тому, что при тщательном размещении весов и KV синхронизацию между ядрами можно ограничить небольшим числом известных высокоскоростных коммуникаций, таких как tensor-parallel communication, которую можно перекрывать с вычислениями.
Также существует дополнительная общая NoC, используемая для обычных коммуникаций и доступа к scale-up network. В целом OpenAI экономит огромное количество энергии и получает значительный прирост производительности благодаря упрощённым NoC и memory subsystem по сравнению с Nvidia и Google.
На уровне ядра OpenAI описывает out-of-order (OoO) core с L1 cache. Это существенное отклонение от подхода, который мы наблюдали в других ускорителях: все они вместо этого используют scratchpad, управляемый программным обеспечением, обычно в сочетании с некоторой поддержкой async DMA. И снова аргумент заключается в том, что это позволяет Jalapeño избегать фиксированных накладных расходов, таких как задержки barrier, которые на других ускорителях (например, GPU) необходимо скрывать или амортизировать за счёт большего объёма работы на ядро, что затрудняет приближение к пиковой пропускной способности/FLOPs.
Компромисс заключается в том, что Jalapeño поэтому полагается на качественный prefetching для своевременного поступления запросов к памяти, что менее предсказуемо и сложнее для анализа. Однако с Codex в хорошо настроенном harness и доступом к детальному tracing поиск оптимального kernel с лучшим prefetching для заданной формы, вероятно, требует минимального вмешательства человека. Мы считаем, что именно это OpenAI сделала, чтобы так быстро запустить DeepSeek R1, Kimi K2.5 и GPT-OSS.
Ядра также поддерживают «малые» размерности матриц, что (в зависимости от того, насколько они малы) должно сделать систему более универсальной для разных размерностей моделей и batch size, менее чувствительной к выравниванию размерностей матриц, накладным расходам padding и неэффективности tiling. Например, TPU, Trainium и чипы Etched имеют очень большие systolic array, которым для предотвращения неэффективности tiling могут требоваться большие batch size или размерности моделей, точно делящиеся на размеры массивов.
В Jalapeño OpenAI сосредоточилась на устранении фиксированных задержек в системе, чтобы обеспечить максимально близкую к roofline производительность во всех областях pareto-кривой. Теоретически это может дать преимущества перед GPU в нескольких рабочих точках:
Значительно лучшая верхняя граница производительности в low-latency/small-batch inference, где GPU ограничены множеством фиксированных накладных расходов, таких как launch latency, barrier latency и latency системы памяти.
Потенциальная возможность приблизиться к hardware roofline даже при large-batch или long-context нагрузках.
Это сопровождается оговоркой: даже если верхняя граница производительности теоретически доступна, реализовать её на реальных kernels может быть сложнее. Поэтому подход, по-видимому, следующий:
Проектировать систему под максимально высокую верхнюю границу производительности для всех форм рабочих нагрузок.
Позволить Codex выполнять рутинную работу по поиску kernels, достигающих этой верхней границы.
Судя по чрезвычайно быстрому темпу, с которым команда OpenAI запустила нагрузки InferenceX на Jalapeño, мы оптимистично оцениваем этот подход.
Если Jalapeño окажется успешным, это станет сильным сигналом о том, что одержимость индустрии программными моделями и идеальными универсальными компиляторами опровергается frontier AI-моделями.
Программное обеспечение
OpenAI пишет kernels для Jalapeño практически как assembly. Каждый kernel получает вручную настроенный код, некоторые из них достигают примерно 3 000 строк, с проверками корректности и собственным sanitizer. Ранняя работа над kernels выполнялась в режиме human-in-the-loop, но затем подход изменился благодаря более масштабной внутренней версии Codex — той, которую OpenAI планирует предлагать корпоративным клиентам. Внутренний serving engine называется «Teacup». Интересно, что до проведения бенчмарка DeepSeek с помощью InferenceX у OpenAI вообще не было внутренней реализации MLA kernels. Способность Codex так быстро писать функциональные и эффективные kernels (без вмешательства кого-либо из команды kernel engineering OpenAI) демонстрирует зрелость программного конвейера.
OpenAI программирует Jalapeño с помощью Gluon. Gluon — язык программирования kernels OpenAI. Построенный поверх Triton, Gluon сохраняет программную модель Triton SPMD (Single Program Multiple Data), но предоставляет низкоуровневые абстракции программирования. Например, для GPU NVIDIA он предлагает API, отображающиеся на инструкции PTX, включая инструкции MMA, инструкции TMA, механизмы mbarrier и многие другие. Самая уникальная абстракция Gluon — layout. В общем случае layout определяет отображение между аппаратным ресурсом (например, 5-м регистром warp 9) и элементом tensor (например, элементом tensor в строке 6, столбце 7). Абстракция layout в Gluon основана на Linear Layouts — типе алгебры layout, изобретённой OpenAI. Linear Layouts математически формализует понятие layout и предоставляет инструменты для работы с layouts. Это позволяет реализовать множество возможностей, включая доказуемо корректные преобразования layout и оптимальный memory swizzling.
Что касается программной модели Jalapeño, каждая программа Gluon отображается на persistent thread. Мы считаем, что это указывает на пригодность Jalapeño для persistent kernel programming pattern, где каждая программа выполняется на нескольких tiles, а программист, а не аппаратный scheduler, распределяет работу. OpenAI упоминала TensorInfo — абстракцию, которая явно кодирует layouts. Вероятно, это набор layouts, разработанный для Jalapeño и использующий Linear Layouts. Наконец, каждое ядро предоставляет data prefetching и decoupled out-of-order units. Например, пользователь может запрограммировать ожидание prefetched data, которое блокируется за semaphore.
В странном повороте судьбы модели OpenAI вроде GPT 5.6 Sol, которые сейчас работают на GPU NVIDIA, использовались для проектирования чипа, представляющего реальную угрозу преимуществу CUDA — собственные GPU NVIDIA помогают в реальном времени продвигать потенциального преемника своих же GPU.
Сравнивая результаты во времени, мы также видим темп разработки Jalapeño: менее чем за 2 недели в некоторых точках интерактивности удалось получить более чем двукратное увеличение пропускной способности. Каждый tarball, который мы получаем от команды Jalapeño, содержит целый мир чудес.
Улучшалась не только производительность kernels: за 8 дней команда Jalapeño включила TP32, опираясь на предыдущие конфигурации TP8 и выйдя за пределы одной системы, чтобы запустить полноценную rack-scale конфигурацию на большой модели. Это действительно впечатляющий темп разработки.
Чтобы проверять производительность до запуска на реальном железе, OpenAI также располагает симулятором «chilisim», точность которого находится в пределах 5% от измеренного на железе результата, с использованием шины трассировки фиксированной ширины. Tracing на A0 был ограничен, но на B0 значительно улучшился, вероятно, благодаря данным реальных запусков на кремнии A0. Инженеры демонстрировали Codex CLI, запускающий внутреннюю модель под кодовым именем «Raiku» или «5.3 Codex Spark», с TPOT 1,2 мс.
Команда также показала демонстрации, написанные Codex и работающие непосредственно на чипе: Doom при 36 FPS, симуляцию гидродинамики FP32 и визуализацию «Liquid Light» с перемещением мыши.
На стороне моделей внутренний подход OpenAI с megakernel, получивший название «gigakernel», строится вокруг одного megakernel, который зацикливается непосредственно на устройстве для снижения нагрузки на CPU и времени запуска. Команда также ещё сильнее смещается в сторону стратегий test-time compute, причём внутри компании особенно интересуются тем, как согласованно использовать 1 миллион rollout.
Разделять или не разделять — вот в чём вопрос
Мы уже упоминали, что OpenAI не использует разделение prefill и decode на этих чипах. Для нас это стало неожиданностью, поскольку производительность GPU NVIDIA и AMD существенно выигрывает от PDD даже на однородном оборудовании. Давайте разберёмся, почему команда Jalapeño пошла именно этим путём.
Разделение prefill-decode (PDD) выглядит привлекательным, когда рабочая нагрузка зафиксирована. Prefill и decode по-разному нагружают аппаратное обеспечение, поэтому назначение каждой фазы на отдельно настроенный пул может повысить эффективность при одном выбранном соотношении входных/выходных данных. Однако production-трафик не сохраняет это соотношение. Длины входных и выходных последовательностей, concurrency, коэффициенты попаданий в кэш, частота принятия speculative-токенов и целевые показатели latency меняются в течение дня.
После разделения устройств на пулы prefill и decode слишком большой спрос на prefill оставляет decode-чипы без работы, пока запросы стоят в очереди. Но слишком большой спрос на decode приводит к обратному. Оператору приходится постоянно прогнозировать правильное разделение, закладывать резервные мощности с обеих сторон и перебалансировать систему, оптимальное соотношение в которой постоянно меняется.
В унифицированной системе некоторые ресурсы могут быть недоиспользованы на определённой фазе, но каждое устройство остаётся доступным для обслуживания следующего запроса. В раздельной системе целый чип может простаивать просто потому, что он принадлежит неправильному пулу. Локальная утилизация выглядит лучше, но глобальная утилизация может оказаться хуже.
Разделение также нарушает locality. Worker prefill создаёт большой KV cache, который worker decode немедленно требует, поэтому система должна передать это состояние по сети до продолжения генерации. Это добавляет потребление пропускной способности, синхронизацию, ожидание в очереди и ещё один домен отказа. Стоимость также растёт с длиной входной последовательности, поскольку KV cache увеличивается. Однако отказ от перемещения KV в основном является оптимизацией мощности и latency; готовность перемещать некоторое количество KV может повысить утилизацию оборудования ценой некоторого увеличения энергопотребления и latency на запрос.
Fungible fleet позволяет перераспределять мощности между latency-sensitive запросами и batch-задачами, ориентированными на throughput, тогда как фиксированное разделение оставляет оборудование без работы при изменении состава трафика. Кроме того, длина контекста меняет баланс между attention и FFN, поэтому любое фиксированное соотношение оборудования эффективно только вблизи расчётной точки.
То же ограничение относится к speculative decoding. Draft-модель должна передавать кандидаты токенов verifier-модели с чрезвычайно низкой latency. Разделение двух моделей по специализированным пулам превращает тесно связанный цикл декодирования в распределённый протокол. Дополнительная коммуникация и координация могут поглотить выигрыш по latency, полученный благодаря drafting. Размещение обеих моделей на одних устройствах и low-latency fabric сохраняет locality, благодаря которой speculation вообще имеет смысл.
Однако disaggregation всё ещё может выиграть там, где спрос достаточно велик, стабилен и предсказуем, особенно когда обычным GPU требуются большие phase-specific batches для достижения хорошей пропускной способности. Но это не бесплатный обед.
От японского к индийскому (от мягкого к острому): Katsu, Vindaloo и Chana — как блюда карри собираются в стоечную систему?
Система Jalapeño на уровне rack unit состоит из CPU host rack и ASIC rack. Host rack содержит 16 host CPU trays под названием «Katsu», каждому из которых соответствует один из 16 ASIC trays под названием «Vindaloo», расположенных справа от Katsu. Каждый host содержит два AMD EPYC класса Turin с 1,5 ТБ DRAM, 2× E1.S и 2× M.2 SSD на rack. Каждый tray также оснащён frontend networking 400G (2×200G). Каждый tray Katsu подключается к каждому tray Vindaloo через 8 внешних PCIe DAC-кабелей, горизонтально проходящих через переднюю часть стойки. Системный дизайн выполнен в партнёрстве с Celestica.
ASIC rack состоит из 16 trays Vindaloo и 8 trays scale-up switches (6 локальных + 2 глобальных), получивших название «Chana». Каждый tray Vindaloo содержит 8 ASIC Jalapeño, что в сумме даёт 128 ASIC Jalapeño на rack. ASIC подключены к каждому из trays коммутаторов Chana через медную backplane, аналогично решению Nvidia Oberon. Топология scale-up разделена на локальный домен из 128 ASIC внутри rack и глобальный домен, соединяющий до 16 racks или 2 048 ASIC. Ниже мы подробнее объясним пропускную способность и топологию.
Энергоснабжение боковой host rack требует примерно 50 кВт выделенной мощности (31 кВт в production), а ASIC rack потребляет 130 кВт, что даёт около 160 кВт на всю систему из двух racks. По энергопотреблению это фактически двухстоечный GB300 rack.
OpenAI может соединить до 2 048 Jalapeño XPU в одной scale-up network. Scale-up network состоит из двух доменов: локального, соединяющего все 128 XPU через backplane внутри rack, и глобального, соединяющего 2 048 XPU через 16 racks с использованием гибридного медного и оптического interconnect. Каждый rack содержит 8 trays Chana. Шесть коммутаторов Chana посередине предназначены для локального домена и каждый содержит один switch ASIC Tomahawk 6 на 102,4T. Два коммутатора Chana сверху и снизу локальных коммутаторов предназначены для глобального домена; мы полагаем, что они могут состоять из 2× 102,4T Tomahawk 6, обеспечивая до 204,8T на switch tray.
В локальном домене каждый из 128 чипов Jalapeño имеет однонаправленную пропускную способность 4,8 Тбит/с на XPU и подключён по принципу all-to-all к 6× 102,4-Тбит/с ASIC Tomahawk 6. Это означает 48 пар дифференциальных линий (DP) male/female на XPU, что соответствует 6 144 DP пассивных медных кабелей на rack, используемых для локального scale-up.
В глобальном домене 16 racks, содержащих в общей сложности 2 048 XPU, соединяются комбинацией медной backplane, электрического коммутатора 204,8T TH6, трансиверов 1,6T и optical circuit switch. Каждый XPU имеет однонаправленную пропускную способность 1,6 Тбит/с для глобального соединения, что соответствует 16 парам дифференциальных линий (DP) male/female на XPU для backplane между XPU и глобальным коммутатором. Пропускная способность каждого global switch tray с 2 ASIC разделяется между backplane и оптикой на передней панели.
Между локальным и глобальным доменами количество backplane-коннекторов на rack достигает 64 DP на XPU и в общей сложности 8 192 DP пассивных медных кабелей на rack.
Глобальный домен использует архитектуру только с rail, состоящую из 8 rails по всему глобальному домену. Мы считаем, что OpenAI маршрутизирует оптические соединения глобального домена через Optical Circuit Switches (OCS), установленные в каждом rack. Для каждого XPU 1,6 Тбит/с глобальной пропускной способности проходит к global switch tray по медной backplane. Затем сигнал выходит из коммутатора через переднюю панель через трансиверы 1,6T, которые направляются к пассивному оптическому коммутатору перед выходом из rack. Это расширяет масштабируемый мир до 2 048 XPU, объединяя 16 racks по 128 XPU каждый.
Поскольку scale-up networking составляет лишь около 10% общей стоимости системы, эта гибкость обеспечивает ценную возможность выбора для будущих моделей с 10–20 триллионами параметров или контекстных окон на 2–4 миллиона токенов. При развёртывании OpenAI сотрудничает с neoclouds и собирает данные о надёжности вместе с партнёрами по дата-центрам до января, одновременно оптимизируя время развёртывания от dock до rack.
Что дальше
Далее мы поговорим о будущем Jalapeño, первая production token которого появится уже скоро. Следующая цель — 100 МВт, и основные препятствия будут связаны с аппаратным обеспечением: сколько чипов они смогут производить, насколько хорошо смогут развёртывать и эксплуатировать дата-центры, как будут справляться с мониторингом, отказоустойчивостью и т. д. Программное обеспечение уже доказало свою работоспособность, а для внутренних моделей любой отрыв в программном обеспечении легко сокращается. За paywall мы обсудим последствия для NVIDIA, AMD, Cerebras и других производителей чипов, которые в ближайшие годы заключили сделки с OpenAI.
