対象読者: ローカルLLMをこれから本格運用したい人。「なんとなく動いた」から「なぜこの値なのか説明できる」へ進みたい人。
環境: Windows 11 + WSL2 / RTX 5070 12GB × 2(NVLinkなし・consumer GPU)/ Sonar 0.22.0(vLLMフォーク)/ 実測日 2026-08-15〜2026-08-19
推論エンジンはSonar(旧称Aphrodite Engine)を使っている。2026年にプロジェクト名が
Sonarへ改称されたが、Pythonパッケージ名・CLIコマンドは歴史的経緯でaphroditeのまま
据え置かれている(pip install aphrodite-engine、起動コマンドもaphrodite run)。
本記事のコマンド例でaphroditeと書いてあるのはこのためで、Sonarと同じものを指す。
0. 3行まとめ
- Qwen3.8-27B(dense 27B・VLM)を exl3量子化2.5bpw にすると、12GB×2という consumer 環境でも 256Kコンテキストが載る。dense 27Bの速度は素の状態だと32 tok/sが天井だが、投機デコード(MTP)を動かす3つのバグを潰した結果、N=16並列で200 tok/s超まで引き上げられた。
- MTPが「読めない・動かせない・生成が壊れる」の3段階で詰まったが、原因はいずれも exllamav3/Aphrodite/vLLM本家それぞれの既知の穴であり、量子化やモデル自体の欠陥ではなかった。
- VLM(画像入力)を有効化したところ本番を2回クラッシュさせた。原因は「解像度上限を設定していなかったこと」で、
--mm-processor-kwargs一行と--gpu-memory-utilizationのスイープ実測で解決した。
1. 前提知識(ここだけ読めば用語で迷わない)
| 用語 | 意味 | なぜ効くのか |
|---|---|---|
| bpw (bits per weight) | モデルの重み1個あたり何ビットで保存するか | 4bpwなら約17GB、2.5bpwなら約12GB。VRAMの使用量がほぼ比例する |
| exl3 | ExLlamaV3の量子化フォーマット | 同じbpwならGGUFより精度が高いとされる。任意のbpw(2.0/2.5/3.0…)を選べるのが強み |
| KVキャッシュ | 会話履歴を覚えておく作業メモリ | ここが小さいと長い会話ができない/同時利用人数が減る |
| MTP (Multi-Token Prediction) | 1回の推論で複数トークンを先読み・検証する投機デコード | 当たれば複数トークンが1ステップで確定し体感速度が上がる |
| TTFT (Time To First Token) | 送信してから最初の1文字が出るまでの時間 | 体感速度の8割はこれ |
| VRAM崖 | ある使用量を超えると急激に遅くなる境界(このマシンでは約11,830MiB) | GPUメモリが溢れるとWDDMがシステムRAMへページングし、実質CPUオフロードになるため |
このマシン特有の制約: RTX 5070は VRAM 12GB。2枚あってもNVLinkがないので「24GBの1枚」にはならず、
--tensor-parallel-size 2でモデルを半分ずつに割って載せる。片方でも12GBを超えたら落ちる。実質的な予算は「12GBの中で重み+KV+作業領域を全部まかなう」。
2. 全体の推移 — 最初のデータ → 中間のデータ → 修正後のデータ
いきなり最終フラグを見せても「なぜそこに着地したか」が分からないので、先に**3つのストーリーそれぞれの「最初→試行錯誤→最終」**を数字で並べる。詳しい経緯は4〜6節で追う。
2-1. 速度: MTP(投機デコード)を動かすまで
| 段階 | 状態 | 速度 |
|---|---|---|
| 最初 | MTP無し(投機デコードなし)・cudagraph通常運用 | 31.8〜32 tok/s(単発) |
| 中間① | MTP有効化を試みる → ロードエラーで起動不可 | — (起動失敗) |
| 中間② | ロードエラーを解消 → 生成が「says says says…」と壊れる | 生成不可 |
| 中間③ | 壊れる原因を回避(--enforce-eagerでCUDA graph無効化) |
18.1 tok/s(単発。動くが遅い) |
| 中間④ | CUDA graphを一部復活させるパッチ適用 | 37.1〜40.1 tok/s(単発) |
| 最終 | 本番規模(256K・並列16)で全パッチ込み | N=16並列合計 115.1 → 226.0 tok/s(後述のVRAM調整でさらに向上) |
2-2. VRAM: 崖からどれだけ離すか
| 段階 | gpu-memory-utilization | 状態 |
|---|---|---|
| 最初 | 0.85(deployされていた値) | 動くが崖に近く、N=16で175.1 tok/sしか出ない |
| 中間① | 0.80 | 画像込み並列でVRAMピークが崖を57MiB超過(危険) |
| 中間② | 0.76 | 崖まで459MiB確保、221.1 tok/sまで改善 |
| 中間③ | 0.84 | 速いが画像並列時に崖までわずか49MiB(危険すぎ) |
| 中間④ | 0.70 | 起動時点でKV不足、クラッシュループに突入(下げすぎ) |
| 最終 | 0.77 | 226.0 tok/s・崖まで336MiBの余裕。速度と安全のバランス点 |
2-3. 複数画像入力: クラッシュから安定稼働まで
| 段階 | 状態 | 結果 |
|---|---|---|
| 最初 | 画像1枚のみ添付 | 正常動作(11,874トークン・19.6秒) |
| 中間 | 異なる画像3枚を同時添付 | バックエンド全体がクラッシュ(2回連続、復旧に1〜2分) |
| 最終 |
--mm-processor-kwargsで解像度上限を指定 |
3枚同時でも正常動作(prompt_tokens 2982〜2988) |
この3つの「最初→最終」を織り込んだのが、次節の本番投入フラグである。
3. 本番投入の設定(2026-08-19時点)
aphrodite run /home/(PC名）/exl3_served/Qwen3.8-27B-exl3-2.50bpw \
--tensor-parallel-size 2 \
--kv-cache-dtype turboquant_k3v4_nc \
--gpu-memory-utilization 0.77 \
--limit-mm-per-prompt '{"image":3,"video":0}' \
--mm-processor-kwargs '{"max_pixels": 1048576}' \
--max-model-len 262144 \
--max-num-seqs 16 \
--compilation-config '{"max_cudagraph_capture_size": 4}' \
--max-num-batched-tokens 3616 \
--long-prefill-token-threshold 1808 \
--stream-interval 2 \
--api-server-count 2 \
--watermark 0.02 \
--scheduling-policy priority \
--prefix-caching-hash-algo xxhash \
--shutdown-timeout 120 \
--enable-request-id-headers \
--log-error-stack \
--enable-prefix-caching \
--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}' \
--mamba-ssm-cache-dtype float16 \
--enable-mamba-cache-stochastic-rounding \
--mamba-backend flashinfer \
--mamba-cache-mode align \
--prefix-match-unit 16 \
--optimization-level 3 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--host 0.0.0.0 --port 8081
以下、カテゴリ別に「なぜこの値か」を説明する。
3-1. VRAMとモデル配置
--tensor-parallel-size 2
モデルを2枚のGPUに分割して載せる。12GBに収まらないモデルを動かす唯一の手段。速度は上がらない(むしろ通信分わずかに落ちる)。「2枚あるから2倍速い」ではなく「2枚あるから載る」。
--gpu-memory-utilization 0.77
GPU全体の何割まで使うかの上限。この数値の決め方だけで丸1セッションかかった(2-2節・5節で詳述)。
--kv-cache-memory-bytes は明示しない
KVキャッシュのバイト数を手動固定するオプションもあるが、明示すると起動時のメモリプロファイリングをスキップして固定値をそのまま予約してしまい、設定を変えるたびにOOMを引きやすい。実際に2026-08-19、実験でこれを明示指定したところ「desired GPU memory utilization」が内部で0.92まで跳ね上がり、即クラッシュループに入った(5節で詳述)。--gpu-memory-utilization任せの自動プロファイリングが安全。
--limit-mm-per-prompt '{"image":3,"video":0}' / --mm-processor-kwargs '{"max_pixels": 1048576}'
画像入力(VLM機能)の設定。この2つの組み合わせがハマったので6節で詳述する。
3-2. KVを圧縮して長い会話を可能にする
--kv-cache-dtype turboquant_k3v4_nc
KVキャッシュをK=3bit / V=4bitに量子化する。素のfp16と比べて数倍のトークンが同じメモリに入る。_ncはnon-contiguous(非連続配置)版。3bit_nc(KもVも3bit)は試したが思考が収束しなくなったため不採用。
--mamba-ssm-cache-dtype float16 + --enable-mamba-cache-stochastic-rounding
Qwen3.8は普通のTransformerではなくGDN(Gated DeltaNet)という線形アテンションを混ぜたハイブリッドで、Mamba的な「状態(SSM state)」を持つ。これをfloat32→float16にすると、block_sizeが半分(3,488→1,792)になった上にKVプールがむしろ増える(370,837→388,932)。日本語精度テストは15/15のまま維持。
--mamba-cache-mode align
Mamba状態のキャッシュ方式。allにすると理論上prefix cacheがよく効くがメモリが約16倍になり非現実的。align一択。
--enable-prefix-caching / --prefix-caching-hash-algo xxhash / --prefix-match-unit 16
同じ書き出し(システムプロンプト等)を再計算せず使い回す機能。TTFTが桁で変わるので必ずON。
3-3. 並列・詰まり対策
--max-num-seqs 16 / --compilation-config '{"max_cudagraph_capture_size": 4}'
最重要の組み合わせ。--max-num-seqsをそのまま16に上げるとCUDA graph捕捉サイズも連動して増え、VRAM不足でOOMする(6/8/16のいずれも素の状態では失敗)。max_cudagraph_capture_sizeで明示的にグラフ本数を4に固定すれば、seqs=16まで安全に上げられる(5本目以降はeagerフォールバックでやや遅いがクラッシュしない)。実測: seqs=8→95.4 tok/s、seqs=16→115.1 tok/s(2026-08-18時点、MTP込み)。
--max-num-batched-tokens 3616 / --long-prefill-token-threshold 1808
block_size(1808)の倍数でないと、align modeのスケジューラが端数切り捨てで予算の一部を毎ステップ無駄にする。1808(×1)/5424(×3)/7232(×4)も試したが3616(×2)が谷底(最良、実測比較済み)。
3-4. 投機デコード(MTP)
--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'
投機デコード自体の話は4節で詳しくやる。ここではnum_speculative_tokensが1固定である理由だけ書く: 2,3,4はいずれも同じ失敗モードでクラッシュする(lm_headのlogits計算バッファがspec_tokens+1倍必要になり、N=16全部が同時decodeする瞬間ピークでOOM)。公式推奨は3だが、このVRAM(12GB×2)・seqs=16との組み合わせでは1のみ安定。MTP採択率(1トークン時点)は84.8%。
3-5. ツール呼び出し・思考タグ
--reasoning-parser qwen3 / --enable-auto-tool-choice / --tool-call-parser qwen3_coder
<think>タグの中身をreasoning_contentとして分離し、ツール呼び出しを構造化して返すための指定。モデルごとに正しいパーサー名を選ばないと、ツール呼び出しが全滅する。旧設定ではqwen3_xmlを使っていたが、これは誤りだった(公式recipes.vllm.ai通りにqwen3_coderが正解)。
3-6. 運用・デバッグ用
| フラグ | 用途 |
|---|---|
--api-server-count 2 |
HTTP処理がボトルネックになるのを防ぐ(推論自体は速くならない) |
--stream-interval 2 |
2トークンごとにクライアントへ送る。体感と負荷のバランス点 |
--shutdown-timeout 120 |
再起動時、処理中のリクエストを待つ猶予 |
--enable-request-id-headers |
レスポンスにリクエストIDを付与。ログ突合に必須 |
--log-error-stack |
エラー時のスタックトレースを出す。原因究明が段違いに速い |
--optimization-level 3 |
torch.compileの最適化レベル |
3-7. 【重要】起動スクリプトの落とし穴
systemdから起動する場合、micromambaは絶対パスで書くこと。相対だとPATHが対話シェルと違うため失敗する。
4. MTPを動かすまでの3段階のバグ狩り(2026-08-18)
Qwen3.8には投機デコード用のMTP層の重みが同梱されているが、これを実際に動かすまでに3つの独立したバグを踏んだ。1つずつ潰さないと次のバグにすら到達できない、という厄介な順序だった(2-1節の表の中間①〜④に対応)。
バグ1: exl3量子化のMTP層をAphroditeが「量子化されていない」と誤判定する
Aphroditeは各レイヤーが量子化対象かどうかをquantization_config.json内のtensor_storage辞書(プレフィックス文字列の一覧)にそのプレフィックスが存在するかだけで判定する。ところがexl3量子化チェックポイントにはmtp.*のエントリが1件も無い(turboderp公式チェックポイントも含む)。これは第三者の手抜きではなく、exllamav3/util/convert_mtp.pyの設計上の既知のギャップ(MTPは本体とは別プロセスで量子化され、後から追加される設計のため)。
対策: quantization_config.jsonのtensor_storageに、MTP線形層のプレフィックス分のスタブエントリを追加するパッチ。ゲート判定にしか使われていないメタデータなので、最小限のダミー値で十分機能した。これで「ロードできない」は解消。
バグ2: ロードできても生成が壊れる(CUDA graphとの相性問題)
パッチ後、ロード自体は成功したが実際の生成が「夏夏夏」「says says says…」のような無限反復に壊れる。--enforce-eager(CUDA graph無効化)を付けると正常な日本語に戻ったため、原因はexl3の逆量子化計算そのものではなく、exl3×MTPの組み合わせがCUDA graphキャプチャと相性が悪く、キャプチャされたグラフを再生する際に不正なバッファを読むという典型的な"silent corruption"パターンだと判明。
Web検索で vLLM issue #40880「MTP × TurboQuant × CUDA graph capture produces degenerate output」が完全一致。根本原因は、TurboQuantAttentionImplのCUDA graphキャプチャ回避パスが、投機デコードのK+1検証バッチを「最初のチャンクのprefill」と誤認識するバグ。1行のパッチ(_cudagraph_supportの設定値変更)で解決し、投機デコードの検証バッチだけがeagerに降格される。
バグ3: 本番規模だとハングする
小規模構成では動いたが、本番規模(256K・max-num-seqs 4)で起動するとtorch.compile完了後、7分間ハングして完全停止。vLLM issue #40807で同一症状のコメントを発見: profile_run/CUDA graph warmupが、投機デコード検証バッチ用の経路を一度も通らないため、その経路が必要とするワークスペース割り当てがプロファイラから見えない("profiler-invisible torch.empty")。結果、必要量0バイトのままワークスペースがロックされ、実際の推論で初めて割り当てが発生した時に拒否される。vLLM本家では明示的なAssertionErrorとして現れるが、うちの環境(TP=2)では例外がrank間で伝播せず無限ハングとして観測された。
対策: ロック直前に必要分(8MB)を先出し確保する1箇所8行のパッチ。vLLM本家の正式な直し方(warmup自体の書き換え)より大幅に簡易だが、同じ症状を解消できた。
重大インシデント記録: ハングしたプロセスを
kill <親PID>で止めたつもりが、実際はEngineCore/Worker_TP0/Worker_TP1という子プロセスが生き残り、新旧2世代分のプロセスがGPU VRAMを食い尽くしたまま放置されていた。この種のプロセスを止める時はps aux | grep -iE "aphrodite|EngineCore|Worker_TP"で子プロセス残存を必ず確認すること。
3つのバグはいずれもexl3固有でもAphrodite固有でもなく、それぞれexllamav3・Aphrodite・vLLM本家それぞれの既知の穴だった。うちの構成(exl3×MTP)がまだ少数派機能の組み合わせなので、これらの穴を最初に踏んだユーザーだった可能性が高い。
注意: これらのパッチはAphroditeのsite-packagesへの直接パッチなので、Aphroditeをアップグレードすると消える。vLLM本家のPRがマージされ、Aphroditeがそれを取り込むまでは維持・再適用する運用になる。
5. VRAM崖とgpu-memory-utilizationのスイープ(2026-08-19)
このマシンには以前から実証済みの「VRAM崖」がある: VRAM使用量が約11,830MiBを超えると、WDDMのページングで実使用が5〜6倍遅くなる(GPU使用率100%なのに電力が上限の1/4以下、という分かりやすい症状)。崖の直上と直下でVRAM差はわずか数十MiBしかないのに速度が激変する。
複数画像対応の作業中(6節)、この崖にVRAMピークが接近したため、--gpu-memory-utilizationを0.85→0.80→0.76と段階的に下げた。ここでふと「崖から遠のいたから速くなったのでは?」という仮説が浮かび、同日中に0.85と0.76を直接A/Bした。
| 条件 | N=16並列 tok/s |
|---|---|
| 0.85 | 175.1 |
| 0.76 | 221.1 |
崖に近いだけで速度が落ちることが確認できたため、0.70〜0.85の範囲を段階的にスイープした。
| gpu-memory-utilization | tok/s | KVキャッシュ(トークン) |
|---|---|---|
| 0.85 | 175.1 | 459,603 |
| 0.84 | 204.1 | 444,283 |
| 0.83 | 196.0 | 428,962 |
| 0.82 | 210.2 | 413,642 |
| 0.79 | 197.8 | 367,682 |
| 0.78 | 227.1 | 352,362 |
| 0.77 | 226.0 | 337,042 |
| 0.76 | 205.7〜221.1 | 321,722 |
| 0.73 | 205.8 | 274,059 |
| 0.70 | 起動失敗 | — |
0.70は起動時点でKV不足(2.03GiB必要 vs 1.77GiB空き)でエンジン初期化に失敗し、systemdのauto-restartクラッシュループに突入した(実際に本番で数分間発生させてしまい、慌てて0.76へ戻して復旧した)。0.73〜0.84あたりは横ばいで、0.85だけ明確に遅く、0.70未満は起動不能。
さらに画像を含む並列負荷(8並列、画像3枚×3+2枚×3+テキスト×2)でのVRAMピークも確認した:
| gpu-memory-utilization | 画像8並列ピーク(GPU0) | 崖(約11,830MiB)までの余裕 |
|---|---|---|
| 0.84 | 11,781 MiB(GPU1) | わずか49 MiB(危険) |
| 0.80 | 11,887 MiB | 崖を57 MiB超過 |
| 0.78 | 11,536 MiB | 294 MiB |
| 0.77 | 11,494 MiB | 336 MiB |
| 0.76 | 11,371 MiB | 459 MiB |
速度と安全マージンのバランスを取り、最終的に0.77に確定した。
教訓:
--kv-cache-memory-bytesを明示指定する方式も同日試したが(0.77相当の等価値2.5GiBを計算して指定)、内部で逆算される「desired GPU memory utilization」が0.92まで跳ね上がり即OOMした。これは2026-08-18の教訓(「明示値だと設定変更のたびにOOMするバグを引きやすい」)がそのまま再現した実例で、gpu-memory-utilization(比率)方式以外は使わない方が安全という結論を補強した。
6. 複数画像対応でのクラッシュとmax_pixels修正(2026-08-19)
Qwen3.8-27Bはconfig上だけでなく実際にvision encoderの重み(model.visual.*テンソル333個)を持つネイティブVLMだと判明し、有効化した。1枚の画像添付は正常動作したが、異なる3枚を同時添付すると2回連続でバックエンド全体がクラッシュした(KeyError: req_id_to_index、RuntimeError: Encoder cache miss。復旧まで約1〜2分の全断)。
原因はvLLM issue #18550(Qwen2.5-VL、複数画像でOOM)と一致していた: limit-mm-per-promptで指定した画像枚数分、起動時のメモリプロファイリングが「1画像あたりの最大想定トークン数」×枚数分のバッファを予約する。モデルのpreprocessor_config.jsonを確認するとsize.longest_edge=16777216(patch16×merge2換算で1画像最大16,384トークン)と事実上無制限になっており、3枚分でこの上限に基づいた過大な予約が発生していた。
対策は--mm-processor-kwargs '{"max_pixels": 1048576}'の一行(1024×1024相当、1画像最大1024トークンに制限)。Aphrodite側のQwen3VLMultiModalProcessorがこのキーワードを正式サポートしていたため、コード変更なしで解決できた。
検証(異なる3枚・同一画像3枚複製、8081直・8083プロキシ経由の両方):
- クラッシュなし、200 OK
- prompt_tokens=2982〜2988(1画像=約996トークン、上限どおり)
- 色の認識は正確、細部の文字認識は解像度低下により犠牲になるトレードオフあり
7. RAGでの暴走ループ対策(2026-08-19)
VRAM・画像の問題を解決した後、実運用中に別種の不具合が見つかった。「広島県について2000字で」という質問で、末尾が「広島市、広島市、広島市…」という無意味な反復に崩壊。続けて「広島県の自治体を全部教えて」と聞くと、さらに深刻な症状が出た: 存在しない市名(「豊府市」「高州市」)を捏造しつつ自己矛盾に気づき、「待て。待て。待て。」を数十回繰り返した末に、生のスペシャルトークン<|im_end|>がそのまま本文に漏れて終了した。
これは以前特定していた「厳密な文字数指定が逐次カウントモードを誘発する」バグより広い現象で、モデルが正確に知らない事実を列挙・検証しようとすると自己修正ループに陥るという一般化されたパターンだった。
対策は「知識を教え込む」のではなく、モデルに数え上げさせずRAGで正確なデータをそのまま渡す方式にした。日本郵便公式の郵便番号データ(KEN_ALL相当)をダウンロードし、47都道府県それぞれの市区町村を機械的に抽出・整形してRAG知識カード化した(手打ちで作ると同じハルシネーションリスクを抱えるため、生成過程もプログラムで正確性を担保)。
広島県の市区町村・自治体を全部教えて、と聞かれたら次の23団体を正確に答える
(郵便番号データに基づく正確な一覧、記憶で数え上げようとして自己修正ループに
陥らないこと): 広島県の市は14市: 広島市(中区・東区・南区・西区・安佐南区・
安佐北区・安芸区・佐伯区)、呉市、竹原市、三原市、尾道市、福山市、府中市、
三次市、庄原市、大竹市、東広島市、廿日市市、安芸高田市、江田島市。
郡部は安芸郡(府中町・海田町・熊野町・坂町)、山県郡(安芸太田町・北広島町)、
豊田郡(大崎上島町)、世羅郡(世羅町)、神石郡(神石高原町)の計9町村。
投入前後の比較:
| 段階 | 「広島県の自治体を全部教えて」への応答 |
|---|---|
| 最初(RAG無し) | 「待て。待て。待て。」を数十回繰り返し、<|im_end|>が生で漏れて終了 |
| 最終(RAGカード投入後) | 6.9秒・finish_reason=stopで23団体を正確に列挙 |
東京都(62団体)・沖縄県(41団体)でも同様に正確・高速な応答を確認済み。
データ処理での落とし穴: 郡名を含む町名・市名が実在する(蒲郡市・小郡市・大和郡山市・上郡町等、「郡」や「市」の字が地名の一部として重複出現)。素朴な正規表現(「郡」の最後の出現でsplit)だと蒲郡市が「蒲郡(市)」のように誤分割される。「市」で終わる名前を先に標準市として確定してから郡判定する、という判定順序で解消した。○文字でという制限に弱いのはOrnith時代にもあった事なのですぐにRAGで解決できました。
8. まとめ — 持ち帰るべき7点
- 12GB×2の予算では、重みとKVは完全なゼロサム。bpwを下げるのは「頭を悪くする」行為ではなく「作業メモリを買う」行為。
- 投機デコード(MTP)は本物の効果があるが、実装のギャップに複数レイヤーで引っかかる。量子化フォーマット(exl3)・推論エンジン(Aphrodite)・エンジンの元(vLLM)それぞれに別々の既知バグが眠っていることがある。1つ直しても次のバグに当たるのは珍しくない。
- VRAM崖は「速度改善」の効果を丸ごと相殺する。設定変更の効果測定は必ずVRAM使用量とセットで見る。崖の存在が疑われる環境では、性能スイープを面倒がらずにやる価値がある。
- VLM(画像入力)は解像度上限を必ず設定する。デフォルトのまま複数画像を許可すると、起動時のメモリプロファイリングが最悪ケースを想定して過大な予約をし、実運用でクラッシュする。
-
--kv-cache-memory-bytesのような「明示指定」オプションは、自動プロファイリングより危険なことがある。手動指定は設定変更への追従性を失い、内部計算のズレでかえってOOMを誘発するケースが2回とも実証された。 - LLMは正確な列挙・カウントが苦手で、自己修正ループに陥る。この弱点は文字数指定に限らず、モデルが正確に知らない事実の列挙全般に及ぶ。対策は「頑張らせる」プロンプトではなく、正確なデータをそのまま渡すRAGが効く。
-
速度は
usage.completion_tokensで測る。ストリームのチャンク数を数えると過小評価しやすい。
測定条件
- ベンチ前に他のリクエストが混ざっていないことを確認(混ざると数値が壊れる)
- 生成長は100〜400トークン程度で統一