目前 主流的开源模型体系 有哪些
1️⃣ 考察意图
面试官想考察你对开源 LLM 生态的广度认知和选型判断力，而非简单罗列模型名称。刁钻点在于：候选人常只背名字，却不懂架构差异（如 LLaMA 的 RoPE 与 Qwen 的 GQA）、许可证陷阱（如 LLaMA 2 的商用限制）、以及实际部署中的 trade-off（如 MoE 的推理延迟 vs 参数量）。答好了能展示你对模型选型的工程决策能力，包括对任务类型、资源约束、社区生态的权衡，这是 P1 级别（进阶）的核心要求。
2️⃣ 标准答
主流开源模型体系可按架构和生态两条线拆解。以下从实际选型角度，分三个梯队展开：
第一梯队：通用基座模型（Decoder-only）
- LLaMA 系列（Meta）：架构上使用 RoPE（旋转位置编码）和 SwiGLU 激活函数，LLaMA 3 引入 GQA（分组查询注意力）以降低 KV 缓存显存。选型优势：社区生态最强，HuggingFace 上 90% 的微调工具（如 LLaMA-Factory、Axolotl）原生支持。坑：LLaMA 2 许可证限制月活超 7 亿需 Meta 授权，LLaMA 3 改为宽松许可证（但需注意 Meta 的 Acceptable Use Policy）。
- Qwen 系列（阿里）：Qwen2.5 支持 128K 上下文，使用 GQA + 滑动窗口注意力（类似 Mistral）。工程取舍：为多语言优化，词表达 152K tokens，但推理时 embedding 矩阵大，显存占用比同参数量 LLaMA 高约 15%。落地解法：若部署中文场景，优先选 Qwen，因中文 token 压缩率比 LLaMA 高 30%（实测）。
- Mistral 系列：Mistral 7B 使用滑动窗口注意力（窗口 4096），推理时显存占用比 LLaMA 2 7B 低 20%。实际坑：滑动窗口对长文本依赖的 RAG 任务不友好，需配合 chunking 策略（如按窗口大小切分）。
第二梯队：特定场景优化模型
- ChatGLM 系列（智谱）：使用 Prefix LM 架构（类似 T5 的编码器-解码器变体），在对话任务上天然支持双向注意力。选型考量：微调成本低（LoRA 时显存比 LLaMA 少 30%），但推理速度比 Decoder-only 慢（因需编码前缀）。适用：中文对话、摘要生成。
- Falcon（TII）：使用 Multi-Query Attention（MQA），推理时 KV 缓存仅需单头，显存极省。但：MQA 导致模型容量下降，同等参数量下效果比 GQA 差 2-3%（通用知识）。适用：资源受限的推理场景（如边缘设备）。
第三梯队：MoE 与多模态
- Mixtral 8x7B（Mistral）：MoE 架构，每次推理只激活 2 个 expert（约 13B 参数），但总参数量 47B。工程取舍：推理吞吐量高（比同效果 Dense 模型快 3x），但显存占用高（需加载全部 expert 权重）。坑：batch size 小时延迟反而高（因 expert 路由开销），适合高并发场景。
- DeepSeek-V2（DeepSeek）：使用 MLA（Multi-head Latent Attention）和 MoE，推理时 KV 缓存压缩 75%。选型优势：长上下文（128K）下显存效率极高，适合 RAG 场景。
选型总结框架：
- 任务类型：对话/生成 → Decoder-only（LLaMA/Qwen）；摘要/翻译 → Encoder-Decoder（T5/GLM）。
- 资源约束：显存 < 24GB → Mistral 7B 或 Qwen 7B（GQA 省显存）；显存 > 80GB → Mixtral 或 DeepSeek-V2。
- 社区生态：需要大量工具支持 → LLaMA；中文场景 → Qwen/ChatGLM。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从架构、生态、选型三个层面回答。架构上，主流是 Decoder-only（LLaMA/Qwen/Mistral），也有 Prefix LM（ChatGLM）和 MoE（Mixtral）。生态上，LLaMA 社区最强，Qwen 中文最优。选型时，我优先看任务类型（对话 vs 摘要）、资源约束（显存/延迟）和许可证。总结一句：没有最好的模型，只有最合适的 trade-off。”
4️⃣ 高频追问 & 应对
追问 1：你刚才提到 LLaMA 3 用 GQA，能具体说说 GQA 和 MQA 的区别吗？为什么 LLaMA 3 选 GQA？
GQA（分组查询注意力）将 KV 头分组，每组共享一个 KV 头；MQA（多查询注意力）所有查询头共享一个 KV 头。GQA 是 MQA 和全注意力（MHA）的折中：MQA 显存省但效果差（约 2-3% 损失），MHA 效果好但显存高。LLaMA 3 选 GQA 是因为在 8B 模型上，分组数设为 8（共 32 个查询头，4 组），显存比 MHA 省 50%，效果损失 < 1%。实际坑：若用 GQA 微调，需确保框架支持（如 vLLM 0.4.0+ 才原生支持 GQA 的 PagedAttention）。
追问 2：如果我要部署一个 128K 上下文的 RAG 系统，选哪个模型？为什么？
首选 DeepSeek-V2 或 Qwen2.5。DeepSeek-V2 的 MLA 机制将 KV 缓存压缩 75%，128K 上下文下显存仅需约 16GB（以 7B 参数量计）。Qwen2.5 的滑动窗口 + GQA 组合，显存占用约 24GB。不选 LLaMA 3：LLaMA 3 原生只支持 8K 上下文，需用 YaRN 扩展，但长文本下 perplexity 会上升 5-10%。工程取舍：若追求效果，选 Qwen2.5（中文场景）；若追求吞吐量，选 DeepSeek-V2（MLA 省显存，可支持更大 batch size）。
追问 3：MoE 模型（如 Mixtral）在推理时有什么坑？怎么优化？
三个坑：1）显存爆炸：需加载全部 expert 权重（47B），即使只激活 2 个。解法：用 vLLM 的 expert 并行（EP），将 expert 分布到多 GPU。2）延迟抖动：路由到不同 expert 的 token 数不均，导致计算负载不均衡。解法：用 Expert Choice Routing（如 DeepSeek-V2 的负载均衡 loss）或动态 batch。3）小 batch 效率低：batch size < 32 时，路由开销占比高，延迟反超 Dense 模型。解法：对低并发场景，直接用 Dense 模型（如 LLaMA 3 8B）。
5️⃣ 避坑 · 常见错误答法
- ❌ “主流模型有 GPT、BERT、T5、LLaMA……” → ✅ 只提开源模型，且按架构分类（Decoder-only / Encoder-Decoder / MoE），避免混入闭源模型（GPT）。
- ❌ “LLaMA 3 最好，因为它参数多。” → ✅ 强调选型依赖场景：中文场景 Qwen 更好，资源受限 Mistral 更优，长上下文 DeepSeek-V2 更合适。
- ❌ “MoE 模型推理快，所以选它。” → ✅ 指出 MoE 的 trade-off：高并发下吞吐量高，但小 batch 下延迟高，且显存占用大。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从长上下文模型选型切入，对比 Qwen2.5（128K）和 LLaMA 3（8K + YaRN 扩展）在检索召回率上的差异，展示你对上下文窗口和 chunking 策略的工程理解。
- 如果你只做过传统 NLP：用 BERT（Encoder-only）和 GPT（Decoder-only）的架构差异类比，说明为什么开源 LLM 主流是 Decoder-only（自回归生成 vs 双向编码），并迁移到微调成本（LoRA 显存）的对比。
- 如果你是校招无项目：聚焦 LLaMA 3 的 GQA 和 DeepSeek-V2 的 MLA 论文复现，在 GitHub 上跑通推理 demo，并记录显存占用对比（用
nvidia-smi和torch.cuda.memory_summary()），展示动手能力。 - LLaMA 3 技术报告：The Llama 3 Herd of Models
- DeepSeek-V2 论文：DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
- Mistral 7B 论文：Mistral 7B
- Qwen2.5 技术报告：Qwen2.5 Technical Report
- MoE 推理优化：Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM（含 expert 并行）