llm-d 1.0’s passing TPU checks do not validate every documented deployment

llm-d 1.0 has passing release checks for three separate Google TPU serving paths—not blanket validation of its documented TPU deployments. Superpower Daily’s bounded review finds positive results for precise routing, native CPU offload and split prompt-processing and response-generation serving. The gap is configuration-specific: those badges do not establish coverage across every TPU generation or prove the features ran together.

The finding narrows, rather than overturns, the production-readiness message around the release. IBM’s October 20 announcement described llm-d 1.0 as ready for operating deployed AI services, emphasizing integration and operational maturity. llm-d coordinates model-serving engines such as vLLM and SGLang. Our question is more specific: which sampled hardware, engine and serving configurations have published validation evidence, rather than deployment instructions alone?

Original analysis: We reassessed saved evidence for TPU and GPU configurations in three v1.0.0-tagged guides: precise prefix-cache routing, tiered prefix caching and prefill/decode disaggregation. We compared those instructions with their release-matrix entries and saved badge results. The review preserves the October 21, 2026, 20:30 UTC cutoff and the collection record at 20:30:57.479 UTC. It is not a new collection or an execution test, and it does not cover every possible feature combination.

Three techniques, three different checks

The techniques address different parts of model serving. Precise prefix-cache routing sends requests toward servers holding reusable prompt context. Each model server publishes events describing its KV cache—the stored intermediate state used during generation—and the router builds an index. Unlike an estimate based on request traffic, this approach uses the servers’ own cache records.

Tiered caching preserves cache blocks beyond accelerator memory by moving them into CPU memory and, optionally, a shared filesystem. A later request can reload reusable context instead of recomputing it. Prefill/decode disaggregation separates prompt processing from response generation into different worker pools. A transfer connector moves the resulting cache between them. A successful check of one technique therefore answers a different question from a check of another.

The release matrix publishes separate validation workflows for these paths. A listed workflow establishes that a validation route exists; it does not by itself establish a passing outcome. The saved observations distinguish those two states:

• Precise routing: vLLM release workflows cover NVIDIA GPUs, AMD ROCm, Intel XPUs and Google Kubernetes Engine (GKE) TPUs. The supplied GKE GPU and TPU routing badges were checked and reported passing. Other listed workflows do not inherit those outcomes.
• Cache offload: native CPU-offload workflows include NVIDIA vLLM and SGLang, TPU vLLM, AMD vLLM and Intel vLLM. LMCache workflows cover NVIDIA, AMD and Intel vLLM; AMD also names filesystem workflows. The supplied TPU native CPU-offload badge was checked as passing.
• Prefill/decode: release workflows include NVIDIA vLLM and SGLang, GKE TPU vLLM, AMD vLLM with separate MoRI and NIXL connector workflows, and Intel XPU vLLM. The supplied TPU badge was checked as passing; the other listed outcomes were not checked in this sample.

The TPU generation changes the evidence

All three guides mark TPU v5p as covered by nightly end-to-end testing, while v6e and v7 are classified as community configurations. In the guides, community means maintained by a hardware vendor or community without nightly end-to-end coverage. The v6e entries explain that nightly testing moved to v5p while v6e capacity was unavailable. A generic TPU badge does not identify a tested generation.

There is meaningful counterevidence to treating community status as documentation alone. The tiered-cache guide explicitly records manual validation of v6e native CPU offload on October 12, 2026. That is a positive, configuration-specific statement. It is not accompanied in this sample by an immutable release-test artifact, however, and it does not establish v6e routing or disaggregation results.

These are not interchangeable recipes with different hardware labels. The precise-routing guide uses a 64-token cache block for most configurations, but v6e requires 256 because the smaller setting runs out of on-chip memory on Torch TPU. The router must use the matching block size. That documented adjustment illustrates why validation should follow the actual configuration, not just the accelerator family.

A combined recipe still needs its own result

The clearest combined TPU example appears in the disaggregation guide. Its v7 community recipe names Qwen3.5-397B-A17B-FP8, TPURaidenConnector and 64 GiB of prefill host-cache offload. That explicitly documents split serving with host offload, rather than merely suggesting the features might compose. But the sample contains no distinct release-test result for that combination. The guide’s separate v7 dynamic-slicing recipe is a different configuration.

Nor should native CPU-offload evidence be extended to every cache backend. The tiered-cache guide distinguishes native offload, LMCache and MooncakeStore, and distinguishes CPU memory from filesystem storage. NVIDIA vLLM MooncakeStore offload has instructions but no corresponding release workflow in the sampled matrix. Neither do SGLang precise routing on NVIDIA and Intel, or community disaggregation configurations for Iluvatar, MetaX, Biren and Moore Threads.

Those gaps mean public release validation was not established within this sample. They do not mean the capabilities are unsupported, failed testing or were never tested elsewhere. Likewise, separate routing and offload results cannot be added together as proof of a full combined stack. The guides describe routing behavior within tiered caching and disaggregation, but not an exhaustive combined-feature test.

A fixed guide, a moving badge

Even the positive observations have a provenance limit. The guide text is pinned to v1.0.0, but release validation targets the release-1.0 branch through mutable badges that update on reruns. The checked payloads contain no run timestamp, tested source-code identifier or image digest—the identifier for a fixed container image. They establish saved passing status, not independent confirmation of an exact, immutable runtime combination.