讨论大模型的时候，很多人会直接比性能跑分，但容易忽略一个更底层的问题：这些模型的架构就不一样。架构的差异会直接影响模型在不同任务上的表现模式、推理速度和硬件需求。
今天拿三个代表性模型来聊聊这件事：Hermes 4 405B（Dense 架构的典型代表）、Mixtral 8x22B（MoE 架构的标杆）、Command R+（针对 RAG 场景优化的 Dense 模型）。它们在架构设计上的差异，远比表面的跑分差距更值得探讨。
Dense vs MoE：先把概念搞清楚
Dense（稠密）架构是大模型最传统的形式——每一次推理，模型的所有参数都参与计算。Hermes 4 405B 就是这种架构。你有405B个参数，推理时405B个参数全部启动。好处是每个 token 都能享受到全部参数的”算力”，坏处是硬件需求和推理成本都很高。
MoE（混合专家，Mixture of Experts）架构的思路完全不同。Mixtral 8x22B 的总参数量大约是141B，但每次推理只激活其中的大约39B。它内部有8组”专家”（Expert），每个 token 根据内容被路由到最合适的2个专家进行处理。这样总参数量大、知识存储丰富，但实际推理时的计算量比全参数模型小很多。
Command R+ 则是 Cohere 出品的一个104B Dense 模型，特点是在训练阶段就针对 RAG（检索增强生成）场景做了深度优化，包括引用生成、长上下文处理、多文档理解等能力。
三种不同的架构思路，三种不同的取舍。
推理能力的差异
先看硬指标。
| 测试项 | Hermes 4 405B | Mixtral 8x22B | Command R+ |
|---|---|---|---|
| MATH-500 | 96.3% | 约65% | 约58% |
| GPQA Diamond | 70.5% | 约45% | 约42% |
| AIME 2024 | 81.9% | 约15% | 不适用 |
数学和科学推理上，Hermes 4 的405B参数量碾压级优势。这其实也正常——推理能力和参数量有很强的正相关，再加上 Hermes 4 的 Extended Thinking 模式，数学成绩不好才是奇怪的事。
Mixtral 8x22B 虽然总参数量有141B，但因为每次只激活39B，在需要深度推理的场景下，能调动的”脑力”确实不够。MoE 架构的设计初衷就不是为了追求单点推理深度，而是为了在广泛的任务上保持不错的平均水平。
Command R+ 的推理能力中规中矩。它的104B参数在做通用推理时足够用，但和405B相比确实有差距。不过 Command R+ 本来就不是靠推理能力吃饭的，它的核心战场在别处。
知识检索和 RAG 场景
到了 RAG 场景，排名直接翻转。
Command R+ 是三个模型中唯一从训练阶段就把 RAG 当作核心能力来设计的。它的几个独特能力值得一说：
引用粒度：给 Command R+ 喂入一组参考文档后，它生成的回答会精确标注每句话的信息来源是哪个文档的哪个段落。这不是简单的”参考了文档A”，而是段落级甚至句子级的引用标注。
多文档理解：当参考文档之间存在信息冲突时，Command R+ 能识别并指出矛盾之处，而不是默默选择其中一个版本。
长上下文忠诚度：在128K token 的上下文窗口中，Command R+ 对文档内容的遵循度（Grounding）比其他两个模型都要好。Hermes 4 和 Mixtral 在长上下文中容易出现”自由发挥”——明明参考文档里有答案，模型却用自己的训练知识来回答。
实测一个具体场景：给三个模型提供10份产品技术文档（总计约5万字），然后问一些需要跨文档整合信息的问题。Command R+ 的回答准确率约92%，且每个信息点都带精确引用。Hermes 4 准确率约78%，引用不够精确。Mixtral 准确率约75%，偶尔会”编造”文档中不存在的信息。
如果你的核心场景是企业知识库问答、文档分析、合规信息检索，Command R+ 是三者中最专业的选择。
推理速度和吞吐量
这是 MoE 架构的主场。
同等硬件条件下（8卡 A100 80GB），三个模型的推理表现：
| 指标 | Hermes 4 405B | Mixtral 8x22B | Command R+ |
|---|---|---|---|
| 首 Token 延迟 | ~2.5s | ~0.8s | ~1.5s |
| 生成速度 | ~15 token/s | ~45 token/s | ~25 token/s |
| 并发能力 | 2-3路 | 8-10路 | 4-5路 |
Mixtral 8x22B 的推理速度是 Hermes 4 的3倍。这就是 MoE 架构的核心优势——总参数多但激活参数少，推理时的实际计算量小，速度自然快。
对于需要高并发的线上服务来说，这个差距的商业影响巨大。同样的硬件投入，Mixtral 能服务的用户数量是 Hermes 4 的3-4倍。如果按每个请求的成本来算，MoE 架构的经济性优势非常明显。
当然，速度快不代表单次回答的质量更高。推理速度和推理质量之间的权衡，需要根据具体业务场景来判断。客服场景对延迟敏感、对深度推理需求不高，选 Mixtral 更合适。数学竞赛辅导场景对回答质量要求极高、延迟容忍度也高，选 Hermes 4 更明智。
硬件需求和部署成本
这个维度直接决定了”玩不玩得起”。
Hermes 4 405B：
- FP16 显存需求：约 810GB
- INT4 量化后：约 200GB
- 最低配置：4x A100 80GB（量化后）
- 推荐配置：8x A100 80GB 或 4x H100
Mixtral 8x22B：
- FP16 显存需求：约 282GB
- INT4 量化后：约 80GB
- 最低配置：2x A100 80GB（量化后甚至单卡可跑）
- 推荐配置：4x A100 80GB
Command R+：
- FP16 显存需求：约 208GB
- INT4 量化后：约 60GB
- 最低配置：2x A100 80GB
- 推荐配置：4x A100 80GB
部署成本上，Hermes 4 是其他两个的2-3倍。如果预算有限，Mixtral 和 Command R+ 的硬件门槛友好得多。
另外有一个实践中的坑：MoE 模型对通信带宽的要求比 Dense 模型高。多卡部署 Mixtral 时，如果卡间通信带宽不够（比如用 PCIe 而不是 NVLink），推理速度会大打折扣。这在部署规划时需要特别注意。
微调和定制化
Hermes 4 本身就是一个微调产物，Nous Research 已经证明了在 405B 基座上做全参数微调 的可行性。如果你有足够的算力资源，在 Hermes 4 基础上做进一步的领域适配是完全可以的。
Mixtral 8x22B 的微调相对复杂一些。MoE 架构的微调需要考虑专家路由的平衡问题——如果微调数据的分布和预训练数据差异太大，可能导致某些专家被过度激活而其他专家闲置。社区里已经有一些针对 MoE 微调的最佳实践，但踩坑的空间比 Dense 模型大。
Command R+ 支持微调但 Cohere 对微调的开放度不如前两者。如果你想深度定制 Command R+，可选的方案和工具不如 Hermes 和 Mixtral 丰富。
谁选谁：场景匹配指南
说了这么多，实操层面的选择建议：
算力充足 + 追求极致质量 → Hermes 4 405B
你的服务器有8卡 A100 或更好的配置，核心需求是数学推理、复杂逻辑分析、或者需要 Agent 系统 的深度工具调用。不太在意推理速度，更看重单次输出的质量。
高并发 + 控制成本 → Mixtral 8x22B
线上服务场景，需要同时处理大量请求，对延迟比较敏感。任务以通用对话、内容生成、简单分析为主，不需要特别深度的推理。硬件预算有限但希望服务更多用户。
RAG 和知识库场景 → Command R+
核心业务是文档问答、知识检索、合规信息查询。需要模型精确引用参考文档内容，不能”自由发挥”。对多文档理解和长上下文处理有较高要求。
架构选择没有绝对的对错。Dense 架构适合”少而精”的深度任务，MoE 架构适合”广而快”的高并发场景，RAG 优化的模型则在特定领域有不可替代的优势。搞清楚自己的核心需求，再做选择，这比追着跑分排行榜选模型靠谱得多。
cocoloop 社区里有一些成员分享过不同架构模型在实际项目中的部署经验和踩坑记录，如果你在做技术选型，这些一手经验可能比基准测试数据更有参考价值。