本站大部分博客和笔记会借助 GPT 等先进模型辅助撰写，包括但不限于资料整理、结构梳理、表达润色和草稿生成。AI 能降低写作成本，但也可能引入事实错误、概念混淆、引用缺失和看似合理的幻觉内容。
因此，除非特别标注，我不保证文中内容完全准确。如果你将这些内容用于学习、工作或决策，请务必自行查证原始资料，并结合上下文判断其可靠性。
写笔记是为了让自己看懂，写博客是为了让别人看懂，不一样的，认真做好后者对自己各方面能力的提升会非常大（比如表达能力），其实很多时候记笔记就是写几段自己能看懂的表达，很随性，但写博客更像是写一篇论文，需要自己先彻底搞明白一个东西后才能输出1
我一直努力将内容写成博客。但是后来发现，根本没有时间和心思，来为别人解释很多事情。我的想法最多是解释给多年后忘记一切的自己听，让我还能快速看懂。能达到这点，这些内容的意义对于我就已经足够。
现在拥抱 AI 之后，我更愿意把这些内容理解为 AI 时代的阶段性理解产出。AI 降低了知识获取、信息筛选和文本生成的门槛，但它并不会自动替代人的理解：一个概念为什么重要、如何与已有知识连接、在哪些边界条件下成立，仍然需要自己反复判断、实践和修正。
所以，我仍然会继续更新这些文档。它们不是面向所有读者的完整教程，而是我在某个阶段借助 AI、资料阅读和个人实践，对相关概念形成的理解快照。未来的我可能会推翻、重写或补充其中很多内容，这也是笔记存在的意义。
从读者的角度，我并不会推荐任何人阅读这个网站的内容：因为你会遇到以下令人烦躁的场景
多级标题维持.导致这种情况，其实和我对知识产出过程的理解有关，我认为过程是 知识是自然聚类和融合的：
而且三者的占比是前面远大于后面，这样看来我这网站大部分的内容岂不是都是笔记的草稿。
我以这样的方式撰写我的正式的毕业论文时，发现这样的处理有利有弊：
总结：知识是自然聚类和融合的思想是没错的，但是在实际生产应用时需要两级的信息筛选过滤体系：区分出正文内的todo内容和未整理的archived信息。通过将罗列的完备信息初步分类归档(有基础的逻辑)以待后续使用，正文精心撰写每一句话保证不需要大量返工。
导言
谭邵杰，中国科学技术大学本硕毕业，现任华为昇腾训练开发工程师，专注于 Ascend NPU 上的大模型训练推理框架优化、多模态模型迁移、分布式并行训练、RL 优化与量化推理加速。
AI 训练推理框架与异构加速优化工程师，长期聚焦 Ascend NPU 生态下的大模型训练、推理、多模态迁移、分布式并行、RL 训练与量化优化。
导言
希望在华为 A3/A5 上实现 InferenceX 中 DeepSeek-R1 在 B200、H100 上的效果，首先需要明确“效果”究竟指什么。它不是一个孤立的峰值吞吐数字，而是由推理引擎、集群调度、并发负载、单用户速度和服务成本共同构成的性能曲线。
本文先解释 Dynamo TRT-LLM 的分层，再辨析 Conc、Interactivity、TTFT 和 Throughput/Chip，最后说明 AgentX 为什么把测试单位从独立请求升级成持续演化的 Agent 会话树。
导言
本文对齐 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 与自动入库。
导言
截至 2026-08-25，Mooncake 中的 USE_ASCEND、USE_ASCEND_DIRECT 与 USE_UBSHMEM 不是三个并列的“HCCL engine”，而是三次不同层次的演进：先复用 HCCL 的低层内存传输能力接通 Ascend，再用 ADXL/HiXL 收敛成通用的一边直传引擎，最后为 Fabric Memory 增加基于 CANN VMM 的专用映射快路。
最重要的结论是：这三条 Mooncake 路径按当前可见源码都不能直接称为 AIV 直驱。Direct 描述的是一边、零拷贝或更短的数据路径；VMM 描述的是内存分配、导出与映射；AIV 直驱描述的则是“谁在 Device 侧构造并提交通信工作”。它们处在不同维度。
导言
理解“AIV 直驱缩短了通信控制路径”之后，下一步不是立即抄一个 AllGather，而是先闭合一条最小链路：Host 建立资源并分配对称内存，启动一个 AIV Kernel；Kernel 把数据写到对端并发布 signal；接收端等待 signal，最后 Host 确认完成并按依赖顺序销毁资源。
本文基于 cann/shmem@382afa08efa801d7bca6c2645fd17e155111efcc 和 CANN 9.0.X / 9.0.0-beta.2 官方文档。代码是绑定该 revision 的教学归一化代码，不是承诺可在任意 CANN 版本直接编译的通用样例。
导言
TileXR 的 README 提到：若 UDMA 不可用，通信会平稳降级为 IPC/MTE。这个说法容易让人误以为 UDMA、IPC 和 MTE 是三个可以直接互换的传输引擎，或者一次 UDMA 调用会在失败后自动改写成 MTE 调用。
更准确的理解是：IPC/MTE 是一条组合路径。IPC 负责让本进程看见其他 Rank 的 NPU 内存，MTE 负责真正搬运数据；UDMA 则是另一套带队列、远端内存注册和完成通知的数据搬运后端。TileXR 所谓“自动降级”主要发生在初始化与能力选择阶段，而不是单次传输内部。
导言
TileXR 和 cann/shmem 都涉及昇腾设备间通信，但它们封装的不是同一层对象。TileXR 面向通信器、共享窗口和融合算子；cann/shmem 面向 PE、对称堆与单边通信原语。把二者简单画成一条“TileXR 调 SHMEM”的直线，会掩盖 TileXR 三个实际 MC2 算子的不同通信路径，也会忽略其固定 SHMEM fork 与 cann/shmem main 之间尚未闭合的 ABI。
本文只依据三个固定源码状态：TileXR 46c58f3d、它的 SHMEM gitlink b79bda38、cann/shmem main 382afa08。没有 Ascend 硬件与完整 CANN 构建验证，因此“源码存在”“设计意图”和“可编译运行”会严格分开。
导言
PagedAttention 是 vLLM 高吞吐推理的核心内存管理机制。它没有改变 Attention 的数学公式，也没有消灭 KV Cache，而是把每条请求持续增长的 KV Cache 切成固定大小的 Block，通过 Block Table 将逻辑连续的 Token 映射到不连续的 GPU 物理块。
它解决的核心矛盾是：LLM 服务需要保留大量、长度未知且生命周期不同的 KV Cache，但 GPU 显存有限，传统连续分配容易产生预留浪费和碎片。 更高的显存利用率允许 vLLM 同时容纳更多请求，进而扩大 Batch、提高吞吐并降低高负载下的排队延迟。
导言
MoE 的 All-to-All 不是一次整齐的等长集合通信，而是由路由结果决定长度的 pack、跨 rank 搬运、完成通知、expert 计算、反向搬运与 combine。固定源码表明：TileXR 主仓已经预留 sendCountMatrix、UDMA flag 与设备指针，却没有落地可追踪的 MoE dispatch/combine kernel；真正实现分别位于它固定的 SHMEM fork 和 cann/shmem。本文只描述源码能证明的部分，所有缺少完整实验条件的性能数字均标为未公开或不可归因。
导言
Mooncake 接入 vLLM 并不是把一个传输库直接塞进 attention：vLLM KVConnector 管请求和生命周期，Mooncake Transfer Engine 或 Store 管数据，vllm-ascend 再补上 NPU 地址、事件与后端适配。本文从固定 revision 的真实调用点穿刺这条链路，并专门核验一个容易混淆的问题：支持 Ascend、HCCL/RDMA 或名为 UBSHMEM 的 transport，是否等于使用 AIV Kernel 直驱？公开源码给出的答案是：不能等同，且当前没有找到 Mooncake KV 传输由 AIV Kernel 直驱的证据。