Files
homelab/k8s/apps/llm-serving/reasoning.yaml
T

115 lines
4.3 KiB
YAML

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:
- --model=unsloth/DeepSeek-R1-Distill-Qwen-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
- --reasoning-parser=deepseek_r1
# Without these, any client sending tool_choice="auto" (pi does, for
# Read/Bash/etc.) gets a 400: "auto" tool choice requires
# --enable-auto-tool-choice and --tool-call-parser to be set.
# deepseek_v3 (matching --reasoning-parser above) 400s here --
# "DeepSeek-V3 Tool parser could not locate tool call start/end
# tokens in the tokenizer" -- this checkpoint is a Qwen2.5-32B base
# distilled on R1 traces, so its tokenizer never got DeepSeek-V3's
# own special tool-call tokens registered even though it kept R1's
# <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
# 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 ("Allocating 64 CPU
# tensors..." then nothing -- 64 is this model's layer count, one
# pinned host tensor per layer, each sized for every CPU block; 2000
# was oversized enough to stall pinning that much host memory, likely
# blowing well past the pod's memory limit). Dropped to a small,
# known-safe starting point -- confirm it actually comes up healthy,
# then watch real host memory usage and raise it deliberately rather
# than guessing a round number again. 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":32,"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