【AI阅读】20250717阅读输入

发布于:2025-07-28 ⋅ 阅读:(16) ⋅ 点赞:(0)

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

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

一、 关键结论
  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 模型碎片化带来的问题,同时提高泛化能力和训练稳定性。


网站公告

今日签到

点亮在社区的每一天
去签到