3. 大模型基础
在部署大模型服务之前，理解模型的内在结构与发展脉络是必要的。Transformer架构自2017年提出后，已成为几乎所有大语言模型（LLM）的基石；而LLaMA、ChatGLM、Qwen等主流开源模型则是在此基础上针对不同场景优化出的代表性成果。本章将拆解Transformer的核心机制，对比三大开源模型家族的技术特点与适用边界，并给出可落地的选型决策路径。
3.1 Transformer架构核心原理与工程视角
核心原理：自注意力与Decoder-only的统治地位
Transformer摒弃了循环神经网络（RNN）的时序递归，完全依赖自注意力机制（Self-Attention）建模序列内任意位置之间的依赖关系。其核心公式为 Attention(Q,K,V) = softmax(QK^T/√d_k)V，其中Q、K、V分别由输入向量与权重矩阵相乘得到。在多头注意力（Multi-Head Attention）中，模型将Q、K、V切分为多个子空间并行计算，使不同头关注不同的语义关系（如语法、指代、主题）。
当前主流大模型几乎全部采用Decoder-only架构，即仅保留Transformer的解码器部分，通过掩码自注意力（Masked Self-Attention）实现从左到右的自回归生成。相比Encoder-Decoder架构（如T5），Decoder-only在预训练任务统一性、上下文学习（In-Context Learning）能力和推理效率上表现更优。工程部署时，Decoder-only模型天然适合流式输出，因为每一步生成仅依赖已生成的。
工程视角的关键组件
- 位置编码（Positional Encoding）：由于自注意力不具备顺序感知，需注入位置信息。现代模型多采用旋转位置编码（RoPE），其外推性更好，对长文本处理更友好。
- 归一化层（LayerNorm/RMSNorm）：稳定深层网络训练。LLaMA与Qwen使用RMSNorm，计算量更小且效果相当。
- 前馈网络（FFN）：通常为两层线性变换加激活函数（如SwiGLU），占据模型约2/3的参数，是推理时的主要计算瓶颈。
- KV Cache：推理时缓存历史的Key和Value矩阵，避免重复计算，是优化推理吞吐的关键手段。
小型场景化说明：为什么Decoder-only更适合服务部署
假设我们需要构建一个代码补全API。若使用Encoder-Decoder模型，每次请求需将整个上下文重新编码，延迟较高；而Decoder-only模型只需将已有代码作为前缀，逐步生成补全内容，且可配合KV Cache实现增量推理，首延迟（TTFT）可降低40%以上。这也是当前主流代码模型（如CodeLLaMA、DeepSeek-Coder）均采用Decoder-only的原因。
3.2 主流开源模型家族对比：LLaMA、ChatGLM、Qwen
模型定位与核心参数
| 维度 | LLaMA（Meta） | ChatGLM（智谱AI） | Qwen（阿里云） |
|---|---|---|---|
| 基础架构 | Decoder-only，RMSNorm，RoPE | Decoder-only（GLM结构），RoPE | Decoder-only，RMSNorm，RoPE |
| 代表性尺寸 | 7B / 13B / 70B | 6B / 32B（ChatGLM3系列） | 1.8B / 7B / 14B / 72B |
| 中文能力 | 原生较弱，需中文微调 | 原生中文优化，双语表现均衡 | 原生中文强，中英混合场景优秀 |
| 词表大小 | 32K（LLaMA2） | 130K（ChatGLM3） | 152K（Qwen2.5） |
| 上下文长度 | 4K-32K（取决于版本） | 8K-128K（ChatGLM3-128K） | 32K-128K（Qwen2.5系列） |
| 开源协议 | LLaMA2社区许可（商用需申请） | MIT协议（ChatGLM3） | Apache 2.0（Qwen2.5） |
判断方法：根据业务场景选择模型
- 英文为主、通用推理任务：优先考虑LLaMA系列，其英文语料质量高，社区生态最丰富（如Alpaca、Vicuna等微调变体）。但需注意，LLaMA原始版本中文能力有限，若业务涉及中文，需额外进行中文指令微调。
- 中文为主、需快速上线：ChatGLM和Qwen是更稳妥的选择。ChatGLM在中文对话、文本生成方面表现自然，且MIT协议对商用友好；Qwen在代码、数学、多语言等综合能力上更均衡，且Apache 2.0协议限制更少。
- 硬件资源受限（单卡≤24GB）：选择7B-14B参数量的模型，并考虑4-bit或8-bit量化。Qwen2.5-7B-Instruct在量化后仍能保持较好的中文效果，是性价比之选。
- 需要超长上下文（如文档分析）：优先Qwen2.5-14B（32K）或ChatGLM3-32B（128K），但需注意长上下文推理时的显存占用和注意力计算开销。
案例拆解：从零搭建中文知识库问答API的选型过程
背景与约束：某金融科技公司需要构建一个内部知识库问答系统，支持员工查询合规政策文档。硬件环境为2张NVIDIA A10（24GB显存），要求单次请求响应时间小于3秒，支持约50并发用户。文档以中文为主，包含大量专业术语。
初始目标与现象：团队最初尝试使用LLaMA2-7B，发现对中文金融术语的理解明显不足，回答经常出现“张冠李戴”的情况。随后测试ChatGLM3-6B，中文理解有所改善，但在处理长文档（超过4K ）时，模型会丢失前文关键信息。
分析判断过程：
- LLaMA2-7B的词表仅32K，中文覆盖率低，导致中文编码效率差，信息压缩损失大。
- ChatGLM3-6B虽然中文好，但上下文窗口为8K，对于平均长度约5K的合规文档，加上问题与历史记录后容易超限。
- Qwen2.5-7B-Instruct支持32K上下文，且词表152K对中文更友好，同时Apache 2.0协议允许商用。
实际操作步骤：
- 下载Qwen2.5-7B-Instruct模型，使用transformers库加载，并启用4-bit量化（bitsandbytes）以降低显存占用。
- 在FastAPI服务中设置max_tokens=2048，temperature=0.3（保证回答稳定性），并启用流式输出以改善用户体验。
- 使用LangChain的RetrievalQA组件，将文档切分为512 的块，通过向量数据库（如Chroma）检索Top-5相关片段，拼接到Prompt中。
- 压测结果：单请求平均延迟1.8秒（含检索），50并发下GPU显存占用约20GB，无OOM。
结果对比与复盘：相比初始LLaMA2方案，Qwen2.5-7B在中文术语准确率上从68%提升至91%，长文档关键信息召回率提升40%。代价是需要额外处理检索逻辑，但整体部署成本未增加。复盘经验：选型不能只看模型参数量，词表大小、上下文长度、中文语料占比是更关键的指标。
3.3 模型选型的综合决策框架与常见误区
决策框架：从需求到模型的映射
| 需求维度 | 关键问题 | 推荐方向 |
|---|---|---|
| 语言支持 | 业务以中文为主还是英文为主？ | 中文为主选Qwen/ChatGLM；英文为主选LLaMA |
| 硬件预算 | 单卡显存多大？是否支持多卡？ | ≤16GB选7B量化；≥40GB可选14B-32B |
| 延迟要求 | 首延迟目标？并发量级？ | 低延迟选小模型+量化；高并发需vLLM |
| 微调需求 | 是否需要领域定制？ | LLaMA生态微调工具最丰富；Qwen支持LoRA |
| 协议合规 | 是否商用？是否需修改模型？ | Apache 2.0（Qwen）最宽松；LLaMA需申请 |
常见误区与总结复盘
- 误区一：模型越大越好。实际上，7B模型在垂直领域微调后可能超过70B基座模型的通用效果，且部署成本降低一个数量级。
- 误区二：忽略词表影响。词表大小直接影响化效率。例如，LLaMA2处理中文时，一个汉字可能被拆分为2-3个，导致有效上下文长度减半。
- 误区三：不评估量化损失。4-bit量化在部分任务上可能造成5%-10%的准确率下降。建议在部署前用业务测试集对比量化前后效果。
- 误区四：忽视生态工具链。LLaMA的社区资源（如llama.cpp、FastChat）最丰富，但Qwen和ChatGLM的官方工具链（如ModelScope）对中文开发者更友好。