跳转至

开启 Dev 模式

查看作者的未审核笔记。原有搜索、标签、分类和归档会同时切换。

2026

TurboBus PCIe Bandwidth Pooling

导言

GPU Memory Offloading 有一个很反直觉的现象:应用可能把大部分时间耗在 PCIe 搬运上,同一台服务器却仍有多数 PCIe 带宽处于空闲。问题不在于服务器缺少链路,而在于每块 GPU 只能使用自己名下的那条链路;不同 GPU、不同作业的搬运阶段又往往没有同时到来。

TurboBus 的核心思想,是把 NVLink、NVSwitch 等高速 Scale-Up Fabric 当成一条节点内的转发背板:繁忙 GPU 先把数据送到邻居 GPU,再借邻居的空闲 PCIe 链路访问 Host Memory。本文沿着论文 Figure 1、4、5、6、7 解释这条思路怎样从一张直觉图落成带隔离、流水、调度和 API 的系统,并区分实验已经证明的收益与仍受硬件拓扑、NUMA 和工作负载限制的外推。

io_uring Async I/O

导言

读到 Tutti 的 GPU io_uring 一节时,我几乎完全没看懂。SQ、CQ、IOCB、CUDA Event 和 Green Context 挤在一起,很难看出它们各自解决什么问题。

本文先用取餐叫号解释核心直觉,再用 Linux io_uring 的 SQ、CQ、SQE、CQE 和 SQPOLL 建立准确模型,最后把这些对象放回 Tutti:为什么队列能把发起请求和等待结果拆成两个时间点,以及为什么还需要 CUDA Event、Green Context 和 slack-aware Scheduler 才能真正减少 GPU 停顿。

SHMEM Symmetric Memory

导言

我最初把 HCCL 理解成集合通信,把 HiXL 理解成单点通信。这个分法可以作为起点,却会让 SHMEM 无处安放:它既能一对一 Put/Get,也能做原子操作与同步,为什么还需要“对称内存”这套约束?

关键在于,HCCL、HiXL 和 SHMEM 并不只是在争夺同一种通信 API。HCCL 更接近“我要完成什么群体操作”,HiXL 更接近“我要把哪段数据传到哪里”,SHMEM 则把问题改写成“我要访问哪个 PE 上的哪个内存坐标”。它用跨 PE 的布局约束,换取设备侧可以低开销地定位和操作远端数据;但当各 PE 的容量需求严重不均时,这份约束也确实可能造成浪费。

Ascend Communication Axes

导言

昇腾通信栈总图从上到下列出了语义、资源、提交者、搬运引擎和互联五部分。看到五个编号,很自然会追问:它们是否正好对应 OSI 七层、互联网五层或 TCP/IP 四层?答案是否定的。经典网络模型按协议功能分层,这张图则按一次通信如何从程序意图落到字节搬运划分责任。本文把两套分类放到同一张坐标系中,说明哪些位置可以近似对应,哪些位置必须保留“无对应”的边界。

Scratchpad and NoC

导言

解释 Scratchpad 时,我们很快会遇到一个新问题:数据由 DMA 显式搬入片上 SRAM,但它从 HBM 到计算核心附近的 Scratchpad,究竟经过了什么?答案里反复出现的 NoC,又是什么概念?

这篇文章沿着一次数据搬运,把几个容易混在一起的对象摆回各自的位置:Scratchpad 负责本地存取,NoC 负责片上运输,DMA 负责执行显式搬运。

Tutti SSD-Backed KV Cache

导言

把 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”结论在哪些条件下成立。

Dynamo TRT-LLM and AgentX

导言

希望在华为 A3/A5 上实现 InferenceX 中 DeepSeek-R1 在 B200、H100 上的效果,首先需要明确“效果”究竟指什么。它不是一个孤立的峰值吞吐数字,而是由推理引擎、集群调度、并发负载、单用户速度和服务成本共同构成的性能曲线。

本文先解释 Dynamo TRT-LLM 的分层,再辨析 Conc、Interactivity、TTFT 和 Throughput/Chip,最后说明 AgentX 为什么把测试单位从独立请求升级成持续演化的 Agent 会话树。

PagedAttention

导言

PagedAttention 是 vLLM 高吞吐推理的核心内存管理机制。它没有改变 Attention 的数学公式,也没有消灭 KV Cache,而是把每条请求持续增长的 KV Cache 切成固定大小的 Block,通过 Block Table 将逻辑连续的 Token 映射到不连续的 GPU 物理块。

它解决的核心矛盾是:LLM 服务需要保留大量、长度未知且生命周期不同的 KV Cache,但 GPU 显存有限,传统连续分配容易产生预留浪费和碎片。 更高的显存利用率允许 vLLM 同时容纳更多请求,进而扩大 Batch、提高吞吐并降低高负载下的排队延迟。

KV Cache Fundamentals

导言

KV Cache 是自回归大模型推理中最重要的运行时状态之一。它把各层历史 token 已经算出的 Key 和 Value 留在缓存里,使后续步骤只处理新 token,而不必反复计算整个前缀。

这不是免费的加速:模型用持续增长的显存驻留换取更少的重复计算。理解这一交换,才能解释为什么生成会加快、长上下文会吃显存、并发容量可能下降,以及为什么修改提示词中间的 token 会使其后的缓存失效。

Modern Matchmaking System

导言

当代成年人并不只是缺少认识异性的渠道,更缺少一种低冒犯、低浪费、可逐步建立信任的了解方式。工作压力压缩了交往时间,陌生人之间又缺乏共同经历;吃饭、看电影和交换兴趣爱好可以判断相处是否舒服,却很难及早暴露城市选择、生育、金钱、父母照护、职业规划和冲突处理等长期问题。

本文不试图发明一套“灵魂伴侣算法”,而是从古代婚姻流程中提取分阶段确认、双向披露、可信中介和体面退出等机制,再用现代关系研究、平等原则与隐私保护重新设计。目标不是替人决定应该爱谁,而是让两个人更早看见:能否共同经营一个长期生活系统。