実測(TP=4・32kコンテキスト・KV fp8・RTX PRO 2000 Blackwell ×4)
Table with columns: 並列数, 合計スループット| 並列数 | 合計スループット |
|---|
| 1 | 43.1 t/s |
| 2 | 85.1 t/s |
| 4 | 167.3 t/s |
プリフィル単流: 3,597 tok/s(8kプロンプト・prefix cache無効・3回平均)
起動方法 — ⚠️公式の推論パーサが必須です
このモデルは OpenAI Harmony 形式(analysis / final チャンネル)で応答します。素のvLLMでは思考(analysis)が本文に混ざって返るため、公式cookbook の専用パーサを登録してから起動してください。本リポジトリに同梱してあります(llmjp4_reasoning_parser.py / example_cli.py)。
# リポジトリのファイルがあるディレクトリで
python3 example_cli.py serve <このモデルのパス> \
--served-model-name llmjp4 --trust-remote-code \
--tensor-parallel-size 4 --max-model-len 32768 \
--kv-cache-dtype fp8 --enable-prefix-caching \
--reasoning-parser llmjp4
P2Pの無いボードでは NCCL_P2P_DISABLE=1 と --disable-custom-all-reduce を追加してください。
思考の深さはリクエストごとに指定できます:
"chat_template_kwargs": {"reasoning_effort": "low"}
検証記録 — reasoning_effort 別の観察(小規模)
日本語の音韻課題(モーラ数え12語・俳句の音数走査3句・字余り検出)を、当環境の汎用27B(Qwen3.8-27B NVFP4)と並べて試した記録です。モデル2体・各課題1〜2回の小規模な検証であり、一般化はできません。判断は結果を見てご自身で。
- effort=low: 語のモーラ数え 10/12(汎用27Bは11/12)。俳句の音数走査は両者ともほぼ不能。ひらがな分かち書きで渡すと両者とも正解した(表記→音の変換が律速で、数える力そのものはある、と読める挙動)
- effort=high: 「古池や〜」を5-7-5と走査し、字余りの句を「5-7-6、字余りあり」と検出した。汎用27Bも最高effortで同じ検出に到達した
- 速度はeffortに応じて変わります(lowが最速)。どのeffortで使うかは用途に合わせて
出力例(effort=low・パーサで本文分離済み):
潮騒に 足あと残す 夕焼けかな
⚠️ 量子化時に踏んだ罠(再現する方へ)
- カスタムトークナイザのラッパー(
llmjp4_tokenizer.py)は環境によって日本語を一文字ずつに分割します(「ありがとうございます」が11トークン)。生の tokenizer.json は正常(同じ語が1トークン)。キャリブレーションは生のtokenizer.jsonで行い、chat_templateだけtokenizer_config.jsonから移植しました。壊れたトークナイザでのキャリブは日本語品質を静かに損なうので、焼く前に必ず検問を
- GPU常駐でキャリブした場合、保存時の集約でOOMすることがあります。このモデルはCPU側に重みを置く方式(llm-compressorのSequentialPipeline既定)で問題なく焼けます
レシピ
llm-compressor NVFP4 (W4A4, group 16)、targets: [Linear]、ignore: ["lm_head"]、キャリブレーション 32サンプル × 8192トークン(neuralmagic/calibration)。
🙏 LLM-jp(モデルと公式パーサ)、vLLM / llm-compressor の各チームに感謝します。