★ FEATURED ARTICLE 做技术分享这些年被问得最多的一个问题其实特别基础大语言模型到底是什么“大”又到底在哪里多数人能答出“参数多”就算不错了再往下问就开始含糊。我写“大模型技术全景”这个系列本意就是把这些基础词彻底聊透。这一篇集中拆“大”和“架构”如果你正准备入行大模型应用开发、要做技术选型或者单纯想知道市面上的模型为什么有的叫 GPT、有的叫 Mamba建议把这篇读完。后面所有实操项目里遇到的概念基本都从三个词上长出来大语言模型、预训练、Transformer 架构。我先把“大”拆成四个可度量的维度参数、数据、上下文、算力。再把当前主流的三条架构路线放上同一张工作台以 GPT 为代表的密集 Transformer、以 Mixtral 为代表的 MoE 混合专家、以 Mamba 为代表的线性状态空间模型最后结合实际部署和微调会踩的坑聊聊到底怎么选。这篇文章不会跟你绕概念每部分都尽量给出可落地的判断依据。1. 大语言模型的“大”拆成四个可度量维度1.1 参数规模决定知识容量也决定部署上限语言模型里的“参数”指的是神经网络中可以被训练的权重和偏置通俗点说就是神经网络用来记规律的“槽位”。大语言模型的“大”最直观的体现确实就是参数多。2018 年 BERT 有 3.4 亿参数GPT-3 干到 1750 亿到 Llama-3 系列开源了 4050 亿参数的版本几年时间差了三个数量级。但参数多到底意味着什么不是“多出来的参数在背答案”而是参数给了模型足够大的假设空间去表达那些复杂的语言规律。比如预测“苹果”后面该接什么词小模型靠词频统计也能做到但“某句话虽然在讲 A但因为前面有个转折真正影响下一个词的是 B”这种远距离、多层次的语言模式就需要大量参数提供表达空间。想让模型同时在数学、代码、医学文本和自然聊天上都有不错表现参数多了才有地方同时塞下这么多模式。可参数多也有硬成本。模型要跑起来参数必须全部放进显存。1750 亿参数如果用 16 位精度加载光权重就接近 350GB一张 80GB 的 A100 根本放不下。这就是“大”带来的第一个工程分水岭模型大不等于能部署。分布式并行、量化、剪枝本质上都是为了跨过这道门槛而生的。1.2 训练数据规模按“万亿 token”计量才够准第二个“大”是训练数据。很多刚入门的朋友会问训练模型用了多少 GB 数据真到实践层面这个问题基本没法回答因为数据量是按 token 来算的。一个 token 可以是一个词、半个词、一个汉字或一个子词像“language model”在常见分词器下会被拆成几个 token。今天的大语言模型预训练语料动辄按几万亿 token 计算清洗之后的有效数据仍然是个让人头晕的量级。为什么数据要这么大因为大语言模型的核心学习方式是从海量文本的统计相关里重建语言能力。它不是靠语法规则书学会造句的而是看过足够多的真实句子之后自己归纳出“什么词更容易跟着什么词出现”“这段文字是什么文体”这些潜在规律。数据覆盖的领域越全模型在通用任务上的表现就越稳。这也是为什么大模型技术里数据工程成了最不能省成本的一环。数据还要讲究混合配比。不是把全部文本随机倒进训练池就完事而是按比例搭配代码、数学推理、多语言、对话等不同来源。不少团队会保留自己的“数据配方”它起的作用一点不比架构调整小。同样的参数量数据分布偏了某些领域的表现会明显滑坡。这里必须多说一句数据清洗。脏数据会造成幻觉也就是“一本正经地胡说八道”。我做过对比实验单纯堆数据量、不去重模型会在重复人物和重复事件上反复打转后来用语义去重加难度分层幻觉明显减少。数据不是越多越好而是越干净、配比越合理越好。1.3 上下文长度模型一次能“记住”多少内容第三个容易忽略的维度是上下文长度也就是模型在一次交互里能看到多长的输入通常也按 token 数来算。把它理解成“短期工作记忆”最准确模型不会把看过的所有历史永久存进大脑它只能在一个上下文窗口内处理信息超出窗口的内容要么被截断要么完全不参与后续预测。上下文窗口为什么直接关系成本因为 Transformer 在生成每个新 token 的时候要用注意力机制去对比当前 token 和之前所有 token 的相关性同时把历史 token 的 Key/Value 向量缓存下来。这份缓存在工程上叫 KV cache。窗口从 2K 提到 32KKV cache 占用的显存会同步暴涨。所以很多产品把“支持 128K 上下文”当作卖点背后其实是把显存和推理成本一起拉高了并不是白送的午餐。上下文变长还带来一个技术问题位置信息怎么编码。绝对位置编码、旋转位置编码这些名词本质上都在解决“模型如何感知第 20001 个 token 跟第 1 个 token 的相对距离”。窗口一旦拉到百万级位置编码和注意力优化都必须重新设计否则模型只是看到了长文本却“记不住”谁在前谁在后。1.4 算力规模训练和推理是两本账最后一个“大”是算力。训练一个大模型到底需要多少计算量业界流传一个很实用的经验公式训练计算量约等于 6 × 参数量 × 训练 token 数。拿一个 70 亿参数的模型在 2 万亿 token 上训练来算粗略估算就是 6 × 7 × 2 × 10^12 ≈ 8.4 × 10^22 FLOPs。这个公式不是精确结果但足够你在没有论文可查的时候快速判断一个训练项目到底有多“贵”。推理成本就是另一本账了。训练时模型把数据反复看很多遍推理时是面对真实请求实时地逐 token 生成结果。每生成一个 token所有激活参数都要完整跑一遍。这就导致大语言模型部署之后不是“一次买断”而是跑每个请求都在持续消耗算力。所以 API 按 token 计费私有化部署要盯每秒钟能处理多少 token逻辑都在这里。这四个维度互相制约参数大知识容量大数据大学到的规律可靠上下文大应用场景宽算力大前三者才跑得动。任何单一维度的大都不足以构成真正的大语言模型它们组合起来才是完整的“大”。2. 三条主流路线的核心差异Transformer 全量注意力、MoE 稀疏路由、线性状态空间在讲架构之前先澄清一个常见的分类方式。很多人会把大模型按编码器、解码器、编码器-解码器来区分比如 BERT 是编码器GPT 是解码器T5 是编码器-解码器。这确实是架构分类但属于“按任务形态分”。我要聊的三种架构是更贴近底层计算模式的路线划分密集 Transformer、MoE 混合专家、线性状态空间模型。它们都在解决同一个问题如何以可控成本让模型在长文本里建立模式识别和关联能力但走的路径很不一样。2.1 密集 Transformer几乎所有大语言模型的地基Transformer 的核心是注意力机制。其计算过程简单讲就是每个 token 被拆成 Query、Key、Value 三个向量然后用当前 token 的 Query 去和序列里所有历史位置的 Key 算相似度得到一组权重再按权重把对应的 Value 加权求和。这套机制最大的本事是能“远距离关联”——判断“虽然前面写了很长一段但真正影响当前词的是第 3 段第 5 句里的那个词”。为什么说它是“密集”的因为每个 token 都要跟上下文里其他所有 token 做一次注意力计算计算量随序列长度平方增长。序列越长计算越贵KV cache 也越大。这是 Transformer 今天的主要瓶颈但也是它能力强的原因信息不会轻易丢失任何两个位置之间都有直接的交互路径。目前主流的GPT 系列、Llama、Qwen 这些大语言模型基本都是 decoder-only 的密集 Transformer 自回归模型每次预测一个 token然后把新 token 接回输入。为什么这个路线能赢不是因为它没有缺点而是它在超大规模算力下被验证得最充分并行效率高、训练稳定、开源生态最全。说“大语言模型等于 Transformer”虽然不准确但现阶段它是绝对主流这个事实没有争议。2.2 MoE 混合专家总参数变大激活参数保持精简MoEMixture of Experts混合专家解决的是规模焦虑。Transformer 变大最直接但每跑一个 token 都要过全量参数推理成本肉疼。MoE 的思路是把 Transformer 里的前馈网络层改造成多组“专家网络”每组专家负责一部分模式另加一个小路由器。每个 token 进来路由器只挑 top-k 个专家去算其余专家闲着。最常被拿来举例的是 Mixtral 8x7B。它看起来由 8 个 7B 参数的专家组成总参数约 47B但每个 token 只激活其中 2 个专家真正参与计算的参数只有 12.9B 左右。也就是说它的推理成本更接近一个 13B 的密集模型知识容量却接近一个更大尺寸的模型。这也是大模型技术里很诱人的一条路线同样的算力预算装下更多知识。但 MoE 不是免费午餐。首先总参数依然要全部放进显存只是每次计算量少了对显存和并行策略的要求反而更高。其次路由如果长期偏向某几个专家其他专家得不到训练最后模型会退化这个现象叫“路由崩溃”。业界一般用辅助负载均衡损失、专家容量上限这些手段来抑制。所以选 MoE 不能只看参数数量还要看它有没有成熟的负载均衡方案。2.3 线性状态空间模型把“历史”压缩成固定状态第三种架构相对年轻也更容易被低估代表是 Mamba、RWKV以及近年出现的 Transformer 与 Mamba 的混合体。它的思路和 Transformer 完全不同不再保留“过去所有 token”的 KV 向量而是用一个固定维度的状态向量持续“吸收”历史信息。推理时像老式 RNN 一样从上一步的状态和当前输入算出新状态再输出预测。因为它跳过了两两比较计算复杂度从 O(n²) 降到 O(n)长文本优势非常明显。上下文越长它越省钱而且没有随序列长度膨胀的 KV cache。不少主打百万级上下文的模型底层就是这种路线。想象一下用 Transformer 处理百万 tokenKV cache 的显存需求大到难以接受换成线性状态空间模型状态始终是固定大小长文本跑起来轻松得多。它也不是没有缺点。固定状态本身就是在“压缩”历史信息遇到需要精确“指回”某个具体细节的任务比如查一个第 900 页才出现的文献编号它的表现就不如全局注意力那么稳。所以纯 Mamba 模型在超长文本和低显存场景有优势但在复杂推理和精确记忆场景还需要和注意力机制配合。行业里开始流行“混合架构”在关键层保留注意力在中间层用状态空间压缩本质上就是两边都要。三个路线的核心差异可以直接用下面这张表看清楚对比维度密集 TransformerMoE 混合专家线性状态空间模型计算复杂度O(n²)O(n²)但激活参数少O(n)KV cache有随上下文膨胀有随上下文膨胀无或很小代表模型GPT、Llama、QwenMixtral、DeepSeek-MoE、Qwen-MoEMamba、RWKV、混合模型核心优势通用、生态成熟、能力强容量大、单 token 算力成本低超长文本、低显存推理主要难点长文本推理成本高总参数占显存、路由不稳定精确关联弱、工具链不成熟3. 三种架构的部署账单与微调差异显存、时延、路由稳定性架构不只是在论文里做比较的落到部署和调优差距立刻变成账单。3.1 推理阶段的显存和时间你要看的不只是“参数量”部署时最容易犯的错是只看总参数量决定用什么卡。实际上推理成本由三部分组成总参数决定权重占用激活参数决定单 token 计算量KV cache 决定并发和长上下文的额外显存压力。三条架构在这三个维度上表现完全不同。密集 Transformer 是最实在的。每个 token 都要跑完整全量参数batch size 再小权重也必须常驻显存。一张 A100 80GB16 位精度下跑 70B 级别模型已经很吃力通常要量化到 int8 或者做多卡切分。生成速度还受显存带宽约束参数越多每生成一个 token 要搬的数据越多。MoE 要分开看两笔账。单 token 计算量确实低因为只激活部分专家所以生成时延可以比同总参数量模型低但专家总权重仍然要全部放在显存里且专家分布在多张卡上还需要 tensor parallel。你解决显存问题的难度并不会因为它是 MoE 就降低反而可能因为“参数被切成很多块”而更麻烦。Mamba 这类线性状态空间模型最大的亮点就在推理显存。没有不断膨胀的 KV cache长文本场景下显存从一开始就没那么大压力。它的瓶颈更多在生态和优化上很多推理引擎和量化工具优先适配的是 Transformer 和 MoEMamba 想跑出理想性能经常需要自己动一点底层代码。3.2 微调差异LoRA 不是万能药三条路的坑不一样微调阶段三条架构的成熟度和坑的位置也完全不同。密集 Transformer 微调经验最成熟。LoRA、QLoRA 这些参数高效微调技术基本是为它量身定制的效果可控、社区资料多遇到问题很容易搜到解决办法。哪怕只给一个小数据集用 LoRA 也能把风格和领域知识调进去这是目前最稳的一条路。MoE 微调要多加小心。直接套 LoRA 不是不行但如果路由器也跟着更新很容易出现路由崩溃所有 token 都涌向同一小批专家其余专家彻底闲置模型容量瞬间浪费。实践里通常要靠冻结部分专家、加路由辅助损失、调大批次来抑制。另外MoE 对微调数据更敏感不同专家的负载会随着数据分布偏移需要你去盯训练日志里的路由统计。Mamba 这类模型已经能用 LoRA 微调了主流训练框架也在快速补齐支持。但它的状态机制对序列顺序更敏感同样的 LoRA 超参放到 Mamba 上不一定直接好用。我自己的体会是学习率往往要调低一点步数要拉长而且评测时不能只看常规验证集要在长序列上做压力测试否则很容易漏掉它“短文本正常、长文本退化”的问题。3.3 选型前我常用的五个自查问题如果你正在给项目选模型不用急着追新先按下面五个问题过一遍你的场景是不是真的需要超过 32K 的上下文如果只是普通客服问答长上下文是锦上添花不是决定性因素。你允许单卡部署还是可以接受多卡集群单卡优先就老老实实选小规模 dense 模型多卡集群才有余力考虑 MoE。你的请求是低并发长连接还是高并发短交互长文本生成场景Mamba/混合架构的显存优势会放大。你团队的调试能力到什么程度如果出了问题要靠搜索引擎选生态最成熟的 Transformer 系比选新奇架构稳妥得多。你的核心场景是普通对话、RAG 检索增强、代码生成还是长文档总结RAG 场景如果主模型选 MoE 或 Mamba检索返回的上下文格式都要重新调不能照搬 dense 模型的 prompt 习惯。把这五个问题跑完你基本就有方向了通用助手和指令任务密集 Transformer 仍是综合最稳的选项想在相近推理成本里获得更大容量MoE 值得优先试真到了超长文本、低显存、流式写入这类场景SSM 或混合架构才真正体现价值。4. 看到一个新的“大模型”时我会自己问四个问题4.1 宣传里的“千亿参数”到底指总参数还是激活参数这是最容易被误导的地方。MoE 模型对外宣传经常写“总参数 XXB”看起来很大但真正决定每个请求成本的是激活参数。反过来一个 47B 的 MoE 和一个 13B 的密集模型推理成本接近不代表它一定更好用。看到参数数字先追问一句这是总参数还是激活参数有没有做量化实际部署时是需要一张卡还是几张卡答案不同结论可能完全反着来。4.2 数据、架构、算法哪个对最终效果影响最大很多初学者把架构想象成决定一切的因素实际做下来会发现数据清洗和配比对效果的拉动往往比架构本身更明显。架构是容器数据是燃料。同样参数的模型一套高质量清洗、去重、均衡配比的数据比把开源数据集直接倒进去训练出来的模型强出一大截。所以当团队问我要不要为了追求热度换一个架构时我通常建议先检查数据流水线多数时候这里的提升空间更大。4.3 长文本能力是“真长文本”还是“窗口拉长”很多模型把上下文窗口从 8K 拉到 128K 甚至更大但窗口长不代表模型真的会用。窗口扩大只是给了模型“看到更多”的机会注意力要能在这个长度上维持稳定是另一回事。我测试长文本模型有个笨办法把一个关键答案放在第 100K token 的位置然后问模型。如果到后半段就没法召回关键信息说明这个长上下文质量还不过关。别轻信宣传实测最大。4.4 押注哪种架构眼光要放几年从投入产出比来看Transformer 短时间内不会退场它的基础设施和生态优势太大了。MoE 已经在用更省的单 token 计算成本换更大知识容量这几年头部模型里使用率明显上升。Mamba 和混合架构则是长上下文方向的新变量但它要真正流行光有模型还不够还要推理引擎、硬件适配、训练框架全都跟上。选型时不要只看“新不新”要看整条工具链能不能支撑你的交付时间。我举一个自己真实经历过的例子。之前有个长文档关键词抽取项目单文档经常几十万字用 Transformer 模型做每轮推理显存压力都很大。后来换成一个小规模 Mamba 模型显存确实舒服很多可检索结果一多模型就偶尔抓不住文档末尾的那个关键条款。最后我改用“Transformer 做理解和抽取Mamba 做前置长文本切分过滤”的混合流程才同时保住准确率和成本。那次之后我形成了自己的选型习惯先确定自己最缺的资源是显存、时延还是效果再决定架构。缺显存又需要长文本SSM 或混合架构值得试做正式产品追求稳围绕成熟的 Dense 或 MoE 开发现实得多。这篇算是把大语言模型里的“大”和主流架构拆开了。下一篇文章我准备聊训练和微调阶段真正影响效果的小细节包括数据配比、LoRA 参数调整和评测集的坑如果你正在调试自己的模型那篇应该对你有用。
阅读完成 · 觉得有帮助？
