agent-platform release v4.40.1

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/triton on the runtime container (giantswarm/agent-platform#572). Triton — the compiler behind every @triton.jit kernel a model runs, the GDN and Mamba kernels of the hybrid architectures among them — keeps its compiled kernels and, with vLLM’s default TRITON_CACHE_AUTOTUNING=1, its autotuning results in ~/.triton/cache inside the container, gone with the pod. A preset that compiles had them on the claim already: at compile init vLLM redirects TRITON_CACHE_DIR in-process to a directory under VLLM_CACHE_ROOT’s torch_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 sets TRITON_CACHE_DIR=/mnt/vllm-cache/triton in the same patch as VLLM_CACHE_ROOT: a directory of the claim’s .vllm-cache beside torch_compile_cache/, which Triton creates as the runtime’s uid under the setgid root:1000 2775 directory exactly as vLLM creates torch_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-policies holds 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”.