どうも、ベア三郎です。
「18Bしか動かないなら、128GBのDGX Sparkでも余裕なのでは？」
ところが、そう簡単にはいきません。今回の主役は、全体では320Bという巨大なAIモデル。1台のメモリには収まりきらない相手に、複数台の小さなAIマシンが挑みます。しかも、公開された速度はなかなか刺激的。思わず「これは試してみたい！」と言いたくなる数字が並んでいます。
ただし、ここで早とちりは禁物。「動いた」と「安心して使える」は、まだ同じ意味ではありません。華やかなベンチマークの裏側にある条件まで、一緒にのぞいてみましょう。
2026年10月16日、推論エンジンTensorFoldが1.0.12を公開しました。目玉のひとつが、GLM-5.3-FlashをNVIDIAのDGX Spark（GB10）で動かす新しい経路です。ただ、大事な前提が先にあります。これはソースビルド前提のプレビューで、READMEの正式対応一覧（qualified platforms）にはGLMのCUDAはまだ載っていません。
メンテナー側も、2台GB10で先頭4層の配信とsynthetic（人工的な小規模テストモデル）検査にとどめ、チェックポイント全体の正確さと速度は自機では未検証だとPRコメントで明言しています。今回は「動いた！」で終わらせず、何が検証済みで何が未検証かを一次資料から読み解きます。
TensorFoldは何をする道具？既存エンジンとの関係
TensorFoldは、ローカルでLLMを動かす道具のひとつで、Apple SiliconのMetalとNVIDIAのCUDAでモデルを動かす推論エンジンです。現在はZigで書かれたネイティブバイナリで、インストール手順は公式runbookにあります。同じくローカルLLMを動かす道具として、llama.cpp（GGUF形式で幅広いハードで動く）やvLLM（サーバー/バッチ/分散に強い）が挙げられます。以前Qwenを単機で比べた記事では、Strataとllama.cppのGGUF変換や重み配置、MTP（Multi-Token Prediction、複数トークンの先読み）を扱いました（→Strata vs llama.cppの実測）。ただしStrataはあくまであのQwen単機の文脈での比較で、今回のGLM-5.3-Flashでの対応や性能順位は確認していません。どれが最強とは言い切れず、得意分野が違うだけです。
GLM-5.3-Flashは「18Bだけ載せる」では済まない
GLM-5.3-FlashはZ.aiのモデルで、総パラメータ320B、そのうち1トークンで実際に動くのが18BのMoE（Mixture of Experts）です。MoEは「専門家チーム」のようなもので、毎回すべての専門家を起こすわけではありません。とはいえ「18Bだけメモリに載せればよい」ではないのが落とし穴。たとえるなら、実際に仕事をするのは18人でも、控えている320人分の席は必要という話です。登場する専門家を毎回すべて計算するわけではなくても、その重みをどこに置くかという問題は消えません。ここで初めて、「1台で頑張る」から「複数台で分担する」という発想が効いてきます。単純に4bitで概算しても320B×0.5バイト＝約160GBになり、DGX Spark単機の128GBを超えます（あくまで概算で実測値ではありません）。
NVFP4は「一律4bit」でも「全部FP4計算」でもない
ここで出てくるのがNVFP4です。4bitの浮動小数点にスケールを添えた形式で、モデル全体を一律4bitにするのではありません。NVIDIAのモデルカードがうたう約3.33倍はディスク容量とGPUメモリ（容量）の削減で、Blackwell向けです。ただし「形式を読み込める」と「Tensor Coreで全演算をFP4（W4A4）として実行する」は別物。PR804の実装はNVFP4の重みを読みつつattentionとKVキャッシュ（会話の中間データを保存する領域で、BF16/FP8はその保存精度）はBF16で動かす構成で、つまりNVFP4重みをBF16入力で計算するW4A16側に近く、名前のNVFP4だけから「全部FP4で計算」「BlackwellのFP4演算を全面活用」とは読みません。
TP（分割）は何台で何が報告されている？
TP（Tensor Parallelism）は、モデルの計算と重みを複数機に分担し、毎層通信する仕組みです。分担する1機ごとの処理単位をrank（ランク）と呼びます。今回のフルモデル経路で、何台で何が報告されているかを整理します（出典：PR804）。
| 台数 | PR804の報告での状態 |
|---|---|
| 1台 | このフルモデル経路の動作報告なし |
| 2台 | 作者が全体を運用・検査 |
| 3台 | PR804の報告ではエンジン検査のみ。サーバー起動はNCCL bootstrap未検証 |
| 4台 | 第三者がswitchless ringでgather指定し動作 |
ソース上の最大16rankを動作保証にはしません。3台は「PR804の報告では」の範囲です。なお別系列のNVFP4 BIZ 2.xでは3台の配信報告が別途あります（後述）。
PR804がやること・やらないこと
PR804は、ModelOptのNVFP4を再量子化せずに読むCUDA経路、NCCLによるTP、MTP（複数トークンを先読みし、本体が検算）、同時要求、全rankのメモリ最小余裕での受け入れ、プロンプト再利用などを含みます。モデルの画像・動画対応や1M文脈を、今回この経路で検証済みとはしません。また、旧Python 0.6.6のEXL3/DFlash2レシピとnative 1.0.12のNVFP4は別物で、古いレシピに「CUDA未対応」とあるのは対象世代の違いです。
作者の公開値（2台GB10）
以下はPR本文のReceiptで報告された値です。ただしTensorFoldの数値は正式リリースの1.0.12ではなく、1.0.10ベースのPRブランチ（commit 6380c8da）での測定です。環境は2台GB10（driver 580.178.04、CUDA 13.3、NCCL 2.30.7、Linux 7.0.0-1019-nvidiaでkho=off、RoCE経由）、NVFP4 revision 423acf37、context 40960、出力256、温度0、3回中央値。TensorFold側はprompt/decode行がparallel 2、比較のvLLMは0.28.1rc1.dev580（nightly 385dce36）でFP8 KV・MTP k=3（一度に先読みするトークン数）・CUDA graphsなし・1 sequenceのプロファイルです。TensorFoldはBF16 KV、vLLMはFP8 KVで、KV形式や測定プロファイル（parallel 2と1 sequence）が異なるため、エンジンだけの差ではありません。
| 設定 | code（TPS） | chat（TPS） |
|---|---|---|
| TensorFold MTPあり | 33.48 | 27.88 |
| TensorFold MTPなし | 17.61 | 17.61 |
| vLLM MTP k=3 | 33.93 | 24.97 |
| vLLM MTPなし | 14.16 | 14.18 |
MTPありだとcodeはTensorFoldがわずかに遅く、chatは約11.7%速い。つまり、「TensorFoldの圧勝！」ではありません。コード寄りのテストではvLLMがわずかに上、チャット寄りではTensorFoldが上という、なかなか面白い結果です。ただし、下に書く測定条件の違いもあるため、11.7%という差をそのまま「エンジンの実力差」と断定するのは禁物。数字を楽しみつつ、条件もセットで読むのがベア三郎流です。TPS＝秒間トークンで、日本語文字数には換算しません。四同時の総量chat52.8/code68.0は単発とは別物です。出典：PR804。
応答の最初のトークンが届くまでのTTFT（秒、cold/中央値3、入力は目標トークン長）も報告されています。
| 入力（目標トークン長） | 2,048 | 8,192 | 32,768 |
|---|---|---|---|
| TensorFold（秒） | 1.305 | 5.872 | 22.745 |
| vLLM（秒） | 1.465 | 6.649 | 28.138 |
32k入力は約23秒。長い資料を読ませた直後は、それだけ最初の文字を待つ計算です。出典：PR804。
第三者のTP4報告（4台GB10）
第三者SvangenStudios氏のPRコメントです。同じ6380c8daビルド・checkpoint 423acf37、4台GB10、CUDA13.0、switchless ring、全rankでTF_GLM_PREFILL_REDUCE=gather。測定は出力256・温度0・3回中央値です。別ホスト・別セッションなので、2台比の倍速や台数比例の結論は引けません。default splitは非隣接接続で失敗しました。
| 設定（TP4・gather） | code（TPS） | chat（TPS） |
|---|---|---|
| MTPあり | 66.29 | 42.10 |
| MTPなし | 25.85 | 25.76 |
四同時の総量はcode130.5/chat85.9。TP4内部の一致で、TP2とのbit一致を証明したわけではありません。出典：PRコメント。
混ぜるな危険！前提が違う数字たち
NVIDIA Forumsのd.piwowar氏の測定は9/30時点の旧EXL3/TR3＋DFlash2とsparkringの比較で、量子化も経路も違います。今回のNVFP4 PR804の表には混ぜません。速い数字には別の前提があります。
また、Bizuayeu氏の「NVFP4 BIZ 2.x」は別系列のPython TensorFold v0.6.5ベースのforkで、TP2/TP3のサーバー運用やFP8 KV、画像・長文の検収を別途報告しています。native ZigのPR804でTP3サーバーが未検証であることと矛盾せず、版と実装が違います。Bizuayeu氏はREADME.ja.mdで日本語でも発信しています。BIZの性能値を今回の表には混ぜません。
筆者の考察：速さより「待ち」と「運用性」
以前の記事で「最高TPSより、TTFTと共有時の待ちが快適さを決める」と書きました。今回も同じです。モデルの容量（メモリに載る量）と計算（毎トークン動かす量）を分けて考える。エンジンの競争も、NVFP4原本をどう扱うか、再現性、同時利用、分散の運用性まで比べる段階に入りました。
向くのは、複数台のGB10を検証できる人です。単機ユーザーは、いま急いで乗り換える必要はありません。「明日から快適に使える道具」を探している人と、「次の可能性を自分で切り開きたい人」では、選ぶべきものが違うからです。今回のニュースは、後者にはワクワクする挑戦状。でも前者にとっては、将来を占う興味深い途中経過として受け取るのがよさそうです。READMEの正式対応一覧にGLM CUDAが載るのを待つか、既存の安定経路を使い続けるのが無難です。
ベア三郎のひとこと。新経路の速さより、「いつ・何台で・何が検証されたか」の輪郭が、いまの段階ではいちばん参考になります。次に自分の用途で比べるなら、同じモデル・入力・MTP条件で、初動（TTFT）と完了までと同時利用を、まとめて測りたいです。
検証メモ：本記事は2026-10-17時点の公開資料に基づく解説で、筆者のDGX SparkでのGLM実測は含みません。数値は作者・第三者の報告値で、環境・KV形式・セッションが異なります。
コメント