如果让你说出 2026 年大模型架构最热的两个词，答案大概率是 **MoE（混合专家）** 和 **Diffusion LLM（扩散大语言模型）**。

前者是 GPT-4、DeepSeek、Qwen3 等顶级模型已经验证的「稀疏激活」路线；后者是 Meta、字节、谷歌近半年密集下注的「下一代生成范式」。

把两者叠加，听起来像是「更强的模型」和「更便宜的成本」的双重胜利。

**但现实是：MoE + 扩散的组合，撞上了一个比「显存墙」更麻烦的瓶颈——I/O 墙。**

2026 年 5 月 arXiv 上的一篇论文 **《TIDE: Efficient and Lossless MoE Diffusion LLM Inference with I/O-aware Expert Offload》**（作者 Z. Chen、Y. Zhao、Y. Sui 等），首次系统性地拆解了这个问题，并给出了一个工程级、可落地的解决方案。

### 一、为什么 MoE + Diffusion 的组合这么诱人

先说为什么这个组合值得做。

**MoE 的核心价值是「用稀疏激活换推理效率」**：每次只激活部分专家（experts），理论上可以做到「模型大、参数多、推理便宜」。Qwen3、DeepSeek-V3 都用这个路线跑出了极致的成本结构。

**Diffusion LLM 的核心价值是「并行生成」**：不像自回归模型逐 token 串行，扩散模型可以一次并行去噪出一整段文本，理论上吞吐有数倍提升空间。LLaDA、DiffuLLaMA 等工作已经在中等规模上验证了这一点。

**两者组合的甜点**是：模型参数规模大、生成吞吐高、推理单价低。

对所有做 To-C 产品的团队来说，这就是「又好又便宜」的最优解。

### 二、为什么这个组合反而跑不起来

但工程团队真正部署时会发现一个尴尬的事实：**理论上的甜点，在真实硬件上跑成了「双倍卡顿」。**

问题出在「专家调度 + 扩散去噪」这两件事的耦合。

**1. 专家权重在 GPU 和 CPU/NVMe 之间来回搬**

MoE 架构里，专家权重是「按需激活」的——但「按需」在硬件层面意味着：某个 token 触发了哪个专家，GPU 就要去把那个专家的参数从显存（不够时从 CPU 内存甚至 NVMe 硬盘）里加载进来。

推理时，这种「跨设备加载」是常态。

**2. 扩散模型是「多次去噪」结构**

Diffusion LLM 不是一次生成，而是要经过多轮去噪迭代。每一轮，所有 token 都要重新计算专家路由——这意味着专家的加载-卸载次数，被进一步放大。

**3. I/O 带宽成为决定性瓶颈**

当模型规模大到 GPU 显存装不下时，**「加载专家」所需的时间，会远超过「激活专家」所需的计算时间**。

换句话说：GPU 在等数据。

一个原本应该是「计算密集型」的任务，被生生拖成了「I/O 密集型」任务。

TIDE 论文把这个现象称为 **「expert loading dominance」**——专家加载压倒了专家计算，成为推理延迟的主要来源。

### 三、TIDE 的核心思路：把「专家调度」变成「磁盘 I/O 调度」

TIDE 的洞见是：**既然瓶颈在 I/O，那就把整个推理过程当成一个「I/O 调度问题」来解。**

这个思路并不新——操作系统里的页面置换、数据库里的查询计划，本质上都是「I/O 调度」。TIDE 是把这一套调度哲学，搬到了 MoE Diffusion LLM 的推理引擎里。

具体来说，TIDE 做了三件事：

**1. 专家预取（Expert Prefetching）**

基于当前去噪轮的专家路由预测，**提前把下一轮可能用到的专家权重从 NVMe 预取到 CPU 内存**，再从 CPU 内存预取到 GPU 显存。

关键：不是「用到了再加载」，而是「即将用到就先拉过来」。

**2. 异步 I/O 流水线（Asynchronous I/O Pipelining）**

把专家加载、专家计算、KV cache 更新三件事**流水线化**，让 GPU 算力永远不空转。

I/O 与计算 overlap，这是高性能计算领域的经典手法，但在 LLM 推理引擎里一直没有被系统化地应用。

**3. 感知去噪步数的缓存策略（Denoising-step-aware Caching）**

TIDE 发现：**扩散模型的不同去噪步，对专家的「热力分布」是不同的**——早期的步需要更「广谱」的专家覆盖，后期的步会聚焦在少数几个专家上。

基于这个观察，TIDE 给不同去噪步配置不同的缓存策略，**减少不必要的加载**。

### 四、TIDE 的实际收益

论文在多个 MoE Diffusion LLM 配置下做了实验，核心数据：

• 在 7B-A14B、16B-A28B 等典型 MoE 配置上，**端到端推理时延最高降低约 4.1×**

• 在大模型场景下（专家数量多、单卡装不下），**HBM（高带宽内存）容量需求可压缩到原始的 1/3**

• **精度零损失**——这是 TIDE 强调的「Lossless」属性

最关键的一点：**TIDE 跑得通的前提条件是「消费级硬件 + 大容量 NVMe」**。

这意味着 1-2 张 4090/5090 加上几 TB 的 SSD，就能跑出原本需要 8 张 H100 才能勉强支撑的 MoE 扩散模型推理。

对开源社区和中小团队来说，这是个不小的福音。

### 五、为什么这件事值得被认真看

**1. 「架构创新」和「系统工程」正在重新耦合**

过去两年，AI 圈对「架构创新」的执念掩盖了「系统工程」的重要性。

TIDE 这样的工作提醒我们：**当架构红利（Transformer → MoE → Diffusion）逐渐被吃透，竞争的下一个战场就是工程优化**。

未来 12-24 个月，AI infra 层会跑出一批新的明星公司——它们的护城河不是模型，而是「让模型跑得更便宜」的工程能力。

**2. 推理成本曲线下行的「第二推力」**

第一推力是模型本身的优化（量化、稀疏化、蒸馏）。

第二推力是硬件升级（H100 → B200 → GB200）。

**TIDE 这类工作提供的是第三推力：调度与系统设计**。

第三推力的特点是「边际成本极低」——一旦调度算法在开源社区里被广泛实现，整个行业的推理成本曲线都会下移。

**3. 「小团队也能跑大模型」的可能性**

当消费级 GPU + NVMe 就能跑出企业级的推理性能时，**「大模型研发」的准入门槛被进一步拉低**。

这是开源生态的胜利，也是闭源 API 提供商的潜在威胁——当本地部署成本逼近 API 调用成本时，企业客户的偏好会再次反转。

### 六、这篇论文的边界

不神化，TIDE 也有它的局限：

• **论文目前主要在「去噪步间的专家路由模式」相对稳定的模型上验证**。如果未来出现路由模式剧烈抖动的架构，TIDE 的预测预取策略可能失效。

• **NVMe 的随机读延迟仍然是物理上限**。当模型参数大到需要从机械硬盘或慢速 SSD 加载时，TIDE 的收益会被压缩。

• **调度策略对框架侵入性较强**。TIDE 与 vLLM、TensorRT-LLM 等主流推理框架的整合还需要社区进一步贡献。

### 七、最后

TIDE 不是一篇会出现在「AGI」讨论里的论文。

但它解决的恰恰是 AGI 真正到来之前，**行业最需要的事情之一**——**把大模型的运行成本压下来**。

当万亿参数模型成为常态、当 Diffusion LLM 逐步接管生成任务、Agent 每天调用数千次 LLM——

**「I/O 调度」会成为推理引擎的胜负手**。

TIDE 给出了一个清晰的范式：**把硬件瓶颈当一等公民来设计算法，而不是用算力去硬堆**。

这才是「工程级创新」该有的样子。