GPT-OSSとQwen3の比較と、GPT-2以降の進化の詳細な考察

2025年8月11日原文(magazine.sebastianraschka.com)

概要

OpenAI が新たに gpt-oss-20b/120b というオープンウエイトLLMを公開
最新の トランスフォーマー系技術 と効率的な実装を採用
MoE や GQA など現代的な設計要素を導入
ローカル実行 も可能な最適化済みモデル
GPT-5 との比較やベンチマークも簡単に紹介

OpenAIの新オープンウエイトLLM「gpt-oss-20b」「gpt-oss-120b」概要

OpenAI が2019年の GPT-2 以来となる大規模 オープンウエイトモデル を公開
gpt-oss-20b は一般的な16GB GPUで、 gpt-oss-120b はH100(80GB)等でローカル実行可能
モデルの設計は従来のトランスフォーマーアーキテクチャをベースに、現代的な改良を多数採用
公式モデルページ（Hugging Face）で 重みとコード が公開
- https://huggingface.co/openai/gpt-oss-20b
- https://huggingface.co/openai/gpt-oss-120b
モデルの進化や設計思想、他モデル（GPT-5等）との比較が注目点

アーキテクチャ比較：GPT-2との違い

gpt-ossシリーズ と GPT-2 は共に「デコーダー専用」トランスフォーマーLLM
モデル設計の進化は主に 細かな最適化 や 新技術の導入 によるもの
ドロップアウト はGPT-2で採用、現代LLMではほぼ未使用
- 単一エポック学習が主流となり、 過学習対策 としての効果が薄いため
位置エンコーディング は絶対位置埋め込みから RoPE 方式へ移行
- RoPE（Rotary Position Embedding）は2021年登場、Llama以降で標準技術に
活性化関数 は GELU から Swish へ
- Swishは計算コストが低く、ほぼ同等以上の性能
- Google Gemmaなど一部モデルは現在もGELUを使用

フィードフォワード層の進化：GLUとMoE

従来の フィードフォワード層 （2層MLP）は GLU（Gated Linear Unit） に置換
- 3層構成でパラメータ数は少なく、 表現力 が向上
- SwiGLUやGEGLUなどのバリエーションあり
Mixture-of-Experts（MoE） 構造を採用
- 複数の専門家層（Expert）から一部のみを動的に選択
- 総パラメータ数が増える一方、 推論時の計算コストは抑制
- 学習時の知識容量増加、90%以上のパラメータがExpertに割り当てられる

Attentionの最適化：GQA

Grouped Query Attention（GQA） を導入
- 複数のAttentionヘッドでKey/Valueを共有し、 計算効率とメモリ効率 を向上
- Multi-Head Attention（MHA）に比べてパラメータ・計算量を削減
- 性能低下はほぼ見られず、現代LLMで広く採用

モデルのローカル実行と最適化

gpt-oss-20b は16GB RAMの一般GPUでローカル実行可能
gpt-oss-120b はH100等の最新GPUで単体実行が可能
MXFP4 などの量子化・最適化技術により、計算資源の要求を抑制

まとめ・今後の展望

gpt-ossシリーズ は最新のLLM設計技術を集約
トランスフォーマーアーキテクチャ が依然として主流
データとアルゴリズムの最適化 が性能向上のカギ
GPT-5 など新世代モデルとの比較・ベンチマークも今後注目
実運用・多ターン対話・コーディングタスク等、さらなる評価が期待

参考文献・リンク

OpenAI公式モデルページ（Hugging Face）
- https://huggingface.co/openai/gpt-oss-20b
- https://huggingface.co/openai/gpt-oss-120b
論文・技術レポート等からの要点抽出

Hackerたちの意見

自分のローカルテストでは、Qwen3がかなり良かった。プロンプトへの応答がより正確で（32Bパラメータ版はほぼ完璧）、音声も自然に聞こえる。Simplebenchのgpt-oss（120bn）は全然ダメだったから、論理パズルもあまり得意じゃないみたい。だから、結局は… - トレーニング手法やデータ - 次元 - 大きな専門家の数が少ない vs 小さな専門家の数が多い

└

予想をするなら、アーキテクチャよりもデータやトレーニングパイプラインの方がずっと関係があると思う。多くの人がgpt-ossがPhiのような合成データセットを採用して、主にゲームのメトリクスに焦点を当てていると推測しているけど、今のところその証拠はかなり説得力があると思ってる。

└

MoEの期待されるパフォーマンス = sqrt(アクティブヘッド数 * 総パラメータ数) = sqrt(120*5) ≈ 24。GPT-OSS 120Bは実質的に24Bパラメータのモデルで、もっと小さいモデルのスピードを持ってるんだ。

└

qwen3は遅いね。使ってみたけど、動いたけど、遅いし機能も足りない感じ。

自分の経験では、qwen3-coderの方が全然良い。gpt-oss:20bをインストールして少しテストしてるけど、プログラムに要約を作るように指示したら、qwen3は数秒で動くのに、gpt-ossは5分後に何もせずにキャンセルされた…だから、qwen3を使ってる。速いし、出力も素晴らしい。もし何か必要なものが得られなかったら、検索エンジンやPerplexityを使うかも。自分の環境は10GBの3080とRyzen 3600x、32GBのRAMだよ。qwen3-coderはすごい。今まで使った中で一番良い。

└

20B版は10GBに収まらない。それがいくつかの問題の原因かも？

└

自分は軽くgpt-oss-20bを使ってるけど、小さい（1文）プロンプトだと無限ループに入ることが簡単だった。llama.cppで動かしてるから、小さな繰り返しペナルティを設定してからは、その問題には遭遇してない（1日に何回かdiffを分析するために使ってるから、運が良かっただけかも）。

└

Qwen3 coder 480Bはかなり良くて、Sonnet 4と同じくらいだね。中国のモデルがアメリカのモデルをすぐに追い越すかもしれないって初めて気づいたよ、特にコーディングに関しては。

└

これをエージェント的に使ってるの？それとも、コピー＆ペーストで「これをコードして」っていう単一入力・単一出力の使い方してるの？エージェント的なコーディングにおいて、フロンティアモデルがローカルからどれくらい離れているのか知りたいな。

現代のオープンウェイトLLMのアーキテクチャがこんなに似ているのは面白いし、ほとんどの革新がトレーニング（データ、RL）の方で起こっているみたい。これは、大きなMLショップで見たこととは逆で、アーキテクチャの調整が重要だった。

└

いいポイントだね。LLMは、リソースが十分あれば、参入障壁を下げるから。アーキテクチャが調整に強いから、計算とデータをたくさん投げればいいモデルが得られるんだ。スケーリング法則を無視しても、良いモデルが得られることもあるし（Llama 3がその例だね）。

└

僕の予想では、LLMのスケールではハイパーパラメータの調整を試みるのは無理だと思う。コストがかかりすぎるからね。いくつかのアーキテクチャを基本的にテストして、一つに決めて、そこからデータや強化学習を使ってどう活用するかを考える必要があるんじゃないかな。

Hacker Newsで議論の続きを見る

ハクソク