导言
在昇腾通信栈的第四轴里，ACL Copy、LD-ST、MTE、IPC、SDMA、RDMA 与 UDMA 被放在相邻位置。看到这么多搬运相关名词，一个很自然的判断是：它们大概是同一种能力的不同代际，后来者之所以出现，是因为前一代不够好。
这个判断抓住了技术演进的一部分，却把几类不同对象混在了一起。这些概念不是七代同类传输引擎，而是地址能力、操作表达和执行后端在不同距离、粒度与控制路径下的组合。本文从无法绕开的物理成本出发，再沿历史纵轴和技术横轴解释它们为何没有统一，以及什么时候一种新思想才真正值得形成新的代码仓。
导言
昇腾通信栈总图从上到下列出了语义、资源、提交者、搬运引擎和互联五部分。看到五个编号，很自然会追问：它们是否正好对应 OSI 七层、互联网五层或 TCP/IP 四层？答案是否定的。经典网络模型按协议功能分层，这张图则按一次通信如何从程序意图落到字节搬运划分责任。本文把两套分类放到同一张坐标系中，说明哪些位置可以近似对应，哪些位置必须保留“无对应”的边界。
导言
解释 Scratchpad 时，我们很快会遇到一个新问题：数据由 DMA 显式搬入片上 SRAM，但它从 HBM 到计算核心附近的 Scratchpad，究竟经过了什么？答案里反复出现的 NoC，又是什么概念？
这篇文章沿着一次数据搬运，把几个容易混在一起的对象摆回各自的位置：Scratchpad 负责本地存取，NoC 负责片上运输，DMA 负责执行显式搬运。
导言
把 KV Cache 放进 SSD 并不难，难的是让它取回来仍比重新 Prefill 更划算。GPU Direct Storage 已经能让数据绕过 Host DRAM，但每个 I/O 仍由 CPU 发起；Paged KV Cache 又会把一次长前缀恢复拆成海量小而散的请求。SSD 的标称带宽于是还没有用满，GPU 已经先停下来等数据。
Tutti 的核心不是再加一级缓存，而是重写 HBM 与 NVMe 之间的运行时路径：CPU 保留前缀索引和对象映射，却退出逐块 I/O 的数据与控制关键路径；GPU 通过对象化批处理、gio_uring 和 slack-aware 调度直接驱动本地 SSD。读完本文，应该能判断这三部分分别消除了什么瓶颈，以及论文的“接近 DRAM”结论在哪些条件下成立。
导言
一开始我只知道一件事：Mooncake 通过 TENT 接入了 NVIDIA GPUDirect Storage。真正沿代码往下追时，三个问题很快连在了一起：TENT 到底怎样调度一次传输，GDS 向上提供了哪些能力，以及新后端怎样实现同一套契约。
最关键的判断是：TENT 不是 GDS 的一层薄封装，而是负责 Segment、内存注册、后端选择、批次和状态推进的统一运行时；GdsTransport 才负责把 File Segment 请求翻译成 cuFile Batch I/O。 理清这条分工后，submitTransferTasks、cuFileBatchIOGetStatus 和新后端接口会自然落在同一张图里。
导言
一场围绕 OpenAI Jalapeño 推理芯片的讨论提出了一个看似矛盾的问题：专用 AI 计算核心可能比顶级通用 CPU 更规则，为什么 AI 芯片仍然很难做？
两句话可以同时成立。矩阵乘加阵列的局部控制逻辑相对规则，但一款有竞争力的 AI 产品还要跨过微架构、RTL、验证、物理实现、先进封装、内存与互联、编译器、Kernel、运行时、模型适配和客户部署。真正的壁垒没有消失，而是从单个计算核心转移到了整条系统栈及其持续迭代能力。
导言
手里已经有一套面向 NPU 的 NDS send/receive 接口，下一步是把它接入 Mooncake。乍看之下，这只是把 GDS 的 cuFile* 调用替换为 NDS API；但沿源码真正走一遍后，会遇到两个容易误判的事实：Mooncake 同时保留了新旧两代 GDS 路径，而 Mooncake Store 的磁盘副本读写目前又绕开了它们。
因此，接入点不应先选旧 NVMeoFTransport，也不能只新增一个 transport 就宣称 Store 已经获得 NPU 直读 SSD。更稳妥的路径是：先把 NDS 实现为 TENT 的 NdsTransport，复用其选择、批次、状态与回退机制；再单独改造 Store 的文件副本路径。
导言
华为昇腾通信资料最容易制造一种错觉：DMA、HCCS、HCCL、SHMEM、Fabric Memory 和 AIV 直驱仿佛是一摞可以从上到下整齐堆叠的软件层。实际并非如此。这些词分别回答“谁组织通信、谁建立地址、谁提交任务、谁搬数据、数据走哪条物理链路、对端是否参与”中的不同问题。有些是库，有些是协议或硬件，有些只是数据路径属性；把它们画在同一层，关系一定会错。
本文把历史纵轴和技术横轴合并：先建立一张总地图，再逐个概念给出小白版与专业版解释，最后核对公开仓库的首次可见提交、立项目的、硬件范围、迁移和待废弃状态。研究截止日为 2026 年 8 月 26 日。
导言
希望在华为 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 与自动入库。