2025年12月19日

LLM 选型避坑指南：从 Total B 到 Active A 的实战经验

从一次选型踩坑说起

去年帮一个做智能客服的朋友选型 LLM 时，我被厂商的参数表搞懵了。Qwen3-235B-A22B、Grok-3-2.7T… 这些数字看着唬人，但到底该看哪个？

折腾了两周我才搞明白：总参数 (Total B) 决定你能不能跑得起，激活参数 (Active A) 决定跑得有多快。这两个指标搞混了，要么预算爆炸，要么性能拉胯。

这篇文章就是把我踩过的坑整理出来，帮你在 MoE、System 2、多模态这些新概念里少走弯路。

先搞懂这两个数字：Total B vs Active A

拿 Qwen3-235B-A22B 来说，这两个数坑了我好几天。

235B (总参数) 就是模型的”体重”。不管用不用，这 2350 亿个参数都得塞进显存。我当时算了一笔账：FP16 精度需要大概 470GB 显存，就算用 FP8 也要 235GB。这意味着至少要 4 张 A100 (80G) 或者 3 张 H800。这就是 Total B 的坑——它只决定了你能不能跑起来，不决定跑得快不快。

A22B (激活参数) 才是真正干活的部分。每次推理只激活 220 亿参数，计算量和延迟跟跑一个 30B 的 Dense 模型差不多。这就是为什么 MoE 能”又大又快”的秘诀——存储上你是 200B+ 的大模型，速度上你是 20B 的小模型。

       [Input]
          |
     [  Router  ]  <-- 核心：路由决定激活哪些专家
          |
    /     |     \
 [Exp 1][Exp 2][Exp 3] ... [Exp N]
 (Active)(Idle) (Active)   (Idle)
    \     |     /
          |
       [Output]


Total B  = 所有专家参数之和 (Exp 1 + ... + Exp N) -> 决定显存占用
Active A = 仅激活专家参数之和 (Exp 1 + Exp 3)     -> 决定推理速度

但这里有个坑我当时没注意到：虽然计算量小，但显存带宽压力一点不小。因为 Router 要不停切换专家网络，显存读取变得很频繁。我测试的时候发现，同样的 235B-A22B 模型，在 A100 和 H800 上的延迟差距比想象中大，就是因为 H800 的显存带宽高很多。

后缀名里的门道

除了这些数字，后缀名也容易让人懵。我实际用过的就三种：

Instruct：万金油版本。拿来直接对话、做 RAG、写文案都行。但别指望它能做复杂的数学题，该错还是错。

Thinking/Reasoning：这是个双刃剑。我之前拿它做代码审查，确实能发现一些深层逻辑问题，但 Token 消耗直接翻了 3-5 倍。而且有个很烦的问题——它会在回答前先”想”一大段，有时候用户等不及就刷新页面了，结果前面的思考过程全浪费了。所以现在我只在离线任务里用它。

FP8/Int4：省钱神器。我用同样的模型对比过 FP16 和 FP8，在大部分业务场景下确实看不出差别。但有一次做中文古诗生成测试，Int4 版本的押韵明显比 FP8 差一截。所以如果是内容生成类的任务，建议先测试一下再决定量化精度。

各家厂商的打法差异

聊完参数怎么看，说说现在主流的几家都在怎么玩。这些是我基于实际 API 调用和本地部署的经验总结的，有些数据官方没公开，只能估算。

Grok：堆参数的”暴力美学”

马斯克这条路子挺极端的——参数往死里堆。

Grok-3 号称 2.7T 总参数，我第一次看到这个数字以为是写错了。什么概念？FP8 量化后需要大概 2.7TB 显存，差不多要 35 张 A100。这根本不是给普通公司玩的，只有 xAI 自己或者超大企业才能跑得起。

但我测试下来发现，它的知识储备确实强。我故意问了一些很冷门的 19 世纪物理学史细节，其他模型都开始胡说，Grok-3 能答对大概七成。代价就是贵得离谱，延迟也高。除非你真的需要处理那种”查资料都要查半天”的专业问题，否则不建议碰。

Grok-2 就务实多了，270B 总参数，激活大概 115B。我用它跑过一些中等复杂度的推理任务，性价比还可以。但说实话，同价位下 Gemini 2.5 Pro 的综合表现更好一点。

Google：多模态和长窗口

Google 的路子跟 xAI 完全相反，不搞暴力堆参数，而是琢磨怎么让模型”看得懂”更多东西。

Gemini 2.5 Pro 我主要用来处理带视频的分析任务。有一次要做一个”自动分析直播录像并生成摘要”的需求，试了 o1 和 Grok，结果它们根本看不懂视频内容。Gemini 2.5 Pro 可以直接丢视频文件进去，虽然处理速度慢一点（一个小时的视频大概要处理 5-8 分钟），但至少能跑出靠谱的结果。

但它的 Thinking 模式有个坑：有时候思考过程太长，会把前面的上下文挤掉，导致回答到一半突然失忆。我遇到过好几次，后来干脆把长文档拆成小块分批处理。

Flash 系列是真的快。Gemini 2.0 Flash 用来做实时语音对话，延迟能控制在 200ms 以内，比 GPT-4o 还快。但代价是复杂逻辑能力明显弱一截，数学题该错还是错。适合做那种”不需要太聪明，但反应要快”的场景，比如简单的客服对话。

OpenAI：换个思路做推理

OpenAI 现在不怎么卷参数规模了，o1 系列就 200B 左右，但走的是另一条路——让模型学会”慢慢想”。

我测 o1 的时候有个印象深刻的例子：一道 LeetCode Hard 的图论题，GPT-4o 直接给了一个错的贪心算法，o1 则会先分析边界条件，然后试几种思路，最后给出正确的动态规划解法。这个过程看着很爽，但 Token 消耗也是真的高——同样的输入，o1 的消耗是 4o 的 4-6 倍。

o1-mini 是我现在的主力写代码模型。参数大概 100B，但代码能力跟 o1 差不多，价格却便宜很多。缺点是文科知识被砍得厉害，问它”鲁迅和周树人的关系”它都可能会懵。

GPT-4o 我现在用得少了，主要是作为 baseline。不知道选什么的时候用它不会出错，但你也别指望它能给你惊喜。

总结：主流厂商核心差异一览表

厂商代表模型核心优势致命短板适用场景
xAIGrok-3知识库极其庞大 (2.7T参数)极其昂贵，延迟高，性价比低冷门学科问答、极端查资料
GoogleGemini 2.5 Pro多模态理解力强，长上下文稳Thinking 模式不稳定，易丢失前文视频分析、超长文档阅读
OpenAIo1 / o1-mini逻辑推理极强，代码能力稳Token 消耗巨大，批量任务贵复杂代码审计、算法题、逻辑推演
QwenQwen3性价比之王，部署门槛低上限不如顶级模型，知识面相对窄实时客服、私有化部署、高并发

不同场景下怎么选

这部分是我踩坑最多的地方。分享几个实际案例：

场景一：复杂逻辑和代码

之前帮一个金融科技公司做智能合约审计工具。刚开始用了 GPT-4o，结果它在处理嵌套条件判断的时候老出错，把一些明显的边界条件漏掉。换成 o1 之后，准确率从 72% 提升到 89%，虽然响应时间从 2 秒变成了 8 秒，但审计这种东西，准比快重要。

但有个教训：不要直接拿 o1 跑批量任务。我试过用它批量处理 1000 份合同，结果账单出来的时候吓了一跳——比 4o 贵了 5 倍。后来改成先用 4o 做初筛，只有复杂合同才进 o1，成本降了 70%，准确率没怎么掉。

避坑提醒：Grok-3 这种纯堆参数的模型，逻辑能力其实不如 o1。我对比过同样的算法题，Grok-3 会给出看起来很长但其实是错的答案，还不如小模型诚实。

场景二：长文档和知识问答

有个做法律咨询的朋友找我，说需要分析几百页的判例文档。我一开始推荐 Grok-3，结果根本跑不动——2.7T 的模型他那边连硬件都凑不齐。

后来换了 Gemini 1.5 Pro，200万 Token 的上下文确实香。我把一整个 300 页的 PDF 丢进去，它能把里面的引用关系理清楚。但有个问题：如果文档里有多处相似的表述，它有时候会混淆。我测试了 20 份文档，大概 3-4 份会出现这种”张冠李戴”的情况。

这个场景下，Total B 确实重要。我用同样的长文档测试 Qwen3-30B 和 Qwen3-235B，大模型在知识召回上明显更稳。但也不是越大越好——Grok-3 虽然参数最大，但幻觉率并不比 Gemini 2.5 Pro 低多少，性价比就很差。

场景三：实时交互

智能客服这种场景，延迟就是生死线。我之前接的一个项目，用户反馈说等超过 3 秒就想关页面。

我们试了一圈，最后用的是 Qwen3-30B-A3B。激活参数只有 3B，在 A10 上单卡能跑到 50 TPS，首字延迟控制在 300ms 以内。虽然回答质量不如大模型，但对于”查物流”、“退换货”这种标准流程，够用了。

这里的关键是：不要一味追求模型能力。我见过有人拿 o1 做客服，结果用户等半天等不来回复，体验反而更差。实时场景就盯着 Active A 看，越小越好。

场景四：私有化部署

数据不出域的需求现在越来越多了。我上周刚帮一个医疗 AI 公司部署本地模型，他们要求所有病历数据不能上云。

硬件限制是 4 张 RTX 4090（24G 显存）。我们试了 Qwen3-72B，Int4 量化后大概需要 36GB，塞不进。最后降到 32B，刚好能跑，但 batch size 只能设到 2，吞吐量很捉急。

有个坑：Int4 量化不是万能的。我们用 32B-Int4 跑医疗实体识别任务，发现对长医学术语的识别率比 FP16 版本低了 8% 左右。最后折中方案是用 14B-FP16，虽然模型小了，但精度反而比 32B-Int4 高。

端侧的话，Llama 3.1 8B 在 iPhone 15 Pro 上能跑到 15 tokens/秒，勉强能用。但别指望它能做复杂任务，问个天气、设个闹钟还行，写代码就算了。

写在最后

选型这事，说到底是 trade-off。没有完美的模型，只有适合场景的模型。

我自己总结的优先级：先确定延迟要求（能不能等），再看显存预算（能不能跑），最后才是能力需求。别一上来就追求”最强”，那个账单你大概率付不起。

这篇文章里的数据都是基于我自己的测试，有些官方没公开的参数是我估的，可能不完全准确。如果你发现有问题，或者有其他选型经验，欢迎留言讨论。

下一步我准备测测 Claude 3.5 Opus 和 Grok-3 在中文逻辑题上的对比，有结果了再更新。