Cambriconが掲げる「Day 0対応」は、チップそのものの新機能というより、モデル公開と同じ日に推論ソフトウェアを使える状態へ持ち込む統合力を示すものです。同社によれば、DeepSeek-V4.1-Flashは、オープンソースのvLLM推論スタックを通じて、CambriconのMLUアクセラレータ上で当日から動作可能になりました。構成要素は、NeuWareランタイム、Torch-MLU-Ops、そして最適化済みBangCカーネルです。13

大規模モデルは、重みが公開されたからといって直ちにサービス投入できるわけではありません。アクセラレータ用ランタイム、フレームワークの演算子実装、分散実行、さらに計算負荷が集中する処理を高速化するカーネルがそろって初めて、現実的な推論環境になります。

Day 0対応を支える3層

Cambriconの説明を整理すると、役割は次の3つに分かれます。

• NeuWare：MLUアクセラレータ向けのソフトウェアランタイム。
• Torch-MLU-Ops：モデルの演算子をMLU上で扱うための基盤。報道では、EngramやCompressorの構造への対応が挙げられています。9
• BangCカーネル：MLUアーキテクチャ上で性能が重要な処理を直接最適化するコード。BangCは、MLU向け高性能プログラムを記述するための異種並列プログラミング言語としてCambriconが説明しています。18

この構成の利点は、専用の一回限りのサービング実装ではなく、vLLMという広く使われる公開推論レイヤーを介してMLUバックエンドを利用できる点にあります。CambriconはvLLMについて、低ビット混合精度推論、並列化最適化、大規模エキスパート並列、PrefillとDecodeを分離するデプロイ方式などを最適化対象として挙げています。18

DeepSeek-V4.1-Flashがサービングを難しくする理由

DeepSeek-V4.1-Flashは、バックボーン5520億パラメータに加え、Engramメモリ1960億パラメータを備えるマルチモーダルMoE（Mixture of Experts）モデルです。テキストと画像を受け付け、コンテキスト長は最大100万トークンに対応します。58

重要なのは総パラメータ数と、実際に各トークンで動くパラメータ数が異なることです。DeepSeekによると、入力プロンプトを処理するPrefillでは1トークン当たり約80億、出力を順次生成するDecodeでは約160億のパラメータを有効化します。8

この非対称性は、長い入力を読む処理の演算量を抑える設計につながります。ただし、実運用のコストや性能は、重みの精度、バッチサイズ、通信、メモリ容量、同時実行数、ワークロード構成にも左右されます。

20層＋20層のCED設計

同モデルは40層の**Causal Encoder–Decoder（CED）**構成で、20層の因果エンコーダと20層のデコーダから成ります。デコーダのグローバルKV状態を各層で独立して算出するのではなく、エンコーダ最終層の隠れ状態から投影するのが特徴です。58

長文コンテキスト推論では、過去トークンを参照するために保持するKVキャッシュがメモリ制約になりやすく、この設計はその負荷を抑える狙いがあります。

KVキャッシュは「1トークン当たり890バイト」

DeepSeekは、Compressed Sparse Attention 2（CSA2）における層間KVキャッシュ再利用とFP4 KVキャッシュを組み合わせることで、HBM上に常駐するグローバルKVキャッシュを1トークン当たり890バイトに抑えたと報告しています。これはDeepSeek-V4-Flashの対応する容量のおよそ4分の1です。78

さらに、SWA Bounded Replayにより、SSDまたはホストメモリに保持する永続KVキャッシュはV4-Flashの約8分の1になるとしています。7

運用面では、リクエスト当たりのKV状態が小さくなれば、同じメモリ予算でより多くの長文セッションを並行処理できる可能性があります。ただし、これらはDeepSeekが示したモデル設計上の数値です。Cambriconのクラスタにおけるスループット、レイテンシー、可用性、精度、運用コストを独立に実証するエンドツーエンドのベンチマークではありません。

サービング最適化はどう効くのか

CambriconはvLLM向けの取り組みとして、複数の最適化を公開しています。18

• 混合精度・低ビット推論：重みや活性値の保持量、メモリ転送量を削減する。
• 並列化最適化と大規模エキスパート並列：巨大なモデルとMoEのルーティング処理を複数アクセラレータへ配分する。
• 通信と計算のオーバーラップ：エキスパートルーティングや集合通信の待ち時間を、演算と重ねて隠すことを狙う。
• Prefill–Decode分離：プロンプト処理とトークン生成を別々のリソースプールとして設計・調整する。

Prefillは長い入力の処理で帯域や演算負荷が大きくなりやすい一方、Decodeは1トークンずつ反復するため応答遅延に敏感です。MoEではさらに、どのエキスパートを使うかの分散協調が加わります。これらの最適化は、理論上の演算性能だけでなく、同時接続時の利用効率やサービスの予測可能性を高めるための組み合わせです。

公開情報には、V4.1-FlashをCambriconハードウェアで動かした際の再現可能なスループット、レイテンシー、クラスタ構成、モデル品質、SLAに関する測定値は示されていません。そのため「本番対応」という表現は、利用・支援可能なデプロイ経路があることを示すものとして捉え、実際の導入前には各事業者が自らの精度、コンテキスト長、量子化、バッチング、障害対応要件で検証すべきです。

PyTorch FoundationのPlatinum加盟が示すこと

PyTorch Foundationは2026年9月8日、CambriconがPlatinumメンバーとして加盟したと発表しました。49 同Foundationは別途、CambriconがvLLMコミュニティと協力し、DeepSeek-V4やGLM-5などのオープンモデルでDay 0サポートを進めてきたとしています。57

この加盟が直ちに全モデル・全機能の対応を保証するわけではありません。一方で、アクセラレータの価値を専用スタックに閉じず、PyTorchやvLLMといった広く使われる公開フレームワークのエコシステム内で高める、という方向性を裏付ける材料にはなります。

ほかに対応を掲げるモデル群

Cambriconのソフトウェア資料には、DeepSeek V3／V3.1、Qwen2.5、Qwen3、Qwen3-Next、GLM-4.5、Qwen3-VL、Flux、Wan 2.1／2.2、Hunyuan-Videoに関する支援・最適化が記載されています。18

ただし、この資料は学習対応とソフトウェア全般の最適化を含みます。したがって、すべてのモデル群がDeepSeek-V4.1-Flashと同じく「Day 0の本番vLLM推論」に対応しているとまでは言えません。推論可否、精度形式、画像対応、コンテキスト長、Day 0の対象範囲は、リリースごとに確認する必要があります。

クラスタ運用者にとっての意味

モデル公開当日の互換性は、既存インフラ上での評価開始までの時間を縮めます。しかもvLLM経由であれば、キャパシティ計画、ルーティング、監視、量子化評価、統合テストを、独自フォークよりもなじみのあるサービング基盤で進めやすくなります。

とりわけ長文・画像対応のワークロードでは、KVキャッシュとメモリ帯域がボトルネックになりやすい領域です。DeepSeek-V4.1-Flashが報告するキャッシュ圧縮は、その制約を緩和するためのモデル側の設計です。78

今回のポイントは、Day 0の発表だけで普遍的な本番性能が証明された、ということではありません。ランタイム、フレームワーク演算子、専用カーネル、分散実行、サービングツールまでを反復可能な形でつなげられるかが、より大規模で疎なMoEモデルやマルチモーダルモデルの登場時に、対応までの期間を短縮する鍵になります。

Cambriconが掲げる「Day 0対応」は、チップそのものの新機能というより、モデル公開と同じ日に推論ソフトウェアを使える状態へ持ち込む統合力を示すものです。同社によれば、DeepSeek-V4.1-Flashは、オープンソースのvLLM推論スタックを通じて、CambriconのMLUアクセラレータ上で当日から動作可能になりました。構成要素は、NeuWareランタイム、Torch-MLU-Ops、そして最適化済みBangCカーネルです。13

大規模モデルは、重みが公開されたからといって直ちにサービス投入できるわけではありません。アクセラレータ用ランタイム、フレームワークの演算子実装、分散実行、さらに計算負荷が集中する処理を高速化するカーネルがそろって初めて、現実的な推論環境になります。

Day 0対応を支える3層

Cambriconの説明を整理すると、役割は次の3つに分かれます。

• NeuWare：MLUアクセラレータ向けのソフトウェアランタイム。
• Torch-MLU-Ops：モデルの演算子をMLU上で扱うための基盤。報道では、EngramやCompressorの構造への対応が挙げられています。9
• BangCカーネル：MLUアーキテクチャ上で性能が重要な処理を直接最適化するコード。BangCは、MLU向け高性能プログラムを記述するための異種並列プログラミング言語としてCambriconが説明しています。18

この構成の利点は、専用の一回限りのサービング実装ではなく、vLLMという広く使われる公開推論レイヤーを介してMLUバックエンドを利用できる点にあります。CambriconはvLLMについて、低ビット混合精度推論、並列化最適化、大規模エキスパート並列、PrefillとDecodeを分離するデプロイ方式などを最適化対象として挙げています。18

DeepSeek-V4.1-Flashがサービングを難しくする理由

DeepSeek-V4.1-Flashは、バックボーン5520億パラメータに加え、Engramメモリ1960億パラメータを備えるマルチモーダルMoE（Mixture of Experts）モデルです。テキストと画像を受け付け、コンテキスト長は最大100万トークンに対応します。58

重要なのは総パラメータ数と、実際に各トークンで動くパラメータ数が異なることです。DeepSeekによると、入力プロンプトを処理するPrefillでは1トークン当たり約80億、出力を順次生成するDecodeでは約160億のパラメータを有効化します。8

この非対称性は、長い入力を読む処理の演算量を抑える設計につながります。ただし、実運用のコストや性能は、重みの精度、バッチサイズ、通信、メモリ容量、同時実行数、ワークロード構成にも左右されます。

20層＋20層のCED設計

同モデルは40層の**Causal Encoder–Decoder（CED）**構成で、20層の因果エンコーダと20層のデコーダから成ります。デコーダのグローバルKV状態を各層で独立して算出するのではなく、エンコーダ最終層の隠れ状態から投影するのが特徴です。58

長文コンテキスト推論では、過去トークンを参照するために保持するKVキャッシュがメモリ制約になりやすく、この設計はその負荷を抑える狙いがあります。

KVキャッシュは「1トークン当たり890バイト」

DeepSeekは、Compressed Sparse Attention 2（CSA2）における層間KVキャッシュ再利用とFP4 KVキャッシュを組み合わせることで、HBM上に常駐するグローバルKVキャッシュを1トークン当たり890バイトに抑えたと報告しています。これはDeepSeek-V4-Flashの対応する容量のおよそ4分の1です。78

さらに、SWA Bounded Replayにより、SSDまたはホストメモリに保持する永続KVキャッシュはV4-Flashの約8分の1になるとしています。7

運用面では、リクエスト当たりのKV状態が小さくなれば、同じメモリ予算でより多くの長文セッションを並行処理できる可能性があります。ただし、これらはDeepSeekが示したモデル設計上の数値です。Cambriconのクラスタにおけるスループット、レイテンシー、可用性、精度、運用コストを独立に実証するエンドツーエンドのベンチマークではありません。

サービング最適化はどう効くのか

CambriconはvLLM向けの取り組みとして、複数の最適化を公開しています。18

• 混合精度・低ビット推論：重みや活性値の保持量、メモリ転送量を削減する。
• 並列化最適化と大規模エキスパート並列：巨大なモデルとMoEのルーティング処理を複数アクセラレータへ配分する。
• 通信と計算のオーバーラップ：エキスパートルーティングや集合通信の待ち時間を、演算と重ねて隠すことを狙う。
• Prefill–Decode分離：プロンプト処理とトークン生成を別々のリソースプールとして設計・調整する。

Prefillは長い入力の処理で帯域や演算負荷が大きくなりやすい一方、Decodeは1トークンずつ反復するため応答遅延に敏感です。MoEではさらに、どのエキスパートを使うかの分散協調が加わります。これらの最適化は、理論上の演算性能だけでなく、同時接続時の利用効率やサービスの予測可能性を高めるための組み合わせです。

公開情報には、V4.1-FlashをCambriconハードウェアで動かした際の再現可能なスループット、レイテンシー、クラスタ構成、モデル品質、SLAに関する測定値は示されていません。そのため「本番対応」という表現は、利用・支援可能なデプロイ経路があることを示すものとして捉え、実際の導入前には各事業者が自らの精度、コンテキスト長、量子化、バッチング、障害対応要件で検証すべきです。

PyTorch FoundationのPlatinum加盟が示すこと

PyTorch Foundationは2026年9月8日、CambriconがPlatinumメンバーとして加盟したと発表しました。49 同Foundationは別途、CambriconがvLLMコミュニティと協力し、DeepSeek-V4やGLM-5などのオープンモデルでDay 0サポートを進めてきたとしています。57

この加盟が直ちに全モデル・全機能の対応を保証するわけではありません。一方で、アクセラレータの価値を専用スタックに閉じず、PyTorchやvLLMといった広く使われる公開フレームワークのエコシステム内で高める、という方向性を裏付ける材料にはなります。

ほかに対応を掲げるモデル群

Cambriconのソフトウェア資料には、DeepSeek V3／V3.1、Qwen2.5、Qwen3、Qwen3-Next、GLM-4.5、Qwen3-VL、Flux、Wan 2.1／2.2、Hunyuan-Videoに関する支援・最適化が記載されています。18

ただし、この資料は学習対応とソフトウェア全般の最適化を含みます。したがって、すべてのモデル群がDeepSeek-V4.1-Flashと同じく「Day 0の本番vLLM推論」に対応しているとまでは言えません。推論可否、精度形式、画像対応、コンテキスト長、Day 0の対象範囲は、リリースごとに確認する必要があります。

クラスタ運用者にとっての意味

モデル公開当日の互換性は、既存インフラ上での評価開始までの時間を縮めます。しかもvLLM経由であれば、キャパシティ計画、ルーティング、監視、量子化評価、統合テストを、独自フォークよりもなじみのあるサービング基盤で進めやすくなります。

とりわけ長文・画像対応のワークロードでは、KVキャッシュとメモリ帯域がボトルネックになりやすい領域です。DeepSeek-V4.1-Flashが報告するキャッシュ圧縮は、その制約を緩和するためのモデル側の設計です。78

今回のポイントは、Day 0の発表だけで普遍的な本番性能が証明された、ということではありません。ランタイム、フレームワーク演算子、専用カーネル、分散実行、サービングツールまでを反復可能な形でつなげられるかが、より大規模で疎なMoEモデルやマルチモーダルモデルの登場時に、対応までの期間を短縮する鍵になります。