fix: swap reasoning-predictor to Qwen3.5-35B-A3B GPTQ-Int4 on vLLM 0.17.0 (bnb-4bit decode was too slow on V100)

k8s/apps/llm-serving/reasoning.yaml

@@ -12,57 +12,46 @@ spec:
   predictor:
     containers:
     - args:
-      # DeepSeek-R1-Distill-32B retired: tool_choice="auto" (what pi sends)
-      # hit a documented vLLM/R1-family conflict -- the model narrated fake
-      # tool_calls in its <think> block instead of emitting real ones,
-      # regardless of parser. Tried swapping to a Kimi-distilled Qwen3.6
-      # MoE checkpoint and an AWQ-quantized Qwen3-30B-A3B first -- both
-      # failed on real, separate blockers (unrecognized model_type; then
-      # marlin INT4 kernels needing compute capability 80+, but worker-1's
-      # GPU is sm70/V100). Landed on dense Qwen3-32B instead: native Qwen3
-      # tool-call format (no narration bug), bnb-4bit works fine on sm70
-      # (proven by the old DeepSeek config already), and no MoE
-      # arch/quantization risk this time.
-      - --model=unsloth/Qwen3-32B-bnb-4bit
+      # dense Qwen3-32B-bnb-4bit retired: sm70/V100 bnb dequant kernel is
+      # slow (no int4 tensor cores pre-Turing, dequant-then-fp16-matmul is
+      # two kernel launches not one fused int4 GEMM), decode crawled at
+      # ~2.5-10 tok/s and blew the gateway's request timeout regardless of
+      # TP/PP config. bnb also outright rejects tensor-parallel-size>1 on
+      # prequant checkpoints ("Please try with pipeline parallelism"),
+      # which is why this went through a PP=2 detour first.
+      # Switched to Qwen3.5-35B-A3B (MoE, GDN hybrid attention) GPTQ-Int4.
+      # Requires vLLM >=0.17.0 -- v0.11.0 errors with "Model architectures
+      # ['Qwen3_5MoeForConditionalGeneration'] are not supported for now."
+      # moe_wna16 is the checkpoint's documented quantization kernel;
+      # compute-capability requirement on sm70 is UNVERIFIED going in --
+      # this rollout is the real test. --kv-cache-dtype stays auto, not
+      # fp8_e5m2: V100 has no FP8 tensor cores at all (Hopper/Ada only),
+      # hardware-blocked regardless of vLLM version. tool-call-parser
+      # changed hermes -> qwen3_coder per the checkpoint's own README
+      # example, not cosmetic. gpu-memory-utilization starts low (0.5)
+      # since real VRAM footprint for this arch+quant combo is unknown;
+      # raise once stable. Old OffloadingConnector kv-transfer-config
+      # dropped -- its block-size math was hand-tuned for the previous
+      # model's dense 64-layer/8-head attention and doesn't carry over to
+      # GDN's hybrid KV structure. Re-add once real numbers are known.
+      - --model=Qwen/Qwen3.5-35B-A3B-GPTQ-Int4
       - --served-model-name=reasoning
-      - --quantization=bitsandbytes
+      - --quantization=moe_wna16
       - --dtype=float16
       - --kv-cache-dtype=auto
-      - --tensor-parallel-size=1
-      - --pipeline-parallel-size=2
+      - --tensor-parallel-size=2
       - --max-model-len=16384
-      - --gpu-memory-utilization=0.90
+      - --gpu-memory-utilization=0.5
       - --max-num-seqs=4
       - --enable-chunked-prefill
       - --enable-prefix-caching
       # qwen3 is vLLM's dedicated reasoning parser for this family's <think>
-      # blocks.
+      # blocks, also documented for Qwen3.5.
       - --reasoning-parser=qwen3
-      # hermes is the documented tool-call parser for general (non-Coder)
-      # Qwen3 models -- native chat template support, not narrated text.
+      # qwen3_coder is the checkpoint README's documented tool-call parser
+      # for this specific GPTQ-Int4 release -- not hermes.
       - --enable-auto-tool-choice
-      - --tool-call-parser=hermes
-      # vLLM 0.11.0's native OffloadingConnector -- spills KV cache blocks
-      # to CPU DRAM instead of discarding them on preemption (max-num-seqs=4
-      # + max-model-len=16384 means concurrent long sequences compete for
-      # the same GPU KV space). No extra dependency, built into vLLM core.
-      # num_cpu_blocks=2000 hung the pod at startup on the old model (2000 x
-      # ~32MB/block blew well past the pod's memory limit). num_cpu_blocks=32
-      # was the safe-recovery value after that -- only ~1GB of real DRAM
-      # (32 blocks x 128 tokens x 256KB/token-across-all-64-layers, fp16),
-      # basically a token-count safety valve, not real offload capacity.
-      # This model: 64 layers, 8 KV heads x 128 head_dim, fp16 -> ~256KB of
-      # KV per token across all layers -> ~32MB per 128-token block.
-      # num_cpu_blocks=256 -> ~8GB of actual DRAM offload (32,768 tokens),
-      # comfortably under the pod's 36Gi limit alongside the ~20GB bnb-4bit
-      # weights. Watch real host memory on boot before raising further --
-      # block_size=128 tokens matches vLLM's own example.
-      # Note: 0.11.0 ships the original (fragmented, small-transfer-block)
-      # version of this connector -- 0.12.0 consolidates KV data into one
-      # contiguous block per request and is reported an order of magnitude
-      # faster for this specific feature, so this is a real but not yet
-      # optimal implementation until the image gets bumped.
-      - --kv-transfer-config={"kv_connector":"OffloadingConnector","kv_role":"kv_both","kv_connector_extra_config":{"num_cpu_blocks":256,"block_size":128}}
+      - --tool-call-parser=qwen3_coder
       - --host=0.0.0.0
       - --port=8080
       env:
@@ -72,7 +61,7 @@ spec:
         value: TRITON_ATTN
       - name: HF_HOME
         value: /mnt/models
-      image: vllm/vllm-openai:v0.11.0@sha256:014a95f21c9edf6abe0aea6b07353f96baa4ec291c427bb1176dc7c93a85845c
+      image: vllm/vllm-openai:v0.17.0@sha256:2296a2a7e1ce1dc59c6577ba5900f4e9910b76c4a0cb134833a8137f92404dfa
       name: kserve-container
       ports:
       - containerPort: 8080