Skip to content
Published on

Qwen3.8-27Bのハイブリッドアテンション — 64層のうちKVキャッシュを積むのは16層だけ

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

この記事は2026-08-15にHacker News APIとGeekNewsフィードで直接確認した項目に基づいています。スコアと順位は変わり続けます。

何が上がっていたか

Hacker News APIで確認した項目です。タイトルは Qwen 3.8 27B、アイテム番号は49299605で、2026-08-15時点で793ポイント、コメント519件でした。リンク先はHugging Faceの Qwen/Qwen3.8-27B-FP8 モデルカードです。同じ日のGeekNewsフィードにも同じ項目が並んでいました。スコアとコメント数は確認している間にも動いていました。

このモデルカードで目を引くのはベンチマークの数字ではありません。層の構成です。

27Bで26万トークンが成り立つ理由

カードに書かれたパラメータは270億個、層は64、隠れ次元は5,120です。コンテキストは262,144トークンが標準で、位置補間を使えば1,000,000トークンまで伸ばせるとあります。

ここで一度止まる必要があります。通常のトランスフォーマーでは、26万トークンはパラメータ数と無関係にそれ自体が負担です。KVキャッシュがトークン数と層数の積に比例して伸びるからです。層が64あれば26万トークン分のキャッシュを64組抱えることになり、その時点でキャッシュは27Bの重みを簡単に超えます。

カードは層構成をこう記しています。16 x (3 x (Gated DeltaNet -> FFN) -> 1 x (Gated Attention -> FFN))。読み下すとこうです。4つ組が16回繰り返され、組の中の前3つがGated DeltaNet、最後の1つだけが通常のアテンションです。

つまり64層のうち48層は線形アテンションで、16層だけが通常のアテンションです。そしてKVキャッシュが伸びるのはその16層だけです。残りの48層は系列がどれだけ長くなっても固定サイズの状態を1つ保つだけです。

そこにグループクエリアテンションがもう一度かかります

キャッシュを積む16層の設定もカードにあります。クエリヘッド24、キー/バリューヘッド4、ヘッド次元256です。クエリとキー/バリューの比が6対1なので、この層が抱えるキャッシュは全ヘッドが自前のキー/バリューを持つ構成に比べて6分の1です。

2つの節約が掛け合わさります。キャッシュを積む層が4分の1、その層の中でさらに6分の1です。26万トークンがコンシューマー機材で成立するのはここです。Gated DeltaNet側はバリューヘッド48、クエリ/キーヘッド16、ヘッド次元128と記されています。

何を失うのか

ただではありません。線形アテンションの状態はサイズが固定なので、過去の全体をその中に圧縮して収めます。圧縮には損失があります。

通常のアテンションは20万トークン前に現れた特定の文字列を正確にたどれます。クエリとその位置のキーを直接内積するからです。固定状態にはその個別の項目が残っていません。純粋な線形アテンションのモデルが長い文書での正確な引用や識別子の照合に弱いのはこのためです。

この構造がハイブリッドである理由がそこにあります。4層ごとに1回入る通常のアテンション層が正確な参照を担う通路です。線形層が要約と流れを安く運び、周期的に現れるアテンション層が必要な瞬間に原文を直接見ます。3対1という比率はその2つを引き換えにした結果であって、最適解として証明された値ではありません。

実務的な意味はこうです。長いコンテキストでこのモデルを使い、要約と推論はうまくいくのに特定の値を正確に取り出す作業だけ妙に外れるなら、それはプロンプトの問題ではなく構造から予想される失敗です。

FP8はどこに効くのか

このリポジトリはFP8版です。カードはブロックサイズ128の細粒度FP8量子化を使い、性能は元のモデルとほぼ同等だと記しています。

ブロックサイズが要点です。重み全体にスケールを1つ使うと、外れ値1つが残り全部の解像度を削ります。128個ずつまとめて組ごとにスケールを持たせれば、外れ値の被害はその組の中に閉じ込められます。

注意すべきは、FP8が重みを減らすのであってKVキャッシュを減らすのではないという点です。上で見たキャッシュの節約は層構成から来たもので、FP8とは別物です。長いコンテキストでメモリが破綻するなら、重みの量子化をさらに締めても解決しません。そのとき見るべきはキャッシュ量子化か同時リクエスト数です。

1Mコンテキストに付いた条件

カードは位置補間で100万トークンまで伸ばせるとしながら、限界も併記しています。実装が静的で、倍率が入力長と無関係に固定されるという点です。

これは読み飛ばしてよい一文ではありません。100万トークン設定を入れておくと、2千トークンのリクエストにも同じ倍率がかかります。短い入力の品質が下がりうるということです。

したがって配備の観点では、1つのエンドポイントで長短どちらのリクエストも受ける構成は危険です。長いコンテキストを要するトラフィックが一部なら、拡張設定を入れたインスタンスと切ったインスタンスを分けるほうが良いです。参考までに、カードが示す100万トークン基準の出力配分は推論に262,144トークン、最終応答に131,072トークンです。

ベンチマークと実行設定

カードに記された数値の一部です。SWE-bench Pro 61.7%、Terminal Bench 2.1 73.0%、IFBench 79.5%、LiveCodeBench v6 90.3%。ビジョン側はOSWorld-Verified 84.3%、AndroidWorld 81.9%、OmniDocBench 1.5が91.1%、MathVisionは思考連鎖を有効にした条件で94.6%です。

推論フレームワークとしてSGLang、vLLM、TokenSpeedが挙げられ、ライセンスはApache 2.0です。

# 例: モデルカードに記された最小の起動形
vllm serve "Qwen/Qwen3.8-27B-FP8"

サンプリング値がモードごとに異なる点が重要です。思考モードはtemperature 1.0、top_p 0.95、top_k 20、presence_penalty 0.0、指示モードはtemperature 0.7、top_p 0.80、top_k 20、presence_penalty 1.5です。既定が思考モードだと書かれています。

コメントで割れた点

コメントで繰り返し指摘されたのはベンチマークではなくトークン使用量でした。あるコメントは自分の非公開の問題を解きはしたが5倍のトークンがかかったと書き、別のコメントは同程度の大きさの競合モデルが10分の1の思考トークンで同じ結論に達するので使う理由を見つけにくいとしています。

この指摘が重要なのは、ベンチマーク表がこの軸をまったく見せないからです。正確度61.7%は、その答えを出すのに何トークンかかったかを含んでいません。ローカル実行ではこれがそのまま体感待ち時間になります。チャットテンプレートがずれているという指摘も何度も出ました。ツール呼び出しが思うように動かないときは、モデルより先にテンプレートを疑う話です。

どう適用するか

ローカルまたは社内推論を検討中なら、実際に持ち帰るべきものは次の3つです。

第一に、モデルをパラメータ数だけで比べる習慣をやめることです。27Bという数字は重みメモリだけを教えます。長いコンテキストを扱うワークロードなら、実際の上限を決めるのはKVメモリであり、それは層構成から来ます。候補モデルの設定ファイルから層数、アテンション層の比率、キー/バリューヘッド数を抜き出して表にするほうが、パラメータ数を比べるよりはるかに有用です。

第二に、評価指標にトークン数を入れることです。正確度だけを測ると、思考トークンを多く使うモデルが常に勝ちます。課題あたりの平均出力トークンと95パーセンタイル遅延を同じ表に載せると、選択が変わることが多いです。

第三に、長いコンテキスト設定をトラフィック全体に有効化しないことです。上で見た静的倍率の問題があるためです。

誰には当てはまらないか

マネージドAPIだけを使い今後もそうする予定なら、この記事の大半は背景知識です。層構成は請求書に現れません。その場合はトークン単価と応答時間だけ見れば十分です。

コンテキストがおおむね8千トークン未満に収まるワークロードも同様です。その長さではKVキャッシュがボトルネックではないため、ハイブリッド構造の利点が現れないまま圧縮損失だけを背負うことになりえます。法務文書から条項を原文どおり抜き出すパイプラインのように、正確な引用が契約条件である作業も、慎重に検証してから導入すべきです。

まとめ

このモデルカードが本当に教えるのは新しいモデルが出たという事実ではなく、長いコンテキストのコストがパラメータ数ではなくどの層がキャッシュを積むかで決まるという点です。48対16という比率はそのコストを再配置した結果であり、代償は遠い過去を正確にたどる能力の一部です。

原文と関連記事

本文の構造説明と適用方法は、モデルカードに記された数値をもとに筆者が整理したものです。

Discuss on Twitter • View on GitHub