reasoning: swap DeepSeek-R1-Distill-32B for Kimi-K2.6-distilled Qwen3.6-35B-A3B

R1-family tool_choice=auto is a documented vLLM architecture conflict --
the model narrates fake tool_calls in <think> instead of emitting real
ones, regardless of parser (deepseek_v3 400s, hermes parses but the model
still doesn't call out). Qwen3's native tool-call format sidesteps this.

No pre-quantized AWQ/GPTQ/bnb checkpoint exists for this specific distill
(only GGUF, llama.cpp/Ollama-only) -- using on-the-fly bitsandbytes
quantization against the full bf16 checkpoint instead.

k8s/apps/llm-serving/reasoning.yaml

@@ -12,10 +12,30 @@ spec:
   predictor:
     containers:
     - args:
-      - --model=unsloth/DeepSeek-R1-Distill-Qwen-32B-bnb-4bit
+      # Swapped off DeepSeek-R1-Distill-Qwen-32B: tool_choice="auto" (what pi
+      # sends) hit a documented vLLM architecture conflict for R1-family
+      # models -- the model narrated fake tool-call completions in its
+      # <think> block instead of emitting real tool_calls, regardless of
+      # parser combo tried (deepseek_v3 400s outright, hermes parsed but the
+      # model itself never called out to the real tool-call path). Root
+      # cause is upstream in the R1 distillation, not this config -- moving
+      # to a Qwen3-family model with a Kimi-K2.6 reasoning distillation
+      # instead, since Qwen3's own tool-call format is natively supported.
+      #
+      # No pre-quantized AWQ/GPTQ/bnb checkpoint exists for this specific
+      # distilled model (only a GGUF, which is llama.cpp/Ollama-only and not
+      # usable here) -- pointing --quantization=bitsandbytes at the full
+      # bf16 checkpoint directly, which makes vLLM quantize on load instead
+      # of requiring a pre-quantized repo. This on-the-fly bnb path is
+      # well-trodden for dense models but less battle-tested for MoE
+      # (this model is 35B total / ~3B active) -- watch first boot closely;
+      # if it OOMs or errors on the MoE expert weights, that's the likely
+      # cause.
+      - --model=lordx64/Qwen3.6-35B-A3B-Kimi-K2.6-Reasoning-Distilled
       - --served-model-name=reasoning
       - --quantization=bitsandbytes
-      - --dtype=float16
+      - --trust-remote-code
+      - --dtype=bfloat16
       - --kv-cache-dtype=auto
       - --tensor-parallel-size=1
       - --max-model-len=16384
@@ -23,19 +43,15 @@ spec:
       - --max-num-seqs=4
       - --enable-chunked-prefill
       - --enable-prefix-caching
-      - --reasoning-parser=deepseek_r1
+      # qwen3 parser handles this family's <think> reasoning blocks (best
-      # Without these, any client sending tool_choice="auto" (pi does, for
+      # match for this architecture; unverified against this exact
-      # Read/Bash/etc.) gets a 400: "auto" tool choice requires
+      # checkpoint -- if it 400s or fails to strip <think> tags, that's the
-      # --enable-auto-tool-choice and --tool-call-parser to be set.
+      # first thing to check).
-      # deepseek_v3 (matching --reasoning-parser above) 400s here --
+      - --reasoning-parser=qwen3
-      # "DeepSeek-V3 Tool parser could not locate tool call start/end
+      # hermes previously verified (on the old model) to work against a
-      # tokens in the tokenizer" -- this checkpoint is a Qwen2.5-32B base
+      # Qwen tokenizer's plain-text tool-call patterns without needing
-      # distilled on R1 traces, so its tokenizer never got DeepSeek-V3's
+      # special tokens; Qwen3's native tool-call format is also
-      # own special tool-call tokens registered even though it kept R1's
+      # hermes-style, so kept as-is.
-      # <think> reasoning format. hermes parses tool calls from plain text
-      # patterns instead of special tokens, so it works against the
-      # underlying Qwen tokenizer regardless. Verified live: deepseek_v3
-      # 400s, hermes returns a real tool_calls response.
       - --enable-auto-tool-choice
       - --tool-call-parser=hermes
       # vLLM 0.11.0's native OffloadingConnector -- spills KV cache blocks