1. 从ATC'26的五篇录取看系统研究的四个风向
先说结论：IPADS这次在ATC'26上拿了五篇论文，分布在长上下文训练、智能体执行、安全推理和软件质量保障四个方向，这个配比本身就很有意思。ATC（USENIX Annual Technical Conference）在系统领域一直以“硬核工程”著称，不欢迎只有调参优化的表面工作，也不喜欢纯idea但落不了地的空想。五篇录取放在一起，透露出的信号是：系统研究正在跟大模型应用做深度绑定，而且不是简单“给模型加个外围”，是在底层并行机制、运行时调度、安全边界治理这些根子上动刀。
我平时接触这类工作比较多，拿到这个消息第一反应是：这四个主题恰好对应了从训练到部署再到维护的完整链路。长上下文训练解决的是“模型能不能练得动、练得长”，智能体执行解决的是“模型用起来能不能跑得稳”，安全推理解决的是“模型在不可信环境里敢不敢用”，软件质量保障解决的是“系统迭代过程中怎么不翻车”。它们不是零散的热点，而是大模型基础设施走向成熟时必须补上的短板。
这篇文章不替IPADS做具体的论文解读，我没那个内部信息；但基于对这些方向长期跟踪和踩坑经验，我会把每一个技术点背后的核心矛盾、常规解法、公认难点以及值得借鉴的工程思路拆开讲清楚。对正在做相关方向的同学，尤其是搞系统、搞AI Infra、搞大模型应用开发的人，应该比单纯看录取列表更有嚼头。
2. 长上下文训练：显存墙、通信墙与序列维度上的并行革命
2.1 为什么长上下文不是“把batch调大”那么简单
现在各家模型都在卷上下文窗口，从128K到1M甚至更长，但真正卡住的不只是注意力计算的复杂度，更多是训练和推理时的显存和带宽。Transformer处理序列时，KV Cache的大小随序列长度线性增长，但激活和中间结果在某些计算模式下会随平方关系膨胀。我以前跟人解释这个问题时常用一个比方：短序列训练像在桌面上摆棋子，桌子够大就行；长序列训练等于把棋子排成几万米的长队，你不仅要找地方放，还要保证每个棋子能被按顺序处理，中间不能断档。
如果只是把输入长度加长，再按老的并行策略切分，最直接的问题就是显存溢出。这是一个纯资源墙的问题，解决思路无非两条：要么让单卡能装下更多（算子级优化、显存复用），要么把活分给更多卡（并行策略调整）。但长序列场景下，通信代价和计算代价的比值会发生剧变，导致传统的张量并行、流水线并行、数据并行组合不再最优。
从系统研究的角度，长上下文训练的核心痛点可以拆成三个层面：
- 显存层面：序列维度过长时，切分序列的Sequence Parallelism以及Activation Checkpointing等策略成为必需品，但怎么切、在哪切、切完怎么合并，每步都影响吞吐。
- 通信层面：All-to-All通信在稀疏注意力、MoE这类结构里非常频繁，长序列下通信量和频率同步上升，网络拓扑一旦不支持，计算只能空转。
- 数值与调度层面：动态长度下负载不均衡严重，一个mini-batch里不同样本的sequence长度可能差异巨大，静态切分必然浪费算力。
2.2 主流方案的“最优解只是局部解”
业界目前处理长上下文训练的常用手段，我梳理下来基本是这几种：
| 方案 | 核心思想 | 典型成本 | 适用场景 |
|---|---|---|---|
| Sparse Attention + 局部窗口 | 降低计算量 | 需要额外mask管理，评估语义损失 | 文本、长代码 |
| Sequence Parallelism | 把序列维度切到多卡 | 需要配套通信原语，不能直接套DeepSpeed | 大规模稠密模型 |
| Ring Attention / Zigzag | 块循环计算注意力，减少峰值显存 | 通信开销不低，调度复杂 | 超长序列（≥1M） |
| 重计算与Offload | 以算换显存 | 训练时间变长 | 单卡/小规模集群 |
这里说句实话：单个方案往往只能解决单点瓶颈。比如Activation Checkpointing能把激活量降下来，但代价是约30%-50%的额外重算开销；Ring Attention能把峰值显存压到很低，但跨设备通信如果没和计算重叠好，整体吞吐反而更差。真正的系统优化是在这几个方案之间做“组合拳”，先用profiler定位瓶颈在哪张卡、哪类算子、哪段通信，再针对性调整。
2.3 从这届论文标题中可以读出的“系统动作”
这类长上下文作品通常会在三个点上做文章：第一，改造注意力计算流程，使其适配新型并行范式；第二，设计更优的内存调度模块，把KV Cache和中间结果的存储位置动态编排；第三，降低长序列带来的通信同步开销，甚至让通信在计算过程中间“无缝渗入”。
具体工程上，我曾经做过的优化流程类似这样：
- 先建一个长序列的benchmark，包含1K、32K、256K、1M几档长度，不用真实模型，用一个类似架构的dummy model测每层算子和通信耗时。
- 用Nsight或Tracy抓kernel流水，区分出：load-bound是显存带宽问题，comp-bound是计算密度问题，sync-bound是通信等待问题。
- 根据瓶颈选策略：如果瓶颈在通信，优先改Tensor Parallel的切分方式，让序列并行尽量在单机内部解决；如果瓶颈在激活显存，就引入选择性重计算，只对高体积低耗时的算子做重算。
- 动态长度场景下，用varlen API或自己排布bucket，让同一batch内长度方差尽量小。
我对长上下文训练最深的感受是：工程细节多于算法创新。有时候把re-materialization的schedule从“每层都做”改成“每两层做一次”，配合更聪明的all-gather时机，吞吐就能涨一截，而这些微小改进拼起来才是系统论文的核心贡献。
3. 智能体执行：从“模型会想”到“系统能落地”
3.1 智能体不是应用层玩具，而是新型计算范式
LLM Agent现在很火，但多数人关心的是prompt怎么写、工具怎么调，很少有人认真把它当成一个“执行体”来设计。一个Agent生命周期里会发生大量计算密集、I/O密集、状态敏感的操作：多轮推理、函数调用、环境交互、权限切换、资源申请与释放。如果只靠外部业务代码去编排，一旦并发上来，问题就全面暴露。
举一个很常见的例子：一个Agent在一个任务里需要调用外部搜索、操作内部数据库、写代码执行并读结果。每一步之间都有依赖，而每一步的耗时又是高度不确定的，可能100ms也可能10s。这种“长尾延迟”和“动态依赖”用传统微服务架构去编排会很别扭：你不可能为每个Agent任务开一个线程池，也不可能预知需要多少内存。
所以从系统角度，智能体执行要解决的核心矛盾就是：不确定的计算流如何在有限的物理资源上高效、稳定地调度。这就像操作系统的进程调度，只不过这里的“进程”是Agent的一次run，它随时会fork、会等待、会退出。
3.2 执行引擎的三大关键能力
考察现在做得比较好的Agent Runtime或Agent Execution Engine，往往具备三样能力：
- 有状态调度：每个Agent Step之间保留上下文状态，可暂停、可恢复、可迁移。这背后需要一个独立的State Store，而不是把状态留在Python进程里。
- 安全工具边界：Agent要调外部工具，但这个权限来自哪里？怎么审计？传统应用里“权限”是静态的，Agent场景里工具选择可能是模型在推理时动态决定的，所以需要通过沙箱、策略引擎、动态预检去做边界控制。
- 可观测与可追溯：一旦Agent行为异常，要能回放每步推理、每次调用，并把它跟资源消耗联动分析。没有可观测性，Agent系统出了问题只能瞎猜。
3.3 调度策略与资源感知：怎么避免“一脚油门一脚刹车”
我之前实现过一个轻量Agent执行框架，刚开始做得像爬虫一样简单：每个任务一个goroutine，任务里顺序跑模型、跑工具。结果并发一高就出问题——有的Agent因为等一个慢工具调用，白白占用模型worker；有的Agent疯狂重试，把工具的限流打爆。后来改成事件驱动型调度，把Agent的每次“推理-执行-观察”当作一个事件周期，用带优先级的状态机去管理，实测比原来的并发模型吞吐提升了快两倍，而且尾巴延迟明显收敛。
这个过程中最大的教训就是：不要让Agent自己决定资源消耗。模型输出是概率性的，它可能一次推理就完事，也可能陷入循环。系统必须在外部用硬性约束去保护：为每个Agent设置最大步数、最大token消耗、单步超时，工具调用的并发数要由全局信号量来控制，而不是由prompt去祈祷。
现在我们再看IPADS在智能体执行方向上的录取，大概能想到他们会在这个抽象层做文章。典型切入点包括：为Agent动态配置隔离环境、把Agent状态持久化并实现跨节点迁移、开发专用的调度器以匹配模型推理与工具I/O的混合负载。这些方向不是想象中“写个Agent框架”这么简单，而是要跟底层内核、虚拟化、容器技术结合。
4. 安全推理：大模型部署中“不敢提但必须解决”的硬骨头
4.1 安全推理的两种味道：隐私保护与内容安全
安全推理这个词在不同语境下的含义能差出十万八千里。在IPADS这类系统所的环境里谈安全推理，大概率偏向下面两类：一是机密推理，即模型权重和用户输入都要在可信环境里跑，防止推理时泄露模型参数、用户prompt；二是输入输出边界控制，即推理链路里需要嵌入安全过滤器、防注入、防数据外带机制。
当前大模型推理服务的部署形态通常是：模型owner把权重放到GPU服务器上，用户通过网络API调用。那么问题来了，这个拥有GPU的服务器运营商能不能看到模型？如果用户传了敏感数据，运营商能不能偷走？更进一步，当多个租户共享一台GPU时，模型和用户数据如何互相隔离？
传统TEE（可信执行环境）主要面向CPU，而大模型推理的主要算力在GPU。Intel TDX和AMD SEV-SNP都支持从CPU向GPU扩展可信边界，但性能损耗和兼容性问题仍然突出。NVIDIA最近在推的Confidential Computing for GPUs（即H100/H200的机密计算模式），本质上是把GPU显存也纳入加密保护范围，但代价是有额外的加解密开销和显存占用。
4.2 系统研究如何把“安全”和“推理性能”做大做小
纯粹把整个推理过程放入TEE里，性能损失可能是数倍，这在生产环境根本没法用。所以安全推理的系统优化就变成了一个“以最小代价覆盖最大攻击面”的透镜问题。
实际实现上，有几个常规打法：
- 混部模式：只在模型加载、权重解密、密钥交换等关键环节使用TEE，大部分矩阵运算仍然走原生GPU路径，只是将中间结果进行加密或扰动，保证即使物理设备被攻破也无法恢复完整模型。
- 分层推理协议：部分注意力层在TEE内计算，线性层在普通环境用同态加密或秘密共享，虽然通信开销增大，但能提高性能。
- 可验证推理：不隐藏模型，而是让推理节点附加一个证明（如zkML或基于承诺的方案），让用户能验证返回结果的正确性，而不泄露中间信息。
对IPADS来说，他们的优势在于对操作系统内核、虚拟化、设备驱动层面的深刻理解。安全推理如果只停留在算法层，会非常单薄，真正硬核的是如何在内核模块里安全地管理GPU上下文、如何在不被恶意驱动干扰的情况下处理DMA、如何在多租户场景下做密钥调度。
4.3 部署安全推理时的几个实战问题
我自己在一款推理服务里尝试过给用户prompt加密、然后通过安全通道传给GPU再做推理，当时遇到几个坑：
- 密钥管理与模型加载解耦：如果密钥只在CPU侧，GPU没法直接解密模型权重，需要在加载阶段用安全API把权重从密文还原到显存，这个阶段如果做不好，模型直接就裸奔了。
- 防止侧信道：GPU的DMA可以访问系统内存，如果不做I/O隔离，攻击者可以通过DMA读走其他进程的数据。必须配置IOMMU或使用可信覆盖页表。
- 性能和安全的平衡：一次解密全模型可能就要几秒钟，这在低延迟场景不可接受，可以考虑按层流式解密，用流水线掩盖解密时延。
安全推理的最终目标是让用户“敢用一个不可信的GPU”，而系统论文的价值正是把这种大胆的想法变成可部署的代码。
5. 软件质量保障：在AI时代重构测试与验证
5.1 为什么传统测试在大模型系统上失效了
软件质量保障原本是相对成熟的话题，但大模型系统出现后，一系列“传统经验失效”的现象值得每个从业者警醒。过去我们测一个函数、一个API，输入是确定的，输出是确定的，写断言很容易；现在拿大模型做模块，输入是自然语言，输出是采样出来的，同一个prompt两次调用结果都可能不同，你怎么写断言？
再往下，大模型系统通常不是单一模型，而是由多个模型组件+传统代码+外部工具协作组成，中间还涉及不可复现的调度顺序。测试时本地能过，一到线上就崩，大概率是数据漂移或环境副作用带来的，而不是代码逻辑错误。
IPADS这五篇里出现软件质量保障方向，说明系统社区已经意识到：大模型应用不能靠“调一调prompt就是好”这种玄学态度，必须用系统的测试、验证、运行时代码分析手段来保障可靠性。
5.2 四类行之有效的质量保障手段
我根据自己在大模型应用开发中的试错经验，把有效的质量保障手段排了个序：
| 排序 | 手段 | 解决的问题 | 要注意的坑 |
|---|---|---|---|
| 1 | 数据漂移检测 | 线上输入分布变化导致效果下降 | 需要建立基准集，定期回放 |
| 2 | 回归测试套件 | 多次重构后原有能力被破坏 | Agent场景下要测完整轨迹而不是单点输出 |
| 3 | 混沌工程 | 外部工具超时、挂掉、乱序返回 | 故障注入不能干扰线上正流量 |
| 4 | 形式化验证/模型检查 | 死锁、资源竞争、状态非法 | 建模成本高，需要抽核心组件做 |
对于Agent执行系统，质量保障的重点应当放在状态一致性检查和故障恢复验证上。比如Agent在step N写入了一个临时文件，step N+1却忘了清理；或者Agent在等待工具响应时，进程被重启，状态丢了。这种问题普通的单元测试完全发现不了，需要做故障注入和状态快照对比。
5.3 高效率覆盖率分析与模糊测试的再应用
传统软件测试里的覆盖率分析和模糊测试，在大模型系统里也没有消失，而是换了一种形态。
- 代码侧覆盖率照常分析，但新增模型侧“prompt空间覆盖率”的概念。对同一个API，要覆盖不同语气、不同隐私级别、不同语义复杂度的请求，否则某些分支可能永远执行不到。
- 模糊测试可以用来生成极端输入，让Agent的意图解析模块崩溃或兜底逻辑被跳过。可以直接用模型本身生成对抗样本，也可以像传统fuzzing那样通过变异种子来试。
- 在大模型应用链路中加“结构化日志断言”，比单纯看模型输出靠谱得多。比如记录每一步的input token数、延迟、工具返回码、重试次数，一旦超出阈值立即告警。
这类系统论文的贡献点不在于提出新的理论，而在于把测试与验证跟大模型runtime深度融合，做到低成本自动化和可量化评估。
6. 几条共通的工程经验与个人心得
把四个方向都过了一遍之后，我想说几句在系统领域折腾这些年最有体感的经验。
第一条：系统调优就是做权衡，不要追求面上最优。长上下文训练里，频繁使用重计算和稀疏化会让显存好看，但吞吐可能下降；安全推理里全链路加密产线肯定过不了性能测试。每个声称“无损”的方案都要在心里画个问号，自己benchmark才是真理。
第二条：给不确定性留出边界。大模型系统的非确定性是本质属性，系统设计时不能假设“模型一定会按预期输出”。要为超时、重试、幂等、降级都做好机制，像设计分布式系统一样设计Agent执行链路。
第三条：可观测性不是事后补，而是第一设计原则。无论长上下文训练还是智能体执行，没有精细的profiling，你连性能瓶颈在哪都不知道；没有完整trace，出了问题只能靠猜。开发展板一开始就要埋好metrics、logs、traces三个面。
第四条：系统研究要选真实的硬问题。IPADS这五篇为什么能中ATC？因为选题都踩真实痛点：长上下文训练跑不动是行业共识，智能体执行不可控是业务方天天骂，安全推理不敢用是甲方最头疼，软件质量没法测是研发流程里的黑洞。系统研究如果只做“新鲜概念”而不指向真实场景，最后只能停留在demo阶段。
每次看到这类论文列表，我都会拿来对照自己手头的项目问一句：这里面解决的技术难题我是不是也遇到过？我的解决姿势是不是够系统化？如果还只是在打补丁，那就说明距离高质量的工程研究还有距离。论文列表不会直接告诉你怎么做，但它像一面镜子，提醒你行业最聪明的一批人正在哪些石头上磨刀。
