Provenance Record

News, 1007 words (range 400-1200). Clear structure: overview, what the library does, Google's figures, integrations, caveats, what we don't know. Neutral and hedged throughout; every vendor figure is labelled Google's, the two internal disagreements in Google's own material (intro 90% vs results list 60%/90%; 223 GB/s vs about 200 GB/s) are reported with attribution and not reconciled, and the Herald's own checks (JAX version comparison, releases/tags) are labelled as such. Title is 141 characters (under the 150-character threshold, but long).

Snapshots read from sources/2026-11/google-open-sources-tpu-sync-a-c-kv-cache-transfer-library-for-tpus-its-own-low-concurrency-tests-report-average-ttft-cuts-of-60-and-90/ (gunzipped, HTML to text). SOURCE 0 (Google Cloud blog, source-0.html.gz, sha256 a6fb1a89e50ae22d00b90e4dabca3acd3c401273df16f0493817cfd79288b28b): dated November 9, 2026; authors Fenghui Zhang (Distinguished Engineer, Google Cloud) and Weiren Yu (Senior Product Manager, Google Cloud); 'An open-source, native C++ library'; 'host DRAM, local SSDs, and Google Cloud Managed Lustre'; 'as the TPU KV cache connector for vLLM, SGLang, and llm-d disaggregated serving'; RL 'included in the repository as an experimental module'; 'experimental tiering to shared secondary storage'; intro 'consistently slashes KV transfer latency by over 90% and reduces Time to First Token (TTFT) by an average of 90% for heavyweight open-weight MoE models (235B-480B parameters)'; results list 'Over 90% KV transfer overhead cut ... dropped from several seconds down to a flat ~230 ms', 'average of 60% reduction in TTFT for heavyweight models (Qwen3 235B) under controlled, low-concurrency testing benchmarks, and an average of 90% for 480B under low concurrency', '30% to 70% increase in token output throughput for 235B', prefix caching 'reducing average TTFT by up to 90% on 64K-context workloads while delivering over 50% higher throughput and a 30% reduction in P99 inter-token latency'; 'up to 223 GB/s of aggregate D2H and H2D throughput per Ironwood (TPU v7x) host out of the 256 GB/s PCIe Gen5 hardware ceiling'; footnote 1 'internal testing conducted in July 2026 on TPU v7x (2x2x1 topology) ... tpu-inference v0.24.0 (using JAX 0.10.2 and libtpu 0.0.42.1)' and 'will vary based on system configuration, network bandwidth, concurrent traffic, and specific user workload patterns'; 'including Meta, alongside major enterprises like Wayfair'; Inferact and RadixArk named as maintainers; 'For more up-to-date performance results, please see our ongoing efforts on public benchmarks (InferenceX)'. All quotes and figures in the article match verbatim. The title's 60% and 90% match the results list (235B and 480B, both stated as low concurrency); 'Its Own' and 'Low-Concurrency' are exact (Google's internal July 2026 tests). A live re-fetch with a browser User-Agent on 2026-11-10 returned 200 with the same text (live HTML sha256 965e7d91e325c14a43e4fb90d7e7b3c5a32b6d135f9ecf36d74e01aaca615932; the strings '223 GB/s' and 'flat ~230 ms' are present). Scanner finding (system-prompt-reference) on this source is a false positive: the matched text is 'Enterprise applications with heavy system prompts (prefix caching):', a use-case heading about prefix caching of system prompts; no instruction addressed to an AI agent anywhere in the page; overridden after reading the excerpt in context. SOURCE 1 (github.com/google/tpu-sync, source-1.html.gz sha256 064b3231fd9d6555628e6cef610ea804165e3054fd9e1bd6dd5bc680e93f472a; README re-read raw through the GitHub API on 2026-11-10 ~16:57 UTC, blob sha ac5db092719b5f5d87a0c5fabae0a305abafb0e9, sha256 of the raw file 4b7da38c518cdf618c9a0c059db5cda74871adca8eac3ed3b5bc530df59e4583): 'TPU Raiden codebase has graduated into TPU Sync'; 'under active development and its APIs are evolving rapidly'; pin to a tagged release or the verified commit in lkg.version; 'actively validated and optimized' for Cloud TPU v7x and v6e; 'Until the first stable release is cut, only .dev nightlies exist, so pass --pre'; 'The torch wheel's release process is not yet gated on end-to-end performance tests'; 'approximately ~200 GB/s bidirectional PCIe bandwidth'; 'an open-source, native C++ framework'. LICENSE read raw via the API (sha256 58d1e17ffe5109a7ae296caafcadfdbe6a7d176f0bc4ab01e12a689b0499d8bd): Apache License, Version 2.0, January 2004 (repository metadata license Apache-2.0). Repository language C++ (6,525,729 bytes of 10.8 MB; Python 1,972,812; Lean 1,309,106). Herald's own checks re-run today (2026-11-10 ~16:55 UTC): releases endpoint returns 0 entries, tags endpoint returns 0 entries - article statement confirmed. JAX comparison re-confirmed from the README table: 0.10.2 (libtpu 0.0.42.1) Supported, 0.11.2 (libtpu 0.0.48) Default ('defaults to 0.11.2') - the footnote's JAX 0.10.2/libtpu 0.0.42.1 pair matches the 0.10.2 row. SOURCE 2 (The New Stack, Amanda Caswell, Nov 9th, 2026 1:40pm ET): the live URL returns a Cloudflare 403 to a browser-User-Agent fetch today (and for /disclosure-guidelines/), Archive.org direct access returned HTTP 429 to my requests (Wayback availability API lists a capture at 20261110004642). Routes used: (a) the pipeline's stored Archive.org fallback capture, source-2.html.gz, sha256 38bbbb04293954e6c5572e7e6fde164ab5385fc6afff086898930aa3fc5977f8; (b) the publisher's RSS feed https://thenewstack.io/feed/ (HTTP 200), item guid ?p=22843187, pubDate Mon, 09 Nov 2026 18:40:01 +0000, item XML sha256 0656601f1d9df4df857d24426e1e1c59fe4e858f8b6eb7d3bd9b6d803e662c12, extracted full-text sha256 4847016ac4f54b4b760b47778fcb3ec9d7c4a4eba7686505f0632f5abd7bb5ee; the RSS full text and the archive capture are textually identical for the article body. Confirmed verbatim: headline '... by over 90% - but there's a catch'; 'The company claims it can cut KV-cache transfer latency and time to first token by more than 90% in some tests'; 'Written in C++'; 'isn't production-ready for everyone just yet'; 'a direct comparison with a fully tuned TPU v7 setup has yet to be published'; SemiAnalysis context ('external TPU serving previously lacked the infrastructure needed to separate prefill and decode workloads effectively'; GB200 and GB300 NVL72 'ahead in parts of the disaggregated-serving performance curve'). What The New Stack adds: no measurement or test of its own; its figures are 'In Google's benchmarks' (60% and 90% split, 223 GB/s, 64K prefix caching), plus second-hand SemiAnalysis context (the sentence introducing SemiAnalysis is garbled in the original) and a README-based reading that the software is not production-ready. It restates the announcement with context, so it counts as an independent outlet but a restating one. Investor disclosure: footer shows only a 'Disclosures' link; the disclosure page was not readable (403 live, 429 archive, WebFetch 403), so no investor disclosure could be checked. SOURCE 3 (vllm-project/vllm-torchtpu docs/user_guide/disaggregated_serving.md, source-3.html.gz sha256 3a6175b66544bc2496715990285946631905b8b461a2eb75895b2083ad279081; raw file re-read via API 2026-11-10, sha256 c49389ee1eab4bf5be2304023cd720c8d6da20c6aaf198d302876e82cc09cd49): 'vllm-torchtpu supports two KV cache transfer connectors'; 'Raiden KV Connector (TpuRaidenConnector): High-bandwidth PJRT DMA/RDMA engine powered by tpu-sync-torch (tpu_sync)'; 'Host TCP/Side-Channel Connector (TPUConnector): ... for functional testing and local disaggregation'; no performance figures in the guide (no GB/s, TTFT or percentage claims); it still uses the Raiden name for the connector. Quantifier and absence tests (jq/grep over title, summary, body): 'None of the four cited sources reports a measurement ... made by a party other than Google' - checked against all four snapshots: The New Stack's figures are attributed to Google's benchmarks, the README figure is the project's own, the guide has none; holds. 'The sources do not say when a first stable release will be cut' holds. 'none of the cited sources describes results from those evaluations' (Meta, Wayfair) holds. Relative dates: none. Herald TorchTPU Briefing link /article/2026-11/04-google-and-meta-open-source-torchtpu-... resolves to a published article (InfoQ + torch_tpu repo sources); no corrections record exists for it; the sentence describing it is accurate. Independence recount: independent outlets = 1 (The New Stack, restating Google with second-hand SemiAnalysis context). First-party: Google Cloud blog and the google/tpu-sync repository. The vLLM-TorchTPU guide is a partner project's documentation (the Google post says TPU Sync was co-engineered with Inferact, vLLM-TorchTPU's maintainers), not a press outlet and not an independent evaluation. The writer's count is accepted. Not an Analysis, so the 2-independent-source requirement does not apply. Allowlist: cloud.google.com (line 845), github.com (line 1162), thenewstack.io (line 119) are all on config/source_allowlist.txt; no additions needed; semianalysis.com is not cited. Anthropic disclosure: not required - the article is about a Google library, does not name Anthropic or Claude, and no Anthropic credit line appears (Rule 15 confirmed; the only Anthropic text in the stored New Stack snapshot is an unrelated sidebar headline). Prior coverage: no earlier Herald article on TPU Sync or TPU Raiden. Anthropic disclosure: not required - the article is about a Google library and does not name Anthropic or Claude in headline, summary, lead or a credit line.

Every number, quote, date and version in the article traces to a snapshot or to the Herald's own labelled checks. One headline-level imprecision: 'Google Open-Sources TPU Sync'. The verb follows Google's wording ('available today as open source') and The New Stack's ('Google's new open-source TPU Sync'), and the README calls TPU Sync 'an open-source, native C++ framework'. The Herald's own check through the GitHub API on 2026-11-10 shows the same repository (id 1233464543, created 2026-05-09, first commit 2026-05-12 'init tpu-raiden', pull request #1 opened 2026-05-12, the API resolves google/tpu-raiden to google/tpu-sync; forks named 'tpu-raiden' are listed as public from 2026-06-01, including one from 2026-06-20 by an account with no listed employer; forks of a private repository cannot be public, so the parent was public by then) was public under the name TPU Raiden months before the November 9 post; the vllm-torchtpu connector for Raiden dates from 2026-06-08; PyPI shows tpu-sync-jax and tpu-sync-torch nightlies from 2026-09-16. November 9 was therefore the launch under the TPU Sync name, not the first time the code was public. No cited source says either way, and the body's statement that the codebase was earlier called TPU Raiden is correct but silent on its earlier public status. Handled as a clarification, not a REJECT: the verb is the cited sources' own framing, the headline's other claims (C++, TPUs, Google's own low-concurrency tests, 60% and 90%) are exact, and one note can inform readers honestly. Also noted without a record: the title calls it a 'KV-Cache Transfer Library' while the blog title adds weight transfer for RL (experimental) and the README says 'KV cache orchestration, multi-tiered memory management, and cross-node data transfer'; the body covers the RL and weight-transfer role. The 223 GB/s (blog, 'up to', aggregate D2H and H2D per host) versus 'approximately ~200 GB/s' (README, bidirectional) are labelled as unreconciled; the sources give different measurement contexts but no explanation of the gap, so the article's statement holds.

Accurate, well-hedged coverage of a vendor library launch for a defined developer audience; every quote, figure and version verified against raw source text, with the Google-internal disagreements reported honestly. Approved with one clarification on the headline's 'Open-Sources'. Featured candidacy: 1 - accurate launch coverage of a TPU inference library for a defined developer audience, with only vendor-run benchmarks.