gemma-4-31b serves 8k context on the 48 GB card — vLLM needs 9.5 GiB of KV cache for 32k next to 31.7 GiB of weights and has 7.3, and named 8640 tokens as the ceiling; 32k returns with an fp8 KV cache once that is proven on the L40S (#591).gemma-4-31b serves 32k context and qwen3-6-35b-a3b 16k on the 48 GB card — the 64k the first shipped with needs 12 GiB of KV cache next to 31.7 GiB of weights and vLLM refused to start (estimated maximum model length is 8624); the fit check passed it (giantswarm/model-manager#149) (#591).Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.47.1...v4.48.0
USER, LOGNAME and TORCHINDUCTOR_CACHE_DIR — the predictor runs as the modelcar uid, which the runtime image’s passwd does not know, and vLLM’s import died in torch’s inductor cache-dir lookup (getpwuid(1010)) on every one of the new presets (#591).forwardToken server registered while its backend did not serve the path yet – a rollout in progress, the previous pod answering 404 – failed its registration probe with server returned 4xx for initialize POST, likely a legacy SSE server, read Failed and was never re-probed: the answer was not classified as a connection failure, so no retry was scheduled, and the sessions connecting later with their own token do not touch the CR’s state. The server stayed Failed (and MusterMCPServerFailed fired after 20 minutes) although the backend had been serving the path since seconds after the registration. Such an answer now enters the reconnect schedule like a refused connection or a 5xx: retried with the same backoff, the MCPServerFailed event and status.lastFailureHTTPStatus naming the status mcp-go dropped (endpoint answered HTTP 404, next retry in 30s at ...), and the server settles on its own once the path answers – in Auth Required for a server connected per session, Connected otherwise. The state rules of a per-session server (Failed only while the endpoint does not answer, Auth Required until the first session connects, Connected from then on, a later session’s failure never the server’s state) are documented in the CRD reference. (#1295)Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.46.0...v4.47.0
qwen3-8-27b-l40s serves NVIDIA’s own Qwen3.8-27B-NVFP4 checkpoint from its signed model image (giantswarm/agent-platform#591): nvidia/Qwen3.8-27B-NVFP4 (20.4 GiB — NVFP4 on the MLPs and the language-model head, FP8 on the attention layers) replaces the Inferact repack’s hf:// source; the preset gains the model-image environment (HOME, HF_HOME and VLLM_CACHE_ROOT under /tmp) and declares 21 + 20 GiB. Parsers, the thinking-off default and the 64k context are unchanged; qwen3-8-27b, the Blackwell recipe, still serves the Inferact repack.qwen3-5-27b, qwen3-coder-next and qwen3-5-35b-a3b (giantswarm/agent-platform#591): 54 GiB BF16, 80 GiB FP8 and 70 GiB BF16 of weights exceed the 48 GB GPU they would target; the presets above are their model-image successors of the same shape. The shipped set goes from twelve to eleven presets; tests/verify-gpu-pool.py leaves each side’s own presets out of the golden comparison until the golden carries this change.muster agent --mcp-server and the REPL wait for a slow tool. The CLI’s MCP client bounded every request at 30 s, tool calls included, while a tool behind the aggregator may legitimately take longer – an MCPServer’s spec.timeout allows up to 300 s – so a tool that answered after a minute succeeded through the aggregator and failed through the bridge with transport error: ... context deadline exceeded after exactly 30 s; muster agent --timeout was bound to nothing. A tool call now runs under a timeout of its own, five minutes by default (the aggregator’s largest tool timeout), for the bridge, the REPL’s call and every CLI command that calls a tool (muster call among them); the handshake, listings, resources and prompts keep their 30 s. muster agent --timeout sets the call timeout for the REPL and the bridge, and the bridge’s call_tool takes an optional timeout argument (seconds) that bounds one call in its place – for a client that knows a read takes longer; the argument is the bridge’s own and never reaches the aggregator. (#1293)<account>.blob.core.windows.net), not to a dedicated data endpoint: with 4.44.3’s allow-list Kyverno’s admission controller got past DNS and the registry and stopped at failed to fetch referrer layer: Get "https://<account>.blob.core.windows.net/…", every model pod still denied. modelServing.imageVerification.kyvernoEgress.hosts defaults to *.blob.core.windows.net in place of *.*.data.azurecr.io (a registry with dedicated data endpoints names that pattern itself), mirrored in both charts; make verify-model-serving-policies holds the default list.qwen3-4b-instruct, qwen3-8b-fp8 and qwen3-14b (giantswarm/agent-platform#591). They pinned 2025 checkpoints whose successors are smaller or stronger under the same licence and are replaced by the 24 GB line-up above (qwen3-5-4b for the 4B, qwen3-5-9b-fp8 or gemma-4-12b for the 8B, gpt-oss-20b or gemma-4-12b for the 14B — which, at 28 GiB of BF16 weights, never fit a 24 GB card and was tuned for a 128 GB node). The upgrade removes their ConfigMaps; a model already served from one keeps serving (the LLMInferenceService is model-manager’s object), and an installation that wants one back carries its file under modelServing.presets (UPGRADE.md).