はじめに

TabbyAPI(exllamav3)でQwen3.6系のEXL3量子化モデルを個人運用していたが、OpenWebUI + Hermes(自作エージェント)の同時利用でリクエストが直列処理になってしまう問題があった。Continuous Batchingを持つSonar(Aphrodite Engine、vLLMのフォーク)への移行を検証したところ、EXL3量子化とQwen3.6系のハイブリッドMamba/GDNアーキテクチャの組み合わせで、upstreamに未報告の実バグを2つ踏んだ。原因を特定してローカルパッチを当て、最終的にPRとして提出した。

その後の副産物として、新しく見つけた9BモデルであるOrnith-1.0-9Bを同じ環境で動かしたところ、27Bモデルを速度・精度・コンテキスト長のすべてで上回るという結果になったので、それも含めて書く。

環境: WSL2 Ubuntu, RTX 5070 ×2 (12GB×2)

発見した2つの実バグ

Aphrodite-engine 0.21.0はEXL3量子化に対応しているが、Qwen3.6/Qwen3.5系のハイブリッドMamba/GDNアーキテクチャ(大半の層がlinear_attention、4層に1層だけfull_attention) + LoRA有効時の組み合わせでバグを踏んだ。

バグ1: EXL3の`in_proj_qkv`層のshard_id不一致

症状: --enable-lora指定時、以下のエラーで起動失敗。

ValueError: Missing EXL3 tensors for ...in_proj_qkv: suh[0], suh[1], suh[2], ...

原因: aphrodite/model_executor/models/qwen3_5.pyのload_weights()は、LoRA有効時にGDN層のin_proj_qkvの重みをタプル(0, 1, 2)という単一キーでロードする：

if self.enable_lora:
    stacked_params_mapping.extend([
        ("in_proj_qkv", "in_proj_qkv", (0, 1, 2)),  # ← タプル1個で1回だけ呼ばれる
        ("in_proj_z", "in_proj_z", 0),
    ])

しかしaphrodite/model_executor/layers/quantization/exl3.pyの_shard_ids_for_layer()には、LoRA無効時の統合レイヤー名in_proj_qkvz向けの分岐しかなく、LoRA有効時の単体レイヤー名in_proj_qkv向けの分岐が存在しなかった。そのため汎用フォールバックに落ちて[0, 1, 2]という3つの別々の整数キーを期待してしまい、実際にロードされたタプルキー(0, 1, 2)と一致しない。

exllamav3自体のアーキテクチャ定義(architecture/qwen3_5.py)を確認したところ、GDN層のqkv投影は常にq+k+vを1つの融合trellis行列として量子化する仕様であり、LoRAの有無に関わらず一貫していることを確認した。

修正(1行追加):

# aphrodite/model_executor/layers/quantization/exl3.py
if prefix.endswith("in_proj_qkv"):
    return [(0, 1, 2)]

バグ2: LoRAレイヤーのデバイス判定がEXL3を認識しない

症状:

ValueError: Unsupported base layer: MergedColumnParallelLinear(...)

原因: aphrodite/lora/layers/utils.pyの_get_lora_device()は、量子化方式ごとに決め打ちの属性名(weight, weight_packed, qweight, w2_weight等)でデバイスを判定していたが、EXL3の属性名(suh/svh/trellis/mcg/mul1)がリストに無かった。EXL3+LoRAの組み合わせがAphrodite全体として一度も配線されていなかったことを意味する。

修正:

elif hasattr(base_layer, "trellis"):
    return torch.device("cuda", torch.cuda.current_device())

EXL3はCUDA専用実装のため、常にcurrent_deviceで問題ない。

環境要因: WSL2でのlibcuda.soリンクエラー

flashinferのJITビルド時にcannot find -lcuda。/usr/local/cudaがconda-forge由来のCUDAツールキットを指すシンボリックリンクになっており、そちらのdevスタブは非標準レイアウトだったため、PyTorchが期待する$CUDA_HOME/lib64/stubs/libcuda.soが見つからなかった。専用の独立スタブディレクトリを作成しLIBRARY_PATHに追加することで、既存環境に触れずに解決した。

upstreamへの還元

発見した2つのバグはdphnAI/sonar(Aphrodite-engine)にPRとして提出済み:

PR #1711 — EXL3 in_proj_qkv shard_id不一致の修正
PR #1712 — LoRAデバイス判定にEXL3を追加

ベンチマーク: Qwen3.6-27B-exl3-3.08bpw

TP=2, KVキャッシュFP8, gpu-memory-utilization=0.88
LoRA無し(有効時はメモリ予算がさらに厳しくなるため今回は見送り)

CUDAグラフ有効化の効果

--enforce-eager(CUDAグラフ無効)で動かすと速度が出なかったので通常モードに切り替えた。

並列数	eagerモード(合計t/s)	CUDAグラフ有効(合計t/s)
1	11.23	32.62
2	20.39	60.32
3	32.28	85.60
4	44.88	99.81
5	56.06	125.68
6	64.81	146.67

単発速度は約2.9倍、6並列合計では約2.3倍に向上。トレードオフとしてCUDAグラフ用バッファの分だけKVキャッシュプールが減少する(eagerモード143,360トークン → CUDAグラフ有効111,177トークン)。

精度検証

基本問題8問(算数・事実確認・指示追従等)は8/8正解。長文コンテキストのneedle-in-haystackテストでは、45,917トークン先に埋め込んだ秘密コードも正確に抽出できた。ハイブリッドMamba/GDNアーキテクチャ(大半がlinear_attention)でも長距離検索が機能することの実証になった。

最終構成(N=1〜8スケーリング)

max-model-len=81920, max-num-seqs=8, max-num-batched-tokens=4096(理由は後述)

並列数	合計t/s
1	31.92
4	117.24
8	194.11

Chunked Prefillのチャンクサイズ(`--max-num-batched-tokens`)実験

Continuous Batchingではchunked prefillがデフォルトで有効になっている。1人が数万トークンの巨大リクエストを送りながら、他5人が短いリクエストを同時に送る、という混在ワークロードで、チャンクサイズによる「公平性」と「総スループット」のトレードオフを実測した。

Qwen3.6-27Bでの結果

chunk size	完了時刻の幅(公平性)	全体完了(総スループット)
256	約60.9秒(最悪)	72.1秒(最遅)
512	約0.95秒	59.2秒
2048(デフォルト)	約5.48秒	51.1秒
4096	約0.89秒(最良)	52.7秒(僅差2位)

256まで小さくすると、公平性・速度の両方が悪化する「行き過ぎ」領域に入る。4096がバランス最良と判断し、最終構成に採用した。

新モデル発見: Ornith-1.0-9B、同一アーキテクチャで27Bを圧倒

作業の途中で、DeepReinforce AIが公開したOrnith-1.0というエージェント型コーディング特化モデルファミリーを見つけた(9B Dense / 31B Dense / 35B MoE / 397B MoEの4サイズ、MITライセンス)。35B版はQwen3.5-35B-A3Bをベースにした、まさに今回格闘していたのと同じハイブリッドMamba/GDN(linear_attention + full_attention)構成。9B版もQwen3_5アーキテクチャ(GDNハイブリッド、MoEではなくdense)で、既存パッチがそのまま使えた。

コミュニティが公開しているEXL3 6bpw量子化版(AnuAmba/Ornith-9B-6bpw-exl3)を使い、同じSonar環境で動かして27Bと対決させた。

VRAM効率とコンテキスト長

	Qwen3.6-27B(3.08bpw)	Ornith-9B(6bpw)
重みサイズ(1GPUあたり)	6.63 GiB	4.42 GiB
KVプール(max-num-seqs=8時)	111,177トークン	508,713トークン
実用可能な最大コンテキスト	81,920トークン(concurrency 1.36〜1.75x)	モデルのネイティブ最大長262,144トークンをそのまま、しかもconcurrency 2.00x

9Bはパラメータ数こそ少ないが6bpwという緩めの量子化のおかげで重みが軽く、モデルの謳い文句である256Kコンテキストを妥協なく、しかも2人同時利用分の余裕付きで確保できた。

速度・精度対決(同一プロンプト、同一トークン予算)

ここでの「切れた」は、max_tokensを各タスクごとに固定した予算(finish_reason: lengthでAPIが打ち切り)で、reasoningモデルなので思考(<think>...</think>)もこのmax_tokensの中に含まれることが原因。予算はタスクの難易度に応じて600〜800トークンとやや厳しめに設定しており(FizzBuzz生成600、二分探索デバッグ800、エージェント計画立案800、多段階計算600)、27Bは思考が長くなりがちで、この予算内に本文(思考後の実回答)を書き始める前に打ち切りが来てしまうケースが多かった。

テスト	max_tokens	27B	9B
FizzBuzzコード生成	600	❌ 途中で構文が切れて壊れたコード(15.6s)	✅ 完走、正しいコード(4.5s)
二分探索デバッグ	800	❌ 思考の途中で予算切れ、回答なし(20.4s)	❌ 同じく予算切れ、回答なし(8.4s)
エージェント計画立案	800	❌ 思考の途中で予算切れ、回答なし(20.4s)	⚠️ 思考は予算内に完了、回答本文の途中で切れる(8.4s)
多段階計算	600	❌ 思考の途中で予算切れ、実質未回答(15.3s)	✅ 完走、正解(6.1s)

驚いたのは速度差(2〜3倍)以上に、**同じトークン予算(600〜800)で27Bは4問中3問が「思考だけで予算を使い切り、実際の回答本文を一度も出力しないままfinish_reason: lengthで打ち切られる」**という結果だったこと(</think>タグが一度も出現していない=ユーザーに渡る本文が空)。9Bは同じ予算でもずっと簡潔に考えて、本文に到達する余裕を残していた。モデルの大きさよりも「思考の冗長さ」がトークン予算内で答えに到達できるかを直接左右する、という実例になった。実運用でこの手の「思考だけで力尽きる」事故を避けるには、reasoningモデルには余裕を持ったmax_tokensを設定するか(前述の通り本番では実質無制限にしている)、思考トークン自体を短くするようプロンプト側で指示する必要がある。

チャンクサイズ実験の再現性

同じchunked prefillのチャンクサイズ実験を9Bでもやり直したところ、27Bと全く同じ傾向(4096が最良)が、より極端な形で再現された。

chunk size	完了時刻の幅	全体完了
256	24.29秒(最悪)	29.66秒
512	17.94秒	25.38秒
2048	1.10秒	21.84秒
4096	0.21秒(最良)	18.47秒(最速)
8192	0.73秒	21.08秒

4096を頂点にした綺麗な山型で、小さすぎても大きすぎても悪化する。「4096が最適」という結論はモデルサイズに関わらず一貫していた。

実際に何ユーザーまで同時処理できるか(N=1〜300)

Ornith-9Bは256Kコンテキストが使えることが分かったので、最終的に「1人あたりの上限は256Kフルで、同時ユーザー数はどこまで許容できるか」を実測した。短めのプロンプトを使い、並列数Nを1→300まで段階的に増やしながらエラーの有無とスループットを見た。

並列数	合計tok/s	状態
1	54.21
8	417.39
16	779.58
32	959.02
64	1096.49	ピーク付近
96	1006.46
128	1063.43	頭打ち
192	1061.84	頭打ち
256	1060.70	頭打ち
300	1064.37	エラーなし

結果として、300並列でも一度もエラーは出なかった。--max-num-seqsの自動デフォルト値(256)を超えても、リクエストは拒否されずキューに積まれて順番に処理されるだけだった。つまり「壊れる上限」という形の答えは今回の範囲では存在しない。

その代わり、N=64付近でGPU計算能力が飽和し、それ以降は合計スループットが1000〜1100 tok/sで頭打ちになることが分かった。実用上の「ユーザー数制限」は、エラーになる人数ではなく「1人あたりの体感速度が落ち始める人数」で考えるべき、という結論になった。

最終本番構成

以上を踏まえて、Ornith-9Bの最終構成を次のように決定した:

aphrodite run /home/cadsv/exl3_served/Ornith-9B-6bpw-exl3 \
  --tensor-parallel-size 2 \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.88 \
  --max-model-len 262144 \
  --max-num-seqs 64 \
  --max-num-batched-tokens 4096 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

max-model-len=262144: モデルのネイティブ最大長をそのまま採用。KVプールに十分な余裕がある(481,637トークン、concurrency 1.84x)ため妥協不要と判断
max-num-seqs=64: スループットが飽和するN=64を採用。「壊れる上限」ではなく「体感速度を維持できる同時ユーザー数の目安」としての設定
max_tokensはクライアント側で意図的に絞らない限り実質無制限として運用。ただし生成は当然KVキャッシュの制約を受けるので、プロンプト分を差し引いた残りコンテキスト(最大262,144トークン)を使い切ったところで打ち切られる。「無制限にすれば256Kを使い切るまで生成できる」というのがこの設定の意味になる

まとめ

EXL3 + Qwen3.6/3.5ハイブリッドMamba/GDN + Aphrodite-engineの組み合わせは、2箇所のローカルパッチで動作した(upstream未報告バグ、PR提出済み)
チャンクサイズ(--max-num-batched-tokens)は大きければ良いわけでも小さければ良いわけでもなく、今回の環境・ワークロードでは4096が明確な最適点だった。モデルサイズが変わっても同じ傾向が再現されたのは興味深い
パラメータ数だけでモデルを比較するのは危険で、量子化の緩さ・VRAM効率・思考の簡潔さまで含めて評価する必要がある。今回は9Bが27Bを速度・精度・コンテキスト長すべてで上回った
2×12GBという決して大きくないVRAM構成でも、量子化とチューニング次第で256Kコンテキストの実用運用まで到達できた