GPT-OSS на День 0

Perplexity прагне зробити найкращі моделі штучного інтелекту доступними для допитливих людей, які вимагають точних і надійних відповідей та агентних дій. Компанія OpenAI нещодавно анонсувала свої моделі з відкритими вагами (gpt-oss-20b та gpt-oss-120b). Як і у випадку з багатьма провідними моделями, Perplexity є однією з перших організацій, які оцінили gpt-oss-20b та gpt-oss-120b.

У цій статті ми ділимося рішеннями щодо інфраструктури нашого власного стека інференсу, які унеможливили підтримку у День 0. Ми зосереджуємося на обслуговуванні цих моделей на графічних процесорах NVIDIA H200, детально описуючи зміни в ядрі, вибори розгортання та компроміси між швидкістю та вартістю.

GPT-OSS на Hopper

Моделі з відкритими вагами постачаються з використанням квантування MXFP4, що допомагає їм поміщатися в пам'ять споживчого обладнання або досягати пікової пропускної здатності на NVIDIA Blackwell. Однак для початкового оцінювання ми хотіли запустити їх на існуючих кластерах H200 Hopper з мінімальними змінами рушія інференсу. Hopper не має виділених тензорних ядер FP4, які були представлені Blackwell. З огляду на це, ми вирішили обслуговувати моделі з точністю FP8, щоб мінімізувати потребу в кастомних ядрах і максимально ефективно використовувати доступне обладнання.

На високому рівні трансформерні LLM є структурно простими:

Вхідне вбудовування

Послідовність шарів трансформера. Кожний містить блок уваги та щільний блок MLP або розріджений блок MoE.

Проєкція вихідного логіта

Під час запуску нової моделі трансформера нас насамперед цікавить дізнатися, якою мірою вони відповідають існуючим моделям, щоб визначити необхідні зміни. OpenAI люб'язно поділилася оглядом своїх моделей заздалегідь, що дозволило нам відповідно налаштувати нашу конфігурацію інференсу. Ми виявили, що модель справді потребувала доволі багатьох невеликих змін.

Увага: GQA з осередками уваги (Attention Sinks)

Кожна головка уваги має передпопередньо навчений параметр осередку, який враховується в Softmax

Позиційне кодування YaRN, подібне до DeepSeek-V3

Проєкції QKV мають зміщення, подібні до Qwen 2

Вихідна проєкція має зміщення

MLP: Розріджена суміш експертів (MoE)

Функція активації SwiGLU, відмінна від більшості моделей з відкритими вагами

Softmax після Top-K для експертних ваг

Експерти мають зміщення

Очікуючи, що кількість параметрів становитиме близько 100B-200B, ми вирішили:

Розширити FlashInfer для підтримки осередків уваги

Повторно використати реалізацію MoE, вже створену для сімейства моделей DeepSeek-V3

Обрати блокове масштабування FP8 128x128 як схему квантування, розширивши ядра DeepGEMM для підтримки терміна зміщення.

Власний рушій інференсу

Наші зусилля з інференсу підтримуються нашим власним рушієм інференсу ROSE. Ми розробляємо ROSE як гнучкий фреймворк, що дозволяє швидко розгортати нові моделі. Крім того, щойно ми беремо на себе зобов'язання обслуговувати модель у великих масштабах, він надає платформу для оптимізації та підвищення продуктивності до передового рівня.

ROSE надає рушій LLM, який може завантажувати модель і генерувати деодировані токени для неї за допомогою кількох декодерів, зокрема спекулятивних та MTP-декодерів. Самі моделі складаються з кастомного набору шарів, які підтримують різні налаштування конфігурації для квантування та паралелізму. Під шарами він об'єднує як ядра Triton, так і CUDA, які ефективно реалізують та об'єднують обчислення, що виконуються окремими шарами.

ROSE створено переважно на Python і покладається на PyTorch для визначення моделей. Хоча Python дозволяє нам бути гнучкими та адаптуватися до нових моделей, ми мігруємо більшість чутливих до продуктивності компонентів, таких як обслуговування та планування пакетів, на Rust.

Щоб запустити нову модель, ми спочатку визначаємо ієрархію моделі та створюємо для неї конвертер ваг. Після того як усі ваги враховані, ми визначаємо прямий прохід для найпростішого варіанту використання TP=1 і гарантуємо, що він працює від початку до кінця. Нарешті, ми реалізуємо та тестуємо підтримку різних форм паралелізму, перш ніж випустити новий контейнер і розгорнути модель на кластері для оцінювання. Потім ми ітеруємо продуктивність, спираючись на відгуки як з панелей моніторингу, так і з більш детальних бенчмарків.

ROSE оперує числовими токенами, маючи мінімальне уявлення про формати чату поза інтеграційними тестами. Паралельно нам довелося зайнятися налаштуванням навколишньої інфраструктури для підтримки токенізатора Harmony та коректного відображення запитів на послідовності вхідних токенів.

З моделлю GPT OSS ми виявили, що жодних змін у наші декодери, каркаси графіка CUDA чи навколишню інфраструктуру вносити не потрібно, що дозволило нам зосередити зусилля на налаштуванні ядер, що підтримують модель.

Ядра для GPT-OSS

Увага з осередками (Sink Attention)

Увага з осередками вводить додатковий коефіцієнт зміщення перед softmax, який акумулюється з добутком Q та K:

Хоча наївна реалізація є досить тривіальною, ефективні реалізації уваги, такі як FlashInfer, розпаралелюють обчислення уваги як між незалежними головками, так і вздовж довжини послідовності KV. Крім того, для забезпечення чисельної стабільності Softmax обчислюється онлайн з одночасним відніманням максимального елемента для чисельної стабільності:

Онлайн-реалізація відстежувала поточний максимум m, ініціалізований значенням -inf, та масштаб d, ініціалізований значенням 1. Ініціалізувавши максимум значенням осередку поточної головки, ми гарантували б його коректне накопичення в Softmax. Нам потрібно було подбати про те, щоб цей максимум включався лише в перший фрагмент, якщо увага була розділена на кілька блоків уздовж довжини послідовності.

Ми налаштували шаблон ядра FlashInfer FA2, який використовується як для попереднього заповнення (prefill), так і для декодування, щоб включити параметри осередків.

MoE

Основна відмінність між шаром MoE різних моделей зазвичай полягає у схемі маршрутизації. Очікуючи значної варіативності, ROSE реалізує це ядро в Triton, що дозволяє нам легко адаптувати його до нових моделей. У випадку з GPT-OSS нам довелося налаштувати оцінку ваг для виконання softmax лише серед обраних експертів Top-K, на відміну від деяких моделей у стилі DeepSeek, які обчислюють softmax для всіх експертів. Ми з'ясували, що для точності критично важливо обчислювати ваги експертів у точності bfloat16.

Проблема з шаром MoE була пов'язана з нашим рішенням повторно використати існуючі ядра DeepGEMM, яким бракувало підтримки термінів зміщення. На щастя, з часом ми глибоко інтегрувалися з ними, внесли зміни, щоб краще з'єднати їх з нашими кастомними ядрами маршрутизації all-to-all. Ми додали підтримку зміщення в DeepGEMM, ініціалізувавши акумуляторні регістри WGMMA значеннями зміщення, завантаженими з пам'яті. Це одноразова операція під час обробки блоку MN, тому вартість, імовірно, є незначною, а кеш L2 забезпечує ефективний доступ до цих значень.

Оскільки ці моделі не отримують очевидної вигоди від паралелізму даних, ми повторно використали ядра маршрутизації та об'єднання лише для TP. Вхідні дані для маршрутизації реплікуються по всіх рангах, тому маршрутизація вибирає токени для локально доступних експертів. Об'єднання виконує зважене накопичення через NVLink.

Налаштування продуктивності

Хоча нашою метою було швидке розгортання моделей, ми хотіли переконатися, що продуктивність залишається прийнятною. Переконавшись у правильності порівняно з еталонною реалізацією, наданою OpenAI, ми профілювали нашу реалізацію за допомогою стандартного профайлера PyTorch, стежачи за виділенням блоків і тредів між ядрами. Функціональність, яку ми повторно використовували, була створена для моделей, що мали більшу приховану розмірність 7168, яка суттєво перевищувала 2880 у моделях GPT-OSS. Ми спеціалізували ініціалізатори ядер для вибору кращих розмірів сітки, що значно підвищило пропускну здатність.

Токенізація та канали

Формат чату Harmony має кілька важливих концепцій для структурування розмов, контенту міркувань та викликів функцій. У цьому форматі кожне повідомлення складається з заголовка та вмісту:

Заголовок містить метадані — найголовніше з них це роль (система, розробник, користувач, асистент, інструмент), канал і одержувач, наприклад to=functions.<function-name> під час виклику інструменту.

Канали (такі як аналіз, коментар та остаточна відповідь) роблять виводи моделі більш прозорими та сегментованими. Оскільки формат забезпечує це розділення, модель може міркувати прозоро (і підлягати перевірці для відлагодження) без витоку ланцюжка міркувань у продакшн. Теги одержувача (заголовки to=) чітко кажуть виконуваному середовищу, який саме суб'єкт має отримати наступний корисний навантаження (payload) — чи то функція, самій моделі чи кінцевому користувачу.

Наш рушій інференсу ROSE є агностичним до форматів. Він отримує пакет вхідних токенів і передає вихідні токени у стрічці. У нашому стеку інференсу завдання форматування вхідних даних у токенізований промпт та парсинг результатів LLM назад у структуровані повідомлення обробляється виділеною інтерфейсною службою JSON API. Ми інтегрували Harmony, додавши новий змінний форматувач/парсер до цього інтерфейсу, що дозволяє бекенду залишатися незмінним, поки фронтенд чисто керує правилами формату чату, викликами інструментів та потоковою передачею. Таке розділення обов'язків зберігає архітектуру модульною, забезпечуючи швидке впровадження нових форматів і функцій відповідей із мінімальними змінами в бекенді.

Вартість та продуктивність

З огляду на відносно невеликий розмір моделей GPT-OSS, ми обмежуємо розгортання репліки одним вузлом, щоб уникнути накладних витрат на міжвузлову комунікацію. Наша реалізація підтримує гнучкі комбінації експертного паралелізму (EP), паралелізму даних (DP) та тензорного паралелізму (TP). Щоб визначити оптимальне налаштування розгортання, ми провели бенчмаркінг усіх комбінацій стратегій шардингу для розмірів пакетів від 1 до 128. Завдяки дезагрегації попереднього заповнення та декодування (Prefill-Decode Disaggregation), ми маємо можливість обговорити компроміс між продуктивністю та вартістю окремо для попереднього заповнення та декодування.

Для оцінки витрат ми припускаємо номінальну ринкову вартість H200 у $3,00/год (примітка: це не наша фактична ціна GPU).

Ми виявили, що встановлення batch_size=1 та DP=1 дає найкращу продуктивність попереднього заповнення. Різні конфігурації TP забезпечують різноманітні компроміси між затримкою першого токена та вартістю. У наведених нижче таблицях подано затримку попереднього заповнення та вартість за мільйон вхідних токенів для різних конфігурацій та довжин вхідних даних.

GPT-OSS 120B:

Затримка prefill і вартість на один мільйон вхідних токенів для GPT-OSS 120B залежно від конфігурації паралелізму та довжини вхідних даних.

GPT-OSS 20B:

Затримка prefill і вартість на один мільйон вхідних токенів для GPT-OSS 20B залежно від конфігурації паралелізму та довжини вхідних даних.

Для декодування ми з'ясували, що EP4 DP1 TP4 є найкращою конфігурацією для більшості випадків. Чотири графіки нижче ілюструють компроміс між швидкістю декодування та вартістю за мільйон вихідних токенів для моделей 120B та 20B при довжинах послідовностей 8192 та 32768.

Розгорнути

Розгорнути

Розгорнути

Розгорнути

Ми також розгляли можливість використання меншої моделі 20B як чернетки для спекулятивного декодування для більшої моделі 120B. Однак оскільки кількість активованих параметрів схожа (3B проти 5B), отримане прискорення виявилося незначним.

Посилання

Дезагреговане попереднє заповнення та декодування

Прискорення Sonar за допомогою спекуляцій​

Менша затримка та вища пропускна здатність при розгортанні DeepSeek на кількох вузлах

​Ефективна та портативна комунікація суміші експертів (Mixture-of-Experts)

​pplx-kernels

DeepGEMM

FlashInfer: Ефективний і налаштовуваний рушій уваги для обслуговування інференсу LLM

Ефективні потокові мовні моделі з осередками уваги

Технічний звіт DeepSeek-V3​

​Формат відповіді OpenAI Harmony | OpenAI Cookbook​

Цитування

@online{perplexity2025GptOssOnDay0,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Vladimir Zaytsev and Kevin Hu and Lauren Kolm and Jesse Dwyer},
  title = {{GPT-OSS on day 0}},
  date = {2025-08-08},
  url = {https://www.perplexity.ai/hub/blog/gpt-oss-on-day-0}
}