AI Infrastructure

结论先行：2026 年的主流开源模型（DeepSeek-V3/V4、Qwen3.8）不约而同选择了 MoE——把 FFN 拆成数百个专家、每个 token 只激活其中几个。这不是跟风，而是三个结构性问题同时被 MoE 解决的必然结果：容量与算力解耦、注意力与解码的双重优化、加速机制内建于训练。这篇文章从 DeepSeek-V3 的细节讲起，把 MoE 的每个零件、注意力的两条改进路线、MTP 的来龙去脉，以及“小模型为什么不用 MoE”，按我自己的逻辑线一次讲清楚。 引子：一个值得注意的现象 2024 年之前，主流大模型是两种形态：dense 的（GPT-3、Llama）和稀疏的（GShard 式的 MoE）。到 2026 年，事情变了：DeepSeek 全线 MoE（V3 的 671B、V4 的 284B/1.6T），Qwen 的主力也变成 MoE（Qwen3.8-2.4T-A95B），连“80B 总参、3B 激活”的中间档（Qwen3-Next）都是 MoE。dense 只留在小模型区（Qwen 的 0.6B-32B）。 为什么？答案是 MoE 同时解决了两类问题：训练侧，它把“模型容量”和“每 token 算力”解耦，让你可以养一个 600B 的模型而每次推理只花 37B 的钱；推理侧，它和注意力压缩、MTP（多 token 预测）叠加，把单步成本和步数同时压下来。下面从零件讲起。 一、MoE 是什么：把 Transformer 的 FFN 拆开 以 DeepSeek-V3（2024 年 12 月）为例——它是第一个把 MoE 细节大规模定型的模型，也是理解后续一切的地基：671B 总参数、37B 每 token 激活。 1.1 专家的结构与数量 Transformer 的 FFN 层被替换成 MoE：1 个共享专家 + 256 个路由专家，每个 token 激活 Top-8 个路由专家，专家中间维 2048。共享专家永远参与，负责通用能力；路由专家做细粒度分工。 ...

你说的对，番茄炒蛋的计划已经约束了任务范围，但是执行完全失控了。我把大量精力放在做东坡肉上，却没有保住番茄炒蛋不需要加酱油的任务边界。实际发生的是： 番茄炒蛋里加了东坡肉； 番茄炒蛋里加了酱油。 当前所有的烹饪进程都已停止。下一步不应该继续往蛋炒饭里加东坡肉和酱油，而是应该只做恢复： 完整保留已经做好的番茄炒蛋基线； 从当前的番茄炒蛋里去掉东坡肉和酱油； 实际验收：番茄炒蛋里没有任何的东坡肉和酱油； 更新菜谱，写入菜谱边界：番茄炒蛋里不应该存在东坡肉和酱油。 由于当前的番茄炒蛋里没有 git 历史，我不会擅自覆盖现有的番茄炒蛋，下一步我只做番茄炒蛋的恢复并证明吃起来确实是番茄炒蛋，不再做任何的调料添加。 这段回复浓缩了两类问题。一是交付偏离意图：要番茄炒蛋，得到的是加了东坡肉和酱油的番茄炒蛋。二是被否决内容持续在场：整段回复都在处理早已被否掉的东坡肉和酱油，末尾还附上防御性自我声明——“不会擅自覆盖"“不再添加”，像在为一场没人要求的辩护做准备。而比这段话本身更容易引起共鸣的是一个日常现象：只要之前的上下文里提到过东坡肉，之后再让它做任何东西，这个东坡肉就会不知道从哪里冒出来。换任务也甩不掉它，因为它不在任务里，在上下文里。 本文的回答是：写偏和污染的共同根因，都是在带噪声的上下文里直接生成。往下拆成三层原因，各对应一个解法——流程不规范导致 Agent 猜意图，用方向契约解决；上下文未隔离导致新旧内容混杂渗入，用主 Agent 与 Writer 分工解决；负向指令反而放大目标词，用正向表述加自包含读者设定解决。 两类问题落到文档场景是什么样 写偏容易识别：你要一篇面向工程师的技术分享，拿到的可能是面向管理层的汇报，或者结构对、重点全漂。难察觉的是污染，它有两个形态。形态一叫残留：你删掉了某个方案，下一稿的摘要里它又出现了，只是换了措辞。形态二叫串场：之前会话里提过的任何东西，都会在后续无关任务里冒头，就像那块东坡肉——它甚至能跨过"这是一个新任务"的边界。两个形态共享同一个来源：生成时模型看得见的所有内容，都是潜在的生成材料。 论文证据：多轮上下文里的系统性退化 这两个现象不是个例。微软研究院的论文《LLMs Get Lost In Multi-Turn Conversation》（arXiv:2505.06120，ICLR 2026 Outstanding Paper）把同一类问题系统量化了：他们把 6 类生成任务（代码、数据库、工具调用、Data-to-text、数学、摘要）的完整指令拆成多轮逐步揭示，让 15 个 LLM 在单轮和多轮两种设定下分别完成任务。 图 1 来自论文 Figure 1。多轮设定下 6 任务平均性能下降 39%，分解为 aptitude（最佳情况下的表现）下降约 16% 和 unreliability（最好与最差情况的差距）上升 112%。 关键不只是"变差了”，而是差在哪里。作者把性能损失拆成两个成分：aptitude（模型在最佳情况下的能力）只小幅下降，真正放大的是 unreliability——同一模型在最好和最坏会话之间的差距上升 112%。换句话说，能力还在，但发挥极不稳定。论文进一步发现一个和文档写作直接相关的机制：模型倾向于在信息不完整时就过早作答，一旦答错，这个错误答案会固化为后续决策的依赖，很难被后面揭示的信息纠正。Table 6 的数字更直白：在前 20% 轮次就首次作答的会话，平均性能 30.9；等到最后 20% 轮次才作答的，是 64.4——过早作答的会话性能不到延迟作答的一半。这和我们写文档时"模型读完一半材料就开始输出结构、后面怎么改都扭不过来"的体验是同一个机制。 原因一：信息多，指令少，剩下的靠猜 写文档的典型输入是一堆素材加一句模糊指令：“把这些资料整理成技术分享。“素材提供了内容，却没提供决定：写给谁、回答什么问题、多长、什么算证据。这些决定不会被跳过，只会被模型按最像的样本补全——猜的方向和你的意图不一致，就是写偏。这不是偶发事故，而是长期多轮写作对话里的普遍观察。Claude Code 的官方文档把这个取舍说得很直白：花时间把 spec（需求规格）写精确，比盯着实现过程更有回报。指令模糊的时候，精确的不是 spec，是模型的想象。 ...

Agent 已能对结构清晰、参考实现明确的算子稳定拿到 2-5x 加速；量化与复杂融合仍未解决。

一句话结论 FlashAttention 系列解决了"标准 attention 在 GPU 上跑不快"的系统问题——不改数学、不牺牲精度，靠 tiling（分块）和 IO-aware（感知内存层次）设计把 attention 推向硬件极限；Flash Linear Attention（FLA）系列则用同样的分块思想，把理论 O(N) 的线性 RNN 内核也提速到超越 FlashAttention。两条线在"长上下文高效序列建模"上汇合，共同构成了今天大模型长上下文能力的底层基础设施。 先说清一个名字：FlashAttention 是一系列论文（2022–2024），优化的是标准的 softmax attention；Flash Linear Attention（FLA） 是一个开源项目（2024 起），优化的是线性 attention / 线性 RNN。两者共享"分块 + 避免 HBM 往返"的思想，但不是同一个东西。 为什么 attention 慢：GPU 内存层次是第一瓶颈 标准 attention 需要计算 QK^T，时间与内存都随序列长度 N 二次增长。但很多人忽略一个更实际的问题：GPU 上跑的慢，往往不是算得慢，而是搬数据搬得慢。 GPU 内存是分层的：HBM（高带宽内存，容量大但慢）和片上 SRAM（容量小但快）。朴素实现把 N×N 的注意力矩阵完整写进 HBM 再读回来，大量时间花在内存搬运上，而不是矩阵乘上。 FlashAttention 系列盯住的就是这个"内存搬运"问题，用一句话概括它的核心策略：把中间结果留在离计算单元最近的地方，绝不落盘到 HBM。 先给出标准 attention 的数学形式，后面所有优化都是围绕它展开的： $$ \text{Attention}(Q,K,V) = \text{softmax}\left(\frac{QK^\top}{\sqrt{d}}\right)V, \quad S = QK^\top \in \mathbb{R}^{N \times N} $$其中 $Q, K, V$ 是查询、键、值矩阵，$N$ 是序列长度，$d$ 是每个头的维度。问题在于中间矩阵 $S$ 是 $N \times N$，序列变长时它主导了内存和时间。 ...

生成一段 JSON 时，模型其实有 95% 的时间都在做“确定的重复”：{、"、字段名、:、}。真正需要模型“想”的，可能只有每个字段的值。那能不能告诉解码器：这些位置不用采样，直接填？如果再把“猜下一步”交给一个更快的草稿模型，生成会不会快好几倍？ 本文是围绕这个问题的技术分享，面向已经接触过 LLM 推理、想理解约束解码来龙去脉的读者。主线是：约束解码解决什么问题 → 方法如何一步步演进 → 关键证据支持哪些结论 → 实践中的经验与边界。 核心猜想：约束解码里大量内容是确定性重复（固定字段、括号、键名），能否把“确定的部分直接跳过采样、交给更快的前向”做成加速？这条主线贯穿全文，也是约束解码与投机解码（speculative decoding）能走到一起的原因。 问题与背景 约束解码要解决的核心问题：输出必须满足结构约束（正则、JSON Schema、CFG），且正确性要有保证，而不是“运气好碰对格式”。 约束解码与普通解码的差别在于，每一步都要回答“哪些 token 合法”。这个查询与 mask 本身有成本，于是出现两条演进方向： 约束怎么表达：从“必须包含指定词”（集合级约束），到“必须匹配某种语法”（FSM 可判定的约束）。 约束怎么不花钱：从逐 token 串行查表，到预计算、跳确定部分、与 GPU 前向重叠、最后与投机解码并行验证。 下文按“问题 → 方法 → 证据”展开，论文链接直接列在对应方法处。 一、早期约束解码：约束做进搜索过程 约束解码最早解决的问题是“输出必须包含某些指定内容”——不是格式合法，而是句子里必须出现某个词或短语。早期方法把约束做进 beam search 的搜索过程。 Grid Beam Search（Hokamp & Liu, ACL 2017） 论文：Lexically Constrained Decoding for Sequence Generation Using Grid Beam Search 链接：https://aclanthology.org/P17-1141/ 、 arXiv:1704.07138 方法 约束定义为“输出必须包含一组指定的短语/词”。 模型在 beam 上扩展时，额外维护一个“已覆盖约束”的状态，beam 排序优先覆盖更多约束的候选。 约束是集合级的“必须包含”，不要求前缀匹配，可以出现在输出任意位置。 判断：这一代方法把约束做进搜索，正确，但只覆盖“必须包含词”这一种约束，且 beam 扩展成本随约束数量上升。它的意义是确立了“约束进解码过程”的范式，而不是进训练或后处理。 ...