fix(llm-serving): num_cpu_blocks=2000 hung pod startup, drop to 32

k8s/apps/llm-serving/reasoning.yaml

@@ -42,16 +42,21 @@ spec:
       # 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 is a starting point sized against the +4Gi/replica
+      # num_cpu_blocks=2000 hung the pod at startup ("Allocating 64 CPU
-      # headroom added below (worker-1 has ~18Gi of request headroom across
+      # tensors..." then nothing -- 64 is this model's layer count, one
-      # both replicas as of 2026-08-19) -- watch actual host memory usage
+      # pinned host tensor per layer, each sized for every CPU block; 2000
-      # and adjust; block_size=128 tokens matches vLLM's own example.
+      # 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":2000,"block_size":128}}
+      - --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: