Fixed
- Triton’s kernel cache lives on the cache claim beside vLLM’s compiled graphs: the redirect rule sets
TRITON_CACHE_DIR=/mnt/vllm-cache/tritonon the runtime container (giantswarm/agent-platform#572). Triton — the compiler behind every@triton.jitkernel a model runs, the GDN and Mamba kernels of the hybrid architectures among them — keeps its compiled kernels and, with vLLM’s defaultTRITON_CACHE_AUTOTUNING=1, its autotuning results in~/.triton/cacheinside the container, gone with the pod. A preset that compiles had them on the claim already: at compile init vLLM redirectsTRITON_CACHE_DIRin-process to a directory underVLLM_CACHE_ROOT’storch_compile_cache/. A preset that serves--enforce-eager— six of the shipped ones — never compiles, so that redirect never ran and every pod recompiled and re-autotuned its kernels during the profiling run. The redirect rule now setsTRITON_CACHE_DIR=/mnt/vllm-cache/tritonin the same patch asVLLM_CACHE_ROOT: a directory of the claim’s.vllm-cachebesidetorch_compile_cache/, which Triton creates as the runtime’s uid under the setgidroot:1000 2775directory exactly as vLLM createstorch_compile_cache/; a compiled preset is unchanged (vLLM’s redirect takes over at compile init, the env is the floor for what Triton compiles before it), and a pod without the cache keeps Triton’s default as it keeps vLLM’s.make verify-model-serving-policiesholds both envs on the runtime container of both shapes, both under the cache mount, and neither on a pod without the cache. README “vLLM’s compile cache and Triton’s kernel cache on the claim”.