导言
本文对齐 InferenceX 官网、公开 API、官方 InferenceX / InferenceX-app 仓库、AIPerf，以及 Ascend 与 vLLM-Ascend 一手资料，回答“哪些 NVIDIA 基线真实存在、AgentX 能否迁移到 A3/A5、需要多少机器、数据怎样采集和提交”。结论是：AgentX 客户端可以直接压测 Ascend 的 OpenAI-compatible 服务，但模型可运行不等于能够同配置复现；DeepSeek-R1 当前没有原生 vLLM 的 H100/H200/B200 对照数据，A3 也不支持与 NVIDIA FP4 等价的原生浮点格式。应先建立严格对照的离线长表，再推进官方 runner、PR 与自动入库。
导言
我看到 Mooncake 为 Ascend 提供了三个编译开关：USE_ASCEND、USE_ASCEND_DIRECT 和 USE_UBSHMEM。最直接的问题是：它们是不是三套并列的通信 engine？特别是后两个名字里已经有 Direct 和 SHMEM，是否意味着数据传输已经由 AIV 直驱？
沿着合入 PR 和源码调用链看下去，答案逐渐清楚：这不是三套同层方案，而是 Mooncake 先后解决“能传”“通用地传”和“把远端内存映射后再传”三个问题留下的三条路径。更重要的是，按当前可见源码，三者都不能直接称为 AIV 直驱。
导言
理解“AIV 直驱缩短了通信控制路径”之后，下一步不是立即抄一个 AllGather，而是先闭合一条最小链路：Host 建立资源并分配对称内存，启动一个 AIV Kernel；Kernel 把数据写到对端并发布 signal；接收端等待 signal，最后 Host 确认完成并按依赖顺序销毁资源。
本文基于 cann/shmem@382afa08efa801d7bca6c2645fd17e155111efcc 和 CANN 9.0.X / 9.0.0-beta.2 官方文档。代码是绑定该 revision 的教学归一化代码，不是承诺可在任意 CANN 版本直接编译的通用样例。
导言
PagedAttention 是 vLLM 高吞吐推理的核心内存管理机制。它没有改变 Attention 的数学公式，也没有消灭 KV Cache，而是把每条请求持续增长的 KV Cache 切成固定大小的 Block，通过 Block Table 将逻辑连续的 Token 映射到不连续的 GPU 物理块。
它解决的核心矛盾是：LLM 服务需要保留大量、长度未知且生命周期不同的 KV Cache，但 GPU 显存有限，传统连续分配容易产生预留浪费和碎片。 更高的显存利用率允许 vLLM 同时容纳更多请求，进而扩大 Batch、提高吞吐并降低高负载下的排队延迟。
导言
Mooncake 接入 vLLM 并不是把一个传输库直接塞进 attention：vLLM KVConnector 管请求和生命周期，Mooncake Transfer Engine 或 Store 管数据，vllm-ascend 再补上 NPU 地址、事件与后端适配。本文从固定 revision 的真实调用点穿刺这条链路，并专门核验一个容易混淆的问题：支持 Ascend、HCCL/RDMA 或名为 UBSHMEM 的 transport，是否等于使用 AIV Kernel 直驱？公开源码给出的答案是：不能等同，且当前没有找到 Mooncake KV 传输由 AIV Kernel 直驱的证据。
导言
Agentic LLM 的每轮新增输入很短，累计上下文却很长。高 KV Cache 命中率把重复计算变成了外部存储读取，但传统 P/D 分离系统只让 Prefill 节点承担读取，结果往往不是 GPU 算力不足，而是 Prefill 侧 Storage NIC 先堵住。DualPath 的核心不是压缩 KV，也不是换一种 Attention，而是把 Decode 侧闲置的存储入口和计算网络一起纳入 KV 加载路径，再用 QoS 与两级调度防止新路径干扰推理。本文进一步判断：昇腾 AIV 直驱可以成为其中一段细粒度 RDMA 控制路径的候选优化，但不能直接替代 DualPath 系统。
导言
Mooncake Store 的 KV Cache 管理很像 PagedAttention：两者都采用 切块、间接寻址、按块复用与淘汰。但它们解决的不是同一层问题。PagedAttention 管理单个推理实例内的 GPU KV Block；Mooncake Store 管理跨请求、跨实例、跨节点的 DRAM 与 SSD 副本。
理解二者关系的关键，是先区分 页表 与 KV 数据页：页表记录当前请求的逻辑块对应哪个 GPU 物理块，真正跨显存、内存和 SSD 分层迁移的是 K/V 张量数据，而不是页表本身。
但只理解“Master 管元数据、Client 传数据”仍然不够。本文沿 Mooncake 固定版本 bfca1ce2af8419c50dc8d464820a95d97d43c930 追到 store_c.cpp、real_client.cpp、client_service.cpp、master_service.cpp 与 transfer_task.cpp，解释每个设计判断究竟由哪段代码实现。
导言
长上下文把 KV cache 从一块 GPU 临时张量，逐步推成了跨 GPU、CPU、SSD、NIC 和远程内存流动的分布式状态。表面上，近几年的论文分别在做分页、卸载、压缩、P/D 解耦、远程复用或直通访问；从更抽象的角度看，它们其实都在回答同一个问题：如何分布式地管理一批有依赖、可重算、持续增长且必须按时到达的数据？
本文以放置、组织、传输为主轴，把命名、依赖、正确性、调度与故障恢复作为支撑平面，纵向回看 2022—2026 年的演化，横向比较七类设计范式，并推演下一阶段可能出现的三条路径。研究截止日期为 2026-08-24。
导言
Mooncake 是 Moonshot AI 为 Kimi 长上下文服务设计的 KVCache-centric 推理架构。它不再把 KV Cache 视为某张 GPU 上随请求消失的临时副产物，而是把它提升为跨 Prefill、Decode、CPU DRAM、SSD 与高速网络统一调度的系统资源。本文先用直觉解释，再从 P/D 解耦、Mooncake Store 与 Transfer Engine、缓存感知调度、Chunked Pipeline Parallelism 四个机制展开，并明确论文、当前开源代码与教学重构之间的证据边界。
导言
KV Cache 是自回归大模型推理中最重要的运行时状态之一。它把各层历史 token 已经算出的 Key 和 Value 留在缓存里，使后续步骤只处理新 token，而不必反复计算整个前缀。
这不是免费的加速：模型用持续增长的显存驻留换取更少的重复计算。理解这一交换，才能解释为什么生成会加快、长上下文会吃显存、并发容量可能下降，以及为什么修改提示词中间的 token 会使其后的缓存失效。