リリース

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 キャッシュの部分だけです。モデルの重みや、長い文脈の状態を保持する層の精度は変えていません。

切り替え前に、次の内容を自社で確認しました。

いずれも自社の限られたテストで、すべての用途で品質が同一であることを保証するものではありません。長い入力で以前と違う応答を感じた場合は、FAQ に記載のサポート窓口までお知らせください。設定を元に戻せる形で運用しています。

今回変わらないもの

今回の変更は「長い入力どうしが同時に走れるようになる」ものです。次の点はこれまでどおりで、今回の対象外です。

同時実行枠の考え方とプランごとの差はこれまでの告知のとおりで、今回その関係は変えていません。

変わらないもの

注意点

単価とモデル一覧は料金ページ、モデル ID とセットアップ手順はドキュメントに掲載しています。

← 新着情報一覧へ

今日から、baseURL を差し替えるだけ。

コンソールを開く