長い資料を読み込むLLMでは、回答を書き始める前の入力処理も待ち時間を左右する。
DeepSeekが2026年9月10日に公開したV4.1-Flashは、40層の主幹を前半20層と後半20層に分け、入力時と生成時で計算経路を変える。［1］［2］
中心にあるのは、後半が参照する大域KVを前半の出力から作る Causal Encoder-Decoder（CED） という構造だ。
本稿では2026年9月15日時点の公式モデルカード、設定ファイル、公開推論コードを使い、入力時8B・生成時16Bという活性パラメータ数の意味を読み解く。GPUでの速度測定は行っていない。
Prefillで準備しているもの
自己回帰型LLMの推論は、大きく二つに分かれる。
- Prefill：既知の入力列を処理し、続きの生成に必要な状態を準備する。
- Decode：その状態を参照しながら、次のトークンを順に生成する。
Attentionで使うKeyとValueを保存したものがKVキャッシュだ。一般的なDecoder-onlyモデルでは、各層がその層に入ってきた隠れ状態からKVを作る。過去の入力に対する後段のKVを用意するには、そこまでの層を計算する必要がある。
たとえば、長い議事録を読んで短い結論を返す処理では、生成する文章が短くても入力全体の処理は残る。入力と出力に同じ深さの計算を割り当てる構造では、この非対称な仕事量を活かしにくい。
CEDは、後段が過去を参照するための情報を、どこで作るかを変える。
前半20層で作った情報を、後半20層が参照する
V4.1-Flashの主幹は、20層のCausal Encoderと20層のDecoderで構成される。後半の大域KVは、前半の最終隠れ状態から射影して作られる。後半の各層で、全履歴に対する別々の大域KVを作る依存関係がなくなる。［2］
ここでの「Causal」は、未来のトークンを参照しないという意味だ。文章全体を双方向に読むエンコーダーを付けた、と理解すると生成時の動作を取り違える。
大域KVの供給関係だけを抜き出すと、次のようになる。局所Attention、正規化、残差経路などは省略している。
この依存関係から、入力全体の大域KVを準備する段階と、後半で予測を計算する段階を分けられることが分かる。公式は、この構造によりPrefillで1トークン当たり8B、Decodeで16Bのパラメータが活性化すると説明している。Bは10億であり、それぞれ80億、160億に相当する。［1］［2］
生成時には前半も必要だ。 新しく生成されたトークンを次のステップで処理するときには、それを前半へ通して履歴側の情報を更新し、後半で次の予測を作る。入力時8Bという数字を、モデル全体が80億パラメータになったという意味には読めない。
| 観点 | 一般的なDecoder-only | V4.1-FlashのCED |
|---|---|---|
| 大域KVの供給元 | 各層の隠れ状態 | 後半はEncoder最終状態から供給 |
| 入力全体の処理 | 後段のKV準備にも層を順に通す | 大域KV準備と後段の計算を分離可能 |
| 次トークンの予測 | 全層の計算を使う | EncoderとDecoderの両方を使う |
| 効率化の焦点 | 各層の演算・キャッシュ管理 | 入力処理の層間依存も変更する |
左列は構造を理解するための一般化であり、すべての既存モデルが同じキャッシュ方式を採るという意味ではない。
近傍の状態まで消えるわけではない
大域KVを共有しても、直近のトークンを見るSliding Window Attention（SWA）の状態は必要だ。公開設定の窓幅は128トークンである。公開コードでも、各Attention層に局所窓用のwindow_kv_cacheが確保されている。［3］［4］
公式モデルカードは、欠けたSWAの状態を直近の窓内トークンの再実行で復元する SWA Bounded Replay を説明している。これによりSWAのKVをSSDへ永続保存せずに済むという。［2］
したがって、「前半を計算すれば後半の準備は一切不要」という説明では不十分だ。大域的な履歴は前半から供給できる一方、局所的な履歴には保持または復元の処理が残る。入力処理を軽くする設計を考える際は、この二種類の状態を分ける必要がある。
設定とコードで追える、共有の境界
公開のinference/config.jsonには、次の値がある。層番号は0始まりだ。［3］
| 設定項目 | 公開値 |
|---|---|
n_layers |
40 |
kv_source_layers |
[2, 8, 14, 20] |
index_source_layers |
[2, 8, 14, 20, 24, 28, 32, 36] |
window_size |
128 |
コードのAttention._compress_kvを見ると、is_kv_sourceが真の層だけが大域KVを生成し、共有状態へ登録する。それ以外の層は、その共有状態を参照する。主幹の後半に当たる層20〜39では、層20だけがKVの供給元になる。［3］［4］
一方、層24、28、32、36はindex_source_layersに入っている。KVを共有することと、参照先の選び方を共有することは別だ。 同じ大域KVを使いつつ、途中の層で参照先を選び直せる。
この役割分担がCompressed Sparse Attention 2（CSA2）のFull、Reindex、Reuseという三つのモードにつながる。ここでは量子化のビット幅より先に、「誰がKVを作り、誰が参照先を選び、誰が再利用するか」を見ると、構造を追いやすい。［2］［4］
活性パラメータ数と、実際の待ち時間
公式モデルカードが示すV4-Flashとの比較は次のとおりだ。主幹のパラメータ数と、1トークンで使う活性パラメータ数を分けている。［2］
| 指標 | V4-Flash | V4.1-Flash |
|---|---|---|
| 主幹パラメータ数 | 284B | 552B |
| 活性パラメータ数 | 13B | 入力8B／生成16B |
主幹は大きくなっているが、入力時の活性パラメータ数は減っている。一方、生成時は13Bから16Bへ増えている。これだけでも、「新モデルはどの処理でも単純に軽い」とは言えない。
仕事量への影響を考えるため、入力をNトークン、出力をMトークンとし、活性パラメータ数とトークン数の積を足す粗い指標を作ってみる。
V4-Flash相当の指標 = 13 × N + 13 × M
V4.1-Flash相当の指標 = 8 × N + 16 × M
仮にN=100,000、M=1,000なら、後者と前者の比は約0.62になる。逆にN=1,000、M=10,000なら約1.17だ。これは上の公開値からの筆者による計算である。
この指標はFLOPs、GPU時間、API料金の推定式ではない。Attentionの計算、通信、メモリ帯域、局所状態の復元、バッチ効率などを省略している。入力と出力の比率によって、活性パラメータ数の増減が効く方向が変わることだけを示している。
実際の導入判断では、入力長別の初回トークン到着時間と、生成中のトークン間隔を分けて測る必要がある。同時実行数とキャッシュヒットの有無もそろえたい。
限界：公開コードを動かせば非対称な高速化も再現できるか
ここには実装上の注意点がある。DeepSeek自身が、公開のinference/README.mdを、読みやすさを重視した参照実装と位置付けている。生成ループは通常の自己回帰サンプリングだ。［5］
実際にTransformer.forwardを追うと、self.layersを順に反復している。この経路には、長い入力に対して後半の層を飛ばす最適化は見当たらない。公開コードで構造を確認できることと、入力時8Bに対応する最適化経路をそのまま測定できることは分けたい。 これは2026年9月15日に確認したコードの静的読解であり、公式API内部の実装を検証した結果ではない。［4］［5］
さらに、次の限界がある。
- 能力差をCED単独の効果にできない。 事前学習は45Tトークンのマルチモーダルコーパスで行われ、後学習も含めて複数の要素が変わっている。新旧モデルの差はCEDだけを入れ替えた実験ではない。［2］
- 全課題で旧モデルを上回るわけではない。 公式のBaseモデル比較では、5-shotのMMLU-Proは68.3から74.1へ上がる一方、8-shotのMGSMは85.7から80.2へ下がる。いずれも提供元の内部評価であり、Instructモデルの実用精度へそのまま移せない。［2］
- 少ない活性パラメータ数は、小さい保存容量を意味しない。 使われるExpertがトークンごとに変わるMoEでは、1トークンで触る重みだけを持てば済むわけではない。552Bという主幹の規模を含め、実際の配置と量子化を確認する必要がある。
- 実行基盤ごとの性能確認が残る。 vLLM Ascendの公式導入文書も、掲載構成のタスク精度と本番性能の検証が完了していないと明記している。起動手順の存在だけでは、速度や品質を保証できない。［6］
実務では、入力が長い仕事から測る
CEDの設計から考えると、最初に評価したいのは、長い入力に対して比較的短い出力を返す仕事だ。議事録から決定事項を抽出する処理、長い仕様書から指定項目を整理する処理などが候補になる。これは構造からの推論であり、これらの業務での優位性が実証済みという意味ではない。
評価用データを、たとえば入力4K・32K・128Kトークンに分け、出力上限、同時実行数、推論努力の設定をそろえる。各条件で初回トークン到着時間、生成中のトークン間隔、処理全体の時間、必要項目の抽出精度を記録する。再実行時のキャッシュが結果を変えるため、初回と再利用時も分ける。
回答が長い仕事では、入力処理の短縮だけでは全体の時間が縮まらない可能性がある。日本語の資料を扱うなら、日本語での抽出漏れや根拠箇所の正確さも同じ条件で確かめたい。
V4.1-Flashを読むうえでの設計上の収穫は、LLMの入力と生成に異なる計算経路を与え、その境界を大域KVの供給元で作っている点にある。モデルの大小だけでなく、どの仕事に、どの層の計算が必要なのかを見ると、推論の効率を考える選択肢が増える。
参考リンク
以下は2026年9月15日確認。発表日は2026年9月10日。モデルカード・コード・実行基盤の文書は更新されるため、実測時には使用した版も記録する。
［1］DeepSeek公式発表：Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient.（2026年9月10日）
［2］DeepSeek公式モデルカード：DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression
［3］DeepSeek公式参照実装：inference/config.json
［4］DeepSeek公式参照実装：inference/model.py
［5］DeepSeek公式参照実装：Minimal inference
［6］vLLM Ascend公式文書：DeepSeek-V4.1-Flash