apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: annotations: serving.kserve.io/deploymentMode: RawDeployment labels: app.kubernetes.io/name: llm-reasoning app.kubernetes.io/part-of: llm-serving name: reasoning namespace: llm-serving 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 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 - --served-model-name=reasoning - --quantization=bitsandbytes - --dtype=float16 - --kv-cache-dtype=auto - --tensor-parallel-size=1 - --max-model-len=16384 - --gpu-memory-utilization=0.90 - --max-num-seqs=4 - --enable-chunked-prefill - --enable-prefix-caching # qwen3 is vLLM's dedicated reasoning parser for this family's # blocks. - --reasoning-parser=qwen3 # hermes is the documented tool-call parser for general (non-Coder) # Qwen3 models -- native chat template support, not narrated text. - --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}} - --host=0.0.0.0 - --port=8080 env: - name: VLLM_USE_FLASHINFER_SAMPLER value: '0' - name: VLLM_ATTENTION_BACKEND value: TRITON_ATTN - name: HF_HOME value: /mnt/models image: vllm/vllm-openai:v0.11.0@sha256:014a95f21c9edf6abe0aea6b07353f96baa4ec291c427bb1176dc7c93a85845c name: kserve-container ports: - containerPort: 8080 protocol: TCP readinessProbe: httpGet: path: /health port: 8080 periodSeconds: 10 resources: limits: cpu: '16' memory: 36Gi nvidia.com/gpu: '1' requests: cpu: '8' memory: 12Gi nvidia.com/gpu: '1' startupProbe: failureThreshold: 80 httpGet: path: /health port: 8080 periodSeconds: 15 volumeMounts: - mountPath: /mnt/models name: models - mountPath: /dev/shm name: shm deploymentStrategy: type: Recreate maxReplicas: 2 minReplicas: 2 nodeSelector: kubernetes.io/hostname: worker-1 runtimeClassName: nvidia volumes: - name: models persistentVolumeClaim: claimName: llm-models - emptyDir: medium: Memory sizeLimit: 2Gi name: shm