【AI阅读】20250717阅读输入

【技术】大语言模型的缓存

LLM的缓存: 在与LLM进行多轮对话时，历史对话的请求和模型的回答，其对应的token和计算结果（作为KV Cache的状态）就可以被存入缓存，在后续对话中调用保存的缓存，从而减小信息传输开销、降低模型调用成本。

以下是和Gemini讨论出来的解释和示例

---

LLM缓存机制总结

核心摘要

LLM的缓存机制，本质上是一种**“计算结果复用”**技术。它通过将对话上下文中已经处理过的部分（Token）及其计算结果（KV Cache）存入临时内存，来避免在后续请求中重复计算相同内容。其最终目的非常明确：提升响应速度，并显著降低API调用成本。

流程逻辑对比

为了清晰地理解其价值，我们可以对比使用缓存前后的处理流程。

流程步骤	未使用缓存（常规模式）	使用缓存（高效模式）
1. 首次请求	用户发送请求 A。	用户发送请求 A。
2. 首次处理	LLM从头完整计算请求A的所有Token。	LLM从头完整计算请求A的所有Token，并将计算结果存入缓存。
3. 后续请求	用户基于A的上下文，发送新请求 B。	用户基于A的上下文，发送新请求 B。
4. 后续处理	LLM必须将 A 和 B 拼接成一个完整的长文本(A+B)，然后从头计算这个长文本的所有Token。	LLM从缓存中直接调取A的计算结果，然后仅计算新请求B的Token，并将新旧结果结合生成回应。
核心区别	每次都要重复计算全部历史上下文。	只计算新增的部分，历史部分直接复用。

关键细节与示例说明

场景示例：一次连续的问答对话。

第一轮请求：

• 用户输入："中国的首都是哪里？"

• Token化：输入被分解为一组Token，我们称之为 Token组A (["中国", "的", "首都", "是", "哪里", "？"])。

• 关键动作：模型处理 Token组A 并生成回答。在使用缓存的模式下，模型会同时将 Token组A 对应的计算结果（即上下文的“理解”）存入缓存中。

第二轮请求：

• 用户输入："那里的天气怎么样？"（这里的“那里”明显指代“北京”）

• Token化：这个新输入被分解为 Token组B (["那里", "的", "天气", "怎么样", "？"])。

成本计算的差异：

• 无缓存成本：

  • 模型需要处理的完整输入是 "中国的首都是哪里？那里的天气怎么样？"。

  • 实际计算量约等于 处理(Token组A) + 处理(Token组B) 的总和。

• 有缓存成本：

  • 模型从缓存加载 Token组A 的现成结果。

  • 它仅需计算新的 Token组B，并结合已缓存的上下文来理解“那里”的指代。

  • 实际计算量约等于 处理(Token组B)。

结论：通过缓存，第二轮请求的计算成本被大幅缩减，因为占很大一部分的 Token组A 无需再次计算。

最终结论

LLM的缓存机制就像是为模型增加了一个**“短期记忆”。它使得模型在进行连续对话或处理具有相同前缀（例如文档摘要、代码补全等场景）的任务时，能够记住对已有信息的“理解”，从而避免了对历史上下文的重复性劳动。这种“只算增量，不算全量”的智能方式，是实现LLM服务高效、低成本**运行的关键技术之一。

---

【技术】MoE概念和原理

 参考阅读

一文阅读：https://zhuanlan.zhihu.com/p/680190127

MoE数量问题：https://www.zhihu.com/question/12879191288/answer/106381620484?utm_psn=1876177033589030912

从deepseek大模型看混合专家模型MoE

https://zhuanlan.zhihu.com/p/673048264

https://zhuanlan.zhihu.com/p/672712751

让Gemini进行总结如下

一、 关键结论

1. MoE是当前大模型实现“降本增效”的核心路径：MoE架构通过在训练和推理时只激活一部分“专家”（子网络），实现了在扩展模型参数规模的同时，保持计算量（FLOPs）相对恒定。这解决了传统稠密模型（Dense Model）“越大越强但也越贵越慢”的根本矛盾。

2. MoE的核心是“稀疏激活”与“动态路由”：其精髓在于模型不必在处理每个任务时都动用全部的计算能力。通过一个“路由器”（Router）来判断每个输入（Token）应该由哪些最擅长的专家来处理，从而实现计算资源的动态、稀疏分配。

3. MoE并非单个巨大模型，而是“专家委员会”：一个MoE模型由多个相对较小的专家网络和一个路由网络构成。例如，一个拥有8个专家的千亿参数MoE模型，在推理时可能只激活其中2个专家，其计算成本仅相当于一个拥有两百多亿参数的稠密模型，但性能却能媲美千亿级别的稠密模型。

4. DeepSeek-MoE是MoE成功应用的关键案例：DeepSeek的开源模型证明了MoE架构的巨大潜力。它通过共享专家（Shared Experts）和路由策略优化，有效地提升了模型性能和训练稳定性，为MoE的实践提供了宝贵的经验。

5. MoE的挑战与未来方向：尽管优势显著，MoE在训练、微调（Fine-tuning）和部署方面仍面临挑战，主要包括训练不稳定、路由策略复杂、以及对显存（VRAM）的高需求。未来的研究方向将聚焦于优化路由算法、改进微调技术和降低部署门槛。

---

二、 支撑论点与细节

1. MoE架构如何工作？——“分而治之”的智慧

• 基本构成：MoE模型主要由两部分组成：

  • 多个专家网络（Experts）：这些是前馈神经网络（FFN），每个专家都有自己独特的参数，并可能被训练成擅长处理特定类型的信息（如语言、代码、逻辑推理等）。

  • 门控网络/路由器（Gating Network/Router）：这是MoE的“大脑”，负责为每一个输入的Token计算权重，并决定将这个Token发送给哪些专家处理。最常见的路由策略是“Top-K”，即选择得分最高的K个专家。

• 示例：Mixtral 8x7B模型

  • 该模型有8个专家，每个专家的参数量约为70亿。

  • 在处理每个Token时，路由器会选择激活2个最合适的专家。

  • 因此，尽管总参数量巨大（约47B），但实际参与计算的参数量仅约13B，实现了性能与效率的平衡。

2. 为什么MoE能“降本增效”？——规模与成本的解耦

• 传统模型的困境：稠密模型的参数量和计算量是强耦合的，模型越大，训练和推理的成本就越高。

• MoE的突破：MoE通过稀疏激活，打破了这种耦合。模型的总参数量可以非常大（“大而全”），但单次推理的计算量只取决于被激活的少数几个专家的规模（“小而精”）。

• DeepSeek的实践：DeepSeek-MoE 16B版本，虽然总参数量庞大，但每次推理只激活约2.8B的参数，使其推理速度能与7B规模的稠密模型相媲美，但性能却远超后者。这直接证明了MoE架构在成本效益上的巨大优势。

3. MoE面临的技术挑战与解决方案

• 挑战一：训练不稳定与负载均衡

  • 问题：如果路由策略不当，可能会导致某些专家被过度使用（“明星专家”），而另一些专家则很少被激活（“懒惰专家”），造成资源浪费和训练效果不佳。

  • 解决方案：引入负载均衡损失函数（Load Balancing Loss）。通过在训练目标中加入一个惩罚项，鼓励路由器将任务更均匀地分配给所有专家，确保每个专家都能得到充分训练。

• 挑战二：对显存（VRAM）的高要求

  • 问题：虽然计算量是稀疏的，但所有专家的参数都需要被加载到显存中，这使得MoE模型对硬件的要求非常高。一个180B的MoE模型可能需要比一个同样大小的稠密模型更多的显存。

  • 解决方案：专家并行（Expert Parallelism）等分布式训练技术，将不同的专家分散到不同的GPU上，以应对显存挑战。

• 挑战三：微调（Fine-tuning）的复杂性

  • 问题：对MoE模型进行全量微调成本高昂，且容易导致性能下降。

  • 解决方案：目前社区正在探索更高效的微调方法，例如只微调路由器、或者冻结大部分专家参数，只对少数专家或适配器（Adapter）进行微调。

4. 从DeepSeek看MoE的进阶玩法：共享专家

• DeepSeek-MoE模型提出了一个创新点：共享专家（Shared Expert）。除了路由选择出的K个“领域专家”外，每个Token还会被一个所有Token都必须经过的“共享专家”处理。

• 作用：这个共享专家负责学习和处理那些所有任务都通用的、基础性的知识模式。这不仅提升了模型的泛化能力，还有效地稳定了训练过程，降低了对路由策略的过度依赖。

通过上述分析，我们可以看到，混合专家模型（MoE）通过其独特的稀疏激活机制，为大模型的发展开辟了一条兼顾性能、规模和成本的可持续发展道路，并正在成为前沿AI研究和应用的核心驱动力之一。

拓展：MoE模型的数据处理路径

介绍MoE（Mixture-of-Experts）模型在训练时的数据路径和处理方式。

理解MoE的训练路径，核心在于理解其“动态”和“稀疏”的特性。它不像传统模型那样有一条固定的、所有数据都必须经过的路径，而是为每个输入（Token）动态地选择一条计算路径。

我们可以用一个“公司项目分派”的类比来开始：

• 项目（输入Token）：一个需要处理的新任务。

• 总调度中心（路由器）：一位经验丰富的项目经理，他了解公司里每个专家团队的特长。

• 专家团队（Experts）：多个并行的专业团队，比如“技术部”、“市场部”、“法务部”等。

• 分派决策（路由）：项目经理拿到新任务后，不会把它发给所有团队，而是快速判断后，选择最相关的两个团队（比如“技术部”和“市场部”）来处理。

• 最终方案（输出）：两个团队分别给出意见，项目经理将他们的意见加权汇总，形成最终的解决方案。

基于这个比喻，MoE模型在训练时的具体路径分为以下几个步骤：

---

MoE训练路径详解（以一个Token为例）

假设我们有一个MoE层，它包含8个专家（Experts），并且路由策略是 Top-K 中的 K=2（即为每个Token选择2个专家）。

第一步：进入路由器（Gating Network）

当一个Token（经过词嵌入转换成向量）抵达MoE层时，它首先被发送到路由器（Router），也就是我们的“总调度中心”。

• 路径：Token Vector -> Router

• 目的：路由器的唯一工作，就是为这个Token计算出一个“分派决策”，即判断哪几个专家最适合处理它。

第二步：计算专家亲和度分数（Expert Scores）

路由器本身是一个小型的神经网络（通常是一个简单的线性层）。它接收Token的向量，然后输出一个代表所有专家分数的列表（logits）。这个列表的长度等于专家的数量（在这个例子中是8）。

• 计算：Router(Token Vector) -> [Score_E1, Score_E2, ..., Score_E8]

• 含义：每个分数代表了对应专家与当前Token的“匹配程度”或“亲和度”。分数越高，代表路由器认为该专家越适合处理这个Token。

第三步：Top-K路由决策与权重分配

系统会从8个分数中，选出最高的 K 个（这里K=2）。

1. 选择专家：假设计算后，专家3（E3）和专家5（E5）的分数最高。那么系统就决定，这个Token的计算路径将经过E3和E5。

2. 计算权重：为了知道最终该如何融合这两个专家的输出，路由器会使用Softmax函数对所有8个分数进行归一化，得到一组概率权重。这个权重不仅用于后续的加权求和，也反映了所选专家的相对重要性。

• 路径决策：Token将被发送到E3和E5。其余6个专家对于这个Token来说，在本次计算中将处于“休眠”状态，完全不参与。这就是“稀疏激活”的核心。

第四步：并行处理（Expert Processing）

Token的向量会被同时发送给被选中的E3和E5。这两个专家网络（它们是标准的前馈神经网络FFN）会并行地对这个Token向量进行计算，各自生成一个输出向量。

• 路径：

  • Token Vector -> Expert 3 -> Output_E3

  • Token Vector -> Expert 5 -> Output_E5

第五步：聚合输出（Aggregation）

MoE层需要将来自多个专家的输出融合成一个单一的输出向量。这一步是通过对专家输出进行“加权求和”来完成的。权重就是第三步中由Softmax计算出的、归一化后的专家分数。

• 计算：Final Output = (Weight_E3 * Output_E3) + (Weight_E5 * Output_E5)

• 含义：如果路由器认为E3比E5更重要（即E3的原始分数更高），那么在最终的输出中，E3的“话语权”就会更大。

第六步（关键补充）：负载均衡损失（Load Balancing Loss）

在训练过程中，存在一个风险：路由器可能会“偷懒”或产生偏好，总是把任务交给某几个“明星专家”，导致其他专家一直空闲，得不到训练。

为了解决这个问题，MoE的训练路径中引入了一个非常重要的机制——负载均衡损失。

• 目的：鼓励路由器将Token尽可能均匀地分配给所有专家。

• 工作方式：它是一个附加的损失函数（Auxiliary Loss）。如果在训练的一个批次（Batch）中，各个专家处理的Token数量差异过大，这个损失函数的值就会变高。模型在优化总损失时，不仅要优化预测任务的损失，也要优化这个负载均衡损失。

• 效果：这会“迫使”路由器学习一种更均衡的分派策略，确保所有专家都能“雨露均沾”，得到充分的训练，从而避免模型能力退化。

---

总结：训练路径的三个关键特性

1. 动态性（Dynamic）：路径不是预设的，而是由路由器根据每个Token的内容动态决定的。Token A的路径可能是专家1和专家7，而Token B的路径可能是专家2和专家4。

2. 稀疏性（Sparse）：在任何一次计算中，只有一个子集的专家被激活和计算。这使得模型可以在拥有巨大总参数量的同时，保持相对较低的单次计算成本（FLOPs）。

3. 并行性（Parallel）：所有专家的参数通常被分布在不同的计算设备（GPU）上。当一个Token需要被分派时，它的数据会通过高速网络被传输到存放对应专家的GPU上进行计算，各个被选中的专家并行工作，结果再被传回聚合。这被称为专家并行（Expert Parallelism），是实现MoE高效训练的物理基础。

 

拓展：Deepseek-MoE的创新

DeepSeek-MoE 提出的 “共享专家（Shared Expert）” 是对传统 MoE（Mixture of Experts）架构的一种 重要改进和补充，解决了原始 MoE 模型中存在的一些核心问题。下面逐点解释这个创新点的意义：

---

📌 一、传统 MoE 的问题回顾

传统的 MoE 模型结构中，每个 Token 只会被路由（gating）到一小部分专家（比如 top-2）中处理，好处是计算效率高，但也带来两个主要问题：

1. 缺乏共享知识：每个专家可能只见到特定类型的样本，导致模型不同部分之间共享信息不足；

2. 过度依赖路由策略：模型性能严重依赖 gating 的准确性，若路由错误，Token 会被送到不擅长处理它的专家，从而性能下降。

---

🚀 二、DeepSeek 的创新点：引入“共享专家（Shared Expert）”

DeepSeek 在传统结构基础上，引入一个 所有 Token 都必须经过的共享专家模块，其特征是：

• 不经过路由选择，所有 Token 都会处理；

• 与领域专家并行计算，最后将共享专家和领域专家的输出合并（如相加）；

• 共享专家只有一组参数，是全局共享的。

---

🧠 三、共享专家的作用和好处

作用	说明
✅ 学习通用模式	能捕捉跨任务、跨样本的基础性知识（如语言结构、常识等），避免不同专家“重复造轮子”
✅ 提高泛化能力	即使 gating 策略选错专家，共享专家也能保证 Token 至少经过了“合理处理”，降低错误风险
✅ 稳定训练	提供一个稳定的梯度通道，防止训练初期 gating 未收敛时专家选择失衡或梯度消失
✅ 提升效率	减少对多个专家训练的依赖，增强参数使用效率和整体表达能力

---

🧩 类比一下

可以把传统 MoE 理解为“多个专科医生，病人被调度到特定的医生看病”，但 DeepSeek-MoE 增加了一个“家庭医生（共享专家）”，所有病人都先看一次家庭医生，再决定要不要找专科，基础病家庭医生直接就能处理掉，复杂的再路由到专科。

---

🧪 总结一句话

共享专家 = 把全局通用能力集中学好，弥补 MoE 模型碎片化带来的问题，同时提高泛化能力和训练稳定性。