· ローカルAI

Jetson AGX ThorでDeepSeek-V4.1純CUDA推論公開

30秒でわかる内容解説

patrickbdevaneyは2026年10月30日、NVIDIA Jetson AGX Thor上でDeepSeek-V4.1-Flash-1017を純粋なCUDA(NVIDIA GPU向けの計算基盤)だけで推論するサーバーを公開した。REAP法(専門部分を減らす剪定手法)でExpert(役割分担する部分)を384中192に剪定し、量子化したモデルを前提とする。OpenAI互換API(OpenAIの形式に合わせたHTTPの入口)を通じて自分の開発環境に組み込みやすく、ローカルLLMの速度と制約を示す。

Thor上の速度と分岐予測の実測

2026年10月30日の計測では、256トークンのチャット回答でデコード速度がコード33.0、説明25.0、数学40.2トークン毎秒に達した。既定では分岐予測デコードが有効で、提案器が3トークンを先に作り、本体が1回の検証で受け付ける。貪欲出力(最も確率の高いトークンを選ぶ出力)は素のデコードとトークン完全一致し、検証用に分離した27プロンプトで逸脱は0だった。

平均高速化は素のデコード比1.345倍で、チャット1.09倍、エージェント1.23倍、コード1.40倍、長い文脈1.40倍、数学1.63倍である。入力読み込みのプレフィルは1.8Kトークンで398、7.2Kトークンで739トークン毎秒に達した。乱数を用いたサンプリングでは全語彙の出力層を16ビット浮動小数点のbf16で扱う。同じ3プロンプトで25.0、19.2、25.2トークン毎秒にとどまった。

メモリは32Kコンテキスト(一度に扱える文脈)で合計122GiBのうち9GiBだけ空き、SPEC=0(分岐予測なし)では17GiB残る。既定のコンテキストは32768だが、1,048,576トークンの状態割り当ては2026年10月25日に旧エンジンで通った。64Kトークンのプレフィル後のデコードも、2026年10月25日に旧エンジンで通っている。

単一バイナリとEngram NVMeの設計

このサーバーは、DeepSeek-V4-Flash-0731のエンジンを基に作られ、V4.1向けの差分をまとめている。CSA2 attention(推論の中間結果であるKVキャッシュの参照元を複数層から選ぶ仕組み)は、Layer 20で候補ブロックを選ぶ。

モデルウェイトはthor-v1ビルドで、Expertに2.83 bpwのK-quant形式(量子化形式)を使う。密な部分にはNVFP4(軽量形式)overlayを組み合わせる。リクエスト経路にPythonを置かない単一バイナリ構成は、Thorの統合メモリで動く前提がある。

It runs on one NVIDIA Jetson AGX Thor (sm_110a, 128 GB unified memory): one binary, no Python on the request path.

このサーバーは1台のNVIDIA Jetson AGX Thor(sm_110a、128GB統合メモリ)で動作し、リクエスト経路にPythonを必要としない単一バイナリである。

Engramテーブル(N-gram、連続する文字列の検索表)は2つの約101GBファイルで、NVMeからio_uring(OSの非同期I/O)で読み込む。CUDA graph(GPU命令列の記録)を使うことで、1トークンごとに1回のgraph launchへまとめる。正しさの検証は、層ごとのコサイン類似度、教師付きの次トークン一致、トークナイザー一致などで行った。

教師付き次トークン一致の不一致のうち、ほぼ同点だった割合は、このビルドで89.1%、元モデルのチェックポイントでは80.5%だった。v41_decodeの初回動作は2026年10月25日に64Kプロンプトで35.9トークン毎秒だった。固定8,192トークンではsm_110a向けのtcgen05とベクトル化後に580.7トークン毎秒まで伸びている。

Thor限定とテキスト専用という制約

このサーバーはThor以外では動く前提を置いていないが、カーネルはsm_110a(ThorのGPU向け命令セット)向けである。tcgen05のような経路はsm_120やsm_121に存在しないため、Thor限定となる。

リクエストは1本ずつ処理し、メモリ帯域(データ移動の速さ)が速さの限界を決める。batch 1(1件ずつの生成)のデコードでは、この機械でバッチ化に利点がないとされている。

画像入力は使えないが、ウェイトには画像用のvision.safetensorsが含まれる。このサーバーは読み込まないため、画像を扱いたい場合は別ルートが必要になる。llama.cpp(LLM推論のオープンソース実装)のfork(分岐版)と画像入力用の補助モデルmmprojを使う。画像入力を扱えない点と1ストリームは、公開構成として明記されている。

start.shは分割ファイル、トークナイザー、keep-set(残すExpertの集合)、row filesを確かめる。Engram row files(検索表の行ファイル)はNVMeに置く必要がある。リムーバブルメディア(USBメモリなど取り外し可能な媒体)では起動を拒否する仕様である。

別のモデル読み込みプロセスが同じThorにいると、メモリを共有する統合環境で再起動を招く恐れがあるため起動しない。空きが約108GiB未満ならOSのページキャッシュを落とし、読み込みは約70秒かかる。

開発環境での運用前提とAPI

前述のThor専用という前提に加え、Vision対応やバッチ処理はこのサーバーでは扱わない。大きなバッチでの動作は想定されていない。

サーバーはGET /のWeb UI(ブラウザ画面)、/health、/metrics、/v1/models、/v1/completionsを備える。POST /v1/chat/completionsはストリーミングに対応する。ツール呼び出しはDeepSeekのDSML形式(ツール呼び出しの記法)で、思考ブロック(reasoning_content)も扱える。

コードとモデルウェイトはMITライセンスで、ref/にはDeepSeekのMITライセンス参照実装が含まれ、ゲートに使う。モデルウェイトは元モデルのMITライセンスを引き継ぐ。

デバッグにはv41_decode(単一プロンプトの検証用ツール)を使うと説明されている。--chat、--ids-file、--consistency、--scoreで単一プロンプトを確認できる。2026年10月30日時点では、これらの制約が公開構成として示されている。

出典