大语言模型“大”在哪？拆解四大维度与Transformer/MoE/Mamba架构选型

做技术分享这些年，被问得最多的一个问题其实特别基础：大语言模型到底是什么？“大”又到底在哪里？多数人能答出“参数多”就算不错了，再往下问就开始含糊。我写“大模型技术全景”这个系列，本意就是把这些基础词彻底聊透。这一篇集中拆“大”和“架构”，如果你正准备入行大模型应用开发、要做技术选型，或者单纯想知道市面上的模型为什么有的叫 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 提到 32K，KV 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 混合专家：总参数变大，激活参数保持精简

MoE（Mixture 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 处理百万 token，KV cache 的显存需求大到难以接受；换成线性状态空间模型，状态始终是固定大小，长文本跑起来轻松得多。

它也不是没有缺点。固定状态本身就是在“压缩”历史信息，遇到需要精确“指回”某个具体细节的任务，比如查一个第 900 页才出现的文献编号，它的表现就不如全局注意力那么稳。所以纯 Mamba 模型在超长文本和低显存场景有优势，但在复杂推理和精确记忆场景，还需要和注意力机制配合。行业里开始流行“混合架构”，在关键层保留注意力，在中间层用状态空间压缩，本质上就是两边都要。

三个路线的核心差异可以直接用下面这张表看清楚：

3. 三种架构的部署账单与微调差异：显存、时延、路由稳定性

架构不只是在论文里做比较的，落到部署和调优，差距立刻变成账单。

3.1 推理阶段的显存和时间，你要看的不只是“参数量”

部署时最容易犯的错，是只看总参数量决定用什么卡。实际上推理成本由三部分组成：总参数决定权重占用，激活参数决定单 token 计算量，KV cache 决定并发和长上下文的额外显存压力。三条架构在这三个维度上表现完全不同。

密集 Transformer 是最实在的。每个 token 都要跑完整全量参数，batch size 再小，权重也必须常驻显存。一张 A100 80GB，16 位精度下跑 70B 级别模型已经很吃力，通常要量化到 int8 或者做多卡切分。生成速度还受显存带宽约束，参数越多，每生成一个 token 要搬的数据越多。

MoE 要分开看两笔账。单 token 计算量确实低，因为只激活部分专家，所以生成时延可以比同总参数量模型低；但专家总权重仍然要全部放在显存里，且专家分布在多张卡上还需要 tensor parallel。你解决显存问题的难度并不会因为它是 MoE 就降低，反而可能因为“参数被切成很多块”而更麻烦。

Mamba 这类线性状态空间模型，最大的亮点就在推理显存。没有不断膨胀的 KV cache，长文本场景下显存从一开始就没那么大压力。它的瓶颈更多在生态和优化上：很多推理引擎和量化工具，优先适配的是 Transformer 和 MoE，Mamba 想跑出理想性能，经常需要自己动一点底层代码。

3.2 微调差异：LoRA 不是万能药，三条路的坑不一样

微调阶段，三条架构的成熟度和坑的位置也完全不同。

密集 Transformer 微调经验最成熟。LoRA、QLoRA 这些参数高效微调技术基本是为它量身定制的，效果可控、社区资料多，遇到问题很容易搜到解决办法。哪怕只给一个小数据集，用 LoRA 也能把风格和领域知识调进去，这是目前最稳的一条路。

MoE 微调要多加小心。直接套 LoRA 不是不行，但如果路由器也跟着更新，很容易出现路由崩溃：所有 token 都涌向同一小批专家，其余专家彻底闲置，模型容量瞬间浪费。实践里通常要靠冻结部分专家、加路由辅助损失、调大批次来抑制。另外，MoE 对微调数据更敏感，不同专家的负载会随着数据分布偏移，需要你去盯训练日志里的路由统计。

Mamba 这类模型已经能用 LoRA 微调了，主流训练框架也在快速补齐支持。但它的状态机制对序列顺序更敏感，同样的 LoRA 超参，放到 Mamba 上不一定直接好用。我自己的体会是：学习率往往要调低一点，步数要拉长，而且评测时不能只看常规验证集，要在长序列上做压力测试，否则很容易漏掉它“短文本正常、长文本退化”的问题。

3.3 选型前我常用的五个自查问题

如果你正在给项目选模型，不用急着追新，先按下面五个问题过一遍：

1. 你的场景是不是真的需要超过 32K 的上下文？如果只是普通客服问答，长上下文是锦上添花，不是决定性因素。
2. 你允许单卡部署，还是可以接受多卡集群？单卡优先就老老实实选小规模 dense 模型；多卡集群才有余力考虑 MoE。
3. 你的请求是低并发长连接，还是高并发短交互？长文本生成场景，Mamba/混合架构的显存优势会放大。
4. 你团队的调试能力到什么程度？如果出了问题要靠搜索引擎，选生态最成熟的 Transformer 系比选新奇架构稳妥得多。
5. 你的核心场景是普通对话、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 参数调整和评测集的坑，如果你正在调试自己的模型，那篇应该对你有用。