资料与口径
- 本机实测：解析本机
~/.claude/projects下 4 个 Claude Code 会话（2026-09-29 至 10-01）的 1,299 次 API 请求的 token 用量与时间戳；用 curl 测到api.anthropic.com的连接时延。这些是客户端视角的真实数据。- 公开资料：Anthropic 文档（prompt caching、数据驻留）、AWS Bedrock 跨区域推理文档、NVIDIA Dynamo 与 llm-d 的推理调度资料、算力合作报道，编号 [W1]…。
- 推算：Anthropic 不公开模型结构和内部拓扑。凡涉及 KV 缓存体积、链路传输时间的数字，都是用公开模型结构做的数量级估算，正文标“推算”。
- 不知道的事：某一次请求具体落在哪个数据中心、哪种芯片上，外部无法观测。本文只回答“业界一般怎么做”和“从客户端能看到什么”。
执行摘要
- 会不会跨数据中心？会，但不是在一次推理内部跨。
- 每次 API 请求是一个独立单元，由全球入口按容量、数据驻留和缓存位置分到某个区域、某个集群完成。一次请求的 prefill 和 decode 基本不会跨地域拆开做。
- 你同时开的多个后台任务，各自是独立会话，可能落在不同集群甚至不同区域。
- Anthropic 的 API 默认是 global 路由，“可能路由到全球任何 Anthropic 运营的数据中心”；可以付 1.1 倍价格限定在美国 [W1]。
- Anthropic 同时在 Google TPU、AWS Trainium、NVIDIA GPU 三类平台上运行 [W2]。
- 你的真实负载很“重”：
- 4 个会话共 1,299 次请求。每次请求的上下文中位约 45.7 万 token、p90 约 84 万；每次输出中位只有 582 token。
- 输入里 96.9% 是缓存读取；同一会话两次请求的间隔中位 11–15 秒。
- 这就是典型的 Agent 负载：长前缀、短输出、高频追加。
- 决定调度的不是带宽，而是 KV 缓存在哪里：
- 一个 45 万 token 上下文的 KV 缓存，按公开大模型结构推算约 30–150 GB。
- 搬一次走 400G 链路要 0.6–3 秒，跨地域更慢；重新算一遍 prefill 代价更高。
- 所以业界的通行做法是按缓存亲和性把同一会话粘在同一组服务器上，而不是把缓存搬来搬去。
- 你的数据印证了这一点：间隔超过 1 小时的请求，85.5% 的输入要重新写缓存；间隔在 5 分钟内的只有 2.1%。
- 用户侧带宽很小，聚合后才可观：
- 每次请求要把完整对话上传一次，约 1–2 MB（推算），平均约 1 Mbps/会话；输出流只有几 KB/s。
- 但 100 万个这样的会话同时在线，上行就是约 1 Tbps 级（推算）。
- 时延里网络占比很小：
- 你这里到 API 入口的 TCP 建连约 20–27 ms，TLS 后首字节约 190 ms。
- 一次典型交互（读缓存 + 生成 582 token）要几到十几秒，网络往返只占百分之几。
- 后台多任务对时延最宽容，所以最适合被调度到“有空闲算力的任何地方”。
- 对光网络的含义：
- Agent 推理不会像训练那样需要跨站大管道。
- 真正的大流量在数据中心内部和园区内部：KV 缓存在 HBM、DRAM、SSD、远端存储之间分层流动，以及 prefill 与 decode 分离时的 KV 传输。
- 跨数据中心这一层考验的是按需带宽、低时延路由和快速恢复。
一、你的 Claude Code 实际在干什么：本机数据
1.1 总体统计（2026-09-29 至 10-01，4 个会话）
| 指标 | 数值 |
|---|---|
| API 请求数 | 1,299（模型 claude-opus-5-5，服务等级 standard） |
| 子 Agent（sidechain）请求 | 0（这几个会话没有用 Agent 工具派生子任务） |
| 每次请求的上下文 token | 中位 456,875；p90 842,140；最大 968,170 |
| 每次请求的输出 token | 中位 582；p90 3,321；最大 33,762；合计 195 万 |
| 输入 token 合计 | 5.9 亿：缓存读 96.9%，缓存写 3.1%，未缓存 <0.01% |
| 同一会话请求间隔 | 中位 10.7–15.2 秒；p90 35–89 秒 |
| 峰值请求率 | 每分钟 12 次（所有会话合计） |
| 同一 10 分钟内最多并行会话 | 3 |
| 活跃时段平均生成速度 | 约 65 token/s（按间隔 ≤120 s 的时段平均） |
| 会话 | 请求数 | 时间跨度 | 间隔中位 | 输出 token |
|---|---|---|---|---|
| 3324d49f | 322 | 44.3 h | 10.7 s | 37.6 万 |
| 83359ff9（本会话） | 676 | 31.4 h | 12.6 s | 107.6 万 |
| 18d79b2f | 139 | 2.7 h | 15.2 s | 20.7 万 |
| 9e0ace17 | 162 | 12.3 h | 10.7 s | 29.1 万 |
1.2 怎么读这些数字
- “长前缀、短输出、高频追加”：Agent 每一步都把全部历史（含工具结果、图片）作为输入，只生成一小段决策或代码，然后执行工具、追加结果、再请求。NVIDIA Dynamo 团队对 Claude Code 的观察相同：典型模式是“长 prefill → 工具调用 → 扩展前缀 → 重复”，一个编码会话有数百次 API 调用，工具调用间隔 2–30 秒 [W3]。
- 缓存命中率 96.9% 与 NVIDIA 测得的 Claude Code 每个 worker 85–97% 一致 [W3]。这说明服务端在用**前缀缓存（prompt caching）**避免重复计算：同一前缀只算一次，之后每步只算新增部分。
- 缓存会过期：
| 与上一次请求的间隔 | 占比 | 该类请求中缓存写入占输入的比例 |
|---|---|---|
| <5 分钟 | 96.5% | 2.1% |
| >5 分钟 | 3.5% | — |
| >1 小时 | 1.0%（13 次） | 85.5% |
Anthropic 的缓存有 5 分钟和 1 小时两种 TTL，命中要求前缀完全一致 [W4]。你离开超过 1 小时再回来，几十万 token 的上下文基本要整体重新 prefill。这是 Agent 推理里最贵、也最容易被忽略的一类请求。
二、请求从你的电脑到推理服务器经过哪些层
业界大模型推理服务一般分四层调度。Anthropic 不公开细节，下面是通行架构，加上能观测到或有公开资料的部分。
| 层 | 做什么 | 公开信息与观测 |
|---|---|---|
| ① 全球入口 | DNS/Anycast 把请求导到最近的边缘节点，终结 TLS，做鉴权和限流 | api.anthropic.com 解析到 160.79.104.10，属 Anthropic 自有 AS399358。本机测得 TCP 建连 19–27 ms、TLS 完成 45–67 ms，说明边缘节点离你很近；未鉴权请求首字节约 180–200 ms，推测包含回源（实测）。你的出口 IP 显示在法兰克福（华为云），测得的是这条路径的时延 |
| ② 区域选择 | 按容量、数据驻留、价格把请求分到某个区域或云平台 | Anthropic API 默认 global，“可能路由到全球任何 Anthropic 运营的数据中心”；inference_geo: "us" 限定美国，价格 1.1 倍 [W1]。AWS Bedrock 的全球跨区域推理按可用容量把请求动态路由到所有商业区域，数据走 AWS 骨干网，不在目标区域落盘 [W5] |
| ③ 集群路由 | 在一个区域内，把请求分到某组推理服务器 | 业界主流是 KV 缓存感知路由：计算请求前缀与各服务器已有缓存块的重合度，再结合负载决定去哪（NVIDIA Dynamo KV Router、llm-d 前缀感知路由）[W3][W6]。llm-d 社区还在提“按 Agent 程序 ID 粘到同一 worker”的亲和调度，避免同一 Agent 的系统提示在多台机器上重复缓存 [W7] |
| ④ 引擎内调度 | 连续批处理、prefill/decode 分离、推测解码、KV 分层卸载 | Dynamo 的四级 KV 存储：GPU HBM（纳秒）→ CPU DRAM（微秒）→ 本地 NVMe（毫秒）→ 经 RDMA 的远端存储（毫秒）[W3] |
算力平台层面：Anthropic 在 Google TPU（2026 年新增 1 GW 以上，2027 年起再加约 3.5 GW）、AWS Trainium（Project Rainier，约 50 万颗 Trainium2）和 NVIDIA GPU 上同时运行 [W2]。同一个模型分布在多家云、多种芯片、多个地域上，第 ② 层的区域选择是真实存在的。
2.1 你的多个后台任务会落在哪里
- 每个任务是独立会话，有自己的对话历史和缓存前缀。第 ③ 层会尽量把同一会话的连续请求粘在已有缓存的服务器上，不同会话之间没有理由放在一起。
- 跨会话能共享的只有完全相同的前缀，比如相同的系统提示和工具定义。缓存按 workspace 隔离 [W4]。NVIDIA 测得 4 个 Opus 并行 Agent 的总体缓存命中率 97.2%，但子 Agent 第一次调用会冷启动缺失 [W3]。
- 会不会跨地域：在 global 模式下，你并行的几个任务落在不同区域是完全可能的，外部无法确认。但同一会话频繁跨区域跳动会让缓存失效、成本激增，所以按工程常理，系统会尽量把一个会话留在一个缓存域里。
三、带宽：每一段链路实际有多大流量
| 链路段 | 流量内容 | 量级 | 说明 |
|---|---|---|---|
| 你 ↔ API 边缘 | 上行：每次请求上传完整对话；下行：流式输出 | 上行每请求约 1–2 MB（推算），平均约 1 Mbps/会话；下行约 65 token/s × 每 token 数字节 + 流式封装，即几 KB/s | API 是无状态的：缓存只省计算，不省传输，每次都要把几十万 token 的上下文重新发一遍（推算） |
| 边缘 ↔ 推理区域（广域网） | 同上，再加回源 | 单会话很小；100 万个同类会话在线时约 1 Tbps 上行（推算） | 规模化后是一条可观但平稳的骨干流量 |
| 集群内：路由 → 推理服务器 | 请求文本、新增 token | 很小 | — |
| 集群内：prefill ↔ decode（分离部署） | KV 缓存 | 单请求可达几十到上百 GB（见下） | 所以 PD 分离一般放在同一机柜或同一高速网络域内 |
| 集群内：KV 卸载与回填 | HBM ↔ DRAM ↔ SSD ↔ 远端存储 | 持续、大块 | Agent 会话之间间隔几秒到几十秒，KV 要在层级间搬进搬出 [W3] |
| 跨数据中心 | 容量溢出、故障切换、模型权重分发 | 平时小，切换时突发 | KV 缓存一般不跨地域搬，宁可在新地点重算 |
3.1 KV 缓存有多大（推算）
Anthropic 不公开模型结构。下面用两类公开结构做数量级参照，按 FP16/BF16 计：
| 参照结构 | 每 token KV 缓存 | 45.7 万 token（你的中位上下文） | 84 万 token（p90） |
|---|---|---|---|
| 低秩压缩 KV（MLA 类，DeepSeek-V3 型：61 层 × 576 维） | 约 70 KB | 约 32 GB | 约 59 GB |
| 分组查询注意力（GQA 类，Llama 3.1 405B 型：126 层 × 8 个 KV 头 × 128 维 × K/V） | 约 516 KB | 约 236 GB | 约 433 GB |
| 搬运 32 / 236 GB 需要的时间 | 100 Gb/s | 400 Gb/s | 800 Gb/s |
|---|---|---|---|
| 32 GB | 2.6 s | 0.64 s | 0.32 s |
| 236 GB | 19 s | 4.7 s | 2.4 s |
结论：
- 在同一高速网络域内（400–800G、RDMA），按需搬 KV 是可行的，这就是 PD 分离和 KV 卸载的基础。
- 跨地域、跨 100G 级 DCI 搬一个会话的 KV 要几秒到几十秒，还要占用宝贵的骨干带宽，通常不如在新地点重算，或者干脆把会话留在原地。
- 这就是为什么缓存亲和调度是 Agent 推理的核心，也是你“离开超过 1 小时再回来会变慢、变贵”的原因。
四、时延：不同任务要求不同，网络占比都不大
4.1 一次 Agent 步骤的时间分解（以你的中位请求为例，推算）
| 环节 | 时间 | 说明 |
|---|---|---|
| 网络往返（你 ↔ 边缘 ↔ 区域） | 约 0.1–0.3 s | 实测边缘建连约 20–27 ms，回源后首字节约 190 ms |
| Prefill（缓存命中，只算新增的数百到数千 token） | 约 0.5–3 s | 缓存未命中时要整段重算几十万 token，可能到数十秒 |
| Decode（582 token × 约 65 token/s） | 约 9 s | 占大头 |
| 本地工具执行（读写文件、运行命令） | 几秒到几分钟 | 在你的电脑上 |
网络往返只占一次步骤的百分之几。即使跨大洲多走 100–150 ms，对 Agent 任务也几乎无感。676 次请求 × 0.2 s 的网络开销，累计约 2 分钟，而会话跨度是 31 小时。
4.2 不同推理任务的时延要求
| 任务类型 | 关键指标 | 典型要求 | 对网络与调度的含义 |
|---|---|---|---|
| 语音、实时交互 | 首 token 时延（TTFT）、每 token 时延（TPOT） | 首 token 数百 ms，每 token 20–50 ms | 必须就近部署，跨地域 RTT 会被感知 |
| 聊天 | TTFT、流式速度 | 首 token 1–2 s 内 | 可接受区域级调度 |
| 前台编码 Agent（你在等结果） | 每一步耗时 | 每步几秒到几十秒 | 缓存命中比网络时延重要得多 |
| 后台多任务 Agent | 任务完成总时间 | 分钟到小时 | 最宽容，最适合调度到全球任何有空闲算力、且缓存在的地方 |
| 批处理 API | 吞吐和成本 | 最长 24 小时 | 放到闲时、闲区域；Anthropic 的服务等级有 standard、priority、batch 之分 |
判断：对后台多 Agent 任务来说，真正影响体验的三件事依次是：
- 缓存能否命中：决定是否要重算几十万 token。
- 推理集群的排队与容量：高峰期限流、降速。
- 本地工具执行速度。
网络时延排在最后。
五、给你使用 Claude Code 的实际建议（从数据推出来的）
- 长时间离开前后的代价最大：间隔超过 1 小时，85.5% 的输入要重新写缓存。长任务尽量连续跑完；如果中途要停很久，回来后先让它压缩上下文（
/compact），再继续。 - 上下文越长，每一步越贵、越慢：你的中位上下文已到 45.7 万 token。阶段性压缩或开新会话，可以同时降低成本和 prefill 时间。NVIDIA 观察到一次上下文压缩把约 17.5 万 token 压到约 4 万 [W3]。
- 并行多任务的开销：每个后台任务都有自己的缓存前缀，第一次调用冷启动。任务越多，冷启动和总上下文越多。把相关子任务放在同一会话里用子 Agent，比开很多独立会话更能复用前缀。
- 数据驻留：如果有合规要求，API 可以设
inference_geo: "us"（1.1 倍价格）[W1]；要在欧洲境内处理，需要通过 Bedrock、Vertex 等云平台的区域部署 [W1][W5]。
六、对光通信与数据中心网络的含义
- Agent 推理不制造“训练式”的跨站大管道需求：跨地域流量由大量 MB 级请求构成，单会话约 1 Mbps，聚合后是 Tbps 级的平稳骨干流量；对 DCI 的要求是容量弹性、低时延路由和快速故障切换。这与 BT 在 ECOC 2026 上“推理约一个波长量级”的估计一致〔ECOC 0920-am-Su1-C-00 p25〕。
- 大流量在数据中心内部：
- KV 缓存的分层存储与搬运（HBM ↔ DRAM ↔ SSD ↔ 远端），以及 PD 分离时单请求几十到上百 GB 的 KV 传输，压在机柜内和集群内的网络上。
- 这对 scale-up 光互连、内存解耦（CXL、光学内存池）、RDMA 存储网络都是直接利好。见 MicroLED 短距光互连深度洞察 中内存解耦的部分。
- 调度在网络之上，但依赖网络：KV 缓存感知路由要求集群内带宽足够、时延可预期。NVIDIA 测得优化路由能把 p50 首 token 时延降 4 倍 [W3]。Agent 越多、上下文越长，集群内的“缓存网络”越重要。
- 值得跟踪的指标：
- 推理框架公开的跨节点 KV 传输量与缓存命中率。
- 推理服务商是否推出跨区域的 KV 缓存复制。
- 长上下文（百万 token 级）普及后，每会话 KV 体积与卸载层级的变化。
- 运营商把“推理 + 记忆同步”纳入算力网络业务定义的进展。
参考来源
- [W1] Anthropic 数据驻留文档（inference_geo：global 与 us，us 为 1.1 倍价格）：https://platform.claude.com/docs/en/manage-claude/data-residency ；相关解读：https://www.spotdev.co.uk/blog/ai-data-residency-uk-chatgpt-claude-gemini-grok-muse
- [W2] Anthropic 多云算力（Google TPU、AWS Trainium、NVIDIA GPU）：https://www.datacenterfrontier.com/machine-learning/article/55335703/inside-anthropics-multi-cloud-ai-factory-how-aws-trainium-and-google-tpus-shape-its-next-phase ；https://www.cnbc.com/2025/10/23/anthropic-google-cloud-deal-tpu.html ；https://convergedigest.com/what-we-know-about-anthropics-infrastructure-commitments-so-far/
- [W3] NVIDIA Dynamo：Full-Stack Optimizations for Agentic Inference（含 Claude Code 缓存命中率、四级 KV 存储、路由效果）：https://docs.nvidia.com/dynamo/v1.0.1/blog/agentic-inference
- [W4] Anthropic Prompt Caching 文档（TTL、隔离范围、前缀完全匹配、价格倍数）：https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- [W5] AWS Bedrock 全球跨区域推理：https://docs.aws.amazon.com/bedrock/latest/userguide/global-cross-region-inference.html
- [W6] KV 缓存感知路由（llm-d、Red Hat、Baseten 使用 Dynamo 的案例）：https://llm-d.ai/blog/kvcache-wins-you-can-see ；https://developers.redhat.com/articles/2025/10/07/master-kv-cache-aware-routing-llm-d-efficient-ai-inference ；https://www.baseten.co/blog/how-baseten-achieved-2x-faster-inference-with-nvidia-dynamo/
- [W7] llm-d：面向 Agent 的 KV 缓存亲和调度提案：https://github.com/llm-d/llm-d/issues/2584
本机数据：~/.claude/projects 下 4 个会话 jsonl 的 usage 字段与时间戳（统计脚本见本次会话）；curl 到 api.anthropic.com 的连接时延，2026-10-01 测得。