live wire
▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel
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.