TensorRT-LLM

vLLM・SGLang・TensorRT-LLMをクラウドGPUで動かしたら、それぞれの個性が見えてきた この記事で分かること Qwen3-8Bを、L4 24GB 1台の上でvLLM・SGLang・TensorRT-LLMに載せ、同じリクエストを送った。揃えたつもりの条件が、5か所で揃っていなかった。どれもベンチマークの数字に入り込む。 速さの順位は載せない（速さは自分の条件で測ってほしい）。すべてこの版・L4（sm_89）での話である。エンジンを選びたいだけなら「エンジン別の要点」と最後の「私の使い分け」へ。 エンジン別の要点 エンジン 知っておくこと vLLM 0.31.0 L4ではQwen/Qwen3-8B-FP8が重みだけFP8（W8A16）で動く SGLang 0.5.21 ツール定義に項目が足され、入力が増える。L4・8B bf16は--mem-fraction-staticの自動値では起動しない（0.87で動いた） TensorRT-LLM 1.2.1 L4ではQwen/Qwen3-8B-AWQ・-FP8をそのまま読めない。KVが足りないと黙って待たせる。キャッシュを消すAPIが無い 用語 用語 意味 KVキャッシュ 生成中のリクエストが、それまでのトークンの計算結果を置いておくGPUメモリ。容量をトークン数で数え、同時に処理できる本数の上限を決める プリフィル 入力（プロンプト）をまとめて読み込む最初の段階。入力が長いほど重い TTFT Time To First Token。送ってから最初の1トークンが返るまでの時間 W8A16／W8A8 重み（Weight）と計算時の値（Activation）のビット数。W8A16は重みだけ8bitで計算は16bit 追い出し（preemption／retraction） KVが足りなくなったとき、処理中のリクエストをいったん外すこと。後でやり直す RadixAttention SGLangのプレフィックスキャッシュ。木構造で、任意のトークン位置まで一致を使い回す（vLLMは決まった長さのブロック単位） sm_89／Ada／Hopper NVIDIA GPUの世代。L4はAda（sm_89）、H100はHopper（sm_90） ModelOpt NVIDIAの量子化ツール。TensorRT-LLM向けの量子化モデルを作る 条件 項目 値 モデル Qwen3-8B（bf16、AWQ 4bit、FP8） GPU NVIDIA L4 24GB 1台（sm_89、AWS g6.xlarge）。ドライバ 595.112.07、CUDA 13.2 エンジン vLLM 0.31.0 / SGLang 0.5.21 / TensorRT-LLM 1.2.1（trtllm-serve、PyTorchの経路） リクエスト /v1/chat/completions。ツール定義10個（ケースごとに40個から選ぶ）＋日本語の質問。システムプロンプトなし、thinkingオフ、質問の末尾にリクエストごとの識別子 max_tokens／最大の文脈長 512／8,192 測った並行数 AWQ・FP8は1と16。bf16は1（16は載らない：3節）。SGLang bf16は容量の確かめで8も 送ったケース 200ケースのうち20ケースを繰り返し送った（並行数1で80件） プレフィックスキャッシュ 3エンジンとも既定で有効。区切り（エンジン×チェックポイント×並行数×測定の種類）ごとにサーバーを起動し直す エンジン別 vLLM SGLang TensorRT-LLM 入力長 最大／中央値（200ケース） 2,591／2,310 2,691／2,410 2,591／2,310 ツールパーサー hermes qwen（Qwen25Detector） qwen3 バッチの上限 max_num_seqs 256・max_num_batched_tokens 2048 max_running_requests 2048 max_batch_size 2048・max_num_tokens 8192 チャンク化プリフィル 有効 有効（4096） 無効 CUDA graph FULL_AND_PIECEWISE 有効 バッチ1〜32・64・128 バッチの上限はどれも並行数16より大きい。 1. 入力：SGLangだけトークン数に差が出た 同じリクエストでusage.prompt_tokensを比べると、SGLangだけ全ケースで+100トークンだった。 // 送ったもの（{…}は省略） {"type": "function", "function": {"name": "search_master", "description": "…", "parameters": {…}}} // テンプレートに渡るもの {"type": "function", "function": {"description": "…", "name": "search_master", "parameters": {…}, "strict": false}, "defer_loading": null} エンジン toolsの扱い prompt_tokens vLLM 型に通すが、テンプレートに渡す長さは変わらない 送ったまま手元でテンプレートに通した長さと一致 SGLang model_dump()で項目を足し、キーの順が変わる +100 TensorRT-LLM — vLLMと一致 書き換えを再現する関数を書き、1,200件でSGLang自身のmodel_dump()と突き合わせて違いは0件だった。確かめるなら、テンプレート適用後の文字列（vLLMなら/tokenize）の差分を取る。 切り替えるオプションは無い。 揃えるならクライアントから足した形で送る（他エンジンの入力も変わる）。今回はそのまま測った。 効き方：プリフィルが重くなる／KVの見積もりがずれる（3節）／精度にも混ざる。ツールが多いほど差は大きい。パーサーも3つとも別の実装で、読み損ねは精度の差として出る。 2. 量子化：「FP8」が同じ意味ではない エンジン 起動時の警告 vLLM Weight-only FP8 compression will be used leveraging the Marlin kernel. SGLang Using default W8A8 Block FP8 kernel config. Performance might be sub-optimal! 「FP8で比べた」表は、重みだけ8bitと計算も8bitが混ざりうる。起動ログのカーネル名で確かめる。 vLLMがL4でW8A16になるのは、カーネルの候補を順に試し、最初に使えるものを選ぶため（vllm/model_executor/kernels/linear/init.pyのinit_fp8_linear_kernel）。 CUTLASSのブロックFP8のカーネルはsm_90・sm_100・sm_120向けしか無い（csrc/.../c3x/scaled_mm_blockwise_sm*_fp8.cu）。--linear-backendで変えられるはずだが試していない。 TensorRT-LLM 1.2.1・L4では、公開の次の2つを読めなかった。 チェックポイント 読めない理由 代わり（ModelOpt 0.37.0） Qwen/Qwen3-8B-AWQ（AutoAWQ形式） load_hf_quant_configにawqの分岐が無い --qformat int4_awq Qwen/Qwen3-8B-FP8（ブロック単位） 対応表で、ブロック単位FP8はAda（sm_89）が対応外（HopperとBlackwell sm100/103は対応）。モデル側の表でもQwen3は対応外なので、H100でも使えない --qformat fp8 --kv_cache_qformat none 2つで約56分かかった。nvidia/Qwen3-8B-FP8はKVまでFP8になるため使わなかった（KVの型の上書きは試していない）。TensorRT-LLMだけチェックポイントが別物なので、量子化した構成はエンジン間で比べず、各エンジン内でbf16との精度差だけ確かめた。 3. 容量：同じGPUでも載る量が違う 名前の似たメモリ設定が、何に対する割合かが違う（L4は約22.5GiB〔23,034MiB〕、Qwen3-8B bf16の重みは15.27GiB）。 | weights | KV | act | rest | GPU |===============|==============|=========|======| vLLM |<---------------- 0.92 ---------------->| SGLang |<----------- 0.87 ----------->| TRT-LLM |<-------- 0.9 x free --------->| act＝活性化など計算中の作業領域（プリフィルの中間結果、CUDA graph）。rest＝エンジンの外で使われる分の余白。模式図で、長さは比率どおりではない。 エンジン 割合の対象 割合に含むもの 値 KVの容量（トークン） 容量を直接指定するなら vLLM GPU全体 重み＋KV＋活性化 0.92（既定） 30,240 --kv-cache-memory-bytes（指定すると0.92は無視される） SGLang GPU全体 重み＋KV（活性化は外） 0.87（手で決めた） 26,813 --max-total-tokens TensorRT-LLM 重みと活性化を確保した後の空き KVだけ 0.9（既定） 約32,800 kv_cache_config.max_tokens（割合と両方なら小さいほう） 揃えたいなら割合ではなくトークン数で直接指定する（オプション名は版で変わりやすい）。今回は既定に近い状態を測るため揃えていない。 KV 1トークン = 36層 × KVヘッド8 × 128次元 × K/V 2 × 2バイト = 144KiB 1本の最大 = 入力2,691（SGLang） + max_tokens 512 + 余裕1 = 3,204 並行数8 = 3,204 × 8 = 25,632（+100前は 3,104 × 8 = 24,832） 並行数16 ≒ 51,300 → bf16は3エンジンとも載らない 全リクエストが最大長まで伸びても入るかで数え、入らない組み合わせは測っていない。 SGLangは自動値（0.684）で起動しなかった。 自動値＝（GPUの容量−作業領域の見積もり）÷GPUの容量（srt/arg_groups/memory_hook.py）。 作業領域の見積もり（L4） 大きさ 固定の分 512MiB プリフィル chunked_prefill_size 4,096トークン×1.5MiB＝6GiB（係数1.5はソースで「経験的な値」） 並列化の分 128MiB（1GPU） CUDA graph デコードの最大バッチ48×2MiB＋プリフィルの分 合計 約7.1GiB（23,034MiB×(1−0.684)） ValueError: Loaded weights leave no GPU memory for the KV cache under --mem-fraction-static=0.684. 並行数8が載る値を0.01刻みで探した（0.01あたり約1,590トークン）。 割合 KVの容量 並行数8（25,632） KV以外の残り 追い出し 0.684（自動） 起動しない — — — 0.84 22,047 載らない 1.82 GB — 0.86 25,224 載らない 1.40 GB — 0.87 26,813 載る 1.11 GB 0回 +100前なら0.86で足りたが、1節の+100で408トークン足りなくなり0.87にした。0.88以上は試していない。 4. 溢れたとき：追い出すか、黙って待たせるか 方式 エンジン 混んだとき遅れる場所 見える指標 追い出す vLLM・SGLang 生成の途中（ストリーミングが止まる） vllm:num_preemptions／sglang:num_retracted_requests_total 待たせる TensorRT-LLM 最初の1トークン（TTFT） 無い。numActiveRequestsで見る TensorRT-LLMは「入力長＋max_tokens」ぶんを先に確保するので、max_tokensを大きく付けるほど同時に受け入れる本数が減る。並行数16で送っても中では8本しか走っていないことがある。空きに合わせて詰め込むMAX_UTILIZATIONもある（処理中のリクエストが一時停止しうる。試していない）。 今回は/metricsを2秒ごとに読み、numActiveRequestsの最大が送った本数に届いたことを確かめた。溢れる組み合わせは測っていない（3節）。 5. 観測：そのまま読むと誤判定になる エンジン 癖 対処 SGLang キャッシュヒットが0だとprompt_tokens_detailsごと出ない 無ければ0 SGLang num_retracted_requests_totalは初回の追い出しまで出ない ゲージnum_retracted_reqsがあれば0回 TensorRT-LLM kvCacheStatsはenable_iter_perf_statsが要り、1件処理するまで空 短いリクエストを1件送ってから読む TensorRT-LLM その1件で、測定の最初のリクエストがcached_tokens=1になった（<|im_start|>を共有。partial reuseが既定で有効なので、32トークンのブロックの一部でも当たる） 書式を通さない/v1/completionsで送る TensorRT-LLM 反復ごとの統計は読むたびに消える 測定中に2秒ごとに読む 「読めなければ0」にしていたら誤った結論を出していた。「読めなければ止める」作りにしていたので気づけた。 エンジン キャッシュの消し方 vLLM POST /reset_prefix_cache（VLLM_SERVER_DEV_MODE=1） SGLang POST /flush_cache TensorRT-LLM APIなし。再起動 キャッシュがどれだけ効くかは、送るケースの数とKVの容量で大きく変わる。今回は20ケース（入力の合計45,957トークン）を繰り返し送った。 チェックポイント KVの容量（トークン） 20ケースぶんが cached_tokens／入力（3エンジンとも同程度） bf16 26,813〜32,800 収まらず、一周する前に追い出される 3.6〜4.7%（当たるのは先頭の書式 約50トークンだけ） AWQ・FP8 76,096〜99,552 収まり、2周目からツール定義ごと当たる 並行数1で約75%、16で約82% 効いているのは並行数ではなく、量子化で空いたKVの容量である。量子化した構成の速さには、計算が軽くなった分とキャッシュに当たった分が混ざりうる。ケースの数・繰り返し方とKVの容量を並べて確かめたい。 6. 動かすまで 版がぶつかるので、仮想環境をエンジンごとに分け、クライアントはHTTPだけで話す。 エンジン torch transformers vLLM 2.13.0+cu132 5.17.0 SGLang 2.13.0 5.12.1 TensorRT-LLM 2.9.1+cu130 4.57.3 問題 対処 TensorRT-LLM環境でModelOptが動かない（NumPy<2固定と最新pyarrowが衝突） pyarrow<22 TensorRT-LLM FP8が起動中にsegfault（原因不明、再実行で通過） — そのとき親プロセスが残り、20分待ち続けた ログにSegfault encountered等が出たら即失敗にして1回だけ再起動 まとめ：比較を作る・読むときのチェックリスト 確かめること 確かめ方 モデルに届く入力は同じか usage.prompt_tokensを並べる。テンプレート適用後の文字列を比べる ツールパーサーは何か 起動オプションを書く 量子化の計算は何か 起動ログのカーネル名・警告 量子化のチェックポイントは同じか 対応表とソースで、使うGPUで読める形式か確かめる KVの容量はいくつか 割合ではなくトークン数で見る。揃えるなら直接指定する 溢れたら何が起きるか 追い出しカウンタと同時実行数。max_tokensも書く 指標が読めないときの扱い 読めなければ止める キャッシュの状態 有効か、区切りごとに消すか、cached_tokensはいくつか。ケースの数・繰り返し方とKVの容量も書く 私の使い分け（推奨案） 速さではなく、導入の手間・設定の素直さ・観測しやすさで決めた。 当てはまる範囲：24GBクラスのGPU1台・8B級・同時8本程度まで。大きいGPUや70B級ではメモリ（3節）と量子化の対応（2節）が変わる。 推奨 想定するユースケース 決め手 気をつけること vLLM 社内チャットやRAGのPoC。公開モデル（量子化版を含む）を差し替えて評価する 公開チェックポイントをそのまま読める（2）。既定の設定で起動し、追い出しがカウンタで見える（3・4） L4のFP8はW8A16（2） SGLang 同じツール定義・システムプロンプトを先頭に付けるエージェントやバッチ処理 RadixAttention（用語）。L4でもFP8がW8A8（2）。※今回は共有部分が短く、実測ではない（5） 入力が増える（1）。割合を手で決める（3）。指標が0で出ない（5）。共有部分の長い順に処理するlpmは既定ではない（既定fcfs） TensorRT-LLM モデルを固定して長く運用する本番API 処理中のリクエストが途中でやり直しにならない（4）。量子化は最初の1回で済む 量子化を作り直す（2）。混むとTTFTが伸びるので、SLAがTTFTなら自分で測る（4）。キャッシュを消すAPIなし（5） 迷ったらvLLMで基準を作り、チェックリストで条件を揃えてから他と比べる。 付録：起動コマンド vLLM 0.31.0（bf16。AWQ・FP8はモデル名だけ替える。VLLM_SERVER_DEV_MODE=1 を付けて起動） vllm serve Qwen/Qwen3-8B --served-model-name Qwen/Qwen3-8B \ --host 127.0.0.1 --port 8000 \ --enable-auto-tool-choice --tool-call-parser hermes \ --enable-prompt-tokens-details --max-model-len 8192 SGLang 0.5.21 python -m sglang.launch_server --model-path Qwen/Qwen3-8B --served-model-name Qwen/Qwen3-8B \ --host 127.0.0.1 --port 30000 \ --tool-call-parser qwen --enable-metrics --enable-cache-report \ --mem-fraction-static 0.87 --context-length 8192 TensorRT-LLM 1.2.1（ModelOptで作ったAWQ。bf16はQwen/Qwen3-8B） echo "enable_iter_perf_stats: true" > trtllm-serve.yaml trtllm-serve ~/models/Qwen3-8B-int4-awq-modelopt \ --host 127.0.0.1 --port 8001 --backend pytorch \ --tool_parser qwen3 --config trtllm-serve.yaml --max_seq_len 8192 出典 SGLang v0.5.21：github.com/sgl-project/sglang/tree/v0.5.21 （srt/entrypoints/openai/serving_chat.py・protocol.py・usage_processor.py、srt/observability/metrics_collector.py、srt/function_call/function_call_parser.py、srt/arg_groups/memory_hook.py） TensorRT-LLM v1.2.1：github.com/NVIDIA/TensorRT-LLM/tree/v1.2.1 （tensorrt_llm/commands/serve.py、llmapi/llm_args.py、_torch/model_config.py、_torch/modules/linear.py、cpp/tensorrt_llm/executor/jsonSerialization.cpp、docs/source/features/quantization.md） ModelOpt 0.37.0：github.com/NVIDIA/Model-Optimizer/tree/0.37.0 （examples/llm_ptq/hf_ptq.py） vLLM v0.31.0：github.com/vllm-project/vllm/tree/v0.31.0 （vllm/config/cache.py、vllm/engine/arg_utils.py、vllm/model_executor/layers/quantization/fp8.py、vllm/model_executor/kernels/linear/init.py・scaled_mm/marlin.py・cutlass.py・flashinfer.py・deep_gemm.py・b12x.py、vllm/utils/flashinfer.py、vllm/platforms/cuda.py、vllm/model_executor/layers/quantization/utils/w8a8_utils.py、csrc/libtorch_stable/quantization/w8a8/cutlass/c3x/、vllm/entrypoints/openai/chat_completion/protocol.py、vllm/v1/metrics/loggers.py）、起動ログ vLLM プレフィックスキャッシュの設計：docs.vllm.ai TensorRT-LLM スケジューラの方針（GUARANTEED_NO_EVICT／MAX_UTILIZATION）：nvidia.github.io SGLang サーバー引数：docs.sglang.io 、new_token_ratioはsrt/managers/schedule_policy.py nvidia/Qwen3-8B-FP8：huggingface.co PagedAttention：Kwon et al., SOSP 2023。RadixAttention：Zheng et al., NeurIPS 2024

@aitrackerbot @nvidia Source: github.com/flashinfer-ai/flashinfer/commit/fc1790… TensorRT-LLM: TensorRT-LLM#20792

DeepInfer: What's Actually Inside DeepSeek's Newly Open-Sourced Inference Engine On October 20, 2026, DeepSeek open-sourced DeepInfer — the inference framework it says powers its own large-scale production services — under the Apache 2.0 license. The repo is deepseek-ai/DeepInfer, and it crossed 10,000 GitHub stars within days of the announcement (as of writing, ~10.5k stars / 926 forks). The one-line version from the official account: > "Introducing DeepInfer, our in-house inference framework, now fully open source! Powering DeepSeek-V4.1-Flash at scale with high throughput..." — @deepseek_ai on X There has been a wall of hot takes since (the Hacker News thread passed 1,400 points). Most of them skip the README, which is actually quite specific about what this release is and — more interestingly — what it is not. This post is a walkthrough of exactly that: what's in the box, what's deliberately left out, where it comes from, and who should actually deploy it. What DeepInfer is From the README, verbatim: > "DeepInfer is the high-performance inference framework that powers DeepSeek's large-scale production services. This open-source release provides offline inference with the core features needed for serving at scale." Two words in that sentence matter more than the rest: 1. "production" — this is not a research playground. It's the same stack that serves DeepSeek's own API traffic, open-sourced as-is rather than rebuilt for external consumption. 2. "offline inference" — the release ships offline (batch-style) inference. A full online serving service needs components DeepInfer does not include (more on that below). It supports exactly one model family today: DeepSeek-V4.1-Flash (default checkpoint: deepseek-ai/DeepSeek-V4.1-Flash-1017 on Hugging Face). This is a model-hardware co-optimized production engine, not a universal deployment framework for every model on HF. What's in the box The feature list from the README, with the configuration knobs that go with them: | Feature | How it's enabled | |---|---| | Optimized kernels (FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect, custom TileLang kernels) | built in | | Draft-token decoding + confidence-scheduled verification | DEEPINFER_ENABLE_MTP_VARLEN=1; max draft length via DEEPINFER_USE_NEXTN_DECODE (default 5) | | Parallelism: attention DP, balanced CP, MoE EP + EPLB | built in | | Decoder SWA bounded replay (only replay a bounded suffix of the context) | DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact, DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140 | | Asynchronous scheduling (overlap CPU batch scheduling with device execution) | enabled by default | | Batch-invariant inference (identical results across batch compositions) | DEEPINFER_BATCH_INVARIANT=1 (NVIDIA only) | | Deterministic sampling (identical outputs for identical inputs and seeds) | DEEPINFER_BATCH_INVARIANT=1 + fixed seq_seed (NVIDIA only) | | Structured outputs (regex / JSON schema / EBNF grammar constraints) | via SamplingParams(so_args={...}) | Two of those deserve a note: - Batch invariance + deterministic sampling kill a whole class of production headache. If you've ever been burned by "the same prompt gives a different answer depending on who else is in the batch," this is the guarantee that removes that bug class — the kind of property usually only achieved with bespoke deployment tricks. Note, though, that it's NVIDIA-only in this release. - Confidence-scheduled verification is speculative decoding where the scheduler uses confidence estimates to decide how to spend verification budget — a scheduling refinement rather than a new algorithm, but the kind of thing that only gets built if you actually serve enormous volume. What it's built on — and the hardware bet The acknowledgments section settles the "is it a vLLM fork?" question: > "DeepInfer was originally built primarily on vLLM, with additional inspiration from SGLang and TensorRT-LLM." So yes — vLLM lineage. What DeepSeek added on top is a stack of self-optimized kernels (FlashMLA, DeepGEMM, DeepEP are DeepSeek's own projects) and a scheduler designed around their model's architecture. The hardware support is the political headline, though: - NVIDIA SM100 GPUs (CUDA 13) - Huawei Ascend 950 NPUs (CANN 9.2) That second line is unusual for a top-tier open-source inference release: Ascend support sitting next to NVIDIA from day one, in a production engine. Requirements are strict on both sides — Linux, GCC ≥ 13.0, Python 3.12, and either CUDA 13 or CANN 9.2. This is not a laptop demo framework. Benchmarks: transparency instead of a hero number The README doesn't lead with a single "we're X% faster" number. Instead it publishes two Pareto plots — prefill throughput vs. latency, and decode throughput vs. per-user speed — measured on 4 SM100 GPUs for prefill and 64 for decode, each within one scale-up domain, with a run_sweep.sh script so you can reproduce the configuration yourself. That's the right shape for claims like these: a Pareto curve with a reproduction script is auditable in a way a bar chart never is. Whether the curves hold up on your interconnect is, of course, a different question — the sweep script exists precisely because the answer depends on your topology. What's deliberately missing This is the part of the README most coverage skipped. DeepInfer is open about requiring three subsystems for a complete inference service that are not in this release: 1. A KV cache system 2. VE/prefill/decode disaggregation (though the README notes most required engine functionality is already implemented) 3. Load balancing across data-parallel replicas for both prefill and decode In other words: this is an engine, not a turnkey server. If you were hoping to swap it in as the backend behind your OpenAI-compatible gateway tomorrow, you'll be building or bolting on those pieces. That's also a fair reading of DeepSeek's release philosophy: publish the hard, differentiating core; let the surrounding infrastructure stay open-ended. One caveat worth repeating: batch invariance and deterministic sampling are NVIDIA-only in this release, and Ascend support, while present, carries exactly the same "read the fine print" weight as any first-version port. Quickstart Build from source (create an empty Python 3.12 environment first):

The 32k Cliff: Choosing the Right Hardware for Your Local AI Coding Harness --- title: "The 32k Cliff: Choosing the Right Hardware for Your Local AI Coding Harness" published: true description: "A deep dive into why 32k context degradation happens across frontier models and how to pick the right local hardware across Mac Studio M5 Ultra, RTX Pro 6000, and DGX Spark." tags: ai, machinelearning, hardware, devops canonical_url: medium.com # uncomment if cross-posting from Medium cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com --- Here's a fact that should change how you spend your hardware budget: Every frontier AI model — regardless of whether it advertises a 128k, 500k, or 1M token context window — experiences measurable performance degradation on complex reasoning tasks past approximately 32,000 tokens. Not a rumor. Validated across RULER, ETHIC, and LMSYS benchmarks. Replicated on GPT-4o, Claude 3.5, Gemini 1.5, Llama 3, Qwen2.5, and Mistral. The phenomenon even has a name: the 32k Cliff. If you're a CTO or technical architect making a hardware decision for a local AI coding harness in 2026, this single finding should reframe every spec you evaluate. The question is no longer "which machine fits the biggest model?" It's "which machine sustains the highest-quality reasoning within the effective working context budget, and scales cleanly for my team?" This post is a structured decision guide. We compare three hardware tiers — the Apple Mac Studio M5 Ultra, the NVIDIA RTX Pro 6000 Blackwell, and the NVIDIA DGX Spark — across the metrics that actually matter for a production coding harness. No marketing. Numbers, trade-offs, and a tiered recommendation at the end. --- Part I: The 32k Cliff — The Invisible Constraint Driving Every Hardware Decision Before we touch a single spec sheet, you need to understand why 32k is the number that matters. What the Research Shows Transformers process context through a soft-attention mechanism. As the sequence length grows, attention weights are spread across an ever-expanding set of tokens. Beyond approximately 32,000–64,000 tokens, three failure modes compound simultaneously: | Failure Mode | Mechanism | Impact on Coding Harness | |---|---|---| | Lost in the Middle | Primacy + recency bias. Tokens in the middle of a long context are retrieved with dramatically lower fidelity. | Tool results, prior diffs, and error logs buried mid-session are effectively ignored. | | Working Memory Saturation | Transformer "working memory" (the ability to track parallel state variables, relationships, and constraints) saturates. | The model starts repeating suggestions, losing variable scope, or failing to honor earlier constraints. | | Context Rot | Accumulated noise — tool calls, backtracking, error logs, exploratory dead-ends — acts as distractors. Each new turn is contaminated by prior noise. | Quality degrades progressively in a long agent session. Hallucinations and loops increase. | | Context Poisoning | An early, incorrect assumption embedded in the context is fed back into every subsequent turn. | A wrong architecture decision in turn 3 can corrupt suggestions in turn 30, even after correction. | The Marketing Number vs. The Working Number | Concept | What It Means | Typical Value | |---|---|---| | Advertised Context Window | Maximum tokens accepted without an error | 128k–2M+ tokens | | MECW (Maximum Effective Context Window) | Tokens before deep reasoning, multi-hop inference, and instruction-following degrade materially | ~32k–64k tokens | | NIAH Score | Needle-in-a-haystack single-fact retrieval accuracy | Misleadingly high — up to 99% at 100k+ on trivial tests | | Practical Coding Task Accuracy | Multi-step refactoring, bug tracing, constraint-following at 32k+ | Drops sharply — often 30–50% below peak performance | > The bottom line: A 1M token context window does not give you 1M tokens of reliable cognition. It gives you a 32k–64k token zone of high-quality reasoning and a large surrounding buffer of low-fidelity bulk context — useful for reference material, not for active problem-solving. What This Means for Hardware Selection This finding changes the evaluation criteria fundamentally: 1. Raw memory capacity matters less than throughput within the working budget. You need to fit a high-quality model in memory — but you don't need to fit the entire project history in context. 2. Tokens-per-second at the reference model size is the primary performance metric. Faster inference = shorter feedback loops = more productive harness sessions. 3. Context engineering infrastructure matters as much as hardware. The best hardware pairing is one that runs a strong model fast, while your harness tooling (RAG, session summarization, memory layering) handles context management. --- Part II: The Reference Model — Qwen3-Coder 30B-A3B-Instruct All benchmark comparisons in this post use Qwen3-Coder 30B-A3B-Instruct (4-bit MLX quantization) as the primary reference model, with Qwen2.5-Coder 32B (Q4) as a secondary comparison point. Why This Model? Qwen3-Coder 30B-A3B is a Mixture-of-Experts (MoE) architecture with 30 billion total parameters but only ~3 billion active parameters per token. This design choice has critical implications for local hardware: | Property | Dense 32B Model | Qwen3-Coder 30B-A3B MoE | |---|---|---| | Active params per token | ~32B | ~3B | | Memory bandwidth demand | High (all weights accessed per token) | Low (only active experts accessed per token) | | Tokens/sec for equal model size | Baseline | 2–4× faster | | 4-bit quantized footprint | ~18–20 GB | ~19–21 GB | | Reasoning quality | Strong | Competitive to stronger (architecture-dependent) | | MLX optimization | Good | Excellent — expert routing benefits from unified memory | At 4-bit MLX quantization, the model fits on any machine with 24GB+ of memory. The MoE architecture makes it far more friendly to bandwidth-constrained hardware. This is the reason it outperforms dense 32B models on Apple Silicon despite the spec sheets looking comparable. --- Part III: Hardware Specification Comparison The Three Contenders Tier A — Apple Mac Studio M5 Ultra Apple's flagship desktop AI workstation. Released September 2026. No M4 Ultra was ever released — Apple skipped from M3 Ultra directly to M5 Ultra. | Specification | Value | |---|---| | Chip | Apple M5 Ultra (quad-die SoC) | | CPU | 30–36 core (performance + efficiency) | | GPU | 64–80 core | | Neural Engine | 32-core | | Unified Memory | 96 GB / 256 GB / 512 GB (configurable) | | Memory Bandwidth | 1.2 TB/s | | Storage | Up to 8 TB NVMe | | Networking | Dual Thunderbolt 5, 10 GbE | | Power Draw (full load) | ~150–250W | | Base Price (96 GB) | $5,499 USD | | Configured (256 GB) | ~$8,499 USD | | Configured (512 GB) | ~$12,000+ USD | --- Tier B — NVIDIA RTX Pro 6000 Blackwell (Workstation) NVIDIA's flagship single-GPU professional workstation card. Released March 2025. Supply-constrained through 2026, with significant price volatility. | Specification | Value | |---|---| | Architecture | Blackwell (GB202, 5nm TSMC 4N) | | CUDA Cores | 24,064 | | Tensor Cores | 5th gen (FP4/FP6/FP8/INT8) | | AI Performance | ~4,000 AI TOPS | | VRAM | 96 GB GDDR7 ECC | | Memory Bandwidth | 1,792 GB/s (~1.79 TB/s) | | TDP | 600W | | Bus | PCIe 5.0 x16 | | Ecosystem | CUDA, TensorRT-LLM, vLLM, ExLlamaV2 | | Launch Price (early 2025) | ~$8,000 USD | | Current Price (2026) | $13,250–$16,000 USD (supply-driven inflation) | | Workstation host required | +$3,000–$6,000 for a suitable workstation chassis | > Important: The RTX Pro 6000 is a discrete GPU, not a complete system. Add workstation platform cost. Total all-in system cost at this tier: $16,000–$22,000+. --- Tier C — NVIDIA DGX Spark (GB10 Grace Blackwell, 128 GB) NVIDIA's compact desktop AI supercomputer. Launched late 2025, expanded to OEM partners (ASUS, Dell, HP, MSI, Lenovo) in October 2026. | Specification | Value | |---|---| | Chip | GB10 Grace Blackwell Superchip | | GPU | Blackwell GPU (Tensor Core, FP4 sparse) | | CPU | 20-core Arm (Grace) | | Unified Memory | 64 GB or 128 GB LPDDR5X | | Memory Bandwidth | 273 GB/s | | AI Compute | ~1 PetaFLOP (FP4 sparse) | | Networking | ConnectX-7 (2× units can be NVLinked for 256 GB effective) | | Software Stack | DGX OS (Ubuntu), CUDA, NIM, TensorRT, vLLM | | Power Draw | ~150–200W | | Price (64 GB) | ~$4,999 USD | | Price (128 GB) | $6,950–$8,000 USD (OEM-dependent) | --- Part IV: The Benchmark Tables Table 1 — Raw Inference Throughput: Qwen3-Coder 30B-A3B @ 4-bit (Primary Reference) | Machine | Inference Engine | Tok/s (Generation) | Prompt Prefill Tok/s | Memory Fit | |---|---|---|---|---| | Mac Studio M5 Ultra (96 GB) | MLX | 110–130 tok/s | ~2,000+ tok/s | ✅ Comfortable (21 GB of 96 GB) | | Mac Studio M5 Ultra (256 GB) | MLX | 110–130 tok/s | ~2,000+ tok/s | ✅ Run 4–6 models concurrently | | RTX Pro 6000 Blackwell (96 GB) | vLLM / TRT-LLM | 140–180 tok/s | ~3,000–4,000 tok/s | ✅ Comfortable (21 GB of 96 GB) | | DGX Spark (128 GB) | vLLM / llama.cpp | 35–75 tok/s | ~1,500–2,000 tok/s | ✅ Comfortable (21 GB of 128 GB) | > MoE models dramatically favor Apple Silicon and NVIDIA Blackwell due to sparse parameter access patterns. The DGX Spark's 273 GB/s bandwidth is the binding constraint here — perfectly adequate for MoE but limiting for dense 70B+ models. --- Table 2 — Dense Model Scaling: Qwen2.5-Coder 32B @ Q4 (Secondary Reference) | Machine | Tok/s (Generation) | Notes | |---|---|---| | Mac Studio M5 Ultra | 55–75 tok/s | Dense model; bandwidth-bound; all 32B weights accessed per token | | RTX Pro 6000 Blackwell | 90–120 tok/s | GDDR7 bandwidth advantage; CUDA kernel maturity | | DGX Spark (128 GB) | 15–25 tok/s | Bandwidth bottleneck severe for dense 32B; fits, but slow | --- Table 3 — Context Window Fidelity (The 32k Cliff in Practice) This is the metric most vendors don't advertise. Based on RULER / ETHIC / multi-hop evaluation benchmarks: | Context Range | Effective Reasoning Quality | Hardware Impact | |---|---|---| | 0–16k tokens | ✅ Peak quality on all platforms | All platforms equivalent | | 16k–32k tokens | ✅ High quality; minor attention dilution begins | All platforms equivalent | | 32k–64k tokens | ⚠️ Noticeable degradation; multi-hop reasoning drops 15–30% | Context engineering becomes mandatory | | 64k–128k tokens | ❌ Severe degradation on complex tasks; primacy/recency bias dominant | Only use for bulk reference, not active reasoning | | 128k+ tokens | ❌ Retrieval of middle-context information unreliable | All platforms degrade equally — hardware doesn't save you here | Key finding: At the 32k–64k boundary, hardware cannot compensate for attention degradation. The mitigation is context engineering (session summarization, RAG, memory layering), not more VRAM. --- Table 4 — Power Draw and Always-On Suitability A coding harness runs for hours or days. Power efficiency is not a luxury — it's operational cost. | Machine | Idle Draw | Full Inference Load | Annual Power Cost (24/7) | |---|---|---|---| | Mac Studio M5 Ultra | ~10–20W | ~150–250W | ~$130–$220 USD/year | | RTX Pro 6000 Workstation | ~80–120W (system) | ~700–900W (GPU + system) | ~$610–$790 USD/year | | DGX Spark | ~25–40W | ~150–200W | ~$130–$175 USD/year | > At $0.12/kWh, over a 3-year hardware lifecycle, the RTX Pro 6000 workstation costs approximately $1,500–$2,000 more in electricity alone compared to the Mac Studio. --- Table 5 — Multi-User Concurrent Inference For teams sharing a local inference server: | Machine | Concurrent Users (30B MoE, ~4k context each) | Concurrent Users (32B Dense, ~4k context each) | |---|---|---| | Mac Studio M5 Ultra (96 GB) | 3–4 simultaneous | 2–3 simultaneous | | Mac Studio M5 Ultra (256 GB) | 8–10 simultaneous | 5–6 simultaneous | | RTX Pro 6000 Blackwell (96 GB) | 3–4 simultaneous (vLLM batching) | 2–3 simultaneous | | DGX Spark (128 GB) | 3–5 simultaneous | 2 simultaneous | | 2× DGX Spark (NVLink cluster) | 8–12 simultaneous | 4–6 simultaneous | --- Table 6 — Inference Stack Compatibility | Stack | Mac Studio M5 Ultra | RTX Pro 6000 Blackwell | DGX Spark | |---|---|---|---| | Ollama | ✅ Native Metal | ✅ CUDA | ✅ CUDA | | llama.cpp / llama-server | ✅ Metal backend | ✅ CUDA | ✅ CUDA | | Apple MLX | ✅ Native, optimized | ❌ | ❌ | | Apple MLX-Server | ✅ Full | ❌ | ❌ | | vLLM | ⚠️ Limited / experimental | ✅ Best-in-class | ✅ Best-in-class | | TensorRT-LLM | ❌ | ✅ Native | ✅ Native | | LM Studio | ✅ | ✅ | ✅ | | ExLlamaV2 | ❌ | ✅ | ✅ | | Fine-tuning / LoRA | ⚠️ MLX-based, limited | ✅ Full CUDA | ✅ Full CUDA | --- Master Comparison Summary | Metric | Mac Studio M5 Ultra | RTX Pro 6000 Blackwell | DGX Spark (128 GB) | |---|---|---|---| | Memory bandwidth | 1.2 TB/s | 1.79 TB/s | 273 GB/s | | Max VRAM / Unified Memory | 512 GB | 96 GB | 128 GB | | Qwen3-Coder MoE tok/s | 110–130 | 140–180 | 35–75 | | Dense 32B tok/s | 55–75 | 90–120 | 15–25 | | Runs 70B dense locally? | ✅ (fits easily) | ⚠️ (tight on 96 GB) | ✅ (fits in 128 GB, slow) | | Runs 120B+ locally? | ✅ (256 GB config) | ❌ Multi-GPU needed | ⚠️ (MoE variants only) | | Power draw (full load) | 150–250W | 700–900W (system) | 150–200W | | Multi-user (team server) | Good (with 256 GB) | Moderate | Good (2× NVLink scales) | | Software ecosystem | Apple MLX + Ollama | CUDA (best) | CUDA (best) | | Fine-tuning support | Limited | Excellent | Excellent | | Noise / thermals | Silent, passive | Loud, hot | Moderate | | Entry system price | $5,499 | ~$16,000–$22,000 total | $6,950–$8,000 | | 3-year power cost | ~$400 | ~$2,000+ | ~$450 | | 3-year TCO (entry) | ~$6,000 | ~$18,000–$24,000 | ~$7,400 | --- Part V: Context Engineering — The Harness-Level Countermeasures Hardware is the substrate. Context engineering is the discipline that keeps your harness operating within the 32k effective zone. These measures are non-negotiable regardless of which hardware you choose. 1. Session Summarization (Compact Before You Degrade) At approximately 20,000–25,000 tokens in a session, trigger a summarization pass: compress the prior context to its essential decisions, constraints, and relevant code state. Carry the summary forward, discard the raw history. Why: This is the single highest-leverage intervention. It keeps every new turn starting fresh within the high-fidelity zone. 2. Structured RAG Over Raw Context Injection Never dump an entire codebase, log file, or document set into the context window. Use retrieval to inject only the top-K most relevant chunks at each turn, ranked and trimmed to fit within 8,000–16,000 tokens of injected context. Why: A 200k-line codebase in context performs worse than 5 surgically retrieved, relevant functions. Every unnecessary token is a distractor. 3. Strategic Information Placement When you must include long reference material, place the most critical instructions and constraints at the very beginning and very end of the prompt. Put background reference material in the middle. Why: Primacy and recency effects are real. The model will reliably process start and end positions even when the middle degrades. 4. Agentic Memory Layering Separate concerns across memory tiers: - Working memory (in-context): Active task state, current file, immediate plan. Keep this under 8k tokens. - Session memory (external fast store): Summarized decisions, key code facts, project constraints. Retrieved on-demand. - Persistent memory (vector/graph DB): Architecture decisions, project history, domain knowledge. Queried via RAG. Why: This is the only sustainable architecture for long-running coding agents. Monolithic context windows are a liability, not an asset. 5. Prompt Caching For static system prompts, coding conventions, and project context that don't change between turns, use inference server-level prompt caching (supported natively on Ollama, vLLM, and MLX-server). Why: Cached prefill tokens don't consume attention budget from the generation phase. Static context becomes free. 6. Context Pruning Pipelines Before submitting each turn, run a lightweight filter that removes: - Redundant tool call outputs - Acknowledged and resolved error messages - Exploratory dead-end code that was rejected - Verbose log output that can be summarized to a single line Why: Context rot is cumulative. Pruning even 30% of noise tokens has outsized impact on output quality at the tail of a session. --- Part VI: Tiered Decision Framework Choose your tier based on your primary constraint. There is no single correct answer. --- 🟢 Tier 1 — The Pragmatic Solo / Small Team ($5,499–$8,500) Recommended: Mac Studio M5 Ultra (96–256 GB) Best for: - Solo CTOs and technical architects who are the primary harness user - Teams of 2–4 developers sharing a local inference server - Privacy-sensitive work (on-premise, air-gapped, no cloud dependency) - macOS / Apple-first development environments Why: - Silent. Zero fan noise. Runs 24/7 without disrupting the office. - MLX is the fastest path for MoE models like Qwen3-Coder. Native Apple Silicon path, zero configuration overhead. - $5,499 base gets you 96 GB and class-leading 1.2 TB/s bandwidth. Far stronger throughput-per-dollar than any CUDA alternative in this price band. - 512 GB max config means you can scale to 120B+ models on a single machine when your needs grow. - Weak point: If your team does active fine-tuning / LoRA training, CUDA ecosystem gaps will frustrate you. If you plan to run dense 70B+ models as your daily driver, bandwidth alone won't compensate for the single-socket architecture. --- 🟡 Tier 2 — The CUDA-Native Team Server ($7,000–$8,000) Recommended: NVIDIA DGX Spark (128 GB) — optionally clustered 2× Best for: - Teams already committed to the CUDA / vLLM / TensorRT stack - Linux-first development shops - Plans for future fine-tuning or model customization - CTOs who want a foot in the NVIDIA enterprise ecosystem for future upgrade paths (DGX Station, cloud parity) Why: - Full CUDA stack. vLLM, TensorRT-LLM, NIM, all work natively without adaptation. - 128 GB with ConnectX-7 — cluster two units for 256 GB NVLink-fused memory for ~$14,000–$16,000, running models up to 120B+ parameters at usable speeds. - $7,000–$8,000 per unit is reasonable for an enterprise-grade local server. - Weak point: 273 GB/s bandwidth is the Achilles heel. Dense models are slow. This machine is purpose-built for MoE architectures and batched concurrent workloads. If you're running dense 70B+, the Mac Studio M5 Ultra will outperform it on tokens-per-second despite lower theoretical compute. --- 🔴 Tier 3 — The Maximum Throughput Workstation ($16,000–$22,000+) Recommended: RTX Pro 6000 Blackwell (96 GB) in a workstation host Best for: - Teams where inference speed per request is the primary bottleneck - Active model fine-tuning, LoRA, RLHF pipelines as a daily workflow - Organizations running proprietary models, not open-weight community models - Shops where the CUDA ecosystem depth (ExLlamaV2, TensorRT, quantization tooling) is a hard requirement Why: - 1.79 TB/s bandwidth is the highest available on a single GPU in a desktop form factor. Crushes everything else on tokens-per-second for models that fit in 96 GB. - 96 GB GDDR7 fits dense 70B in FP8 or Q8 comfortably. - 4,000 AI TOPS with FP4 sparse — purpose-built for both inference and training. - Weak point: Price has inflated dramatically due to supply constraints — from $8,000 at launch to $13,000–$16,000 by October 2026. Total workstation TCO ($18k–$24k) is harder to justify against the Mac Studio for pure inference workloads. The power draw (700–900W system-level) is also a meaningful operational cost over 3 years. --- Part VII: The Decision Tree START: What is your primary use case? │ ├─ Pure local inference (running models, no training) │ │ │ ├─ Budget under $9,000? │ │ ├─ macOS / Apple ecosystem → Mac Studio M5 Ultra (96 GB) ✅ │ │ └─ Linux / CUDA ecosystem → DGX Spark (128 GB) ✅ │ │ │ └─ Budget $10k–$22k? │ ├─ Need 120B+ models on one machine → Mac Studio M5 Ultra (256–512 GB) ✅ │ ├─ Need maximum tokens/sec for 30B–70B → RTX Pro 6000 Blackwell workstation ✅ │ └─ Need team server + future fine-tuning → 2× DGX Spark (NVLink cluster) ✅ │ └─ Fine-tuning + inference ├─ Team of 1–3 → RTX Pro 6000 Blackwell workstation ✅ └─ Team of 4–10 → 2× DGX Spark cluster or cloud burst ✅ --- Conclusion The 32k cliff is not a flaw in the hardware. It's a fundamental property of current Transformer architectures. No amount of VRAM or memory bandwidth makes it go away. What hardware does determine is: - How fast the model thinks (tokens per second within the effective context zone) - How large a model you can run (model quality ceiling) - How many developers can share the resource (team scalability) For the vast majority of engineering teams building a local AI coding harness in 2026, the Mac Studio M5 Ultra (96–256 GB configuration) represents the best balance of price, performance, silence, power efficiency, and memory scaling. The DGX Spark is the right call for CUDA-native shops or teams planning ahead for fine-tuning. The RTX Pro 6000 Blackwell earns its price only when raw inference speed and the full CUDA depth stack are hard requirements. The hardware is the table. Context engineering is the game. --- --- > ⚠️ Disclaimer & Editorial Notice > > * Personal Analysis & Opinion: This article represents an independent, opinionated technical analysis intended solely for educational and architectural discussion. It does not constitute professional IT procurement, legal, or financial advice. > * No Vendor Affiliation: The author has no financial interest, partnership, or sponsorship with Apple, NVIDIA, or any hardware/software vendors mentioned. All trademarks belong to their respective owners. > * Rapid Ecosystem Volatility: Hardware pricing, availability, software compatibility (MLX, CUDA, vLLM), and community benchmarks reflect publicly reported data as of October 2026. Because the AI hardware landscape shifts rapidly, numbers should be treated as directional estimates, not guaranteed specifications. > * Limitation of Liability: Readers should independently verify vendor quotes, run internal benchmarks against their specific workloads, and consult their enterprise procurement policies before committing capital. The author assumes no liability for hardware purchasing decisions or benchmark variance. Power cost estimates assume $0.12/kWh at 24/7 operation. --- References & Further Reading Sources are grouped by topic. All URLs verified as of October 2026. The 32k Cliff & Long-Context Research - "Lost in the Middle: How Language Models Use Long Contexts" — Liu et al. (Stanford / UC Berkeley, 2023). The foundational paper on the U-shaped recall curve. arxiv.org - RULER Benchmark — A challenging long-context evaluation beyond needle-in-a-haystack. aclanthology.org - FutureAGI: The 32k–64k Cliff in Enterprise Tasks — Analysis of MECW across frontier models. futureagi.com - Context Rot and Agentic Session Degradation — MorphLLM analysis of cumulative noise in long agent loops. morphllm.com - "Lost in the Middle" Practical Explainer with Mitigation Strategies — Big Data Boutique. bigdataboutique.com - Context Engineering vs. Brute-Force Context Capacity — Zylos AI overview. zylos.ai Hardware Specifications & Pricing - Apple Mac Studio (M5 Ultra) — Official specs apple.com - NVIDIA RTX Pro 6000 Blackwell — Technical specs — TechPowerUp GPU Database. techpowerup.com - RTX Pro 6000 Blackwell price history and supply constraints — Tom's Hardware. tomshardware.com - NVIDIA DGX Spark (GB10 Grace Blackwell) — Full specs and ecosystem nvidia.com - DGX Spark OEM variants pricing (ASUS, HP, Lenovo) — Compute Market. compute-market.com - Mac Studio M5 Ultra vs DGX Spark comparison — Appauxin. appauxin.com - Mac Studio M3 Ultra specs and pricing history — EveryMac. everymac.com Inference Benchmarks & Model Performance - Can It Run AI? — Hardware inference speed database canitrun.dev - LLM Check — Tokens/sec benchmarks across Apple Silicon generations llmcheck.net - Will It Run AI? — Model/hardware fit calculator willitrunai.com - LLM Configurator — DGX Spark MoE benchmark estimates llmconfigurator.com - Apple Silicon MLX inference speed — Reddit community benchmarks reddit.com - Bizon-Tech: Apple Silicon vs NVIDIA for local LLM inference bizon-tech.com - DGX Spark GB10 inference review — Dendro Logic. dendro-logic.com - Spheron Network: RTX Pro 6000 Blackwell inference analysis spheron.network Reference Model - Qwen3-Coder-30B-A3B-Instruct-4bit (MLX community quantization) — HuggingFace model card. huggingface.co - Qwen3 technical report and architecture overview — Qwen team blog. qwenlm.github.io - MLX-LM inference speed community data — omlx.ai. omlx.ai Inference Stacks & Frameworks - Ollama — Local model serving for macOS, Linux, Windows. ollama.com - llama.cpp / llama-server — CPU, Metal, and CUDA inference backend. ggml-org/llama.cpp - vLLM — High-throughput CUDA inference server. docs.vllm.ai - Apple MLX — Apple's machine learning framework optimized for Apple Silicon. ml-explore.github.io - LM Studio — Cross-platform local model UI with llama.cpp backend. lmstudio.ai - TensorRT-LLM — NVIDIA's high-performance LLM inference library. NVIDIA/TensorRT-LLM - NVIDIA NIM — Microservices for optimized model inference on NVIDIA hardware. developer.nvidia.com

llm-jp-evalとllm-jp-eval-inferenceを変更し、オープンウェイト版Jevの日本語性能を比較可能にする <details> <summary> 2026年10月19日現在、本記事更新中 </summary> ・キャンペーンに出してみたいという気持ちやまず、いま書けているところで出しました… ・現状GitHubへのコミット履歴のURLに任せているコードの説明は、本記事に加筆する予定です ・検証結果の考察も、より厚みを持たせたいです… </details> --- > 本記事では、llm-jp-evalとllm-jp-eval-inferenceを変更し、オープンウェイト版意思決定モデルの日本語性能を比較した方法と結果を紹介する。オープンウェイト版意思決定モデルの場合、9B級では、NLI・CR・LMの性能はJevと遜色なかったが、HE-JA・HE-ENは約0.2ポイント水をあけられていた。そのため、HE-JA・HE-ENに近いユースケースの場合は、事後学習を要する可能性がある。一方、意思決定モデルとそのベースのLLMを比べた場合、意思決定モデルのほうがポイントが高い傾向にある。その背景として、意思決定モデルが選択式のベンチマークあるいはそれに類似した学習データを学習していた可能性も考えられるが、各意思決定モデルのモデルカードからは定かではない。 !lang_scores_radar.png --- TypeSafe AI社Jevの登場により、「意思決定モデル」あるいはSystem One Modelと呼ばれる新しいAIが俄かに注目を集めている。質問文や思考の条件と選択肢を与えたときに、瞬時に選択結果とその確率を構造化されたデータで返却するモデル、とのことである。Jevや「意思決定モデル」の詳細は、下記のような既存記事に委ねたい。 - Introducing System One Models & Jev - 「TypeSafe AI⁠⁠、AIモデル「Jev」の早期提供を開始—⁠—判断結果を構造化データで高速出力⁠⁠、ソフトウェアでの活用を想定」 - 「『Jev』とは　“文章を書かないAI”がなぜ話題に？　元OpenAI研究者が開発、『“スマートなif文”と考えてみて』」 すでにJevの性能評価は、日本語や日本国内という環境でも行われている。だが、性能評価者それぞれのユースケースに特化したレポートが多く、自分のユースケースに当てはまるのか分からないこともある。そのような中で、「日本語ベンチマークでJevの性能を検証する」に触発され、汎用的な日本語ベンチマークテストである「llm-jp-eval」によって、複数個の意思決定モデルを評価したいと考えた。もちろん、ベンチマークテストが自分のユースケースに近いことは少ないかもしれない。ただ、どのモデルが日本語に長けているかを判断する上で、多面的かつ統一的にモデル性能を測れるベンチマークテストは依然として有効とも考える。 また、Jevの登場直後から、オープンウェイトの意思決定モデル、つまりローカル端末やオンプレミスないし自社で契約したクラウド環境上といった「自分の環境」の中に配置して動かせる意思決定モデルも登場している。これらが利用できると、以下の点でメリットがある。 - プロプライエタリな意思決定モデルの運用に必要な外部通信をせずに、データを保全しやすい自分の環境下で意思決定モデルを運用できる - 事後学習等のモデル自体への改造も含めて、自分の環境下の意思決定モデルに適用できる （プロプライエタリなモデルの場合、事後学習できても学習済みモデルをモデルの提供会社の環境から移せない） - プロプライエタリな意思決定モデルを提供している会社と取引するための審議・与信・決裁・決済などをする傍ら、開発環境で意思決定モデルを試せる 一方、これらのオープンウェイト意思決定モデルは、言語モデルを推論するための各種パッケージvllmやtransformersでも開発中のバージョンでのみ動作する。llm-jp-evalで推論・評価する際には、これらの開発中のパッケージをllm-jp-evalにも導入しなくてはならない。 そこで、この記事では、llm-jp-evalとその推論モジュールllm-jp-evalに開発版のvllmやtransformersを導入し、オープンウェイトで商用利用可能な意思決定モデルを推論・評価した方法を示したい。 検証対象モデル 大枠 1. オープンウェイトで商用利用可能な意思決定モデル （≒ローカル端末やオンプレミスないし自社で契約したクラウド環境上といった「自分の環境」の中に配置して動かせる商用利用可能なモデル） 1. 日本語に対応しているモデル 1. 精度BF16/FP16の下で、NVIDIA GeForce RTX 5090（専用GPUメモリ32GB；以下、RTX 5090）というGPUで動かせるモデル 当初予定と実際 当初は、「Jev・Clef・d1・Jeff・Kev…意思決定モデル（System One）を仕組みから比較する【2026年10月版】」や「『GLiNER2.5』を試す」を参考に、下記のモデルを検証対象に考えていた。 - Cloudflare/clef-flash - Kev - jaredpalmer/kev-9b - jaredpalmer/kev-4b - Jeff - jeff-legacy/Jeff-Gemma4-E2B - jeff-legacy/Jeff-Qwen3.5-2B - jeff-legacy/Jeff-Qwen3.5-0.8B - GestaltLabs/Jeff-1 - convaiinnovations/laya-multilingual - fastino/gliner2.5-multi-v1 だが、下記のように、独自の推論設定・実行環境を要しvllmが未対応のものが多かった。そこで、vllmが対応している意思決定モデルや、その意思決定モデルのベース（種車？）となっているLLMを検証することにした。 | 例 | パラメタ数 | ベースモデル | ベースモデルへの事後学習方式 | ライセンス | BF16/FP16でRTX 5090で動作するか | Hugging Faceでの提供有無 | vLLMでのサーバー化（2026年10月13日現在） | | ---------------------------------------------------------------------------------------------------- | ---------- | --------------------------- | ---------------------------- | -------------------------- | ------------------------------- | ------------------------------- | ------------------------------------ | | 【参考】Cloudflare/clef | 27B | Qwen/Qwen3.8-27B | LoRA | apache-2.0 | 不可能 | 有 | 未対応 | | 【参考】jaredpalmer/kev-27b | 27B | Qwen/Qwen3.8-27B | フルファインチューニング | apache-2.0 | 不可能 | 有 | 未対応 | | Cloudflare/clef-flash | 9B | Qwen/Qwen3.5-9B | 詳細不明 | apache-2.0 | 可能 | 有 | 対応 | | jaredpalmer/kev-9b | 9B | Qwen/Qwen3.5-9B-Base | LoRA | apache-2.0 | 可能 | 有 | 未対応 | | jeff-legacy/Jeff-Gemma4-E2B | 5B | google/gemma-4-E2B-it | フルファインチューニング | apache-2.0 | 可能 | 有 | 未対応 | | jaredpalmer/kev-4b | 4B | Qwen/Qwen3.5-4B-Base | LoRA | apache-2.0 | 可能 | 有 | 未対応 | | GestaltLabs/Jeff-1 | 4B | Qwen/Qwen3-4B-Instruct-2507 | LoRA | apache-2.0 | 可能 | 有 | 未対応 | | LiquidAI/d1-3B | 3B | LiquidAI/LFM2.5-VL-3B | 詳細不明 | lfm1.0（年商1,000万米ドル未満の場合商用利用可；制限の付け方がLlamaライセンスに近い） | 可能 | 有 | 対応 | | jeff-legacy/Jeff-Qwen3.5-2B | 2B | Qwen/Qwen3.5-2B | フルファインチューニング | apache-2.0 | 可能 | 有 | 未対応 | | jeff-legacy/Jeff-Qwen3.5-0.8B | 0.8B | Qwen/Qwen3.5-0.8B | フルファインチューニング | apache-2.0 | 可能 | 有 | 未対応 | | convaiinnovations/laya-multilingual | 0.322B | mmBERT-base | （事前学習モデル？） | apache-2.0 | 可能 | 有 | 未対応 | | fastino/gliner2.5-multi-v1 | 0.287B | mDeBERTa-v3-base | （事前学習モデル？） | apache-2.0 | 可能 | 有 | 未対応 | | 【参考】Jev・Microsoft-Decision-1などのプロプライエタリモデル | 不明 | 不明 | 不明 | （プロプライエタリモデル） | 不明 | 無（各社インフラからのAPI提供） | 未対応 | hotchpotch/S1MB-leaderboardなどの意思決定モデルのリーダーボードには、様々なモデルが出ており、上掲のモデルよりベンチマークテストで優れた成績を出しているモデルもある。しかし、CC-BY-NC 4.0でライセンスされている[openjev/OpenJev-Flash-9B](openjev/OpenJev-Flash-9B)のように、非商用利用のみ可能なモデルは今回の検証対象から除外した。 検証方法 アクセス承認が必要なデータセットに対する承認手続き アクセス承認が必要なデータセットは、下記の2つである。 - cais/hle - llm-jp/jhle 承認していない場合、task installで以下のエラーが出る。 huggingface_hub.errors.GatedRepoError: 403 Client Error. (Request ID: Root=<Request ID>) Cannot access gated repo for url https://huggingface.co/api/datasets/<dataset_provider>/<dataset>. Access to dataset <dataset_provider>/<dataset> is restricted and you are not in the authorized list. Visit https://huggingface.co/datasets/<dataset_provider>/<dataset> to ask for access. task: Failed to run task "install": exit status 1 そのため、検証前に各データセットのHugging Faceリポジトリで承認手続きを完了させておく。 llm-jp-evalに対する変更 llm-jp-evalのコードではアクセスできないデータセットを利用するためのコード変更 TensorRT-LLM#18380 によると、2026年8月29日時点からmmlu_enのデータセットへのURLはリンク切れになっていた。 !image.png そのため、src/llm_jp_eval/jaster/mmlu_en.pyを書き換え、[ Center for AI SafetyのHugging Faceのmmlu用レポジトリ](huggingface.co)からdatasets.load_dataset()でダウンロードする方式に変更した。それに伴い、Testデータなどのデータ種別ごとにデータを分ける処理や各データの前処理の工程を、src/llm_jp_eval/jaster/mmluprox.pyに倣って変更した。正直mmlu_enはmmluproxと近いだろうと思っただけでmmluproxの_download()とpreprocess_evaluation_data()を取り入れているため、変更後のsrc/llm_jp_eval/jaster/mmlu_en.pyの正確さには自信がない。御批正賜りたい。 詳しくは下記をご覧いただきたい。 github.com/CLRafaelR/llm-jp-eval/commit/05213c925… 選択式データセットを対象とする評価設定とデータセット一覧を追加する 選択肢から1つだけ正解を選ぶ形式（択一選択式）であり、全ての問題で選択肢が固定の個数・固定のラベルになっているベンチマークテストのみ実施した。たとえば、全ての問題で選択肢が4つあり、どの問題でもラベルがA～Dのアルファベットになっているようなベンチマークテストのみ実施した。 自由記述で回答する形式（自由回答式）のベンチマークテストは実施しなかった。また、選択式であっても、bigbenchhard_*のように問題ごとに選択肢の個数や選択肢のラベルが変わるものは実施しなかった。また、一見選択式であっても、chabsaのように読解すべき文章からの特定表現の抽出（自由記述のような形式）も伴う回答や、jculture-mcqのように正解数が1個とは限らないベンチマークテストは実施しなかった。 選択式のベンチマークテストは、task installやtask prepare dataset=allで作成されるベンチマークテストのJSONファイル（デフォルトでは、local_files/datasets/2.1.5/配下に作成される。例: local_files/datasets/2.1.5/evaluation/test/jamc-qa.json）で、キーlabel_listの値（選択肢のリスト）が空でないものを採用した。一方で、winogrande_xlとopenbookqaは、「日本語ベンチマークでJevの性能を検証する」では検証対象外だったが、選択肢のリストがlabel_listにあるため、検証対象とした。 変更履歴は、下記をご覧いただきたい。 github.com/CLRafaelR/llm-jp-eval/commit/4e30bb736… llm-jp-eval-inferenceに対する変更 詳しくは下記をご覧いただきたい（※加筆修正をお待ちください…） github.com/CLRafaelR/llm-jp-eval-inference/commit… 検証対象モデルは、vllmのvllm/entrypoints/openai/decisions/strategies.pyの下記実装に従って、どのようなstrategy（推論方法）で最終的な出力を出すかがルーティングされる。 github.com/vllm-project/vllm/blob/2365177ddda7714… これを表にまとめると、下記の通りである。 | モデル | 選択される Strategy | 推論方法 | |---|---|---| | Cloudflare/clef-flash | ClefFlashStrategy | joint-schema ヘッド・token_classify | | vllm-sr/d3-edge | D3Strategy | 専用読み出しヘッド・classify | | vllm-sr/d3-flash | D3Strategy | 専用読み出しヘッド・classify | | LiquidAI/d1-3B | LiquidStrategy | d1 固有のプロンプトとラベルトークンの確率 | | Qwen/Qwen3-0.6B | NextTokenStrategy | 回答位置のラベルトークンの確率 | | Qwen/Qwen3.5-9B | NextTokenStrategy | 回答位置のラベルトークンの確率 | 検証結果 オープンウェイト版での言語別のベンチマークテストの結果は下記のとおりである。 <!--!lang_scores_radar.png--> !lang_scores_radar.png さらに下記は「日本語ベンチマークでJevの性能を検証する」でのJevの検証結果である。 !参考: 「日本語ベンチマークでJevの性能を検証する」でのJevの検証結果 両者を比べると、9B級オープンウェイト版意思決定モデル（Cloudflare/clef-flashとvllm-sr/d3-flash）の場合、NLI・CR・LMの性能はJevと遜色なかったが、HE-JA・HE-ENは約0.2ポイント水をあけられていた。そのため、HE-JA・HE-ENに近いユースケースの場合は、事後学習を要する可能性がある。一方、意思決定モデルとそのベースのLLMを比べた場合、意思決定モデルのほうが高得点傾向にある。その背景として、意思決定モデルが選択式のベンチマークあるいはそれに類似した学習データを学習していた可能性も考えられるが、各意思決定モデルのモデルカードからは定かではない。 データセット別スコアの成績は、下記である。gpqa_diamond_jaとjamc_qaが軒並み低得点だった。 <!-- !exact_match_radar.png --> !exact_match_radar.png 推論時間の比較は、下記のとおりである。意思決定モデルでは、推論時間の短さが訴求されることがある。Jevの場合の例では、0.114sすなわち114ミリ秒だが、vllmで推論させたときは、意思決定モデルもそのベースであるLLMも推論時間に差はなかった。むしろClaudeflare/clef-flashが推論時間が長い時があるのは、気になった。 <!-- !time_profile_bar.png --> !time_profile_bar.png