过去几十年里，计算机系统一直绕不开一个经典问题：内存墙。
CPU 越来越快，内存访问却跟不上。于是我们发明了缓存、预取、NUMA、高带宽内存、近内存计算，试图让处理器不要"饿死"。
但到了今天，真正麻烦的可能已经不只是"内存够不够快"。
在 GPU、DPU、AI 加速器、CXL 内存池、PCIe 设备、压缩引擎、交换芯片共同组成的异构服务器里，新的瓶颈正在出现：
我们不再只是搬不动数据，而是越来越难知道数据到底是怎么被搬动的。
更准确地说，现代机器遇到的是一种新的"内存墙"：
异构内存墙。
它不是单纯的带宽问题，而是一个关于控制流、数据流、可观测性、调试、迁移和安全审计的问题。
这也是本文要讨论的 Slug Architecture 的核心动机：
能不能让未来的 CXL 异构系统，像传统冯·诺依曼机器一样，可以被观察、记录、回放和验证？
一、传统冯·诺依曼机器为什么好调试？
经典冯·诺依曼模型有一个很强大的抽象：
一个处理器读取内存中的状态，执行一串指令，然后通过 load/store 改写内存状态。
这听起来很普通，但它带来了巨大的工程便利。
因为只要我们在合适的边界上记录：
- CPU 寄存器；
- 内存内容；
- 指令流；
- 中断和特权状态；
- 一些关键 I/O 事件；
理论上就可以把一段执行过程保存下来，之后迁移、调试、重放，甚至在另一台机器上复现。
操作系统、虚拟机、调试器、checkpoint/restart、确定性回放，这些能力本质上都建立在这个抽象之上。
换句话说，传统计算机之所以"可控"，是因为我们大体相信：
CPU 是因果关系的中心，内存是被动对象，设备行为可以由操作系统或驱动程序中介。
但这个假设在今天已经越来越站不住了。
二、现代服务器已经不是"一颗 CPU + 一堆内存"
现在的服务器，尤其是 AI 和云计算场景里的服务器，已经更像一个小型联邦系统。
里面可能有：
- CPU；
- GPU；
- DPU；
- NPU / AI 加速器；
- 压缩与加密引擎；
- DMA 控制器；
- PCIe 设备；
- CXL switch；
- CXL Type-3 内存扩展设备；
- HBM；
- 持久化内存；
- 存储级内存；
- 甚至未来的 UCIe chiplet。
每个组件内部可能都有自己的执行逻辑、缓存、队列、固件、微码、调度器和私有内存。
从局部看，它们也许都是"小型冯·诺依曼机器"。
但从全局看，这台机器已经不是一个简单的冯·诺依曼系统了。
CPU 把任务 offload 给 GPU，GPU 通过命令队列执行 kernel；统一内存系统在后台做 page migration；DMA 引擎悄悄把数据写入某段内存；CXL 设备通过 CXL.cache 和 CXL.mem 参与缓存一致性和内存访问；交换芯片又可能影响请求的排序。
于是问题来了：
当某个 tensor 被错误修改时，到底是谁写的？
是 CPU？
是 GPU kernel？
是 DMA？
是 CXL 设备？
是驱动？
是统一内存迁移？
还是某个加速器在合法事务中做了非法事情？
传统的 CPU trace 很难回答这个问题。
三、异构系统里的"残余流"：真正难观察的部分
在异构计算里，CPU 往往只是提交任务的人。
比如：
- CUDA kernel launch；
- GPU command buffer；
- DMA descriptor；
- DSA work queue；
- AMX 调用；
- I/O accelerator request；
- 统一内存 page fault；
- completion interrupt；
- device firmware decision。
这些行为不是简单地出现在 CPU 指令流里。
它们跨过了 CPU、驱动、runtime、设备队列、内存系统、互连 fabric 和设备固件。
论文里把 CPU trace 之外仍然影响系统执行结果的部分称为 residual flow，可以翻译成"残余流"或者"剩余因果流"。
它包括两类：
第一类是残余控制流，比如队列提交、设备调度、完成中断、page fault、固件决策。
第二类是残余数据流，比如隐式内存迁移、cache line 所有权转移、DMA 写入、设备私有内存更新。
这部分流量恰恰是现代系统里最关键、也最难观测的东西。
很多软件系统可以在训练 epoch 之间做 checkpoint，也可以序列化对象状态，或者强制 runtime 走确定性队列。
但这些方法往往是在很高的软件层观察系统。
它们看到的是"事情发生之后的结果"，而不是"事情发生时的因果事件"。
这对于粗粒度恢复还可以接受。
但对于下面这些场景就不够了：
- 指令级调试；
- 低延迟迁移；
- 连续安全审计；
- 透明加速器虚拟化；
- 细粒度故障恢复；
- 跨 CPU/GPU/CXL 设备的确定性 replay。
所以，Slug Architecture 的出发点是：
不要只在软件层追着结果跑，而要在内存 fabric 的边界上记录因果事件。
四、CXL 不只是扩内存，也可以成为"可回放的底座"
CXL，也就是 Compute Express Link，通常被理解成一种内存扩展和设备互连技术。
它主要有三类能力：
- http://CXL.io：兼容 PCIe 的发现、配置和控制通道；
- CXL.cache：允许设备参与主机缓存一致性；
- CXL.mem：允许主机访问设备侧内存。
很多人讨论 CXL 时，关注的是：
- 能不能扩展内存容量；
- 能不能做内存池化；
- 能不能减少 CPU 和加速器之间的数据拷贝；
- 能不能做 disaggregated memory；
- 能不能服务更大的 AI 模型。
这些都很重要。
但 Slug Architecture 提出了另一个视角：
如果 CXL fabric 本来就承载了跨 CPU、设备和内存池的关键事务，那么它也应该成为记录和回放这些事务的地方。
也就是说，CXL 不只是"搬运数据的高速公路"，还可以是"记录数据如何被搬运的黑匣子"。
这就是所谓 CXL Fabric Replay 的核心想法。
五、Slug Architecture 的基本思想：每个端点都是一个小岛
Slug Architecture 把整个异构系统看成一组通过可回放内存 fabric 连接起来的"冯·诺依曼小岛"。
每个小岛可以是：
- CPU core complex；
- GPU；
- DPU；
- CXL Type-3 内存设备；
- CXL switch；
- 压缩引擎；
- UCIe chiplet；
- 其他专用加速器。
每个小岛内部可以非常复杂。
它可以有自己的 ISA、scheduler、firmware、microcode、cache、local memory，甚至可以是完全黑盒。
Slug Architecture 并不要求所有设备暴露内部微架构，也不要求所有加速器统一成同一种 ISA。
它只要求一件事：
每个端点在对外的内存和 offload 边界上，暴露一个可编程的 External Memory Controller。
这个 External Memory Controller 可以理解成一种"外部内存控制器"或"边界控制器"。
它不是普通的 load/store 通道，而是一个能观察、过滤、压缩、标注和回放外部可见事务的可编程控制平面。
它需要观察的对象包括：
- memory read / write；
- cache ownership transition；
- invalidation；
- DMA；
- peer-to-peer transfer；
- offload descriptor；
- doorbell；
- completion；
- interrupt；
- 地址翻译；
- page migration；
- security label；
- protection key；
- provenance tag。
注意这里的重点：
它不需要理解 GPU 内部每条指令是怎么执行的。
它只需要知道这个 GPU 或加速器在系统边界上做了什么：
读了哪里，写了哪里，什么时候发起了请求，哪个队列提交了任务，哪个事务产生了影响，哪些内存范围被修改，哪些一致性关系被建立或打破。
这就像调试分布式系统时，我们不一定要知道每台机器上每条指令的执行细节，但必须知道机器之间发了什么消息、消息顺序是什么、哪些消息影响了最终状态。
六、Hardware JIT：给内存控制器装一个"可编程探针"
如果每个设备都要记录所有事务，开销肯定爆炸。
所以 Slug Architecture 引入了第二个关键机制：
Hardware JIT。
它可以理解成一种运行在硬件边界上的动态编译机制。
系统不会永远开启一个笨重的全量 tracer，而是根据当前 workload、拓扑、页面布局、安全策略和 replay 目标，动态生成一组很小的硬件程序，安装到各个 External Memory Controller 里。
输入是一组 policy bundle，例如：
- 当前有哪些 CPU、GPU、CXL switch、内存池和 chiplet；
- 当前页表和 protection domain 是什么；
- 哪些共享内存区域值得关注；
- 哪些 GPU kernel 或 queue 是关键边界；
- 当前目标是调试、迁移、入侵检测还是故障恢复；
- 允许多少 metadata 带宽；
- 最大采样率是多少；
- 哪些内存范围需要完整记录，哪些只需要 hash。
输出则是安装在控制器里的小程序。
这些程序可以：
- 分类事务；
- 绑定 epoch ID；
- 过滤不重要流量；
- 压缩重复模式；
- 记录依赖边；
- 为事务添加 provenance 标签；
- 对特定地址范围做安全检查；
- 生成 replay record。
可以把它类比成：
面向 CXL memory fabric 的 eBPF。
只不过 eBPF 的目标通常是操作系统内核，而这里的目标是设备和内存边界上的控制器。
七、Replay Record：不记录所有细节，只记录重建因果关系所需的信息
Slug Architecture 不是要把整个系统每个周期都完整录下来。
那样成本太高，也没必要。
它关注的是：
哪些 fabric-visible event 足以重建程序可见的执行结果？
一个 replay record 大致包含：
- 源 endpoint；
- 目标 endpoint；
- epoch ID；
- 事务类型，比如 cache read、writeback、invalidation、CXL.mem read、CXL.mem write、http://CXL.io doorbell；
- 地址或对象 ID；
- ordering metadata；
- dependency edge；
- fence；
- payload hash、delta 或 full payload；
- provenance label；
- security label。
这里有一个重要设计：不同场景可以使用不同记录模式。
第一种是 Validation Mode 。
只记录 hash 和 ordering metadata。系统假设端点重新执行时可以产生同样 payload，所以只需要验证结果是否一致。
第二种是 Delta Mode 。
记录压缩后的差异，适合那些可能存在一定不确定性的内存区域。
第三种是 Full Mode 。
完整记录 payload，适用于不可信设备、外部输入、可疑区域或短时间的深度调试窗口。
这种分层策略很重要。
因为它意味着 Slug Architecture 不追求"永远全量记录"，而是追求：
在大多数时候低成本记录，在关键时刻提高记录精度。
八、CXL Fabric Replay：回放的不是设备内部，而是边界行为
Slug Architecture 最核心的思想是：
不需要复刻每个设备内部的执行细节，只需要在 fabric 边界上复现等价行为。
比如一个 GPU 内部如何调度 warp，某个 AI 加速器内部如何安排矩阵计算，这些都可以是黑盒。
只要它在某个 epoch 内对外部内存产生的可见行为是一致的，系统就可以认为 replay 成功。
CXL Fabric Replay 的过程大致分为四步。
第一步是 Checkpoint 。
系统保存 CPU architectural state、部分 endpoint state、memory pool mapping，以及 External Memory Controller 的程序版本。
第二步是 Record 。
各个控制器在系统正常运行时记录压缩后的事务、依赖边和必要的 payload 信息。
第三步是 Seal 。
在 epoch 边界上，系统对内存范围、队列状态、未完成的一致性所有权等生成紧凑承诺。
第四步是 Reconstruct 。
在 replay 机器上重新安装兼容的控制器程序，重放或验证 fabric event，并在端点提前越过 epoch 边界时进行 stall，直到相关依赖满足。
这里最重要的一句话是：
replay 不需要保存每个 cycle，它只需要保存影响 memory-visible behavior 的 happens-before 关系。
也就是说，只要 GPU 写入、CPU 读取、CXL switch 排序这些关键依赖关系被正确记录，系统就可以在不同的物理 GPU 或不同的内存池上复现同样的程序可见状态。
九、Epoch 和 Stall：让异构系统"等一等"
为了控制 replay 粒度，Slug Architecture 使用 deterministic epoch。
epoch 可以由很多事件定义：
- GPU kernel launch；
- queue submission；
- page-fault batch；
- timer interrupt；
- memory fence；
- Hardware JIT 插入的 synthetic boundary。
在 replay 时，如果某个 endpoint 到达 epoch 边界，但它依赖的 fabric event 还没有被重放完成，那么 External Memory Controller 可以暂时 stall 它的请求。
这听起来像是在执行流里插入"内存操作气泡"。
设备不需要永久停机，只是在因果关系还没追上时等一下。
未来如果有 ISA 支持，这种等待可以变成轻量 replay/debug 扩展。
如果没有 ISA 支持，也可以通过 queue throttling、page protection、CXL switch backpressure 或 device firmware cooperation 来近似实现。
这套机制的价值在于：
它不试图控制每个设备内部的每个细节，而是在跨设备交互的边界上控制因果顺序。
十、安全意义：谁写坏了内存，终于可以追责了
Slug Architecture 不只是为了调试。
它还有一个很强的安全含义。
在异构系统里，恶意或故障设备可能通过"合法事务"完成"非法行为"。
比如：
- GPU kernel 写了不该写的页；
- DMA 引擎读取了未授权 descriptor；
- CXL 内存设备返回了过期数据；
- 某个设备绕过 CPU trace 修改了关键状态；
- 加速器通过合法 CXL transaction 破坏了高层安全策略。
CPU-only trace 很可能看不到这些事情。
但如果每个 endpoint 的边界都有 External Memory Controller，系统就可以在事务发生时做 provenance 和 policy 检查。
比如：
- 这个 GPU kernel 只能写这些 page；
- 这个 DSA engine 只能读这个 protection domain 签名过的 descriptor；
- 这个 memory expander 在 ownership transition 后不能返回 stale data；
- 某个 CXL switch 的排序行为必须满足指定依赖关系。
正常运行时，控制器可以只输出紧凑的 provenance commitment。
一旦发现异常，就切换到 full recording，对可疑 page、queue 和 epoch 进行精细记录。
这样在事故响应时，系统可以更明确地回答：
这次内存破坏到底来自 CPU 代码、GPU kernel、DMA 写入、CXL 事务，还是外部设备？
这对云厂商、AI 训练集群、金融系统和高可靠计算都非常关键。
十一、它和现有技术是什么关系？
Slug Architecture 并不是要推翻现有系统，而是把一些已有能力向更底层推进。
CPU 侧已经有一些硬件 tracing 能力，比如 Intel Processor Trace 和 Arm CoreSight。它们证明了低开销硬件 tracing 是可行的。
GPU 和统一内存 runtime 也已经能提供 kernel、queue、allocation 等语义边界。
CXL 则提供了跨 CPU、设备和内存池的互连基础。
Slug Architecture 的新意在于：
把这些能力统一成一个 replay-first 的架构契约。
也就是说，未来设备不只是要支持"更快访问内存"，还要支持"让这次访问可以被记录、解释、验证和回放"。
它不要求今天所有 CXL 设备立刻具备完整能力。
更现实的路径是：
- CPU 继续使用现有 tracing；
- GPU runtime 提供 kernel、queue、allocation 边界提示；
- CXL switch 和 Type-3 设备先对特定地址范围记录有序内存事务；
- 操作系统像管理 IOMMU、性能计数器和设备固件一样，管理 External Memory Controller 程序；
- 未来这些能力进入 CXL capability structure，成为跨厂商标准接口的一部分。
十二、怎么验证这个架构是否有价值？
Slug Architecture 目前更像一个架构提案，而不是已经量产的系统。
要验证它，不能只问"tracing 是否更快"，而要问：
fabric-level replay 是否能以比软件 checkpoint 和设备专用 profiler 更低的代价，提供更强的可观测性？
一个合理的 prototype 可以分三层。
第一层是软件 CXL fabric simulator/emulator，用来模拟 CXL.cache、CXL.mem、http://CXL.io、switch ordering 和 endpoint-local queue。
第二层是 runtime shim，用来插桩 CPU thread、GPU kernel launch、DMA descriptor 和 memory allocation boundary。
第三层是 Hardware JIT compiler，把 replay policy 编译成 transaction filter、dependency tracker 和 compression rule。
后续可以用 FPGA CXL endpoint 或带可编程逻辑的 CXL.mem 设备做硬件原型。
关键不是造一个完整 GPU，而是证明：
只记录边界级 transaction，就足以回放代表性的异构 workload。
适合评估的 workload 包括：
- 带 unified memory page migration 的 GPU kernel；
- CPU + accelerator 的 DMA queue pipeline；
- 基于 CXL.mem 的 disaggregated memory workload；
- LLM 推理或训练中 CPU memory、GPU memory、pooled memory 之间的 tensor 移动；
- 通过 CPU store、DMA write、CXL transaction 注入故障的内存破坏场景。
指标可以包括：
- 相比原生执行的 runtime overhead；
- 每 GiB application memory traffic 产生多少 metadata；
- replay fidelity；
- 是否能稳定复现 bug；
- checkpoint size；
- replay time；
- 是否能把未授权内存流正确归因到 endpoint。
论文中的合理假设是：
Slug Architecture 不会做到零开销，但有机会让关键 workload 的连续可观测性足够便宜，甚至在大多数时候保持开启。
在大部分 payload 只用 hash 或 commitment 验证，而不是完整复制的情况下，确定性 replay window 的目标开销可以控制在一个较低区间。对于可疑或不确定区域，开销会更高，但系统可以把 full recording 限制在真正重要的 page、queue 和 epoch 上。
十三、为什么这个方向值得关注？
我认为 Slug Architecture 最有意思的地方，不在于它提出了某个单点优化，而在于它重新定义了"未来计算机应该暴露什么接口"。
过去我们希望硬件暴露：
- 更高带宽；
- 更低延迟；
- 更大容量；
- 更强算力；
- 更多 cache；
- 更好的能效。
但在异构计算时代，也许还需要一个新的硬件接口：
可回放性。
如果一台服务器由几十种 endpoint 组成，而且每个 endpoint 都能独立读写内存、迁移数据、参与一致性、执行 offload，那么系统软件只靠 CPU 视角已经不够了。
未来真正重要的问题会变成：
- 这次内存写入是谁产生的？
- 这个设备有没有越权访问？
- 这个 GPU kernel 是否真的只影响了允许的内存范围？
- 这次训练崩溃能不能在另一台机器上复现？
- 这个 bug 是 CPU、GPU、DMA、CXL switch 还是内存池导致的？
- 在不暂停整个系统的情况下，能不能持续审计关键数据流？
这些问题不是"更快的内存"单独能解决的。
它们需要 memory fabric 自己变得可观察、可验证、可回放。
结语：下一堵内存墙，不只是性能墙
传统内存墙讲的是 bytes per second。
但异构时代的新内存墙，讲的是：
我们是否还能理解一台机器内部发生了什么。
当 CPU、GPU、DPU、CXL 设备、内存池和交换芯片一起构成一个复杂系统时，调试、迁移、审计和恢复不能再依赖"英雄式的软件重建"。
Slug Architecture 的核心主张可以概括成一句话：
如果 CXL 会成为未来服务器、加速器和内存池的骨干，那么 replay 就应该成为 fabric 的原生能力，而不是事后补救的软件技巧。
这也是它最有想象力的地方。
它把异构系统重新组织成一组局部自由、边界可控的冯·诺依曼小岛：
每个设备内部可以保持复杂和专有，但只要它跨越内存和 offload 边界，就必须留下可验证、可压缩、可回放的因果记录。
如果这个方向成立，那么未来的服务器不仅会更快、更大、更省电，也会更可调试、更可迁移、更可审计、更可信。
而这可能才是 AI 时代系统架构真正需要跨过去的那堵"新内存墙"。