Skip to main content

​
为什么模型名称很重要

浏览 Hugging Face 或 Ollama 的模型库，你会看到类似 Qwen/Qwen3-235B-A22B-Instruct 或 bartowski/Llama-3.3-70B-Instruct-GGUF 的名称。这些不是随机字符串——每个片段都编码了你在下载前需要做出的决策。 名称告诉你：
  • 模型有多大——因此需要多少 VRAM 或系统内存。
  • 它被训练用于什么——通用聊天、编码、推理、视觉或原始文本补全。
  • 它是如何压缩的——以及你在大小和质量之间做了怎样的权衡。
  • 谁制作了它——以及权重是原始的，还是第三方重新打包的。
学习阅读这些约定只需 5 分钟，就能避免下载不适合你 GPU 的 70B 模型，或浪费 VRAM 在无法遵循指令的基础模型上。

​
模型名称的解剖

大多数开放权重模型名称遵循以下模式：
并非每个名称都包含所有片段，发布者使用的分隔符也各不相同——有些使用连字符，有些使用斜杠或什么都不用。但你通常可以识别出这些部分： 逐片段解析的真实示例： Qwen/Qwen3-235B-A22B-Instruct mistralai/Mistral-7B-Instruct-v0.3 TheBloke/Llama-2-7B-Chat-GGUF —— TheBloke（第三方量化者），Llama 2，7B 参数，聊天微调，GGUF 格式。
当组织是像 TheBloke、bartowski 或 unsloth 这样的第三方量化者时，模型本身是由其他人训练的——仓库包含原始权重的重新打包或量化版本。

​
解码大小标签

位于 B 之前的数字是以十亿为单位的参数数量。它是能力和内存需求的最大驱动因素。

​
MoE 模型：两个数字

MoE（混合专家）模型列出总参数和活跃参数，写作 235B-A22B 或 30B-A3B：
  • 第一个数字是总参数数量——你需要存储在内存或磁盘上的量。
  • 第二个数字（A 之后）是活跃参数数量——每个 token 运行多少参数。
一个 235B-A22B 模型需要足够的内存来容纳 235B 参数，但每次只计算 22B，因此它生成 token 的速度比密集的 235B 模型快得多。权衡在于：MoE 模型在磁盘和内存中比相同活跃大小的密集模型更大，但在推理时更快。
一个 235B-A22B MoE 模型在每个 token 的速度上大致相当于密集的 22B 模型，但你仍然需要 VRAM 或系统 RAM 来存储所有 235B 参数。在 Q4_K_M 下，这大约是 120 GB——远多于密集 22B 模型的 13 GB。

​
参数数量如何映射到能力

更多的参数通常意味着更强的能力，但这种关系不是线性的。70B 模型的提升并非 10x（相对于 7B 模型）——它在推理、细微差别和复杂任务方面明显更好，但经过良好微调的 7B 模型仍然可以很好地处理日常聊天和简单的编码任务。合适的大小取决于你的硬件和任务，而不仅仅是“越大越好”的规则。

​
架构后缀

发布者在基础模型之外附加后缀以表示架构变体。这些影响模型能做什么以及需要什么硬件。
一个密集模型在每个 token 上使用所有参数。MoE（混合专家）模型将每个 token 路由到“专家”子网络的子集。MoE 模型的总参数更大，但由于只有活跃参数进行计算，因此每个 token 的速度更快。如果模型名称包含两个大小数字（如 235B-A22B），它就是 MoE。
标记为 -VL 的模型除了文本外还接受图像或视频。示例：Qwen3-VL-32B-Instruct、gemma-4-12b-it。VL 模型需要额外的 VRAM 用于视觉编码器，除了语言模型权重之外。
标记为 -Coder 的模型主要在代码上进行微调或训练。它们在编程任务上通常优于相同大小的通用模型，但在开放式对话方面可能较弱。示例：Qwen3-Coder-480B-A35B-Instruct。
带有 -Math 或推理特定标签的模型在数学问题解决和思维链数据上进行训练。它们比相同大小的通用模型在逐步逻辑方面更强，但范围更窄。
一些发布者将实验性版本标记为 next、preview 或 experimental。这些可能具有不完整的训练或未测试的聊天模板——适用于评估，不适用于生产。

​
训练阶段标签

训练阶段告诉你模型是否能进行对话，还是只能补全文本。这是决定模型是否开箱即用的最重要片段。 Instruct 和 Chat 在大多数情况下可以互换——两者都意味着模型经过微调以响应用户提示。Chat 是较旧的标签（Llama 2 使用它）；Instruct 在较新的系列中更常见。一些发布者如 Mistral 两者都不使用，而是依赖版本标签（v0.3）与基础名称一起使用。
对于本地使用，你几乎总是想要 Instruct 或 Chat。Base 模型无法遵循指令——它只补全文本——如果你像聊天机器人一样提示它，会给出令人困惑的输出。
如果你看到一个没有训练阶段标签且没有 Base 标签的模型，在假设它是指令微调之前，请检查模型卡片。一些发布者发布微调模型而不标记它们，但其他发布者发布基础模型也不标记它们。

​
量化标签（GGUF 世界）

GGUF 量化标签遵循 llama.cpp quantize README 中记录的命名方案。Q 数字大致是每个权重的位数；越高意味着文件越大，质量越高。K-quants 添加混合精度——不同的张量根据敏感性获得不同的位宽——末尾的 S/M/L 标记该级别内的小/中/大变体。 以下是你将遇到的完整范围，带有实用指导：

​
实用甜点

  • Q4_K_M —— 从这里开始。质量好，适合消费级硬件。
  • Q5_K_M —— 当你的 VRAM 有余量时升级。对于大多数任务近无损。
  • Q8_0 —— 最小损失。当质量至关重要且内存可用时使用。
  • Q3_K_M —— 仅在为了容纳在 Q4_K_M 下无法加载的更大模型时才降级到此。预期会有质量损失。

​
大小比较：每个量化的 7B 模型

GGUF 量化的文件大小是权重的真实 VRAM 数字。在此基础上添加 KV 缓存（参见 KV 缓存和上下文）以获得总内存需求。

​
I-quants (imatrix) vs K-quants

你可能还会看到以 IQ 开头的量化名称——如 IQ4_XS 或 IQ3_XXS。这些是imatrix quants，使用重要性矩阵构建：校准数据告诉量化器哪些权重最重要，以便更仔细地保留它们。I-quants 可以在相同的位宽下产生比 K-quants 更好的质量，特别是在非常低的位宽下，代价是量化过程更慢。如果仓库同时提供 Q4_K_M 和 IQ4_M，I-quant 可能略好——但差异通常很小，两者都可以工作。 有关量化如何工作以及为什么 K-quants 优于简单量化的更深入解释，请参见 量化。

​
其他常见后缀

除了量化标签外，模型名称还包括格式和精度标签，告诉你哪个后端可以加载文件。
由 llama.cpp 基于的后端使用的格式——Ollama、LM Studio 和任何 llama.cpp 服务器。GGUF 文件将权重、分词器和聊天模板捆绑到 1 个文件中。大多数消费级硬件运行 GGUF。
一种 GPU 量化格式（通常为 4 位或 8 位），通过 AutoGPTQ 或 vLLM 在 NVIDIA GPU 上运行。在 GPU 上比 GGUF 快，但仅限 NVIDIA 且与 llama.cpp 后端不兼容。
激活感知权重量化——另一种类似于 GPTQ 的 GPU 格式，但使用激活统计数据进行校准。由 vLLM 和其他一些推理引擎支持。NVIDIA GPU。
ExLlamaV2 格式——支持混合比率量化，其中不同的层使用不同的位宽。针对 NVIDIA GPU 和 ExLlamaV2 推理引擎优化。
全 16 位精度。FP16（float16）和 BF16（bfloat16）都是每个参数 2 字节。BF16 具有更宽的指数范围，在训练期间数值更稳定；对于推理，两者行为相似。需要 vLLM 或类似引擎。
8 位浮点数——FP16 的一半大小，质量损失最小。由 vLLM 和 SGLang 等推理引擎在支持 FP8 的 GPU 上使用（NVIDIA Ada Lovelace 及更新版本，AMD MI300）。
NVIDIA 的 4 位浮点格式，在包括 DGX Spark 在内的 Blackwell GPU 上可用。提供激进的尺寸缩减和硬件原生支持——参见 DGX Spark 模型兼容性。

​
发布者量化 vs 第三方量化

多个方通常发布同一模型的量化版本：
  • 发布者量化——Qwen、Mistral、Google 和其他人越来越多地在全精度权重旁边发布自己的 GGUF 文件。这些通常是最安全的选择，因为发布者控制原始权重和聊天模板。
  • Unsloth——提供带有优化聊天模板和动态量化的 GGUF 量化。还提供 1.58 位（unsloth/...-1.58bit）变体，极其小。通常可靠且广泛使用。
  • TheBloke——多产的早期量化者，其仓库帮助定义了 GGUF 分发生态系统。组织良好，但可能落后于最新模型或错过最近发布的聊天模板更新。
  • bartowski——活跃的社区量化者，命名一致，对新发布的覆盖良好。通常在新模型发布时最先发布 GGUF 变体之一。

​
如何验证第三方量化

  1. 检查仓库是否链接回原始模型。
  2. 将文件大小与该量化级别预期的文件大小进行比较（上表是参考）。
  3. 查找聊天模板元数据——缺失或错误的模板会静默降级输出。
  4. 如果发布了量化的困惑度基准，将它们与发布者自己的数字进行比较。

​
快速决策指南

将你的硬件与模型大小和量化级别匹配：

8 GB VRAM

7B Q4_K_M 或 14B Q3_K_M。坚持使用较小模型和舒适的量化——7B 在 Q4_K_M 下优于 14B 在 Q2_K 下。

16 GB VRAM

14B Q5_K_M 或 32B Q4_K_M。14B 在 Q5 下近无损；32B 在 Q4 下牺牲一些质量以换取显著更多的能力。

24 GB VRAM

32B Q5_K_M 或 70B Q4_K_M。32B 在 Q5 下是单 GPU 质量的甜点。70B 在 Q4 下推动能力更高，但填满大部分 VRAM。

48 GB+

70B Q5_K_M 或像 235B-A22B Q4_K_M 这样的 MoE 模型，带有卸载。你有空间容纳最大模型的高质量量化。

128 GB (DGX Spark)

120B+ MoE 模型在 FP8 或 NVFP4。前沿规模模型的全精度或近全精度。参见 DGX Spark 模型兼容性。

仅 CPU

3B Q4_K_M 或 7B Q3_K_M。CPU 推理很慢——保持模型小。预期每秒 1–5 个 token。
这些是起点。你实际的 VRAM 使用还取决于上下文长度（KV 缓存随上下文增长）、批处理大小，以及后端是否将层卸载到系统 RAM。使用 模型适配指南 进行精确尺寸计算。

​
命名红旗

并非每个模型名称都遵循约定，有些模式需要谨慎：
  • 无大小标签——没有参数数量的模型名称可能是任何东西。下载前检查模型卡片。
  • “Uncensored”变体——通常只是移除了安全训练，而不是能力改进。基础模型的质量可能不变或更差，如果移除破坏了对其。
  • 合并模型——组合来自 2 个或更多模型的权重（例如，合并编码模型和聊天模型）。质量变化很大，仅从名称很难预测。查找合并方法（SLERP、DARE、TIES）以及是否发布了评估结果。
  • 极低量化——Q2_K 几乎总是过于损失，除了测试模型是否加载之外。预期推理降级、格式损坏和幻觉。如果模型只提供 Q2 量化，寻找相同参数数量的不同模型。
  • 没有变更日志的版本号——v0.1 到 v0.9，没有清楚描述版本之间更改了什么。除非你有特定原因不使用，否则使用最新的。
  • “AWSD”或类似的炒作标签——一些仓库添加吸引注意力的后缀，不对应任何标准技术。如果你在其他地方找不到该术语，请持怀疑态度。

​
将所有内容放在一起

以 unsloth/Qwen3-30B-A3B-Instruct-GGUF 为例。从左到右阅读：
  1. unsloth —— 由 Unsloth 量化（第三方量化者）。
  2. Qwen3 —— Qwen3 架构，阿里巴巴的当前代数。
  3. 30B-A3B —— MoE 模型：30B 总参数，每个 token 3B 活跃。
  4. Instruct —— 指令微调，准备好聊天。
  5. GGUF —— llama.cpp 格式，在 Ollama、LM Studio 或任何 llama.cpp 后端上运行。
仅从名称你就知道：这是一个运行速度快、在 Q4_K_M 下适合 8 GB VRAM 且能遵循指令的小型 MoE 模型。你不需要打开模型卡片来决定是否尝试它。 现在比较 meta-llama/Llama-3.3-70B-Instruct。那是 Meta 的 Llama 3.3，70B 密集参数，指令微调——没有 GGUF 标签意味着你看到的是需要 vLLM 或类似引擎的全精度权重。名称告诉你它是一个大型、高质量的模型，需要严肃的硬件。

​
下一步：阅读模型卡片

现在你可以解码名称，模型卡片 告诉你名称遗漏的所有内容——上下文长度、许可证、聊天模板和预期用途。

阅读模型卡片

在下载前查找重要的参数、架构、上下文长度和许可证。

量化

量化如何工作以及为什么 K-quants 优于简单量化。

模型适配指南

检查模型和量化组合是否适合你的硬件。