Introduction

Green contexts are a lightweight alternative to traditional contexts, that can be used to select a subset of device resources. This allows the developer to, for example, select SMs from distinct spatial partitions of the GPU and target them via CUDA stream operations, kernel launches, etc.

CUDA 中的 Green Context 是一种轻量级的上下文形式，可作为传统 CUDA 上下文的替代方案，为开发者提供更细粒度的 GPU 空间划分与资源分配能力。

Green Context 使用户能够定义和管理 GPU 资源的独立分区，主要是Streaming Multiprocessors（SM)。你可以将特定数量的 SM 分配给某个特定的 Green Context ，然后在该 context 所拥有的资源范围内启动 CUDA kernel 并管理只在此 context 内运行的 stream。

技术定位

Green Contexts 介于 CUDA Streams（动态无分区）和 MPS（有分区但动态不足）之间，支持单进程内动态 SM 资源分区，提供确定性的非对称执行能力。

Green Context enables lightweight intra-process spatial sharing. Briefly, we can create multiple CUDA streams with dedicated SM allocations for concurrent GPU kernels.

Green Context解决了GPU资源调度的难问题——把”碰运气式”并行升级为”精准规划”。它通过预分配SM资源池，让关键任务能独占专属算力，既保证低延迟响应，又避免多任务互相干扰。

应用场景

一个典型的应用场景是：你的程序中有部分代码对延迟极为敏感，并且需要优先于其他所有 GPU 工作执行。通过为这段代码单独创建一个 Green Context 并分配 SM 资源，而将剩余的 SM 分配给另一个 Green Context 处理其他任务，你就能确保始终有可用的 SM 供高优先级计算使用。

ASPLOS’26的paper: Towards High-Goodput LLM Serving with Prefill-decode Multiplexing，就是基于Green Context做的工作，blog可参见PD-Multiplexing: Unlocking High-Goodput LLM Serving with GreenContext。

创建与使用流程

1. 查询 GPU 的 SM 数量（Blackwell 为 160）
2. 制定资源分区策略
3. 创建分区描述符
4. 生成 Green Context 沙箱
5. 从 Context 创建 CUDA Stream
6. 正常向 Stream 提交核函数

总结

Green Context 的核心价值，不是简单地“限制 kernel 能用多少个 SM”，而是给 CUDA 提供了一种更可控的资源管理方式。它把原本机会式的并行，进一步变成了可规划的并行。通过把 SM资源按 context 进行划分，应用可以在低时延、吞吐和隔离性之间做更灵活的权衡。

对需要保障关键任务响应时间、减少多 stream 相互干扰、或验证不同资源配比效果的场景来说，Green Context 提供了一种几乎不需要修改 kernel、只需少量 host 侧改造就能落地的新手段。

参考资料:

1. 刚刚，英伟达CUDA迎来史上最大更新！
2. Green Contexts
3. 简单了解下CUDA Green Context
4. 一次看懂：CUDA 最新技术与未来 3 年路线图
5. cuda13新特性green context
6. PD 多路复用：SGLang 借助 NVIDIA GreenContext 释放高有效吞吐量的大语言模型服务能力

在大型AI模型训练中，单机单GPU的配置已无法满足算力与内存的需求。随着模型参数规模的不断扩大，分布式训练已成为深度学习发展的必由之路。而支撑分布式训练最基础的能力正是分布式训练通信原语（Communication Primitives）。

分布式训练通信原语的概念

“通信原语”并非指某个具体的框架或API，而是指各种分布式系统中高度抽象、反复出现的基础通信与协同操作。它们定义了在训练过程中多设备、多进程之间如何交换数据、同步状态、维持一致性。无论你使用PyTorch、TensorFlow还是JAX，也无论采用数据并行、模型并行还是混合并行策略，底层实现都依赖这些AI分布式训练通信原语的高效实现。可以说，通信原语的性能直接决定了分布式训练效率的上限。

常见分布式训练通信原语详解

基于实际训练中最常见的通信模式，我们在此介绍八种核心AI训练通信原语：广播Broadcast、分散Scatter、聚合Gather、全聚合AllGather、规约Reduce、规约分散ReduceScatter、全规约AllReduce以及全交换All-to-All。

广播Broadcast

1. 广播Broadcast是一对多通信原语，即一个发送者对应多个接收者。在集群中，某个节点（或GPU）将其数据广播至所有其他节点。例如将GPU0的数据同步至GPU1、GPU2与GPU3。

2. 广播Broadcast是一对多数据同步机制，能将一个GPU的数据同步至所有其他GPU。其应用场景包括：

• 并行数据参数初始化，确保所有GPU的初始参数一致性；
• AllReduce组合（广播Broadcast+规约Reduce）中的广播操作；
• 分布式训练参数服务器架构中，主节点向工作节点广播Broadcast数据，再由工作节点将数据规约Reduce回主节点的广播环节。

分散Scatter

1. 分散Scatter与广播Broadcast虽同属一对多通信原语，但存在本质区别。分散与广播的核心差异在于：

• 广播Broadcast：向所有节点发送相同的完整数据。
• 分散Scatter：将数据拆分后分别发送给不同节点。

2. 例如，将一份数据DATA拆分为DATA-A、DATA-B、DATA-C与DATA-D：

• DATA-A → GPU0
• DATA-B → GPU1
• DATA-C → GPU2
• DATA-D → GPU3

3. 分散Scatter的逆操作是聚合Gather，其典型应用场景包括：

• 规约分散ReduceScatter组合中的分散Scatter操作；
• 模型并行中，初始化时模型参数分散至不同GPU的环节。

聚合Gather

1. 聚合Gather是多对一通信原语，即多个数据发送者对应一个数据接收者。它将集群中多个节点的数据汇集到单个节点上。各节点将自身数据发送至主节点，聚合完成后主节点即拥有所有节点的数据。例如：

• GPU0 → DATA-A
• GPU1 → DATA-B
• GPU2 → DATA-C
• GPU3 → DATA-D
• 最终主节点将获得完整的DATA-A/B/C/D数据集。

2. 聚合Gather是多对一数据收集方法，将多张GPU卡的数据收集到单张GPU卡上。其逆操作对应分散Scatter，应用场景即规约分散ReduceScatter组合中的分散Scatter环节。

全聚合AllGather

1. 全聚合AllGather是多对多通信原语，实现多张GPU卡之间的数据同步全收集。可将其视作聚合与广播操作的组合，即：

• 首先，将各节点数据收集至主节点（Gather）；
• 随后，将完整数据广播至所有节点（Broadcast）。
• 最终Allgather的结果是每个节点都拥有完整数据。

2. 全聚合AllGather的逆操作是规约分散ReduceScatter，其典型应用场景包括：

• 并行模型训练场景；
• 在并行模型训练中，前向计算所需的参数需要全量同步，此时需要通过AllGather将拆分在不同GPU上的参数同步到单张GPU上才能进行前向计算。

规约Reduce

1. 规约（Reduce）是多对一通信原语，用于将多个节点的数据进行归约Reduce计算并将结果汇总至单个节点。常见的规约Reduce操作包括：

• 求和（SUM）
• 求积（PROD）
• 最大值/最小值（MAX/MIN）
• 逻辑与/或（LAND/LOR）
• 按位与/或/异或（BAND/BOR/BXOR）
• 最大值位置/最小值位置（MAXLOC/MINLOC）

2. 这些规约Reduce操作通常需要GPU或加速卡硬件支持对应的算子（operator）才能实现高性能。

3. 规约Reduce的典型应用场景包括：

• 全规约AllReduce中的规约Reduce环节；
• 规约分散ReduceScatter组合通信中的规约Reduce操作；
• 分布式训练参数服务器架构中，Master节点先将模型参数广播Broadcast至所有Worker节点，各Worker完成计算后通过规约Reduce操作将结果聚合回Master节点。

规约分散ReduceScatter

1. 规约分散ReduceScatter是多对多通信原语，具有多个数据发送者与多个数据接收者。它在集群所有节点上沿相同维度执行规约Reduce操作，随后将结果分发至集群每个节点。规约分散ReduceScatter等效于在每个节点上执行一次规约Reduce操作后，再进行一次分散Scatter分发操作。其逆操作是全聚合AllGather。

2. 规约分散ReduceScatter是多对多数据操作，采用”先规约Reduce后分发”的方式。它首先对各GPU卡上的数据进行规约（例如求和），再将数据分发（分散Scatter）处理。其应用场景包括：

• 规约分散ReduceScatter可同时适用于数据并行与模型并行场景：
• 数据并行中规约分散ReduceScatter+全聚合AllGather组合内的规约分散ReduceScatter操作；
• 模型并行中前向AllGather后反向计算中的规约分散ReduceScatter环节。

全规约AllReduce

1. 全规约AllReduce是多对多通信原语，具有多个数据发送者与多个数据接收者。它在集群所有节点上执行相同的规约Reduce操作，并将各节点的规约结果发送至每个节点。全规约AllReduce可通过在主节点执行规约Reduce+广播Broadcast或通过规约分散ReduceScatter+全聚合AllGather组合实现。

2. 全规约AllReduce是多对多数据规约操作，将集群中所有GPU的数据规约（如求和）后分发至各GPU。其应用场景包括：

• AllReduce可适用于数据并行场景；
• 各类通信拓扑中的数据并行场景，例如环式全规约（Ring AllReduce）与树状全规约（Tree AllReduce）中的全规约AllReduce实现。

全交换All-to-All

1. 全交换All-to-All操作中，每个节点将数据分散至集群所有节点，同时各节点也从集群所有节点收集数据。全交换All-to-All是全聚合AllGather的扩展形式，其区别在于：全聚合AllGather中不同节点从给定节点收集相同数据，而全交换All-to-All中不同节点从给定节点收集不同数据，本质上实现了数据转置操作。

2. 全交换All-to-All是多对多转置操作，将数据从所有GPU卡转置至集群中每张GPU卡。其主要应用场景包括：

• 全交换All-to-All适用于模型并行场景；
• 模型并行中的矩阵转置环节；
• 从数据并行到模型并行的矩阵转置过程。

从通信原语到通信库：以NCCL为例

NCCL（NVIDIA Collective Communications Library）是为GPU间通信提供原语的库。它具有拓扑感知能力，可轻松集成到各类应用中。NCCL实现了集体通信与点对点收发原语，并非完整的并行编程框架，而是专注于加速GPU间通信的工具包。

NCCL提供的集体通信原语包括AllReduce、Broadcast、Reduce、AllGather、ReduceScatter、AlltoAll、Gather与Scatter。此外，NCCL还支持点对点收发通信，可灵活实现Scatter、Gather或All-to-All操作。

通过NCCL，通信原语在概念层面被转化为可用的库函数。在传统CUDA编程中，集体通信通常通过多次CUDA内存拷贝操作与本地规约计算内核组合实现；NCCL将每个集体通信原语封装在单个内核中，同步处理通信与计算，从而实现更高效的同步并降低资源开销。

总结

在分布式深度学习训练中，训练框架本身通常不会直接操作底层通信网络，而是通过高性能通信库完成参数同步、梯度规约等操作。这些通信库既屏蔽了复杂的硬件细节，又提升了训练性能。不同的AI芯片和加速卡厂商会提供专属的通信库或扩展方案，例如硬件感知的MPI实现或自研CCL库，以优化底层网络的使用。

实际分布式训练集群中的网络互联形态极其多样：既可能采用以太网、InfiniBand、RoCE v1/v2等通用协议，也可能使用NVLink等专用或半专用高速互联协议。这就需要通信库能够结合厂商提供的SDK和接口，针对特定硬件进行优化，例如CUDA-aware MPI、NCCL、NVSHMEM等。同时，还需要根据实际的网络拓扑和节点布局，选择最合适的通信策略与算法。

参考资料:

1. GPU售前知识—AI分布式训练通信原语
2. Fast Multi-GPU collectives with NCCL
3. In-Depth Understanding of AI Distributed Training Communication Primitives

Overview

PIM和PNM是两种用于突破“存储墙”瓶颈的计算架构，旨在通过将计算能力与内存紧密结合来提高计算效率，减少数据在处理器和内存之间的传输延迟和带宽瓶颈。

As shown in Figure 3 (a), PIM places a processing unit (PU) alongside each memory bank so that parallel computations can be implemented across all memory banks, exploiting the high internal memory bandwidth. A PU can be a MAC (Multiply and Accumulate) unit, a compute core, or a database query processor, specialized in workloads with low arithmetic intensity. However, due to the constraints stemming from the memory process technology applied for the memory core die, PIM logic faces inherent limitations in supporting more complex computations, thereby restricting it to wimpy processing units. On the other hand, as depicted in Figure 3 (b), PNM places processing modules not in the memory core but rather on the data read path between the host processor and the memory node or local main memory. Similar to PIM, PNM is also suitable for workloads with low arithmetic intensity. However, since PNM logic is fabricated using standard logic process nodes, it allows for a broader range of supported operations. Thus, one can fuse multiple kernels into a single module,and exploit high aggregate bandwidth for task-specific computations.

PIM(存内处理)

PIM是指将计算单元直接集成到内存芯片内部，使得数据可以在存储位置直接进行处理。通过这种方式，PIM减少了数据在处理器（如CPU、GPU）和内存之间的传输，降低了延迟和能耗。

优势:

• 高带宽利用：内存内的计算能够充分利用内存的高带宽优势，因为计算和数据都在内存内部完成。
• 低延迟：减少数据在内存和处理器之间的往返传输，降低整体延迟。
• 节能：通过减少数据移动，PIM能够显著降低系统能耗。

PNM(近存计算)

PNM是将计算单元放置在内存附近的芯片上，而不是直接集成在内存内部。虽然不如PIM直接在内存中处理数据，但PNM仍然通过将处理器靠近内存来减少数据传输的延迟。

相比于PIM，PNM可以在更广泛的硬件配置中实现，因为计算单元和内存是物理分开的，易于升级和扩展。

PIM vs PNM

• PIM (Processing-in-Memory, 存内计算): 计算逻辑和存储单元在同一个die上.
• PNM (Processing-Near-Memory, 近存计算): 计算逻辑和存储单元在不同但邻近的die上.

下表总结了PIM和PNM在数据中心LLM推理场景的对比:

结论

针对数据中心LLM PNM优于PIM: 尽管PIM在理论带宽和功耗上更有优势, 但PNM在实际应用中更胜一筹.

• 软件分片(Sharding): PIM要求将数据切分到极小的内存bank(如32-64MB), 这对于LLM复杂的内存结构来说非常困难. PNM的分片粒度可以大得多(如16-32GB), 易于实现.
• 逻辑PPA (性能, 功耗, 面积): PNM的计算逻辑可以使用先进的逻辑工艺制造, PPA更优. 而PIM的计算逻辑受限于DRAM工艺, 性能较差, 功耗较高.
• 内存密度与成本: PNM不影响标准内存的密度和商品化定价.
• 功耗/散热预算: PIM中计算逻辑的功耗和散热受到DRAM die的严格限制.

参考资料:

1. 大语言模型推理硬件的挑战与研究方向
2. 科普专栏｜PIM PNM对OpenAI O1有多么重要？
3. Accelerating Retrieval Augmented Language Model via PIM and PNM Integration(MICRO’25)
4. PIM Is All You Need: A CXL-Enabled GPU-Free System for Large Language Model Inference
5. Processing-Near-Memory Systems: Developments fro Academia & Industry
6. deepseek对话

Flit Mode, PAM4(Pulse Amplitude Modulation with 4 levels), and FEC(Forward Error Correction)这三者构成了 PCIe 6.0 能倍增速率的核心“铁三角”。可以这样理解它们的关系：PAM4 是提速的“发动机”，FEC 是处理高误码的“安全网”，而 Flit Mode 则是为了让 FEC 能顺利工作的“标准化集装箱”。

它们是一条环环相扣的因果链：

起点：PAM4 提速，但引入了严重的误码

为了将传输速率从前代的 32 GT/s 翻倍至 64 GT/s，PCIe 6.0 将信号调制方式从 NRZ（1比特/时钟周期）换成了 PAM4（2比特/时钟周期）。代价是信号幅度被分成4级，对噪声更敏感，导致位错误率（BER）急剧上升。

对策：必须用 FEC 主动纠错

在如此高的错误率下，如果仍沿用传统的“错了就整包重传”机制，链路大部分时间都将浪费在无效的重传上，实际有效带宽可能不升反降。

因此，必须引入FEC。它在发送端加入校验数据，让接收端能直接在原地纠正大部分错误，只有遇到无法纠正的少量错误时才请求重传，从而将有效带宽保持在极高水平。

条件：FEC 需要定长数据块，催生了 Flit

FEC 算法(如低密度奇偶校验 LDPC)必须工作在固定长度的数据块上，通过计算整个数据块的校验位来纠错。而传统 PCIe 的 TLP长度是可变的，短至几个字节，长至几千字节，完全无法匹配 FEC 的要求。

于是，Flit应运而生。它把所有数据都打包进固定的 256 字节“集装箱”里，FEC 就能以此为基本单位进行编解码和纠错。Flit Mode 便是围绕这种固定包结构建立的全新数据交换规则。

协同工作的简化流程

一条数据在 PCIe 6.0 链路中的旅程如下：

1. 打包：各种不定长的 TLP 被按照 256 字节标准封装进 Flit
2. 编码纠错：每个 Flit 被加上 FEC 校验位，信号以 PAM4 形式高速发出
3. 接收纠错：接收端对 PAM4 信号采样，并利用 FEC 对每个 Flit 进行纠错
   • 多数情况：FEC 成功纠正了 PAM4 传输引入的错误，数据直接通过
   • 极少数情况：错误超出了 FEC 能力，则触发选择性重传，只重传出问题的那个 Flit

总结

• PAM4 是“因”：提速需求催生了 PAM4，也带来了高误码这个必须解决的技术挑战。
• FEC 是“核心手段”：为对抗高误码而引入的根本性纠错方案。
• Flit 是“必须的结构”：为满足 FEC 对定长数据块的要求而设计的新一代数据传输格式。

三者共同将 PCIe 6.0 打造成了一个速度极快、纠错极强且效率极高的互连通道。

参考资料:

1. A Deeper Dive into FLIT Mode, PAM4, and Forward Error Correction (FEC)
2. deepseek对话

PCIe Segment（段）是一个硬件层面的概念，指一组完全独立的PCIe总线域；而PCIe Domain（域）是Linux内核在软件层面为每个Segment分配的编号。

• PCIe Segment：是硬件概念。它代表一个完全独立的PCIe总线树，由独立的Root Complex（根复合体）管理。不同Segment之间的地址空间和配置空间是互相隔离的。多Segment常见于大型服务器，用于突破单个总线域只能有256个总线的限制。
• PCIe Domain：是Linux内核中的软件表示。内核使用域号来区分不同的硬件Segment。因此，可以在Linux的lspci -t命令的输出中看到“Domain: Bus: Device. Function”的格式，这个Domain号实际上对应的就是硬件Segment。

Segment和Domain的核心区别在于：一个Segment是物理上独立的总线树，而一个Domain则是内核给这个树分配的软件编号。举个例子，如果一台服务器有4个物理的PCIe Segment，在Linux中我们就会看到4个Domain（通常编号为0、1、2、3）。

一个系统中的每个PCIe 设备使用Domain: Bus: Device. Function来唯一标识，具体含义与取值范围如下：

核心是将PD分离放在两个或多个Datacenter中的异构GPU集群。

• 跨集群边界将Prefill从Decode中分离出来，通过将Prefill迁移到更快的计算硬件，可以降低长上下文请求的成本和延迟
• 这个问题的核心障碍在于 KVCache传输量太大。不过最近的混合注意力（Hybrid-attention）架构从根本上改变了这一局面，大幅减少了 KVCache的增长，通常降低了一个数量级
• 在真实的场景下由于请求到达的突发性和长短的不均衡，全部通过跨机房的专线传输还是很容易出现拥塞。 系统上我们需要尽可能识别值得传的 KVCache，从而实现跨机房异构 PD 不仅是更便宜，TTFT 还更低这一目标
• 最基本的原则就包括短的 incremental prefill 就在本地消化，长的才分到远端 prefill，但实际还需要进一步考虑网络拥塞和不同机房 KVCache 复用命中的情况

Prefill-as-a-Service：KVCache的跨数据中心传输
Prefill-as-a-Service：跨机房异构 PD 分离的最后一块拼图是线性注意力？
Kimi新论文：把KVCache玩成新商业模式了

IPADS开源形式化方法智能体FM-Agent

上海交大IPADS开源形式化方法智能体FM-Agent：让代码不仅可生成，还可推理
编程智能体的隐藏bug，被上交IPADS团队用数学逻辑给揪出来了

如今的Coding Agent生成十万行以上的系统级代码，甚至构建一个完整的编译器，都已不再稀奇。但一个严峻的挑战随之而来：如何保障这些大规模代码的正确性？上海交大IPADS团队推出形式化方法智能体FM-Agent，通过将形式化验证方法与LLM结合，首次实现了面向大规模软件的全自动正确性推理，对27万多行已经过层层测试的系统代码进行“深度体检”，找到522个被遗漏的隐蔽bug。

霍尔逻辑由图灵奖得主托尼·霍尔于约六十年前提出，但受限于人工成本，形式化方法在大规模软件中的应用始终未能普及。FM-Agent并未追求传统形式化验证所依赖的严格公式证明，而是借助大模型的强大推理能力，首次实现了面向大规模系统软件的全自动正确性推理。这一工作延续了霍尔逻辑的核心思想，站在巨人的肩膀上，同时也为形式化方法的实际落地提供了新的可行路径。

Harness Engineering

别再说”Prompt工程”了！2026全网爆火的Harness Engineering是什么鬼？

A Survey of Context Engineering for Large Language Models

https://mp.weixin.qq.com/s/deBKVO_TpuoYIfaXb6KlWw

上下文工程（Context Engineering）原理简介

Nsight Systems

NVIDIA Nsys 通常指的是 NVIDIA Nsight Systems（命令行工具nsys），是 NVIDIA 官方的系统级性能分析工具。它主要用于对 CUDA 应用程序进行全系统时间线分析，帮助开发者快速定位 CPU 和 GPU 之间的瓶颈，而不仅仅是 GPU 内核内部的耗时。

deepseek对话

Nsight Compute

Nsight Compute：专攻 GPU 内核内部的微架构分析（如带宽、占用率、指令吞吐），属于“内核级”分析。

https://developer.nvidia.com/nsight-compute

manim

可视化数学
https://github.com/3b1b/manim

dmidecode

https://github.com/mirror/dmidecode

Dmidecode reports information about your system’s hardware as described in your system BIOS according to the SMBIOS/DMI standard. This information typically includes system manufacturer, model name, serial number, BIOS version, asset tag as well as a lot of other details of varying level of interest and reliability depending on the manufacturer. This will often include usage status for the CPU sockets, expansion slots (e.g. AGP, PCI, ISA) and memory module slots, and the list of I/O ports (e.g. serial, parallel, USB).

2025阿里云技术年报 基础设施篇

https://mp.weixin.qq.com/s/ykEFWsM1VrYcDSj9KRdzaQ

如何在短时间内提升自己

https://mp.weixin.qq.com/s/LdeBYWcxb3ZSASf6aGo7aQ

Backgrpund

Overview

This design fully utilizes the capacity of both local DRAM and CXL memory by placing data exclusively at either of them, but not both. For example, once a cacheline is moved to local DRAM, it will no longer occupy any space in CXL memory.

The associativity between physical memory and local memory is direct-mapped, which means each line in the physical memory address space can only be cached at one location in local memory.

Details

参考Managing Memory Tiers with CXL in Virtualized Environments中的3.1 即可。

参考资料:

1. The Advantages of Managing the CXL Memory Tier in Hardware
2. Managing Memory Tiers with CXL in Virtualized Environments(OSDI’24)
3. deepseek会话

In-Network Computing

在网计算(In-Network Computing)，可以简单理解为：让网络在传输数据的过程中，顺便完成一部分原本属于主机的计算任务。这里的“计算”通常不是通用计算，而是聚合、归约、统计、筛选，以及某些固定模式的算术或逻辑操作。

在 AI 和 HPC 场景中，最有价值的一类在网计算，就是对集合通信中的归约操作进行卸载。因为归约是最常见、最频繁、也最容易在规模扩展后成为瓶颈的环节；如果交换机能够在数据流经时，先把多个节点发来的数据做一轮聚合，那么继续向上传输的数据量就会变少，最终回到端点的也不再是大量原始中间值，而是更接近结果的数据。

这会同时带来几个好处：

1. 降低端点参与归约的负担
2. 减少网络中传输的中间数据
3. 缩短集合通信完成时间
4. 提高系统扩展效率

而 SHARP，就是这种思想在高性能网络中的代表性实现。

SHARP的介绍

传统模式下，交换机只负责收包、转发、出包；即使是 AllReduce 这类高度结构化的操作，交换机本身也并不真正“理解”归约，因此大量中间数据仍需要在端点之间来回流动，归约主要还是由主机侧完成。

SHARP(Scalable Hierarchical Aggregation and Reduction Protocol)是 NVIDIA 的一种in-network computing技术，用来把 AllReduce、Reduce、Broadcast 等集合通信操作从 CPU/GPU 卸载到 InfiniBand 交换网络中执行。

AllReduce

现代AI训练（如大语言模型）和科学计算严重依赖于集合通信，尤其是 AllReduce 操作（用于同步梯度、参数等）。AllReduce的通信开销常常成为训练瓶颈。

1. 传统AllReduce（无SHARP）

• 数据在GPU间多次传输。
• 最终聚合计算由某个GPU的CUDA核心完成。
• 占用宝贵的GPU计算资源（尽管是轻量计算）。
• 产生大量网络流量，消耗带宽，增加延迟。

2. 使用SHARP的AllReduce

• 计算卸载： 聚合计算（如求和）由交换机内部的专用硬件引擎执行。
• 流量锐减： 数据在交换机树形网络的每一级就开始聚合，网络中传输的数据量逐级减少，极大降低了最终的网络流量（可降低高达50%以上）。
• 解放GPU： GPU无需处理聚合计算，可以更专注于张量核心的计算。
• 降低延迟： 在网络中就近计算，减少了端到端的通信延迟。

3. 核心价值： 将网络从一个被动的“数据搬运工”，转变为一个主动的“计算参与者”，从而打破集合通信的瓶颈。

工作原理

以最常见的“求和”AllReduce为例，剖析SHARP工作原理：

1. 初始化与配置： 集群管理软件（如NCCL）识别到支持SHARP的交换机拓扑，并为本次AllReduce操作在交换机上配置一个“聚合树”。
2. Leaf叶子节点发送： 每个GPU（主机）将其需要聚合的数据块发送到它所连接的第一级（Leaf叶子）交换机。
3. 第一级聚合： Leaf叶子交换机的SHARP引擎接收来自其下所有GPU的数据，在交换机内部硬件中直接进行求和计算，生成一个部分聚合的结果。
4. 向上传播： Leaf叶子交换机将部分聚合的结果（数据量已小于原始多份数据的总和）发送到上一级（Spine主干）交换机。
5. 递归聚合： Spine主干交换机的SHARP引擎再次接收来自多个下级交换机的部分聚合结果，并进行第二次聚合。此过程在交换机的层次结构中持续向上，直到到达聚合树的根交换机。
6. 生成全局结果： 根交换机生成最终的全局聚合结果（所有GPU数据的总和）。
7. 结果广播： 根交换机再将这个最终结果沿聚合树向下广播到所有参与计算的GPU。

关键点： 数据在向上传输的过程中不断被“压缩”（聚合），因此从根节点向下广播的数据量是最小的（一份完整结果）。这相比于传统的环状或树状AllReduce算法，显著减少了网络的总数据吞吐量。

SHARP vs. GPUDirect RDMA

1. GPUDirect RDMA： 解决的是“路径”问题，允许第三方设备（如网卡）直接访问GPU显存，绕过CPU和系统内存拷贝，降低延迟。它优化的是点对点通信。
2. SHARP： 解决的是“流量和计算”问题，在网络内对多个数据流进行聚合计算，优化的是集体通信。
3. 关系： 它们是互补的，可以同时启用。GPUDirect RDMA确保数据从GPU到网络的路径最优，而SHARP确保数据在网络中的聚合效率最高。现代AI集群通常同时启用这两项技术。

总结

SHARP是构建大规模、高效率GPU计算集群的一项革命性网络技术。它通过“网络内计算”的理念，直接攻克了分布式AI训练中最耗时的集合通信瓶颈，是当今万卡级GPU集群不可或缺的关键技术之一。

参考资料:

1. 【论文阅读】Scalable Hierarchical Aggregation Protocol (SHArP)
2. Pushing the Limits of AI with In-Network Computing
3. GPU集群性能提升技术——IB交换机中的SHARP详解
4. SHARP与在网计算
5. NCCL 原理详解：让多GPU通信更高效

• 当 Docker 不再安全：腾讯云 CubeSandbox 如何用 Rust+KVM 重塑 AI Agent 沙箱
• TencentCloud/CubeSandbox

核心优势

• 极致冷启动： 基于资源池化预置和快照克隆技术，直接跳过耗时初始化流程。整个沙箱服务端到端冷启动一个可服务的沙箱时间平均 < 60ms
• 单机千例的高密部署： 基于 CoW 技术实现极致内存复用，用 Rust 重构底层极致裁剪，使得单实例内存开销低至 <5MB，轻松在一台机器上跑起数千个 Agent。
• 真正的内核级隔离： 告别不安全的 Docker 共享内核（Namespace）。每个 Agent 拥有独立的 Guest OS 内核，杜绝容器逃逸，放心运行任何大模型生成的未知代码。
• 零成本迁移（E2B 完美平替）： 原生兼容 E2B SDK 接口规范。只需替换一个 URL 环境变量，无需业务代码改动就可切换到免费的 Cube Sandbox，并获得更好的性能体验。
• 网络安全： 基于 eBPF 的 CubeVS 在内核态实现严格的沙箱间网络隔离，支持细粒度出站流量过滤策略。
• 开箱即用： 可一键快速部署，同时支持单机部署和集群部署。
• 事件级快照回滚（coming soon）： 百毫秒级的高频快照回滚能力，基于快照快速创建分叉探索环境

历史文档:

• Cube轻量虚拟化如何做到100ms交付一个安全容器

IPADS开源SkVM

上海交大IPADS开源SkVM：让Agent Skill”一次编写，处处高效运行”

Agent时代重新思考编译技术：Skill是代码，LLM+Harness是异构处理器，借鉴语言虚拟机（Language VM）的设计理念，首次将传统编译器与运行时思想系统性地引入Agent技能领域，SkVM让Skill一次编写，到处高效执行。

核心理念：把Skill当作程序来编译

英伟达 GPU 机密计算

英伟达 GPU 机密计算：AI 时代机密计算边界的延伸

传统机密计算主要保护 CPU 执行环境中的数据与代码，其目标是在操作系统、虚拟化层乃至平台管理员不完全可信的前提下，仍然保证工作负载的机密性与完整性。Intel TDX、AMD SEV-SNP 和 Arm CCA 虽然实现路径不同，但本质上都属于 CPU 侧可信执行环境基础设施：通过硬件隔离、内存保护、启动测量和远程证明，为虚拟机或受保护执行域建立一个不依赖宿主软件信任的安全边界。它们解决的核心问题是，应用在 CPU 和系统内存中运行时，如何不被宿主环境窥探或篡改。

但在 AI 基础设施中，仅有 CPU 侧保护并不充分。因为真正承载高价值数据和核心计算的，往往已经不是 CPU，而是 GPU。模型权重、推理输入、检索增强数据、中间激活值乃至部分业务逻辑，都会进入 GPU 显存并在加速器上执行。如果机密计算只覆盖 CPU 虚拟机，而无法覆盖 GPU 执行路径，那么对 AI 而言，这种保护就是不完整的。英伟达 GPU 机密计算的意义，正是在于把机密计算的保护边界从 CPU 扩展到 GPU，使 GPU 成为整个可信执行体系的一部分，保护模型参数、数据和其他重要客户资产。

为什么 AI 时代值得重新讨论 OS：从 Linux Kernel 到 GPU 执行栈的系统重构

https://mp.weixin.qq.com/s/dVpd5_99co4wk0L-tOpiJQ

AI时代的操作系统革新，核心不在于推翻Linux，而在于围绕tensor、graph、kernel、KV cache等新的一等对象，建立一套从驱动、编译器到运行时服务的全新系统抽象，以管理和调度异构计算资源。

DPU PCC

DPU PCC：为什么拥塞控制从“固定算法”走向“可编程”

DOCA 官方给出的定义非常直接：Programmable Congestion Control（PCC）允许用户设计并实现自定义的拥塞控制算法，以更灵活地处理集群中的网络拥塞问题。
PCC 不是一个具体的拥塞控制算法，而是一个拥塞控制开发框架。它的目标是提供一套 API 和执行环境，让客户可以自己写算法、加载算法、运行算法，并基于网络反馈动态调整每条流的发送速率。

DPU PCC 的本质，是把拥塞控制从一个封闭的网卡内置算法，升级成一个运行在 DPU 数据路径加速环境中的可编程控制框架。它让开发者能够围绕真实业务需求，自定义反馈机制、流状态管理和速率调节逻辑，从而在 AI、存储和多租户集群中获得更合适的网络行为。

Sandlock：最轻量级的 AI Agent 沙箱

The lightest AI sandbox. A process-based sandbox for Linux, no container, no VM, no root.

应对AI Agent的安全问题，不应盲目堆叠重量级的硬件隔离，而应针对其应用层的行为模式，设计精细、轻量的访问控制策略。Sandlock正是这一理念的实践，它提供了一种更贴合Agent本质的安全方案。

• https://mp.weixin.qq.com/s/ICxIj6ydpftSLwgjA9zZAg
• https://github.com/multikernel/sandlock

Lightweight process sandbox for Linux. Confines untrusted code using Landlock (filesystem + network + IPC), seccomp-bpf (syscall filtering), and seccomp user notification (resource limits, IP enforcement, /proc virtualization). No root, no cgroups, no containers.

1

sandlock run -w /tmp -r /usr -r /lib -m 512M -- python3 untrusted.py

Bubblewrap vs Sandlock

Bubblewrap和Sandlock是两种设计理念和实现路径都截然不同的沙箱工具。简单来说，Bubblewrap是一个通用的、轻量级的“容器构建工具箱”，而Sandlock是一个为AI Agent场景专门设计的、高密度的“进程执行沙箱”。

目标定位不同

Bubblewrap是一个通用的工具，旨在安全地运行一个浏览器或一个游戏等普通应用。而Sandlock则是专为AI Agent量身定做，它思考的问题是：“如何安全、高效地让大模型生成的上万个代码片段并发执行？”。

安全模型的根本分歧

这源于它们对“敌人”的不同理解。

• Bubblewrap默认环境中可能存在主动的攻击者，因此首要任务是利用Namespace创建一个与外界隔绝的“硬边界”。
• Sandlock则认为Agent不是攻击者，真正的风险是提示词注入。它的核心不是建立边界，而是通过Landlock和Seccomp执行一套精细的访问控制策略（Policy），例如这个Agent只能读/data目录，只能写/tmp。

效率的极致追求

在AI场景中，常需同时运行成百上千个沙箱实例。Bubblewrap每个实例都需要独立的初始化过程，资源开销会线性增长。而Sandlock通过其写时复制（COW） 技术，可以瞬间从一个“黄金镜像”克隆出上千个实例，共享内存，极大节省了时间和空间。同时，Sandlock的开销极低，启动仅需5毫秒，远快于传统容器或虚拟机。

如何选择

选择Bubblewrap，如果你的目标是：

• 为普通桌面应用（如一个闭源游戏或聊天软件）提供一个基础的运行沙箱。
• 需要一个无需守护进程、轻量级的通用沙箱工具。

选择Sandlock，如果你的目标是：

• 在AI Agent系统中安全地执行由模型生成的不可信代码。
• 需要高并发、低延迟地执行大量短暂任务（如批量代码评估）。
• 需要精细到每个工具调用的访问控制策略。

基于GPU加速的内存回收方案

vivo的ZRAM异构压缩技术：基于GPU加速的内存回收方案

key idea: 将zram压缩内存数据的操作由CPU offload到GPU以进行加速。

• 当我们谈论 AI 推理的 KV Cache，我们在说什么？
• 阿里云提出基于CXL的KV缓存管理内存架构Beluga

Memory Mirroring

The Intel Xeon processor family-based platform offers a RAS (Reliability Availability Serviceability) feature called Memory Mirroring. This feature allows users to configure the memory in a highly reliable mode such that system uptime can be maintained—even when a memory component is affected by an uncorrectable fault. When enabled, a trade-off between memory capacity and reliability is required. For example, user-accessible memory may be reduced to half of the total available memory.

Address Range Partial Memory Mirroring

The Intel Xeon processor E7 v3 product family-based platform introduces a new layer of support for partial memory mirroring called Address Range Mirroring. When Address Range Mirroring is used, the platform allows an OS to specify a subset of total available memory for mirroring (and also to optionally specify whether to mirror the range 0–4 GB). This capability allows a user to make an appropriate trade-off between non-mirrored memory range and mirrored memory range, thus optimizing total available memory while keeping highly reliable memory range available for mission-critical workloads and/or kernel space.

Legacy memory mirroring is transparent to the OS; however, address range mirroring requires a firmware-OS interface for a user to specify the desired subset of memory to mirror. To fully utilize Address Range Mirroring:

• Present partial or total mirrored memory on the platform to the OS.
• Provide the OS a method to request the amount of mirrored memory that takes effect on subsequent boots.

总结

1. Legacy Memory Mirroring是将所有内存都做mirror，因而available memory会减半
2. Address Range Partial Memory Mirroring是选择部分内存做mirror

参考资料:

1. Address Range Partial Memory Mirroring

流程

每一次内存访问都会指定一个mkey和一个VA地址，mkey来自WQE或报文里的LKEY/RKEY，它是一个32bits的地址空间标识，包含index和key两部分。MTT地址翻译过程如下：

1. 使用mkey.index索引mkey context table(MPT)得到mkey context。
2. Key检查：对比mkey.key和mkey context里的key是否一致。
3. PD检查：对比发起内存访问的QP里的PD和mkey context里的PD是否一致。
4. 地址范围检查：mkey context对应了一个MR，里面包含address和length两个字段用于指明MR的范围，这里需要检查当前正在进行的内存访问是否在这个MR范围内。
5. 访问权限检查：根据mkey context内的local/remote read/write/atomic权限检查当前操作是否合法。
6. 当上面的检查通过时，就可以使用mtt pointer了，它是MTT表的基地址。
7. 访问MTT表需要一个索引MTT index=当前访问地址accessing VA - mkey_context.va得到，其中mkey_context.va是MR的起始地址。另外需要考虑PA所指向的page大小，当page为4K时，上面的MTT index还要右移12位。
8. 用上面的index索引MTT表就能得到一个MTT entry，它里面包含一个PA地址，即page number页号。如果page为4KB则最终的PA = (page number << 12) + (accessing VA & 0xfff)。

上述步骤均由RDMA硬件完成。

MTT entry

MTT entry的细节可以Mellanox Adapters Programmer’s Reference Manual (PRM):

State Machine

总结

• MTT:用于记录本地内存的物理地址映射，以便远端节点可以直接访问这些内存区域。
• MPT:用于定义哪些本地内存区域可以被远端节点访问，以及它们的访问权限（如读/写）。每当有新的 RDMA 操作请求到来时，RDMA硬件会检查 MPT，以确定是否允许此次访问。
• MTT 和 MPT 是 RDMA 技术中不可或缺的组成部分，前者负责将虚拟地址转换为物理地址，后者则提供内存访问的安全性和隔离性。两者共同作用，确保了 RDMA 操作既高效又安全。

参考资料:

1. RDMA 高级
2. Mellanox Adapters Programmer’s Reference Manual (PRM)
3. RDMA 关键技术研究：Memory Region
4. 从阿里云eRDMA看如何解决RDMA在数据中心大规模使用问题
5. 【RDMA MPT && MTT简介】
6. 自研RDMA的地址翻译表的实现技术

原理

• pin住host的dram内存
• host CPU mmu建立VA到pinned memory的映射
• GPU mmu建立VA到pinned memory的映射

通过将一段pin住的物理内存，同时映射到CPU和GPU的虚拟地址空间来实现。这样一来，GPU内核就能像访问自己的显存一样，直接读写这块主机内存，省去了显式的cudaMemcpy操作。

Advantages

GPU threads can directly access zero-copy memory. There are several advantages to using zero-copy memory in CUDA kernels, such as:

• Leveraging host memory when there is insufficient device memory
• Avoiding explicit data transfer between the host and device
• Improving PCIe transfer rates

劣势与挑战

• 带宽瓶颈: 访问速度受限于PCIe总线带宽。对频繁访问的数据，效率远低于本地显存。
• 高延迟: 每次访问都需经过PCIe总线，延迟比本地显存高几个数量级。

实践

分配并映射新的pinned内存
这种方式直接分配并映射一块全新的host pinned内存，是最常见的方法。

• 核心API: cudaHostAlloc
• 关键步骤:
  • 分配：使用 cudaHostAlloc 并指定 cudaHostAllocMapped 标志。
  • 获取设备指针：通过 cudaHostGetDevicePointer 获取该内存对应的GPU侧有效指针。
  • 在核函数中使用：将设备指针传入核函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#include <cuda_runtime.h>
#include <stdio.h>

// GPU 核函数：直接对主机上的锁页内存进行操作
__global__ void vector_add_kernel(float *a, float *b, float *c, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < n) {
        // 直接访问主机上的锁页内存，如同访问显存
        c[idx] = a[idx] + b[idx];
    }
}

int main() {
    int n = 1024;
    size_t size = n * sizeof(float);

    // 1. 在主机上分配并映射锁页内存
    float *h_a, *h_b, *h_c;
    cudaHostAlloc((void **)&h_a, size, cudaHostAllocMapped);
    cudaHostAlloc((void **)&h_b, size, cudaHostAllocMapped);
    cudaHostAlloc((void **)&h_c, size, cudaHostAllocMapped);

    // 2. 在主机端初始化数据
    for (int i = 0; i < n; ++i) {
        h_a[i] = 1.0f;
        h_b[i] = 2.0f;
    }

    // 3. 获取该主机内存对应的GPU设备指针
    float *d_a, *d_b, *d_c;
    cudaHostGetDevicePointer((void **)&d_a, (void *)h_a, 0);
    cudaHostGetDevicePointer((void **)&d_b, (void *)h_b, 0);
    cudaHostGetDevicePointer((void **)&d_c, (void *)h_c, 0);

    // 4. 配置核函数并启动
    int threadsPerBlock = 256;
    int blocksPerGrid = (n + threadsPerBlock - 1) / threadsPerBlock;
    vector_add_kernel<<<blocksPerGrid, threadsPerBlock>>>(d_a, d_b, d_c, n);
    cudaDeviceSynchronize();

    // 5. 检查结果，此时结果已直接写入主机的 h_c 中
    for (int i = 0; i < n; ++i) {
        if (h_c[i] != 3.0f) {
            printf("Error: h_c[%d] = %f\n", i, h_c[i]);
            break;
        }
    }
    printf("Test passed!\n");

    // 6. 清理资源
    cudaFreeHost(h_a);
    cudaFreeHost(h_b);
    cudaFreeHost(h_c);
    return 0;
}

参考资料:

1. cuda-samples
2. Page-Locked Host Memory
3. Professional CUDA C Programming
4. https://chat.deepseek.com/share/ran9srj0hi8t35xmsw

Why Bubblewrap Beats Docker

This beats Docker for quick workflows. Docker requires a running daemon and lots of configuration files. Bubblewrap lets you execute your app directly—no daemon, no stale containers cluttering your system.
这比 Docker 更适合快速工作流。Docker 需要运行一个守护进程，还要准备一大堆配置文件。而 Bubblewrap 让你可以直接运行应用程序——没有守护进程，也不会有残留的容器把系统搞得乱七八糟。

If you’re experienced enough to worry about Docker misconfigurations, Bubblewrap gives you more control when you need it. You just run a command. No YAML files or debugging background services.
如果你经验足够丰富，会担心 Docker 配置不当带来的问题，那么 Bubblewrap 能在你需要的时候给你更强的控制力。你只需要执行一条命令就行，无需编写 YAML 文件，也不用去排查后台服务的故障。

Key Differences

When to Use Which?

Use Bubblewrap when:

• You need to run a single, untrusted command in an existing shell session with limited file system or network access (e.g., running untrusted code from an AI agent).
• You want a lightweight security sandbox without the overhead of building full container images or running a daemon.
• You are developing or using desktop applications (it is a core component of Flatpak for sandboxing applications).

Use Docker when:

• You need to package an application and all its dependencies into a consistent, portable unit for deployment across different environments (development, staging, production).
• You require an ecosystem for managing container lifecycles, orchestration (e.g., Kubernetes integration), and large-scale application delivery.
• You are building microservices or other server-side applications that need a repeatable build process.

参考资料:

1. A better way to limit Claude Code (and other coding agents!) access to Secrets

ECMP

在路由协议中，如果下一跳有多个路径可以选择，并且多个路径的 cost metric 相等，那么路由器就会根据包的 header，计算一个 hash 值，然后根据这个 hash 值对这个 flow 选择一条固定的路径，作为下一跳。

ECMP是一个基于流的负载均衡策略，当路由器发现同一目的地址出现多个最优路径时，会更新路由表，为此目的地址添加多条规则，对应于多个下一跳。可同时利用这些路径转发数据，增加带宽。ECMP算法被多种路由协议支持，例如： OSPF、ISIS、EIGRP、BGP等。

对于未开启ECMP的网络来说，无法充分利用路径资源。例如下图所示：

假设从S0到Server的路径为S0-S1-S2-S4（即图中橘色路径），那么即便存在另一条等价路径（即图中蓝色路径），路由器仍然会每次选择第一条橘色路径转发数据。除非此条路径发生拥塞，才会重新选择路径。

当开启ECMP功能时，便可同时利用两条路径，进行基于流的负载均衡。例如主机A到Server的数据流选择橘色路径，主机B到Server的数据流选择蓝色路径。

ECMP的路径选择策略有多种方法：

• 哈希： 例如根据源IP地址的哈希为流选择路径
• 轮询： 各个流在多条路径之间轮询传输
• 基于路径权重： 根据路径的权重分配流，权重大的路径分配的流数量更多

ECMP’s Dilemma in AI Workloads

Datacenters often utilize Clos networks as their underlying fabric, which provides multiple equal-cost paths between any source and destination. To distribute traffic across these paths,ECMP is the most widely used load balancing(LB) mechanism, which determines the path of a flow by hashing the 5-tuple in the packet header. ECMP works well for traditional workloads, where there are millions of flows that ensure a relatively even distribution of traffic. However, unlike traditional datacenter workloads, AI training workloads exhibit traffic patterns that are fundamentally mismatched with ECMP’s design:

1. Small number of flows: In AI training job, each node establishes very few connections, as communication is only required with a limited set of peers.
2. Large flow sizes: The flow sizes typically range from several MBs to hundreds of MBs.
3. Bursty traffic: AI training is an inherently synchronized process, where most nodes enter the communication phase almost simultaneously. This synchronization results in a bursty traffic pattern, with large volumes of data being exchanged in a short period of time.

These flow characteristics (i.e., few in number, large in size) result in a high ECMP collision rate, as the small number of flows can’t be evenly distributed across available paths, leading to severe performance degradation in AI training workloads.

packet spraying

Packet spraying is a high-performance network load-balancing technique that distributes individual packets of a data flow across multiple available network paths rather than relying on a single path. By utilizing all paths, it achieves high link utilization and reduces tail latency, particularly beneficial for data center AI/ML workloads and bursty traffic.

Key details about packet spraying:

• Benefits: It provides high throughput, mitigates congestion, and is effective for short-lived, latency-sensitive traffic.
• Techniques:
  • Random Packet Spraying (RPS): Randomly assigns packets to paths to balance load.
  • Deterministic Packet Spraying: Uses a counter to distribute packets to ensure even path distribution.
  • Adaptive Packet Spraying (APS): Dynamically steers packets away from congested paths based on real-time feedback.
• Challenges: The main drawback is potential out-of-order packet delivery, which can trigger unnecessary retransmissions.

总结

• ECMP是flow粒度的Load Balance技术
• packet spraying是packet粒度的Load Balance技术，粒度更细，但是会引入out-of-order packet delivery问题

参考资料:

1. Unlocking ECMP Programmability for Precise Traffic Control(NSDI’25)
2. 数据中心网络高可用技术：ECMP
3. ECMP网络的介绍(转)
4. Equal-Cost Multi-Path Routing (ECMP)
5. Enabling Packet Spraying over Commodity RNICs with In-Network Support(APNET’25)
6. On the Impact of Packet Spraying in Data Center Networks(Infocom’13)

Background

现代固态硬盘(SSD)内部通常配备了一定容量的DRAM作为缓存，它的主要作用是存放FTL(Flash Translation Layer)映射表和其他临时数据，以加速SSD的数据处理效率。

FTL映射表记录了逻辑地址到物理地址之间的转换关系，因为NAND闪存的特性决定了其不能像传统硬盘那样进行直接的线性读写，必须通过FTL层来管理块擦除、页编程等操作。由于NAND闪存的每个块或页都有一个唯一的物理地址，当操作系统请求对某个逻辑地址进行读写时，SSD需要查询FTL表以找到对应的物理位置。如果FTL表能存储在快速访问的DRAM中，那么SSD就可以更快地完成地址转换，从而提高整体I/O性能。

在传统的SSD中，DRAM起着至关重要的作用，包括存储元数据、缓冲写入数据、合并短写入为长写入以及在SSD内部为了垃圾回收而移动数据等。由于NAND闪存与传统硬盘的工作机制有显著差异，DRAM有助于弥补两者间的交互问题，并优化整体性能。

DRAM-less SSD是一种不内置独立DRAM芯片的固态硬盘，它依赖于主机服务器的部分DRAM内存来执行原本由SSD内部DRAM承担的任务。这种设计的主要优点在于降低成本和降低功耗，尤其是在大规模数据中心用户中受到欢迎。

What

DRAM-less SSD通过利用主机内存中的Host Memory Buffer (HMB)替代内部DRAM，这使得主机能够更紧密地控制SSD的操作时机和行为。

Spec

NVME协议中对HMB有2个关键参数：

• HMB建议值（HMPRE）：设定实际分配给HMB使用的主机内存容量，为设备提供最优性能的内存分配量
• HMB最小值（HMMIN）：确保设备正常工作的HMB的最低内存分配量，低于这个值可能影响性能

参考资料 ：

1. 探究NVMe SSD HMB应用场景与影响
2. Exploring Performance Paradigm of HMB NVMe SSD’s
3. NVMe spec

Prerequisite

NVMe CMB机制

While CMB and PMR are PCIe-based memory on the NVMe drive, the PMR is specifically designed to be non-volatile (persistent), whereas the CMB is typically volatile.

PMRs add persistent to CMBs.

Introduction

Persistent Memory Region (PMR) is an optinal area of persistent memory that is located on the NVMe device, that can be read with standard PCIe memory reads/writes. This could be extra DRAM that is power protected, storage class memory or other new memory types.

Mode of Operation

参考资料:

1. 太强大了！NVMe SSD变身内存！
2. What is Persistent Memory Region?
3. NVMe SSDs with Persistent Memory Regions
4. Important new NVMe features for optimizing the data pipeline

Prerequisite

VLAN

Motivation

虚拟机规模受限制

一台物理服务器上可能运行几十甚至上百台虚拟机，但接入交换机的 MAC 地址表容量有限，无法支撑海量虚拟机的 MAC 学习需求。

网络隔离能力弱

传统 VLAN 只有 12个比特位，最多支持 4096 个隔离域。对于大型云平台而言，租户数量可能远超这个数字，VLAN不够用了。

虚拟机迁移范围受限

虚拟机迁移通常要求目标主机在同一个二层广播域内，这就限制了迁移只能在一个较小的物理范围内进行，无法实现跨机房、跨数据中心的灵活迁移。

Introduction

VXLAN是主流的overlay技术，通过“MAC in UDP”的封装方式，将二层以太网帧封装在 UDP 报文中，通过三层 IP 网络进行传输。

这样一来再也不怕虚机“乱跑”了：

虚拟机的 MAC 地址只在 VXLAN 边缘设备（VTEP）之间可见，中间网络设备无需学习，解决了 MAC 表瓶颈。

使用 24 位的VNI（VXLAN Network Identifier），支持多达 1600万个隔离段。

只要IP可达，虚拟机就可以跨任意三层网络迁移，构建了一个“虚拟大二层”。

核心组件

VTEP

A VTEP(VXLAN tunnel endpoint) is an edge device on a VXLAN network and the start or end point of a VXLAN tunnel. The source VTEP encapsulates the original data frames sent by the source server into VXLAN packets and transmits them to the destination VTEP on the IP network. The destination VTEP then decapsulates the VXLAN packets into the original data frames and forwards the frames to the destination server.

VNI

A VNI(VXLAN Network Identifier) is a user identifier similar to a VLAN ID. A VNI identifies a tenant. VMs with different VNIs cannot communicate at Layer 2.

VXLAN Gateway

Similar to in VLANs, hosts with different VNIs or those on VXLAN and non-VXLAN networks should be unable to directly communicate with each other. To meet these communication requirements, VXLAN introduces VXLAN gateways.

packet

VXLAN packet format (outer IPv4 header used as an example)
As shown in the preceding figure, a VXLAN tunnel endpoint (VTEP) encapsulates the following headers into the original Ethernet frame (original L2 frame) sent by a VM:

• VXLAN header
  A VXLAN header (8 bytes) contains a 24-bit VNI field, which is used to define different tenants on the VXLAN network. It also contains a VXLAN Flags field (8 bits, set to 00001000) and two reserved fields (24 bits and 8 bits, respectively).
• UDP header
  The VXLAN header and the original Ethernet frame are used as UDP data. In the UDP header, the destination port number (VXLAN Port) is fixed at 4789, and the source port number (UDP Src. Port) is calculated using a hash algorithm based on the original Ethernet frame.
• Outer IP header
  In the outer IP header, the source IP address (Outer Src. IP) is the IP address of the VTEP connected to the source VM, and the destination IP address (Outer Dst. IP) is the IP address of the VTEP connected to the destination VM.
• Outer MAC header
  The outer MAC header is also called the outer Ethernet header. In this header, the source MAC address (Src. MAC Addr.) is the MAC address of the VTEP connected to the source VM, and the destination MAC address (Dst. MAC Addr.) is the MAC address of the next hop along the path to the destination VTEP.

So basically the underlay is the actual physical topology doing the routing. While the overlay is the virtual network interconnecting the end devices between which overlay protocol is configured.

If we look at the packet itself, this is how it looks in overlay (the blue portion - the original frame) vs underlay (the red+blue - the encapsulated frame):

流程

如图所示：VM A发出数据包给VTEP后，VTEP-1 收到这个包，查表发现 VM B 在远端的 VTEP-2 下面，便开始封装vxlan包。VTEP-2 收到这个 IP 包，发现目的端口是 4789，知道这是个 VXLAN 包后剥离外层 MAC、IP、UDP、VXLAN 头，取出里面的原始以太网报文送给VM B，VM B 收到的就是一个标准的以太网报文，完全感知不到经历了中间的“包装”。

总结

VXLAN 不仅是技术的演进，更是云时代网络架构的必然选择。它通过封装与隧道技术，在 IP 网络上构建出灵活、可扩展、多租户隔离的虚拟二层网络，真正实现了“网络随业务而动”。

参考资料:

1. 一文搞懂VXLAN：云计算背后的网络“黑科技”
2. Introduction to Virtual Extensible LAN (VXLAN)
3. Understanding Underlay and Overlay networks
4. What Is VXLAN?
5. Vxlan explained in simple terms | Cisco CCNA 200-301
6. VxLAN | Part 1 - How VxLAN Works
7. rfc7348
8. VXLAN原理介绍以及Linux和OvS的实现分析
9. Linux 网络虚拟化隧道技术 VxLAN 全面了解

黄色路径非P2P路径，RDMA CX5网卡接后收到数据后，先写到主存DRAM中， NVME 设备驱动从主存读取数据再写入NVME SSD硬盘中。

绿色P2P路径， RDMA NIC网卡获取数据后直接写入NVME SSD硬盘。

P2P通信带来的收益:

1. 减少了主存DRAM的使用
2. 缩短了通信路径，提升了数据传输的效率

p2p操作序列

参考资料:

1. Important new NVMe features for optimizing the data pipeline
2. PCIe P2P
3. NVMe Over Fabrics Offload video
4. NVMe Over Fabrics Offload slides