Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.5.1...v0.5.2
requirements.residentWeightsGiB: the weights a runtime holds in memory when it keeps part of the checkpoint on disk (giantswarm/model-manager#240). It is optional, at most weightsGiB (the render fails above it) and defaults to weightsGiB. On a unified-memory node, model-manager’s fit check needs the --gpu-memory-utilization claim to hold the resident weights plus overheadGiB. qwen3-8-flash-next-nvfp4 declares 74 GiB resident (the n-gram table is read from disk), so 74 + 20 GiB fit within its 0.80 claim. nemotron-3-super-nvfp4 declares 12 GiB of overhead instead of 30, so 75 + 12 GiB fit within its 0.72 claim: the CUDA-graph pool already counts inside the claim.docs/model-serving-image-pulls.md: the runtime’s download at boot and where a cold node’s time goes (giantswarm/agent-platform#812). A GPU pool node created by cluster-manager (0.26.0) on gpu-node-pool 0.8.0 fetches the pre-pull’s images (modelServing.prepull.images) into containerd while it joins, so the pre-pull, gated on the GPU, only unpacks. On a cold g6.xlarge node Ready → predictor Ready went from 471–482 s to 419–437 s. The page records the variants measured: unpacking at boot as well slows the GPU operator’s and the node’s DaemonSet pulls and is slower overall. What remains is the unpack of the 15 GB runtime.Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.43...v1.0.0
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.114.0...v4.114.1
ingress.mode: agentgateway-muster, components.agentgateway.enabled: true and agent-platform-mcps.agentgateway.viaMuster: true in both charts (was muster-direct, off, false) (giantswarm/agent-platform#252). The topology the platform is developed, demonstrated and documented against is now what a plain install gets: MCP traffic on /mcp goes through the agentgateway data plane to muster, while OAuth discovery and everything else stays on muster’s / route. Installations that set the three keys explicitly are unchanged. A release without muster (a serving or runtime slice) has no ingress topology and renders no data plane whatever the mode; a slice beside the platform’s release sets components.agentgateway.enabled: false, as the slice examples do. muster-direct and agentgateway-direct are deprecated; removing them is a later major release.modelServing.prepull.images defaults to gsoci.azurecr.io/giantswarm/storage-initializer:v0.21.0, then gsoci.azurecr.io/giantswarm/llm-d-fast/llm-d-cuda:v0.8.0, in both charts. The predictor’s storage-initializer downloads the weights, so its pull is on the critical path. Beside the 6.6 GB runtime pull its 96 MB took 72–86 s on a g6.xlarge or g6.2xlarge and 46–62 s on larger sizes, alone 5–12 s. The pre-pull’s init containers run in order, so the small image now lands first and the kubelet de-duplicates the predictor’s pull of the same reference; the runtime image still lands while the weights download. An installation that overrides prepull.images adds the storage-initializer ahead of its runtime reference to get the same start. make verify-serving-slice holds the reference to the KServe version of the kserve-llmisvc-resources line (0.7.x is v0.21.0) and the runtime image second.kolibri-1: Aleph Alpha’s Kolibri-1 split across two 128 GB GB10 nodes (giantswarm/agent-platform#804). Kolibri-1 is a German/English mixture of experts (78B, 3.5B active, Apache 2.0) with tool calling and a reasoning mode. It is served as its FP8 checkpoint (73.4 GiB) from the model image giantswarm/models/kolibri-1:e52eb4627d11, on giantswarm/vllm-aleph-alpha (vLLM 0.29 with Aleph Alpha’s plugin, which registers the architecture and the kolibri1 parsers), with a 256k context, an FP8 KV cache and --gpu-memory-utilization=0.60. One GB10 cannot hold the weights at that share, so it is served split, half the weights per node; measured on two GB10s: 36.85 GiB of weights and a 34.8 GiB KV cache (6.8M tokens) per node, a parsed tool call, about 65 tokens/s for one stream. model-families.yaml gains the Kolibri row.Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.111.0...v4.111.1
backstage.catalogs and the portal’s agent-deployment catalog location (giantswarm/backstage-catalogs#705). The connectivity chart’s app-config registers no templates/agent-deployment/template.yaml location from giantswarm/backstage-catalogs, and the cilium Backstage policy opens api.github.com on 443 while backstage.skillsRepositories is set (the skill discovery’s reads) in place of github.com, api.github.com and raw.githubusercontent.com while backstage.catalogs.version was set. backstage.catalogs is gone from both charts and from components.backstage.omitKeys; a set backstage.catalogs fails the meta chart’s render, naming it. make verify-wiring asserts the refusal and the GitHub API leg. UPGRADE.md.devstral-small-2 is sized for one 48 GB GPU: --gpu-memory-utilization=0.90 (was 0.50) and overheadGiB: 16 (was 30); components.model-manager.versionRange is >=1.10.2 <2.0.0 (giantswarm/agent-platform#718). The preset was the only one downloading from hf:// and serving --enforce-eager that is small enough for one L40S, but its 0.50 left about 22 GiB of a 48 GB card, less than its 25 GiB of weights, and its 25 + 30 GiB claim made cluster-manager refuse a pool of one 48 GB GPU. Measured on one L40S (g6e.2xlarge) from hf://: the weights take 23.3 GiB on the GPU and the KV cache 15.8 GiB at 0.90 (103,632 tokens, 12.6 concurrent 8k contexts), 41.5 of 46 GB used, and the chat and tool-call round trip answers. On a unified-memory node model-manager 1.10.2 composes the utilization from the weights plus overhead instead of the preset’s 0.90 (giantswarm/model-manager#223), so the preset serves on a DGX Spark unchanged; the model-manager floor moves to that release and the customer BOM pins it.