qwen3.8-27b-uncensored の長い入力の順番待ちを減らしました
qwen3.8-27b-uncensored の推論基盤で、KV キャッシュの収容量を約 2.3 倍に広げました。モデル ID・エンドポイント・単価・コンテキスト長はいずれも変わりません。リクエスト側の変更も不要です。
「長い会話履歴を渡すと、応答が返り始めるまでが長い」というご意見をいただいていました。調べたところ、GPU の計算能力が足りないのではなく、長い入力どうしが同じ GPU の中で順番待ちになっていました。 今回はその詰まりを解消する変更です。
何が起きていたか
推論中のモデルは、入力の全トークンの中間状態(KV キャッシュ)を GPU メモリに置きます。長い入力ほどこの領域を多く使い、空きが足りないと次のリクエストは前の 1 本が終わるまで待ちます。
長い入力を受けている GPU では、この領域が約 26.8 万トークンしかありませんでした。11 万トークンの入力が 1 本走っていると、次に来た 20 万トークン級の入力が入りきりません。同時に 4 本処理できる設計なのに、実際には 1 本しか走れない時間帯がありました。直近 6 時間の内部ログでは、生成中の記録の 11% で後続のリクエストが順番待ちになっていました。
その待ち時間が、そのまま応答開始まで(TTFT)に乗っていました。
収容量を約 26.8 万 → 約 60.7 万トークンに
KV キャッシュの GPU メモリへの配分を見直し、1 トークンあたりの保持形式も圧縮して、同じ GPU メモリで約 2.3 倍のトークンを収容できるようにしました。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| KV キャッシュの収容量 | 約 26.8 万 tok | 約 60.7 万 tok |
| 14.4 万 tok の入力 × 3 本同時 | 入らない | 3 本同時に処理 |
| 20 万 tok 級の入力 × 2 本同時 | 入らない | 2 本同時に処理 |
| 単価 | 入力 ¥70 / 出力 ¥480 | 据え置き |
| コンテキスト | 256K(262,144)tok | 据え置き |
自社実測で、14.4 万トークンの入力 3 本、および 20 万トークン級の入力 2 本が、それぞれ順番待ちなしに同時に処理されることを確認しています。長い入力のリクエストが同じ GPU で前の 1 本を待つ状況は解消しました。
応答の品質は確認しています
保持形式を圧縮したのは、注意機構が参照する KV キャッシュの部分だけです。モデルの重みや、長い文脈の状態を保持する層の精度は変えていません。
切り替え前に、次の内容を自社で確認しました。
- 4.6 万 / 18.4 万 / 24.2 万トークンの文書に埋めた情報を取り出すテストで、それぞれ 3 問中 3 問に正答
- 14.4 万トークンの入力を 3 本同時に流した状態でも、全問正答
- 18.4 万トークンの文書から複数の人物情報を突き合わせて答える推論で、5 問中 5 問に正答
- 生成速度(トークン/秒)とプロンプト処理速度は変更前と同等
いずれも自社の限られたテストで、すべての用途で品質が同一であることを保証するものではありません。長い入力で以前と違う応答を感じた場合は、FAQ に記載のサポート窓口までお知らせください。設定を元に戻せる形で運用しています。
今回変わらないもの
今回の変更は「長い入力どうしが同時に走れるようになる」ものです。次の点はこれまでどおりで、今回の対象外です。
- 1 回のリクエストの生成速度(トークン/秒)は上がりません
- 長い入力のプロンプト処理時間そのものは短くなりません。10 万トークンを渡せば、その処理には引き続き数十秒かかります
- 推論基盤の一部の GPU は今回の対象外で、そちらに振られたリクエストの挙動は変わりません
- 利用者全体のリクエストが設備を使い切っている時間帯は、引き続きプランごとの同時実行枠で順番待ちになります
同時実行枠の考え方とプランごとの差はこれまでの告知のとおりで、今回その関係は変えていません。
変わらないもの
- モデル ID・エンドポイント・API キーはそのままです
- 全モデルの公開単価に変更はありません。入力 ¥70 / 出力 ¥480(1M tok・税込表示)のままです
- コンテキスト長・対応パラメータ・画像入力の扱いに変更はありません
- HAI Go / HAI Go Plus の対象モデル・月額・利用枠に変更はありません
- 過去のリクエスト・ご利用明細への影響はありません
- 旧 ID
qwen3.6-35b-a3b-uncensoredの読み替えはこれまでどおり有効です
注意点
- 混雑時に順番待ちが発生する可能性そのものは残ります。 今回解消したのは GPU 内部での長い入力どうしの詰まりで、「優先処理」や「待たされない」をお約束するものではありません
- 順番待ちの上限はストリーミングのほうが長いため、エージェント用途では
stream: trueを推奨します(詳細) - 同じ内容で始まるプロンプトを送り直す場合はプレフィックスキャッシュが効きます。可変の情報は末尾に寄せてください
- 設備の構成は今後も混雑状況に応じて調整します