开源模型篇
对比 DeepSeek、Qwen、GLM、Kimi、MiniMax 等开源模型。
闭源模型篇
对比 GPT、Gemini、Claude、Grok、Qwen 和豆包。
模型从哪里找
开放权重模型通常托管在以下平台:- Hugging Face:全球使用最广泛的模型与数据集平台之一。
- ModelScope 魔搭:国内常用的模型、数据集和应用托管平台。
- HF-Mirror:Hugging Face 的第三方镜像入口。
huggingface-cli、modelscope CLI 或支持断点续传的下载工具。使用第三方镜像时,应校验仓库来源、文件大小和哈希,不要直接运行来源不明的模型代码。
常见信息源包括模型官方博客、Hugging Face Model Card、GitHub Release、论文、r/LocalLLaMA 和国内技术社区。社区体验适合发现线索,模型规格仍应回到官方仓库确认。
先认识参数量
模型名称中的B 表示十亿参数:
7B约为 70 亿参数。32B约为 320 亿参数。235B-A22B表示总参数约 2350 亿,每个 Token 推理时激活约 220 亿参数。
Dense 与 MoE
在 2026 年,大型模型普遍使用 MoE,小型和中型模型仍常见 Dense。两者的关键区别是每个 Token 经过前馈网络时使用多少参数。Dense 密集模型
Dense 模型的每一层都会使用该层的全部权重。可以把它理解为由同一支完整团队处理每个请求。 优点:- 权重参与路径稳定,实现和调优相对直接。
- 同等总参数规模下,单 Token 使用的计算容量通常更高。
- 小规模部署时更容易预测延迟和行为。
- 总参数越大,每个 Token 的计算量通常越高。
- 大型 Dense 模型吞吐低,对计算资源要求高。
MoE 混合专家模型
MoE 在部分层中设置多个专家前馈网络,并由路由器为每个 Token 选择少量专家。它像一个拥有多个专科的团队,由分诊系统选择本次参与的成员。 优点:- 总参数可以很大,同时将单 Token 激活参数控制在较低水平。
- 在权重能够被高效读取的前提下,计算量通常低于同等总参数的 Dense 模型。
- 可以用更大总容量容纳知识和技能。
- 所有专家权重通常仍需要存入显存或内存;激活参数少不等于权重占用少。
- 路由、专家并行和跨卡通信增加部署复杂度。
- 激活参数较小时,注意力主干和单 Token 计算容量可能更接近小模型。
“Dense 一定更聪明”或“MoE 一定更快”都不准确。合理比较应同时固定训练质量、激活参数、总参数、硬件、批量和推理框架。
用 Qwen3 对比 Dense 与 MoE
下面使用参数规模接近、结构不同的 Qwen3-32B 和 Qwen3-30B-A3B 作为例子。
MoE 模型的大量总参数位于专家前馈网络中,而 Attention、Embedding 等共享主干更接近激活规模。它可能拥有较大的知识容量和较低计算量,但加载完整权重时仍需要接近 30B 模型的存储空间。
如何阅读 Model Card
模型 ID 常写成组织名/模型名,例如 Qwen/Qwen3-32B。仓库首页的 Model Card 通常提供:
- 模型架构与训练阶段
- 参数量和激活参数量
- 上下文长度
- 支持语言和任务
- 推荐推理框架与最低版本
- 聊天模板和调用示例
- 许可证、限制和评测结果
常见术语
不要只看仓库名称。社区量化、微调和合并模型可能沿用基础模型名字,但许可证、聊天模板和能力已经发生变化。
Embedding 与隐藏维度
文本进入 Transformer 前,会先被分词器转换为 Token ID,再由 Embedding 矩阵映射为向量。基础估算公式为:tie_word_embeddings: false,两套矩阵需要分别计算。
Qwen3 系列使用约 151,936 的词表:
- Qwen3-32B 的
hidden_size=5120,单个矩阵约 7.78 亿参数。 - Qwen3-30B-A3B 的
hidden_size=2048,单个矩阵约 3.11 亿参数。 - 两者都不绑定输入输出权重,因此对应部分需要乘以 2。
层数与前馈网络
num_hidden_layers 表示 Transformer 模块堆叠数量。更多层允许进行更多次表示变换,但模型能力不由层数单独决定。
intermediate_size 通常表示 Dense 模型前馈网络的中间宽度;MoE 模型可能使用 moe_intermediate_size 表示每个专家的前馈宽度。
MHA、MQA 与 GQA
注意力会把隐藏状态投影为 Query、Key 和 Value。多个注意力头可以学习不同的表示子空间,但不能简单等同于明确的“思考角度”。
Qwen3-32B 使用 64 个 Query 头和 8 个 KV 头;Qwen3-30B-A3B 使用 32 个 Query 头和 4 个 KV 头。两者都是 GQA。
KV Cache 为什么重要
自回归生成时,已经处理过的 Key 和 Value 会缓存在显存中,避免每生成一个 Token 都重新计算全部历史。KV Cache 随以下因素增长:- 上下文长度
- 并发请求数
- Transformer 层数
- KV 头数与单头维度
- Cache 数据精度
原生上下文、RoPE 与 YaRN
原生上下文通常表示模型训练或后训练时重点覆盖的长度。超过原生长度后,即使框架允许继续输入,召回和推理质量也可能下降。 RoPE 使用旋转方式把位置信息编码进 Query 和 Key。YaRN 是一种 RoPE 扩展方法,通过调整不同频率的位置编码,使模型能够在超过原生训练长度时继续工作。YaRN 并不是把 128K 文本直接压缩成 32K 文本。更准确地说,它重新缩放位置编码,使模型能够表示更远的位置关系。外推仍可能损失局部精度、检索能力和长距离一致性。
- 开头、中间和结尾的信息召回
- 多个相似事实之间的区分
- 跨文件引用和约束保持
- 输入长度增加后的速度与显存变化
- 有效答案是否随上下文变长而退化
学会阅读仓库文件
模型仓库通常包含以下文件:Dense 配置示例
MoE 配置示例
architectures、model_type 和 transformers_version 很重要。推理框架版本过旧时,可能无法识别模型或使用正确算子。
数据精度
数据精度影响权重大小、计算吞吐和数值误差。需要区分“硬件可以存储”“框架可以模拟执行”和“硬件原生高速计算”。
查看 NVIDIA 官方的 CUDA GPU Compute Capability 可以确认 GPU 架构,但具体模型格式是否可用仍由推理框架和量化内核决定。
常见量化格式
量化通过较低精度保存权重或激活值,减少显存与带宽开销。不同格式不是简单的质量排名,还需要匹配硬件和推理后端。
参考 vLLM Quantization 文档 检查硬件与量化方法的当前兼容矩阵。
显存怎么估算
权重的最低理论占用可以粗略估算为:
实际占用还包括:
- 量化比例、零点和元数据
- KV Cache
- CUDA Context 和计算工作区
- 激活值与临时张量
- 推理框架自身开销
- 多卡通信缓冲区
按硬件选择格式
下面是经验性起点,不是绝对兼容表:GPU 型号不能单独决定最佳格式。相同架构的消费卡和数据中心卡还会受到显存容量、显存带宽、互联方式和驱动版本影响。
推理框架怎么选
部署前确认框架是否支持模型架构、聊天模板、量化格式、Tensor Parallel、Prefix Cache 和目标上下文长度。
一套实际部署流程
1
定义业务负载
明确模型用途、上下文长度、并发、响应时间、结构化输出、工具调用和多模态要求。
2
盘点硬件
记录 GPU 架构、显存容量、显存带宽、GPU 数量、互联方式、系统内存和存储速度。
3
筛选模型与精度
先按能力筛选模型,再根据权重、KV Cache 和运行开销选择 BF16、FP8、AWQ、GGUF 等格式。
4
选择推理框架
根据硬件和并发选择 vLLM、SGLang、TensorRT-LLM、llama.cpp 或 MLX,并核对兼容矩阵。
5
小上下文启动
先用较短上下文和低并发确认模型能正确加载,再逐步增加上下文、批量和并发。
6
运行真实评估
使用业务任务记录准确率、首 Token 延迟、输出速度、显存、吞吐和失败率。
7
再决定采购
用实测数据判断需要一张消费卡、多卡工作站还是数据中心 GPU,不要只按参数量采购。
常见误区
- 激活参数少,所以显存占用也少:MoE 的全部专家权重通常仍需加载。
- 上下文标称 128K,就能准确使用 128K:标称窗口不等于有效召回和推理能力。
- 量化位数越高,效果一定越好:校准方法、层级敏感度和推理内核同样重要。
- 模型文件能加载,就代表硬件原生加速:框架可能进行了反量化、类型转换或兼容执行。
- 层数或注意力头越多,模型一定越聪明:这些参数必须结合隐藏维度、训练和整体架构理解。
- 公开榜单领先,就适合本地业务:部署质量最终取决于真实任务、延迟、成本和稳定性。
config.json、数据精度与量化格式之后,你就能先排除明显不匹配的方案,再通过实际测试选择模型和硬件,而不是依赖一份通用部署教程。