live wire
▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security
upstreambeat.ai
releaseAI

KServe 0.20 gives model-serving teams safer rollouts and a hardware-backed path for encrypted models

The release adds TEE-based model decryption, progressive traffic controls, CPU-backed KV-cache offload and first-class tracing for Kubernetes inference workloads.

KServe 0.20 adds declarative rollout, encryption, and tracing controls.
Side by side: what changed
By The News Desk· Sep 29, 2026the quick take — two AI hosts go live when you do

KServe 0.20 pulls several day-two model-serving controls into its Kubernetes APIs: encrypted-model handling inside trusted execution environments, progressive traffic management, CPU-backed KV-cache offload and declarative tracing. The project’s release post was published August 6.

What changed

For sensitive model artifacts, KServe can now download JWE-encrypted files and ask a local Confidential Data Hub inside a trusted guest to obtain the decryption key through hardware attestation. The model is decrypted inside the trusted execution environment rather than exposed to the host. The implementation works with both InferenceService and LLMInferenceService, and the project says it is compatible with Key Broker Service backends including Trustee and Intel Trust Authority.

The release also adds weighted traffic groups to LLMInferenceService. Operators can shift requests between service versions while readiness and degradation are tracked for each group independently. For conventional InferenceService workloads in RawDeployment mode, KServe 0.20 adds named canaries with percentage-based traffic allocation; promotion can retarget the stable service without recreating model pods.

For vLLM deployments, a structured kvCacheOffloading.cpu field now lets operators reserve CPU memory as a secondary KV-cache tier. KServe renders the corresponding vLLM transfer configuration, including for disaggregated prefill/decode layouts. A separate tracing API enables OpenTelemetry for the inference server and scheduler without requiring teams to inject environment variables through pod-template overrides.

Who should care

Platform teams already standardizing inference behind Kubernetes custom resources get the clearest benefit. The release moves rollout safety, model confidentiality and observability into declarative configuration instead of leaving each model team to assemble sidecars, environment variables and bespoke deployment logic.

There are useful runtime changes too. KServe now supports vLLM as a standalone InferenceService runtime, routes Anthropic Messages API traffic through the inference pool, and can mount OCI model images directly with Kubernetes ImageVolume. That native OCI path requires Kubernetes 1.33 or newer.

What to do

Teams testing 0.20 should start with one operational problem rather than enabling everything at once. Canary or weighted traffic controls are the lowest-risk place to validate rollback behavior. KV-cache offload should be benchmarked against latency and host-memory pressure under realistic prompts. Confidential serving needs a working attestation and key-broker chain, so it belongs in a threat-model review rather than a routine configuration toggle.

The release also upgrades its llm-d dependency to 0.8.0 and adopts llm-d.ai routing CRDs. Existing users should therefore review CRD and controller changes before upgrading production clusters.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.