本地大模型文件名怎么读：参数量、MoE、量化与 GGUF 全解析

从模型仓库下载本地大模型时，文件名常常长这样：Qwen3-30B-A3B-Instruct-2507-gguf-q2ks-mixed-AutoRound。第一次看到它，很容易当成无意义的技术缩写直接跳过。其实这串字符是一份被压缩进一行的规格表：模型有多大、采用什么架构、每次生成 token 时动用多少参数、权重以多少位存储、打包成什么文件格式，全都写在名字里。读懂它，选本地模型时就不必反复翻文档对比表格。本文按字段从左到右逐个拆解，适合准备在本地跑模型、但被文件名劝退的读者。

准备工作

阅读本文不需要安装任何软件，也不需要下载模型。需要具备的只是对几个基础概念的模糊印象，下面会逐一讲清：

• 参数：模型内部被训练出来的数值，是模型能力的载体。
• 推理：模型根据已有上下文逐个生成 token 的过程。
• 权重存储精度：每个参数用多少位来保存，直接决定模型文件占多大内存或显存。

如果你手上已经有一个看不懂的文件名，可以边读边对照。文中出现的具体模型名、版本号与量化标识仅作示例，实际可用版本、文件体积与硬件要求请以模型发布方和推理软件的当前信息为准。

操作步骤

第一步：看参数量，B 代表十亿

文件名里最先出现的通常是参数量，例如 7B、14B、35B、70B。这里的 B 是 billion，即十亿。所以 7B 表示 70 亿参数，35B 表示 350 亿参数，70B 表示 700 亿参数。

参数量之所以重要，是因为在本地运行时，模型越大，通常需要的内存或显存越多。需要注意的是，一些闭源商用模型的参数量可能达到万亿级别，但这类模型一般不以文件形式分发，文件名里也就不会出现这类数字。

还有一个容易被忽略的前提：参数量大，并不等于每次生成 token 都会动用全部参数。这就引出了下一节的 MoE。

第二步：判断是不是 MoE 架构

本地能下载的模型大致分两类：稠密模型与混合专家模型。

• 稠密模型：每个 token 基本会用到整套参数。一个 35B 的稠密模型，推理时大致动用全部 350 亿参数。
• 混合专家模型（MoE）：内部参数池更大，但被划分成若干「专家」。每次处理一个 token 时，由路由机制决定调用哪些专家。

因此 MoE 模型可以拥有很大的总参数量，却不必一次性全部参与计算。文件名里如果出现形如 A3B 的片段，基本可以判断这是一个 MoE 模型。

第三步：读 A3B，看每 token 激活多少参数

看到 35B-A3B 这样的写法时，两个数字各有分工：

• 35B：总参数量约 350 亿。
• A3B：每个 token 大约激活 30 亿参数。A 指 activated，即激活。

这正是 MoE 能用大总参数量、却不必付出同等计算量的原因。对比一下：

这里最容易踩的坑是把 A3B 理解成「这是一个 3B 模型」。不是。模型本身仍然持有 350 亿参数，只是每次计算时用到的是一小部分。

第四步：区分 Base 与 Instruct

同一个模型经常有两个版本，例如 Qwen3.5-35B-A3B-Base 与 Qwen3.5-35B-A3B-Instruct。差别不在大小，而在预训练之后又做了什么训练。

• Base：原始预训练版本。它从训练数据中学到了语言规律，但没有被专门调教成会听指令的助手。
• Instruct：在预训练之后又经过指令微调，更擅长遵循命令、回答问题、以对话形式完成任务。

换句话说，Base 学的是「预测并生成文本」，Instruct 在此基础上进一步学的是「按指令行事、与用户交互」。两者可以拥有完全相同的架构、参数量和量化等级，行为却差别明显。例如 35B-A3B-Base-Q4 与 35B-A3B-Instruct-Q4 都是同一底层模型的 4 位版本，但做聊天机器人或通用交互时，通常选 Instruct 版本。

要记住的是：Base 与 Instruct 和模型大小、量化等级无关，它描述的是模型被训练成什么行为方式。

第五步：理解 FP16 与 BF16 的存储精度

确定了参数量之后，下一个问题是：每个参数存了多少信息？这里会出现 FP16 和 BF16 两个词。两者都用 16 位保存一个数值，但内部结构不同。

以 350 亿参数的模型为例，若以 16 位存储，仅权重就大约需要 350 亿 × 16 位，约合 70 GB。这个体积对多数消费级机器来说过大，于是人们开始压缩权重，也就是量化。

第六步：读 Q4、Q5、Q6、Q8 这些量化等级

Q4、Q5、Q6、Q8 表示不同的量化等级。量化不再用 16 位保存权重，而是用更少的位。常见对应关系是：

• Q8 → 约 8 位
• Q6 → 约 6 位
• Q5 → 约 5 位
• Q4 → 约 4 位
• Q3 → 约 3 位

数字越小，模型通常越小。差距可以很大：一个 350 亿参数的模型在 16 位精度下约 70 GB，而按每个权重约 4 位计算，同一模型会接近 18 GB。实际体积会有出入，因为真实的量化方案还带有额外元数据，并非每个数值都严格占用标称位数。但原则很简单：更低位宽的量化降低内存需求，代价通常是模型质量有所下降。

第七步：看懂 Q4 后面的 K 和 M

文件名里还会出现 Q4_K_M 这样的写法。Q4 已经知道是 4 位量化的意思，那 K 和 M 是什么？它们标识的是具体的量化方案。

现代量化方法并不一定用同一种方式存储每一个权重，而是通过不同的分组、缩放因子和精度组合，在模型体积与质量之间取得更好的平衡。因此会出现这些名字：

• Q4_K_M
• q2ks（与带下划线的写法是同一回事，只是去掉了下划线）
• Q6_K_s
• Q8_0

不需要记住每种变体的实现细节。对多数使用者来说，有用的信息只有一条：Q4_K_M 是一种常见的 4 位量化方案，设计目标是兼顾体积与质量。比较同一模型的两个版本时，Q4_K_M 与 Q6_K 的差别主要就是量化等级与方案不同。

第八步：GGUF 是文件格式，不是量化等级

最后出现的 GGUF 与前面讨论的内容属于不同维度。它是一个模型文件格式，告诉软件这个模型是如何打包和存储的。

于是下面这个文件名可以逐段读出来：

Qwen3-30B-A3B-Instruct-2507-q2ks-mixed-AutoRound-gguf

• Qwen3 → 哪个模型
• 30B → 总参数量
• A3B → 每个 token 激活多少参数
• Instruct → 经过怎样的调优
• 2507 → 版本或日期标识
• gguf → 容器与文件格式
• q2ks → 量化格式
• mixed → 并非每一层都用同样的位宽
• AutoRound → 量化算法

一个完整示例

把前面所有字段串起来，读一遍这个看起来吓人的文件名：

Qwen3.5-35B-A3B-Q4_K_M-GGUF

从左到右依次是：

1. Qwen3.5：模型系列与版本。
2. 35B：总参数量约 350 亿。
3. A3B：MoE 架构，每个 token 约激活 30 亿参数。
4. Q4_K_M：4 位量化，采用 K 系列中偏中等质量的具体方案。
5. GGUF：以 GGUF 格式打包的文件。

合起来就是一句话：这是 Qwen3.5 系列、总参数约 350 亿、每次只激活约 30 亿参数的混合专家模型，权重被压到 4 位量化的 K_M 方案，并以 GGUF 格式分发。整行文件名本质上就是一份被压缩成一行规格表。

速查表

注意事项

• A3B 不等于 3B 模型。它描述的是每 token 的激活参数量，模型本身仍持有全部总参数。
• Base 与 Instruct 与大小、量化无关。它们描述的是训练方式带来的行为差异，同名同量化的两个版本可能表现完全不同。
• 量化后的实际体积不等于标称位数乘以参数量。真实方案带有额外元数据，并非每个数值都严格占用标称位数。
• 低位宽通常意味着质量损失。降低内存占用的同时，模型质量一般会有所下降，需要在体积与效果之间取舍。
• 不同量化方案之间不可直接按数字比较。Q4_K_M 与 Q6_K 的差别不只是位宽，还包括具体实现方案。
• 文件名中的版本号、日期标识与可用量化组合会随发布变化。具体有哪些文件、需要多少内存或显存，请以模型发布方与推理软件的当前信息为准。