街角的餐饮界最近出了两件大事。第一家店叫“小泽厨房”,后厨只有一位全能主厨,他一个人备菜、掌勺、出餐,速度却比对面十几人团队的大饭店还快,味道也更受欢迎——这是 Mistral 7B,一个只有 70 亿参数的法国开源模型。第二家店叫“专家大院”,是它的升级版。大院后厨挂名 8 位专科大厨,法餐、川菜、日料各有所长,但奇异的是:每张订单进来,前厅经理只喊最对口的 2 位大厨掌勺,其余 6 位继续在休息室喝茶。大院账面有 470 亿参数的厨师编制,可每次只消耗相当于 130 亿参数的人力成本——这就是 Mixtral 8x7B 的“专家混合”(MoE)绝活。 小泽主厨还有一门独门功底:他不背整本菜谱,只盯最近翻过的几页,这叫“滑动窗口注意力”;专家大院则练就了“看单派厨”的精准眼力,这叫门控路由。这篇文章带你把两家后厨里里外外看个遍:从架构创新到公开成绩单,从开源菜谱到如何把店开进自家社区(本地部署),再到定制专属菜单(微调)。读完你会明白:为什么越来越多聪明的团队,开始扔掉“模型越大越好”的执念。
看懂 Mistral 系列,能让你在做模型选型时少花冤枉钱——同样的预算,有人买回一台“用不动的巨兽”,有人请回一位“立刻出活的能手”。这篇文章帮你练就那双选厨的眼睛。
可视化演示
展示分布式数据库两阶段提交(2PC)协议的完整流程:Prepare投票阶段与Commit决策阶段,对比全部提交与部分中止两种场景。
本节配有交互动效(进入视口后自动加载,约 3KB)。
两阶段提交 - 全部提交场景 协调者发送Prepare消息,参与者投票YES/NO 全部YES则Commit,任一NO则Abort 决策 = AND(所有参与者投票) 2PC保证原子性,但存在协调者单点故障风险。
模型定位
小泽厨房开张那天,很多人等着看笑话:一个人撑后厨,能行吗?结果试营业第一周,排队的人从街头排到街尾。原因很朴素——这位主厨把每一道菜都练到了极致,翻台率比隔壁十三个人的团队还高。Mistral 7B 就是 2023 年 9 月法国 Mistral AI 端出的这道菜。
AI 圈衡量模型“牌面”的第一个指标是参数量——可以理解为厨师学过的菜谱页数。Mistral 7B 只有 70 亿参数(7B 即 7 Billion),同期的 Llama 2 13B 却有 130 亿。按常理,参数多应该更能打,可评测结果反了过来:Mistral 7B 在 MMLU、HellaSwag 等多项基准上都压过了 Llama 2 13B。原因在于,模型能力并不只由参数量决定,训练数据的质量、架构设计的取舍同样关键。
Mistral 7B 用 Apache 2.0 协议开源,允许商用;原生支持 8K 上下文,后来延伸到了 32K。对小团队来说,它意味着“花小钱办大事”——不用凑几万美元的算力账单,一张消费级显卡就能请回一位靠谱主厨。
1. 分子 S——评测得分:S 代表模型在标准数据集(如 MMLU)上的分数,表示“菜做得好不好吃”。
2. 分母——参数量:7.3×10⁹ 是 73 亿,1.3×10¹⁰ 是 130 亿。注意 10 的指数差一档,数量级完全不同。
3. 不等式——单位效率:用“得分 ÷ 参数”衡量每一亿参数产出的能力,分母小、分子大,比值自然更高,这正是小模型的核心竞争力。
所以小泽主厨的生意经是:不拼后厨人数,拼菜谱质量和烹饪手法。对开发者来说,Mistral 7B 这类“小而强”的模型特别适合做应用底座——省下的显卡预算,可以请更多的前端和服务端“服务员”。
滑动窗口注意力
小泽主厨记性好其实是假象,他靠的是“只看眼前”。传统大模型读文章时,每个词都要和全文所有词算一遍亲密度——像厨师接单时要把整本菜谱从头翻到尾,菜谱越厚,上菜越慢。这种“每个词看所有词”的机制,叫全局注意力。
注意力(Attention)的本质是“加权回顾”:生成新词时,模型对原文每个位置打个分,谁分高就多看谁。标准实现里,文章有 N 个词就要算 N×N 次两两关系,计算量随 N 的平方暴涨——一篇 8000 字的文章就是 6400 万次关系运算,对话越长越吃力,就像主厨翻菜谱翻到手抽筋。
Mistral 7B 的解法是滑动窗口注意力(Sliding Window Attention,SWA):每个词只看前后 W 个词(默认 W=4096)。排队时你只需留意前后几个人的动态,不用记住整个大厅。更妙的是,多层窗口堆叠之后,高层神经元能通过“接力”看到很远的词——视野并没有真正丢失,只是换了个省力的看法。
1. Q 与 K 的内积:Q 是查询向量,K 是键向量,两者点积计算“我找的东西”和“你提供的东西”的匹配程度。
2. 缩放因子:√d_k 是键向量的维度。内积数值会随维度变大而膨胀,除一下让 softmax 的梯度更稳定。
3. 掩码矩阵 M:SWA 的精髓全在这里——窗口内为 0 表示放行,窗口外为 -∞ 表示禁止关注。矩阵里“哪里是窗”由窗口大小 W 决定。
4. softmax 归一化:把每个位置的分数变成概率,窗口内所有被放行的位置权重加起来为 1。
5. 加权求和:用这些概率对 V(每个位置承载的内容)做加权平均,得到当前词的新表示。
回到餐厅:小泽的“只看眼前”不是目光短浅,而是把记性用在刀刃上。4 层窗口像 4 个服务员接力传话——每个人只把话传给身边窗口内的同事,一层层传下去,大厅另一端也能听到。省下的翻菜谱时间,让小泽能同时接待更多客人,出菜速度自然遥遥领先。
MoE架构
小泽厨房的招牌菜火了之后,老板决定开一家“专家大院”——Mixtral 8x7B。大院后厨里挂名 8 位专科大厨:有人精法餐、有人擅川菜、有人专攻烘焙。最妙的是运作方式:每张订单进来,前厅经理快速扫一眼菜单,只喊最对口的 2 位大厨掌勺,其余 6 位继续喝茶。这套模式的专业名字叫“专家混合”(Mixture of Experts,MoE)。
技术上,MoE 把标准 Transformer 里的前馈网络层(FFN,可以理解为模型“思考”的模块)替换成 8 个并行的专家 FFN,再加一个门控网络(Gating Network,也就是那位前厅经理)。每个 token(可以理解成一个词片段)进入时,门控给 8 位专家各打个分,选出最高的 2 位,让它们处理后再按得分权重融合输出。
关键数字:Mixtral 总参数量约 46.7B,但每个 token 实际只激活约 13B 参数。所以模型文件虽然大(约 90GB),推理速度却接近一个 13B 模型。注意,这里有个经典误解:名字"8x7B"不是 56B——8 指专家数,7B 是每个专家模块的架构量级参考,不是简单乘法。
1. 输入 token x:模型把文本切成一个个 token,每个 token 都独立走一遍“派单”流程,就像每桌客人独立下单。
2. 门控打分:门控网络用权重矩阵 W_g 对 x 做线性变换,得到 8 个分数,再用 softmax 变成概率。分数代表“这道题谁更对症”。
3. Top-2 截断:只保留概率最高的 2 位,其余专家的权重被强制变成 0——他们完全不参与计算,这是省算力的根源。
4. 加权融合:被选中的专家各自输出 E_i(x),乘上门控权重后求和,得到该 token 的最终输出。
专家大院的经营理念是“能力全员共享,成本按需结算”。8 位大厨的工资照发(参数计入总文件),但每道菜只动用 2 位(稀疏激活),所以人力成本只有 2 人份。对做应用的人来说,Mixtral 的意义在于:想要 47B 级别的知识储备,却只需支付 13B 级别的电费。
性能表现
吹得天花乱坠不如拿成绩单说话。AI 圈有一套标准考卷:MMLU(万题综合知识考试)、HellaSwag(常识推理)、GSM8K(小学数学应用题)、HumanEval(代码编写测验)。专家大院开业后,几乎门门功课都不输“对面大饭店”的 Llama 2 70B,考试成本却少了一大截。
具体成绩方面:Mixtral 8x7B 在 MMLU 上拿到 70.6 分,超过 Llama 2 70B 的 68.9;代码测验 HumanEval 得 40.2,超过同规模的众多开源模型(比如 CodeLlama 7B 的 33.5)。Mistral 7B 单枪匹马也在 MMLU 拿下 60.1,把 Llama 2 13B 的 55.9 甩在身后。尤其亮眼的是多语言能力——训练语料里法语、德语、西班牙语占比高,这让非英语场景的开发者特别心动。
为什么 Mixtral 能“缩着打”?因为稀疏激活让每个 token 只走 2 个专家,等于每道题只有 2 位对症大厨认真做,其余专家不掺和。实验结果反复证明:参数总量决定“知识储备上限”,激活参数决定“当下解题速度”,两者可以脱钩。
1. 答对题数:N_correct 是模型在考卷上答对的题目数量,是“正确”个数的计数。
2. 总题数:N_total 是考卷总题数,MMLU 大约有 1.4 万道题,覆盖 STEM、人文、社科等 57 个科目。
3. 百分化:两者相除得到一个 0 到 1 的比例,乘以 100% 换算成百分制分数,方便人和模型横向对比。
成绩单漂亮之余,还得算算学费。Mixtral 跑一次推理只激活 13B 参数,单位成本远低于同分数段的其他 70B 级模型。这就好比一个高材生只用三成力气就考到年级前三——对创业团队来说,“每分成本”往往比“满分”更值钱。
开源生态
小泽主厨有个传家规矩:菜谱完全公开,欢迎同行抄作业,甚至允许你拿他的菜谱开分店赚钱。Mistral 的两款模型都采用 Apache 2.0 协议——这是开源界最宽松的许可之一:可以下载、可以改、可以商用,只要保留版权声明。
实际动手时:模型权重在 HuggingFace 上直接下载,一行 transformers 代码就能跑起来。社区在 Mistral 7B 之上衍生了一大票热门模型——OpenHermes、Zephyr 等对话增强版,还有各种中文优化版。对个人开发者来说,这意味着你不需要从零训练,直接在“成熟菜谱”上改口味,把精力省给业务。
“开源可商用”六个字对商业公司尤其关键。Llama 2 有“月活过亿需另外申请授权”的限制,GPT-4 是闭源按 token 收费;而 Apache 2.0 没有这些条条框框,是创业者把模型放进产品时的安全垫。
1. 使用权:允许下载权重、部署到服务器或端侧设备、在生产环境运行,不额外收费。
2. 修改权:允许改架构、改权重、做微调和剪枝——社区衍生模型的前提就是这一项。
3. 商用权:允许把模型嵌入付费产品、提供商业化 API,这是创业公司最看重的命脉。
4. 再分发权:允许把修改后的模型重新发布给公众,但必须保留原版权声明。
公开菜谱让同行们在招牌菜上长出了麻婆豆腐版、法式吐司版……生态越繁荣,模型越不容易被时代淘汰。所以选型时我总看两个指标:协议松不松、社区活不活。Mistral 两项都拿高分,这也是它迅速走红的关键原因。
本地部署
想请小泽主厨回自家小店,先看看厨房多大。Mistral 7B 原始权重(fp16 精度)约 14GB,一张 16GB 显存的消费级显卡就能端上来;Mixtral 全量约 90GB,一般团队都嫌贵。好在有“量化”这门手艺——把参数的数值精度从 16 位压缩到 4 位,等于把精装菜谱缩印成口袋本,体积缩到四分之一,口味损失有限。
最常见的工具是 Ollama:一条 ollama run mistral 命令,自动下载量化版并在本地起服务。Q4 量化版权重只有约 4.4GB,普通笔记本的 CPU 也能跑出能用的速度。Mistral 7B 也因此成为端侧部署的明星——手机、树莓派,甚至浏览器里都能运行。
我们来算一笔账:
代入 7B 参数、4bit 量化:7×10⁹×4÷(8×10⁹)≈3.5GB,加上激活值和对话缓存的额外开销,留 8GB 内存比较稳。推理速度方面,M1 Mac 上 4bit 量化版约每秒 15~25 token,足够对话场景的阅读节奏。
1. P——参数量:7B 模型即 P=7×10⁹。参数是权重的个数,每个权重都要占内存。
2. q——量化位宽:fp16 全精度时 q=16,4bit 量化后 q=4。位宽直接决定单个权重的存储大小。
3. 除以 8 换单位:1 字节 = 8 位,先把总比特数换成字节,再除以 10⁹ 得到 GB。
请大厨进社区小店的关键不是菜谱厚不厚,而是“冰箱够不够大”。量化就是把菜谱缩印的功夫——牺牲一点点精度,换来在普通 PC 上流畅出菜。对端侧 AI 团队而言,Mistral 7B 是目前“冰箱尺寸/菜品水准”比最划算的选择之一。
微调实践
请回来的大厨是通用型,但你的店主打徽菜:客户术语、客服话术、行业黑话,他都得现学。全参数重新训练不现实——动辄几十万成本。于是 LoRA 登场:它像给主厨戴一副“定制眼镜”,原手艺不动,只额外记录“微调的口味偏好”。
LoRA(Low-Rank Adaptation,低秩适配)发现了一个规律:大模型微调时,权重的更新量 ΔW 其实高度“浓缩”,可以用两个很小的矩阵 A、B 相乘近似。训练时原始权重 W 原地冻结,只更新 A、B:可训练参数从 70 亿降到几千万,一张消费级显卡就能完成微调。常用工具是 HuggingFace 的 PEFT 库配合 transformers 的 Trainer。
微调通常三步走:第一步准备数据集——几百到几千条“问题-答案”对,把历史客服工单、文档问答整理成指令格式,数据质量远重要于数量;第二步选框架——PEFT 或 SFT 训练器;第三步评估——留出验证集,看回答风格和正确率是否达标。典型用例包括法律文书问答、电商客服机器人、代码补全助手。
1. 冻结原参数:原始权重 W 在训练中一动不动——相当于大厨已有的手艺完全保留。
2. 低秩分解:更新量 ΔW 被拆成两个小矩阵相乘,r 远小于 m、n,训练参数量从亿级降到百万级。
3. 合并回加:推理时把 BA 加回 W,得到微调后的权重 W′。模型结构完全不变,只是“口味”变了。
回到餐厅:LoRA 不是让主厨重学做菜,而是给他换一副“口味镜片”——切到客服场景是一副,切到法律场景再换一副,随时切换,原手艺不丢。这种“只换镜片不换人”的范式,是今天大模型落地的标准姿势。
AI 应用场景
场景一:端侧离线客服助手
阶段:模型部署与推理优化
解决的问题:传统云端客服 API 有三大痛点:每轮对话按 token 付费、网络延迟不稳定、用户隐私数据必须出网。把 Mistral 7B 做 4bit 量化后部署到本地服务器或用户终端,对话全程不出内网,单次推理成本趋近于零。
具体案例:某电商售后团队把历史工单整理成 3000 条问答对,用 LoRA 微调 Mistral 7B,再量化为 Q4 部署到公司内网一台 16GB 显存的旧服务器上。客服输入客户问题,系统 1~2 秒给出答案草稿,敏感订单数据永不外传。
场景二:多领域知识库问答
阶段:模型选型与推理架构
解决的问题:企业内部知识库覆盖法务、财务、技术三个领域,单一模型经常“顾此失彼”。Mixtral 8x7B 的 8 位专家天然适合多领域混合——虽然专家分工并非显式按领域划分,但其“稠密+稀疏”的组合在跨域任务上表现更稳。配合 RAG(检索增强)把相关文档喂进上下文,效果更佳。
具体案例:一家咨询公司用 Mixtral 8x7B 搭建内部“百晓生”问答系统,接入 Notion 知识库做检索增强,模型负责综合生成。上线后,跨部门提问的准确率比之前用的单一 7B 模型提升约 12 个百分点,GPU 成本只增加了约 40%。
场景三:低成本垂直领域微调
阶段:模型训练与微调
解决的问题:法律文书写作需要专业话术和固定格式,直接让通用模型写,输出往往“正确但不像人话”。全参微调需要多卡训练,小团队玩不起。LoRA 让可训练参数从 70 亿降到千万级,单张 24GB 显卡即可完成微调。
具体案例:一家律所科技团队用 2000 条判决书摘要样本,对 Mistral 7B 做 LoRA 微调,3 小时完成训练。生成的法律文书摘要格式符合度和信息完整度显著提升,随后用 Ollama 部署到内部服务器,供 30 位律师日常使用。
Python 演示
"""MiniMoE: 极简版专家混合模型演示用 numpy 实现 Mixtral 8x7B 的核心机制:门控打分 -> Top-2 稀疏激活 -> 加权融合输出"""import numpy as np class MiniMoE: def __init__(self, d_in=8, n_experts=8, top_k=2, d_ff=16): self.n_experts = n_experts self.top_k = top_k # 门控网络: 负责给每个专家打分 self.W_g = np.random.randn(d_in, n_experts) * 0.02 # 8 位专家, 每位是一个两层小网络 (d_in -> d_ff -> d_in) self.experts = [ ( np.random.randn(d_in, d_ff) * 0.02, np.random.randn(d_ff, d_in) * 0.02, ) for _ in range(n_experts) ] def gate(self, x): # 输入 x: (batch, d_in), 输出概率: (batch, n_experts) scores = x @ self.W_g probs = np.exp(scores) / np.sum(np.exp(scores), axis=1, keepdims=True) return probs def forward(self, x): probs = self.gate(x) # Top-2 选择 top_idx = np.argsort(-probs, axis=1)[:, :self.top_k] out = np.zeros_like(x) for b in range(x.shape[0]): for j in top_idx[b]: w1, w2 = self.experts[j] h = np.maximum(x[b] @ w1, 0) # ReLU 激活 out[b] += probs[b, j] * (h @ w2) return out, probs, top_idx def main(): np.random.seed(42) model = MiniMoE(d_in=8, n_experts=8, top_k=2) x = np.random.randn(4, 8) # 模拟 4 个 token out, probs, top_idx = model.forward(x) print("Token 数: 4, 专家数: 8, 每次激活: 2") print("门控概率矩阵 (4x8):") print(np.round(probs, 3)) print("每个 token 激活的专家序号:") print(top_idx) print("输出形状:", out.shape) if __name__ == "__main__": main()
self.W_g = np.random.randn(d_in, n_experts) * 0.02这是“前厅经理”的门控矩阵:把输入打分给 8 位专家,乘 0.02 让初始权重小而均匀,避免一开始就出现“偏科”。probs = np.exp(scores) / np.sum(np.exp(scores), axis=1, keepdims=True)手写 softmax:把 8 个分数转成概率分布,和为 1,对应“谁更对症”的置信度。top_idx = np.argsort(-probs, axis=1)[:, :self.top_k]倒序排序后取前 2,选出每个 token 的 Top-2 专家序号,这就是稀疏激活的“裁缝”动作。out[b] += probs[b, j] * (h @ w2)选中专家的输出乘上门控权重再累加,正是公式 y = ΣG(x)E(x) 的落地实现。if __name__ == "__main__":Python 的标准入口写法:模块既能被 import 复用,又能独立运行演示。
常见误区
误区看到 Mixtral 8x7B,第一反应是 8×7=56,觉得它是个 560 亿参数的巨无霸,于是按 56B 去估算显存和下载时间,结果发现算得完全不对。
正解官方总参数量约 46.7B,“7B“是每个专家模块的架构量级参考,并不是精确的乘法;而且推理时每个 token 只激活约 13B 参数。算显存应该按”激活参数 + KV 缓存”来估,而不是简单地拿总参数乘位宽。
为何常见:名字里的“ד太有误导性,人天生喜欢把乘号当算术;加上 MoE 概念较新,一时难以建立”总参数 ≠ 激活参数”的直觉。
误区以为 8 位专家每次都会被调用,只是权重不同、贡献有大有小,所以速度和显存开销应该和 47B 的稠密模型一样。
正解门控网络的 TopK 会把非入选专家的输出权重直接置 0,它们在计算上是“完全跳过”的,不产生任何矩阵乘法。所以 Mixtral 的推理速度接近 13B 稠密模型,这才是 MoE 省算力的根本原因。
为何常见:多数人不习惯“稀疏”思维,默认挂了名就要干活;官方文档又没有反复强调"skip",很容易被忽略。
误区窗口只有 4096 个 token,那 8000 字的长文章后半段岂不是“失忆”?很多人因此认为 Mistral 处理不了长文本。
正解多层滑动窗口堆叠后,高层 token 通过中间层“接力”能间接关联到相距很远的 token,有效感受野接近全窗口;推理时还有滚动缓存机制,已生成内容仍可通过窗口滚动被看到。窗口限制的是“单次直接注意力”,不是“长期记忆”。
为何常见:把“注意力窗口”误解成“记忆长度”,忽略了多层网络的级联效应在长距离信息传播中的桥梁作用。
误区既然写着“开源”,那直接下载部署就行,完全不用看协议细节,反正不要钱。
正解Apache 2.0 确实允许商用,但不同模型协议天差地别:Llama 2 有月活过亿的门槛,有些模型限制商用或要求回传。商用前务必核对 LICENSE 文件。另外,推理有算力成本、带宽成本、运维成本,“免费”的只是授权费。
为何常见:“免费”二字最抓眼球,而协议条款枯燥,多数开发者没有耐心逐条读完,等出事后才追悔莫及。
误区既然是“小模型”,那下载下来任何电脑都能如丝般顺滑运行,不用考虑硬件配置。
正解Mistral 7B 的 fp16 权重约 14GB,需要 16GB 内存或显存才勉强加载;只有 4bit 量化到 4GB 左右、配好 Ollama 这类工具,普通笔记本才能流畅跑。端侧部署的前提是“量化 + 推理优化”,而不是模型天然省电。
为何常见:“7B 小模型”里的“小”是相对 70B 说的,绝对体量并不小;媒体宣传又放大了“轻量”的印象,让人误以为小模型等于随便跑。
面试题
Q1. 关于 Mistral 7B,下列说法正确的是?
- A.参数规模达到了千亿级别
- B.小参数性能反超大模型← 正确答案
- C.完全闭源且商用付费
- D.必须依赖超算才能运行
答案:B。Mistral 7B 只有 70 亿参数,却在 MMLU 等多个基准上超过 Llama 2 13B,是“以小博大”的典型;它采用 Apache 2.0 开源可商用,量化后消费级显卡即可运行,A、C、D 都与事实相反。
Q2. 滑动窗口注意力相比全局注意力的核心优势是?
- A.计算量由平方级降为线性级← 正确答案
- B.窗口越大模型一定越聪明
- C.彻底放弃长距离语义关联
- D.不再需要查询与键矩阵
答案:A。SWA 把每个 token 的注意力限制在窗口 W 内,总计算量从 N² 降到 N×W,呈线性增长。它并没有完全丢长程信息——多层堆叠后高层的感受野依然很广,所以 C 错;B 和 D 属于无根据的夸大和误解。
Q3. Mixtral 8x7B 的"8x7B"应如何理解?
- A.总参数量恰好等于五十六B
- B.八个七B模型串联做推理
- C.八个专家网络总参约四十七B← 正确答案
- D.用八张GPU卡并行训练
答案:C。Mixtral 总参数约 46.7B,名称中的“8“指专家数,”7B”是专家模块的规模参考,并非精确乘法。C 最接近正确描述;A 是典型误区,B、D 则是望文生义。
Q4. 在 MoE 中,门控网络(Gating Network)负责?
- A.对最终输出做概率归一化
- B.将所有专家输出直接拼接
- C.控制模型学习率的大小
- D.为每个token挑选对口专家← 正确答案
答案:D。门控网络先给 8 位专家打分,再用 TopK 选 2 位,最后按权重融合输出。它不负责归一化输出,也不拼接所有专家结果,更与学习率无关,D 是唯一准确描述。
Q5. Apache 2.0 协议下的 Mistral 模型,用户可以?
- A.只能做研究不能商用
- B.必须回传所有衍生版本
- C.免费使用修改并且商用← 正确答案
- D.只允许非盈利组织使用
答案:C。Apache 2.0 是宽松许可的优秀代表:使用、修改、商用、再分发都可以,只需保留版权声明。A、B、D 描述的分别是“仅科研”、“强回授”和“非盈利限定”,都不是 Apache 2.0 的特征。
Q6. 把 Mistral 7B 量化到 4bit 后,权重约占多少内存?
- A.大约十四GB
- B.大约九十GB
- C.大约二十八GB
- D.大约三到四GB← 正确答案
答案:D。7×10⁹×4bit÷8÷10⁹≈3.5GB,所以 D 正确。14GB 对应 fp16 原始权重,28GB 对应 8bit 量化,90GB 对应 Mixtral 全量,都不符合题意。
Q7. 关于 LoRA 微调,以下说法正确的有?
- A.只训练低秩分解的小矩阵← 正确答案
- B.原始模型权重完全冻结← 正确答案
- C.推理时把乘积加回原权重← 正确答案
- D.微调后模型结构发生改变
答案:ABC。LoRA 冻结 W,只训练 A、B 两个低秩矩阵,推理时 W′=W+BA,模型的网络结构完全不变,所以前三个正确、D 错误。正因如此,LoRA 才能用极小的显存完成大模型微调。
Q8. 下列哪些属于 Mistral 7B 的优势?
- A.开源协议允许商用部署← 正确答案
- B.单张消费级显卡即可部署← 正确答案
- C.上下文长度完全不受限制
- D.性能超越同级规模模型← 正确答案
答案:ABD。Mistral 7B 拥有 Apache 2.0 许可、量化后单卡可跑、7B 参数反超 13B 模型,A、B、D 都成立。但注意力有窗口和上下文上限,C 明显夸大,不属于真实优势。
Q9. Mixtral 8x7B 推理时,每个 token 实际激活的参数量约为?
- A.五十六亿参数
- B.一百三十亿参数← 正确答案
- C.四百七十亿参数
- D.七十亿参数
答案:B。Mixtral 总参数约 46.7B(接近 470 亿),但门控只激活 Top-2 专家,实际参与计算的只有约 13B 参数。记住“总参约 47B、激活约 13B”这两个数,就能快速估算内存与算力成本。
Q10. Mixtral 8x7B 推理成本低的原因包括?
- A.TopK 路由让每个token只走两位← 正确答案
- B.总参虽大但只激活少量专家← 正确答案
- C.门控把八位专家结果全部融合
- D.滑动窗口压缩了上下文长度
答案:AB。稀疏激活与 TopK 是省算力的核心——未被选中的专家在计算上完全跳过,所以 A、B 正确。C 说“全部融合”违背了稀疏原则,D 与推理成本无直接关系,均不成立。