И как они выглядят на фоне Qwen 3

? Telegram @TheWeeklyBrief — краткие обзоры и подкасты

? GitHub Pages — углублённые разборы статей

5 августа, 2025 года OpenAI выпустила новые модели LLM с открытым весом: gpt-oss-120b и gpt-oss-20b — первые полностью открытые модели с момента выхода GPT-2 в 2019 году. И да, благодаря некоторым умным оптимизациям, их можно запускать локально (но об этом чуть позже).

Это первый раз с момента выпуска GPT-2, когда OpenAI делится крупной полностью открытой моделью. Ранние модели GPT показали, как масштабируется архитектура трансформеров. Затем выпуск ChatGPT в 2022 году сделал эти модели мейнстримом, продемонстрировав их практическую пользу для задач письма, получения знаний (а позже и программирования). Теперь же компания поделилась долгожданными весами модели, и архитектура содержит несколько интересных деталей.

Я провёл последние несколько дней, изучая код и технические отчёты, чтобы обобщить самые интересные подробности. (Спустя всего несколько дней после этого OpenAI также анонсировала GPT-5 — я кратко затрону её в контексте моделей gpt-oss в конце статьи.)

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

• Сравнение архитектуры моделей с GPT-2

• Оптимизация MXFP4, позволяющая разместить модели gpt-oss на одной видеокарте

• Компромиссы между шириной и глубиной (gpt-oss vs Qwen3)

• Внимание, смещения и «поглотители» (attention bias and sinks)

• Бенчмарки и сравнение с GPT-5

Надеюсь, вы найдёте эту статью полезной!

1. Обзор архитектуры модели

Прежде чем подробно обсуждать архитектуру, начнём с обзора двух моделей — gpt-oss-20b и gpt-oss-120b, показанных на Рисунке 1 ниже.

Если вы раньше видели схемы современных LLM или читали мою предыдущую статью «Большое сравнение архитектур», вы можете заметить, что на первый взгляд здесь нет ничего принципиально нового или необычного.

Это неудивительно: ведущие разработчики LLM, как правило, используют одну и ту же базовую архитектуру, внося лишь небольшие доработки. Это моё личное предположение, но, думаю, причины в следующем:

• Между лабораториями происходит значительная ротация сотрудников.

• Мы до сих пор не нашли ничего лучше архитектуры трансформера. Хотя существуют state space models и модели диффузии текста, насколько мне известно, никто не доказал, что они работают так же хорошо, как трансформеры, на данном масштабе. (Большинство сравнений, которые я нашёл, сосредоточены только на результатах бенчмарков. До сих пор неясно, насколько хорошо эти модели справляются с реальными многоходовыми задачами письма и программирования. На момент написания статьи самая высокорейтинговая неполностью-трансформерная модель на LM Arena — Jamba, гибрид трансформера и state space модели, занимает 96-е место. 

• Большая часть улучшений, скорее всего, достигается за счёт данных и тонкой настройки алгоритмов, а не за счёт кардинальных изменений архитектуры.

ПРИМЕЧАНИЕ: мне любезно указали, что существует более высокорейтинговая гибридная модель — Hunyuan-TurboS на 22-м месте.)

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

Также хочу отметить, что я никоим образом не связан с OpenAI. Моя информация основана исключительно на изучении опубликованного кода модели и технических отчётов. Если вы хотите узнать, как использовать эти модели локально, лучшее место для начала — официальные страницы моделей OpenAI на Hugging Face Hub:

• https://huggingface.co/openai/gpt-oss-20b

• https://huggingface.co/openai/gpt-oss-120b

Модель на 20 млрд параметров (gpt-oss-20b) может работать на потребительской видеокарте с 16 ГБ ОЗУ. Модель на 120 млрд параметров (gpt-oss-120b) может работать на одной карте NVIDIA H100 с 80 ГБ ОЗУ или на более новом оборудовании. Я вернусь к этому позже, поскольку есть несколько важных оговорок.

---

2. Наследие GPT-2

Прежде чем углубиться в сравнение gpt-oss с более современными архитектурами, давайте совершим путешествие во времени и сравним ее бок о бок с GPT-2 (Рисунок 2), чтобы наглядно увидеть, какой путь был пройден.

И gpt-oss, и GPT-2 — это LLM, использующие только декодер и построенные на архитектуре трансформера, представленной в знаменитой статье «Attention Is All You Need» (2017). За прошедшие годы многие детали этой архитектуры эволюционировали.

Впрочем, эти изменения не являются уникальными для gpt-oss. Как мы увидим далее, они встречаются во многих других современных языковых моделях. Поскольку я уже подробно обсуждал многие из этих аспектов в предыдущей статье «Большое сравнение архитектур», я постараюсь быть краткими и сосредоточиться на ключевых моментах.

2.1 Отказ от Dropout

Dropout (2012) — это классический метод предотвращения переобучения, который случайным образом «отключает» (то есть обнуляет) часть активаций слоя или оценок внимания (Рисунок 3) во время обучения. Однако в современных больших языковых моделях dropout используется крайне редко, и большинство моделей, вышедших после GPT-2, от него отказались.

Можно предположить, что изначально dropout был использован в GPT-2 как наследие оригинальной архитектуры трансформера. Исследователи, скорее всего, заметили, что он не дает реального улучшения производительности LLM (я наблюдал то же самое в своих небольших экспериментах по воспроизведению GPT-2). Это связано с тем, что LLM обычно обучаются всего за одну эпоху на огромных наборах данных, в отличие от режимов обучения в сотни эпох, для которых dropout изначально был создан. Поскольку LLM видят каждый токен только один раз за всё обучение, риск переобучения невелик.

Что интересно, хотя dropout много лет игнорировался при проектировании архитектур LLM, я нашел исследовательскую статью 2025 года с экспериментами на относительно небольших моделях (Pythia 1.4B), которая подтверждает, что в условиях обучения в одну эпоху dropout приводит к ухудшению итогового качества модели.

2.2 RoPE заменяет абсолютные позиционные эмбеддинги

В трансформерных LLM позиционное кодирование необходимо из-за механизма внимания. По умолчанию attention рассматривает входные токены так, как если бы они не имели порядка. В оригинальной архитектуре GPT эту проблему решали абсолютные позиционные эмбеддинги: к вектору токена добавлялся изученный вектор, соответствующий его позиции в последовательности (Рисунок 4).

RoPE (Rotary Position Embedding) предложила другой подход: вместо добавления позиционной информации в виде отдельных векторов, она кодирует позицию путем вращения векторов запроса и ключа, которое зависит от позиции каждого токена. (Идея RoPE элегантна, но ее объяснение — тема сложная, которую я планирую подробно разобрать отдельно.)

Впервые представленные в 2021 году, RoPE получили широкое распространение с выходом оригинальной модели Llama в 2023 году и с тех пор стали стандартом для современных LLM.

⚓ Пример программного кода реализации RoPE

2.3 Swish/SwiGLU заменяет GELU

Ранние архитектуры GPT использовали активационную функцию GELU. Почему теперь используют Swish вместо GELU? Swish (также известная как сигмоидный линейный блок, SiLU) считается вычислительно немного дешевле, и, на мой взгляд, в этом и заключается вся причина. В зависимости от того, на какую статью вы посмотрите, вы обнаружите, что одна функция немного лучше другой с точки зрения производительности моделирования. На мой взгляд, эти небольшие различия, вероятно, лежат в пределах стандартной погрешности, и конкретный результат будет сильно зависеть от тонкой настройки гиперпараметров.

Активационные функции были горячей темой для споров, пока сообщество глубокого обучения более десяти лет назад в основном не остановилось на ReLU. С тех пор исследователи предлагали и пробовали множество вариантов, похожих на ReLU, но с более гладкими кривыми; GELU и Swish (Рисунок 5) — это те из них, что прижились.

Ранние архитектуры GPT использовали GELU, которая определяется как

Здесь erf (от англ. error function — функция ошибок) — это интеграл от гауссовой функции, вычисляемый с помощью полиномиальных приближений, что делает его вычислительно более затратным, чем более простые функции, например, сигмоиду, используемую в Swish .

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

Swish используется в большинстве современных архитектур. Однако GELU не полностью забыта; например, модели Google Gemma по-прежнему используют GELU.

Однако более значимое изменение заключается в том, что сам feed-forward модуль (небольшая многослойная сеть) заменен на его «воротируемый» аналог — GLU (Gated Linear Unit), предложенный в статье 2020 года. Конкретно, 2 полносвязных слоя заменяются на 3, которые используются, как показано на Рисунке 6 ниже.

На первый взгляд может показаться, что варианты GEGLU/SwiGLU лучше обычных слоев просто потому, что в них больше параметров из-за дополнительного слоя. Но это обманчиво, потому что на практике весовые матрицы  и  в SwiGLU/GEGLU обычно выбираются в два раза меньше, чем матрица  в традиционном feed-forward слое.

Чтобы проиллюстрировать это лучше, рассмотрим конкретные реализации в коде:

> Обратите внимание, что функция Swish реализована как «silu» в PyTorch.

Предположим, размерность эмбеддинга равна 1024. В случае обычного feed-forward слоя:

• fc1: 1024 × 4096 = 4 194 304 параметра

• fc2: 4096 × 1024 = 4 194 304 параметра

• Итого: 8 388 608 параметров.

Для варианта GLU:

• fc1: 1024 × 1024 = 1 048 576 параметров

• fc2: 1024 × 1024 = 1 048 576 параметров

• fc3: 1024 × 1024 = 1 048 576 параметров

• Итого: 3 × 1 048 576 = 3 145 728 параметров.

Таким образом, использование вариантов GLU в итоге приводит к меньшему общему количеству параметров, при этом они еще и показывают лучшую производительность. Причина этого в том, что эти варианты обеспечивают дополнительное мультипликативное взаимодействие, что повышает выразительную способность сети (по той же причине глубокие и узкие сети могут превзойти широкие и мелкие при условии качественного обучения).

⚓ Пример программного кода реализации SwiGLU

2.4 Mixture-of-Experts вместо единого модуля FeedForward

Помимо обновления модуля feed-forward до SwiGLU, о чём шла речь в предыдущем разделе, в gpt-oss единый feed-forward модуль заменяется на несколько таких модулей, при этом на каждом шаге генерации токена используется лишь подмножество из них. Такой подход известен как «смесь экспертов» (Mixture-of-Experts, MoE) и проиллюстрирован на Рисунке 8 ниже.

Таким образом, замена одного feed-forward модуля на несколько (как это реализовано в архитектуре MoE) существенно увеличивает общее количество параметров модели. Однако ключевая хитрость заключается в том, что не все «эксперты» задействуются («активируются») для каждого токена. Вместо этого специальный маршрутизатор (router) выбирает лишь небольшое подмножество экспертов для каждого конкретного токена.

Поскольку одновременно активны лишь несколько экспертов, модули MoE часто называют разреженными (sparse), в отличие от плотных (dense) модулей, которые всегда используют полный набор параметров. При этом большое общее количество параметров, обеспечиваемое архитектурой MoE, повышает ёмкость языковой модели, позволяя ей усваивать больше знаний в процессе обучения. В то же время разреженность сохраняет эффективность вывода (inference), поскольку не все параметры задействуются одновременно.

(Интересный факт: в большинстве моделей MoE веса экспертов составляют более 90 % от общего числа параметров модели.)

⚓ Пример программного кода реализации Mixture-of-Experts

2.5 Grouped Query Attention вместо Multi-Head Attention

Как упоминалось в моих предыдущих статьях, в последние годы Grouped Query Attention (GQA, «групповое внимание по запросам») стало более эффективной с точки зрения вычислений и количества параметров альтернативой классическому Multi-Head Attention (MHA, «многоголовому вниманию»).

В MHA каждая «голова» имеет собственные проекции ключей и значений. GQA снижает потребление памяти за счёт объединения нескольких голов в группы, которые совместно используют одни и те же проекции ключей и значений.

Например, как показано на Рисунке 9, если у нас есть 2 группы ключей и значений и 4 головы внимания, то головы 1 и 2 могут использовать одну и ту же пару ключ–значение, а головы 3 и 4 — другую. Такая группировка уменьшает общее количество вычислений для ключей и значений, что приводит к снижению объёма памяти и повышению эффективности без заметного ухудшения качества модели, согласно аблационным исследованиям.

Здесь размер группы равен 2, где пара «ключ-значение» используется совместно двумя запросами.

Таким образом, основная идея GQA — сократить количество «голов» ключей и значений, заставив несколько голов запросов делить одни и те же ключи и значения. Это (1) уменьшает общее число параметров модели и (2) снижает потребление пропускной способности памяти при выводе, поскольку в кэше KV-пар (ключ–значение) хранится и извлекается меньше данных.

Хотя GQA в первую очередь служит инструментом повышения вычислительной эффективности по сравнению с MHA, абиляционные исследования (например, в оригинальной статье про GQA и в статье про Llama 2) показывают, что по качеству моделирования она сопоставима со стандартным MHA.

⚓ Пример программного кода реализации Grouped Query Attention

2.6 Внимание с подвижным окном (Sliding Window Attention)

Внимание с подвижным окном (Рисунок 10 ниже) впервые было предложено в статье LongFormer (2020) и позже получило широкое распространение благодаря Mistral. Примечательно, что в gpt-oss оно применяется в каждом втором слое. Можно рассматривать его как вариант многоголового внимания (а в данном случае — Grouped Query Attention), в котором контекст внимания ограничен небольшим окном, что снижает как объём памяти, так и вычислительные затраты.

Конкретно, gpt-oss чередует слои GQA с полным доступом ко всему контексту и слои GQA с подвижным окном, ограниченным 128 токенами.

Как я уже обсуждал в предыдущей статье, Gemma 2 (2024) использовала аналогичное соотношение 1:1. А Gemma 3, вышедшая ранее в этом году, пошла ещё дальше и перешла на соотношение 5:1 — то есть только один слой с полным вниманием приходится на каждые пять слоёв с локальным (оконным) вниманием.

Согласно аблационным исследованиям в рамках проекта Gemma, использование внимания с подвижным окном практически не влияет на качество моделирования, как показано на рисунке ниже. Стоит отметить, что размер окна в Gemma 2 составлял 4096 токенов, а в Gemma 3 был уменьшен до 1024. В gpt-oss же окно составляет всего 128 токенов — что удивительно мало.

И в качестве интересного факта: в официальной анонсирующей статье отмечается, что внимание с подвижным окном, похоже, уже использовалось в GPT-3:

«Модели используют чередующиеся плотные и локально-полосатые разреженные паттерны внимания, аналогичные GPT-3».

Кто бы мог подумать! Я перечитал оригинальную статью про GPT-3, и там действительно упоминалось:

«Мы используем ту же модель и архитектуру, что и в GPT-2 [RWC+19], включая модифицированную инициализацию, предварительную нормализацию и обратимую токенизацию, описанные в той работе, за исключением того, что в слоях трансформера мы применяем чередующиеся плотные и локально-полосатые разреженные паттерны внимания, аналогичные Sparse Transformer [CGRS19].»

2.7 RMSNorm вместо LayerNorm

Наконец, последнее небольшое улучшение по сравнению с GPT-2 — замена LayerNorm (2016) на RMSNorm (2019), что стало общей тенденцией в последние годы.

Подобно замене GELU на Swish и SwiGLU, RMSNorm — это ещё одно небольшое, но разумное улучшение эффективности. RMSNorm, как и LayerNorm, предназначен для нормализации активаций слоя, как показано на Рисунке 11 ниже.

Возможно, вы помните, что не так давно стандартом де-факто была BatchNorm. Однако она утратила популярность, главным образом потому, что её сложно эффективно распараллеливать (из-за необходимости вычислять статистики по батчу — среднее и дисперсию) и она плохо работает при малых размерах батчей.

Как видно на Рисунке 11, и LayerNorm, и RMSNorm масштабируют выходы слоя, приводя их к разумному диапазону значений.

LayerNorm вычитает среднее значение и делит на стандартное отклонение, чтобы выходы слоя имели нулевое среднее и единичную дисперсию (дисперсия = 1, стандартное отклонение = 1).

RMSNorm делит входы на корень из среднего квадрата (root-mean-square). Это масштабирует активации до сопоставимой величины, но не принуждает их к нулевому среднему или единичной дисперсии. В приведённом примере среднее значение равно 0.77, а дисперсия — 0.41.

Обе нормализации стабилизируют масштаб активаций и улучшают обучаемость, однако RMSNorm чаще предпочтителен в крупномасштабных LLM, потому что он дешевле в вычислениях. В отличие от LayerNorm, RMSNorm не содержит смещающего (bias) члена и заменяет дорогие операции вычисления среднего и дисперсии на одну операцию вычисления среднеквадратичного значения. Это сокращает количество межпризнаковых редукций с двух до одной, что снижает коммуникационные накладные расходы на GPU и повышает эффективность обучения.

На Рисунке 12 показано, как это выглядит в коде:

⚓ Пример программного кода реализации RMSNorm

2.8 Наследие GPT-2

Я по-прежнему считаю, что GPT-2 — отличная архитектура для начинающих, изучающих LLM. Она достаточно проста, чтобы не запутаться в слоях оптимизационных ухищрений, но при этом достаточно сложна, чтобы дать прочное понимание того, как работают современные трансформерные модели.

Начав с GPT-2, вы сможете сосредоточиться на фундаментальных концепциях (механизмы внимания, позиционные эмбеддинги, нормализация и общий пайплайн обучения), не перегружаясь дополнительными функциями и доработками, характерными для более новых архитектур.

Более того, я считаю, что стоит потратить время на изучение и даже самостоятельную реализацию GPT-2 до того, как начинать наслаивать на неё более современные изменения. Вы не только легче поймёте эти нововведения, но и, скорее всего, будете больше их ценить — ведь у вас появится чёткое понимание тех ограничений или проблем, которые они призваны решить.

Например, взяв за основу свой код GPT-2, я недавно реализовал с нуля архитектуру Qwen3, которая, как окажется далее, очень похожа на gpt-oss. Это подводит нас к следующей теме: сравнению gpt-oss с более современной архитектурой.

---

3. Сравнение gpt-oss с современной архитектурой (Qwen3)

Теперь, когда мы проследили эволюцию от GPT-2 до GPT OSS, можно перейти к следующему шагу и сравнить GPT OSS с более современной архитектурой — Qwen3, выпущенной тремя месяцами ранее, в мае 2025 года.

Причина, по которой я выбрал именно Qwen3, заключается в том, что на момент написания это одна из лучших моделей с открытыми весами. Кроме того, одна из MoE-моделей Qwen3 в целом сопоставима по размеру обучаемых параметров с gpt-oss.

На Рисунке 13 ниже показано сравнение gpt-oss-20b и модели Qwen3 сопоставимого размера.

Как видно, gpt-oss-20B и Qwen3-30B-A3B очень похожи по компонентам архитектуры. Основное различие (помимо размерностей) заключается в том, что gpt-oss использует внимание с подвижным окном, о чём уже говорилось в разделе 2.6 (на рисунке это не показано), тогда как Qwen3 такого механизма не применяет.

Далее мы рассмотрим наиболее примечательные детали по порядку.

3.1 Ширина против глубины

Если внимательно сравнить обе модели, станет ясно, что Qwen3 — гораздо более глубокая архитектура: у неё 48 трансформерных блоков вместо 24 (Рисунок 14).

С другой стороны, gpt-oss — гораздо более широкая архитектура:

• Размерность эмбеддинга: 2880 вместо 2048

• Промежуточная размерность проекции «экспертов» (feed-forward): также 2880 вместо 768

Стоит также отметить, что gpt-oss использует вдвое больше голов внимания, хотя это напрямую не увеличивает ширину модели — ширина определяется размерностью эмбеддинга.

Даёт ли один из подходов преимущество при фиксированном количестве параметров? Как правило, более глубокие модели обладают большей гибкостью, но их сложнее обучать из-за проблем нестабильности — взрывающихся и исчезающих градиентов (с которыми борются RMSNorm и skip-соединения).

Более широкие архитектуры выигрывают в скорости генерации (больше токенов в секунду) благодаря лучшей параллелизации, но ценой более высокого потребления памяти.

Что касается качества моделирования, то, к сожалению, я не знаю хороших «яблоко-к-яблоку» сравнений (где размер модели и обучающие данные строго фиксированы), кроме аблационного исследования в статье про Gemma 2 (Таблица 9). Там для архитектуры с 9 млрд параметров более широкая конфигурация оказалась немного лучше глубокой: по среднему значению на 4 бенчмарках широкая модель набрала 52.0 балла против 50.8 у глубокой.

3.2 Немного крупных экспертов против множества мелких

Как показано на Рисунке 14 выше, примечательно, что у gpt-oss удивительно мало экспертов (всего 32 вместо 128), и при этом активируется лишь 4 из них на токен (вместо 8). Однако каждый из этих экспертов значительно крупнее, чем у Qwen3.

Это интересно, потому что последние тенденции указывают на пользу от большего числа мелких экспертов. Такое изменение при фиксированном общем числе параметров хорошо иллюстрирует Рисунок 15 из статьи DeepSeekMoE.

Стоит отметить, что, в отличие от моделей DeepSeek, ни gpt-oss, ни Qwen3 не используют общих (shared) экспертов.

Справедливости ради, небольшое число экспертов в gpt-oss может быть побочным эффектом её размера в 20 млрд параметров. Если взглянуть на модель в 120 млрд (Рисунок 16 ниже), видно, что количество экспертов (и трансформерных блоков) действительно увеличили, сохранив всё остальное без изменений.

Наиболее скучное объяснение такой схожести моделей 20B и 120B, вероятно, в том, что основное внимание уделялось модели 120B, а 20B получили простым укорочением (меньше блоков) и сокращением числа экспертов — ведь именно в них сосредоточена основная масса параметров. Можно также предположить, что они начали обучать 120B-модель, а затем «отрезали» часть блоков и экспертов для дообучения (вместо инициализации с нуля).

В любом случае, крайне необычно масштабировать только эти два компонента. Например, если посмотреть на MoE-модели Qwen3 разных размеров (Рисунок 17 ниже), видно, что они масштабируются более пропорционально по множеству параметров.

3.3 Смещения внимания и «поглотители»

И gpt-oss, и Qwen3 используют Grouped Query Attention. Основное отличие — в том, что gpt-oss ограничивает длину контекста с помощью внимания с подвижным окном в каждом втором слое, как уже упоминалось.

Однако меня привлёк ещё один интересный нюанс: похоже, что gpt-oss использует смещения (bias) в весах внимания, как показано на рисунке ниже.

Я не видел таких смещений с времён GPT-2, и они обычно считаются избыточными. Действительно, в недавней статье математически показано, что это верно как минимум для проекции ключей (k_proj). Более того, эмпирические результаты демонстрируют почти нулевую разницу между моделями со смещениями и без (см. Рисунок 19 ниже).

Ещё одна деталь, которую вы могли заметить на скриншоте кода (Рисунок 18) — определение «поглотителей» (sinks). В общем случае attention sinks — это специальные токены в начале последовательности, к которым всегда применяется внимание, чтобы стабилизировать его работу, особенно в сценариях с длинным контекстом. Если контекст становится очень длинным, такой токен в начале всё ещё остаётся в фокусе внимания и может обучиться хранить полезную общую информацию обо всей последовательности. (Эта идея впервые была предложена в статье «Efficient Streaming Language Models with Attention Sinks».)

В реализации gpt-oss attention sinks — это не реальные токены во входной последовательности. Вместо этого это обучаемые bias-логиты, добавляемые к оценкам внимания для каждой головы (Рисунок 20). Цель та же, но без изменения токенизированного входа.

3.4 Лицензия

Наконец, как и Qwen3, модели gpt-oss распространяются под открытой лицензией Apache 2.0 — это замечательно (это та же лицензия, которую я предпочитаю для своих собственных open-source проектов). Это означает, что модели можно использовать для дистилляции в другие модели или в коммерческих продуктах без ограничений.

Открытые веса vs. открытый исходный код. Этот вопрос обсуждается годами, но стоит уточнить, чтобы избежать путаницы вокруг данного релиза. Некоторые разработчики моделей публикуют только веса и код для инференса (например, Llama, Gemma, gpt-oss), тогда как другие (например, OLMo) выпускают всё — включая код обучения, датасеты и веса, что соответствует строгому определению «открытого исходного кода».

По этому строгому критерию gpt-oss — модель с открытыми весами (как и Qwen3), поскольку включает веса и код инференса, но не код обучения и не датасеты. Однако в индустрии эта терминология используется несогласованно.

Я предполагаю, что «oss» в «gpt-oss» означает «open source software»; однако меня приятно удивило, что сама OpenAI в своём официальном анонсе чётко называет gpt-oss моделью с открытыми весами.

---

4. Прочие интересные детали

Хотя предыдущие разделы описали эволюцию архитектуры с момента GPT-2 и обсудили её сходства с Qwen3 (и большинством других современных моделей), есть ещё несколько важных нюансов, о которых я ещё не упомянул. Они не совсем вписываются в предыдущие разделы, но заслуживают внимания.

4.1 Обзор обучения

К сожалению, информации о размерах обучающих наборов и алгоритмах почти нет. Ниже я собрал самые интересные фрагменты из отчёта в model card (1) и анонсирующего поста (2):

Модели gpt-oss обучались с использованием наших самых передовых методов предобучения и постобучения [...] (1)

[...] обучение заняло 2.1 млн часов на GPU H100, причём gpt-oss-20b потребовала почти в 10 раз меньше. (1)

[...] включая этап обучения с учителем и этап обучения с подкреплением с высокими вычислительными затратами [...] (2)

Мы обучали модели на преимущественно англоязычном текстовом датасете с акцентом на STEM, программирование и общие знания. (2)

Таким образом, мы знаем, что gpt-oss — это модели, ориентированные на рассуждения. Объём вычислений — 2.1 млн часов на H100 — примерно сопоставим с 2.788 млн часов на H800, затраченных на обучение модели DeepSeek V3, которая почти в 5.6 раза крупнее. К сожалению, данных о времени обучения Qwen3 пока нет.

Интересно, что в оценку времени обучения gpt-oss включены как обучение с учителем для следования инструкциям, так и обучение с подкреплением для рассуждений, тогда как DeepSeek V3 — это лишь предобученная базовая модель, на основе которой отдельно обучалась DeepSeek R1.

4.2 Уровни рассуждений

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

Конкретно, модели gpt-oss могут получать инструкции вида «Reasoning effort: low/medium/high» («Уровень рассуждений: низкий/средний/высокий») в системном промпте, что напрямую влияет на длину и точность ответа, как показано на Рисунке 21.

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

Немного досадно, что OpenAI, в отличие от Qwen3 или OLMo, не выпустила базовые модели до этапа обучения с подкреплением для рассуждений. Базовые модели особенно ценны для исследователей, работающих над методами рассуждений (поэтому сейчас я предпочитаю использовать Qwen3 Base). Вероятно, решение OpenAI было продиктовано промышленными и production-сценариями, а не исследовательскими потребностями.

Заметим, что оригинальные модели Qwen3 также имели переключатель для включения/отключения режима рассуждений (через параметр enable_thinking=True/False в токенизаторе, который просто добавлял теги <think></think> для отключения рассуждений). Однако команда Qwen3 обновила свои модели за последние недели и отказалась от гибридного подхода в пользу специализированных вариантов: Instruct / Thinking / Coder.

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

После обсуждения с сообществом и размышлений мы решили отказаться от гибридного режима рассуждений. Теперь мы будем обучать модели Instruct и Thinking отдельно, чтобы достичь наилучшего качества.

4.3 Оптимизация MXFP4: небольшая, но важная деталь

Одним из интересных сюрпризов стало то, что OpenAI выпустила модели gpt-oss с квантованием MoE-экспертов в формате MXFP4.

Раньше форматы квантования были нишевой темой, актуальной в основном для мобильного и встраиваемого ИИ, но всё изменилось с ростом размеров моделей. В данном случае оптимизация MXFP4 позволяет запускать модель на одном GPU.

Вот как это выглядит на практике:

• Крупная модель (120B) помещается на один GPU с 80 ГБ памяти (H100 или новее). Это не потребительское железо, но арендовать машину с одним H100 гораздо дешевле, чем с несколькими. Плюс не нужно заботиться о распределении модели по GPU и накладных расходах на коммуникацию. Приятно, что поддержка AMD MI300X доступна с самого начала!

• Меньшая модель (20B) умещается даже в 16 ГБ видеопамяти; правда, для этого требуется GPU серии RTX 50 или новее, поддерживающий MXFP4. (Примечание: недавно вышел патч, добавивший поддержку и для старых карт, например, RTX 4090.)

Отметим, что модели также будут работать и на старом оборудовании, но без MXFP4, и тогда потребление RAM будет значительно выше. Без MXFP4-оптимизации модели в формате bfloat16 займут около 48 ГБ (gpt-oss-20b) и 240 ГБ (gpt-oss-120b).

Кстати, я спокойно запускаю gpt-oss-20b на своём Mac Mini через Ollama. Она использует около 13.5 ГБ памяти — вполне разумный объём.

4.4 Бенчмарки

Модели ещё слишком новые для независимых бенчмарков. Проверив лидерборд LM Arena, я обнаружил, что gpt-oss там пока не представлена. Таким образом, Qwen3-Instruct остаётся на данный момент лучшей моделью с открытыми весами по мнению пользователей LM Arena (Рисунок 22).

Однако, согласно бенчмаркам рассуждений из анонсирующего поста gpt-oss, эти модели сопоставимы как с проприетарными моделями OpenAI, так и с Qwen3 (Рисунок 23).

Однако стоит учитывать, что gpt-oss-120b почти вдвое меньше модели Qwen3 A235B-A22B-Thinking-2507 и при этом запускается на одном GPU.

Производительность в бенчмарках, впрочем, не всегда отражает реальную удобство использования. За несколько дней ограниченного тестирования я обнаружил, что gpt-oss весьма компетентна. Тем не менее, как и другие, я заметил у неё относительно высокую склонность к галлюцинациям (этот момент также упомянут в её model card).

Возможно, это связано с сильным акцентом на задачи рассуждений — математику, головоломки, код, — что могло привести к некоторому «забыванию общей информации». Однако, поскольку gpt-oss изначально создавалась с учётом использования инструментов, это ограничение со временем может стать менее значимым. Интеграция инструментов в open-source LLM всё ещё на ранней стадии, но по мере её развития я ожидаю, что модели всё чаще будут обращаться к внешним источникам (например, поисковикам) при ответах на фактологические вопросы.

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

---

5. gpt-oss и GPT-5

У OpenAI выдалась насыщенная неделя: вскоре после выпуска gpt-oss компания представила долгожданную модель GPT-5. Релиз GPT-5 оказался любопытным. И если я должен сказать об этом что-то одно, то меня по-настоящему удивило, насколько хороши их open-source модели по сравнению с их же лучшим коммерческим продуктом — если судить по бенчмаркам (Рисунок 24).

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