参数量只是容量上限
参数量描述的是模型容量上限，不等于能力。同样的参数量，训练数据质量、后训练策略与推理时投入的算力不同，表现可以差出代际。反过来，推理链更长、采样次数更多的小模型，在窄任务上常能追平更大的模型。读参数之前先分清总参数与激活参数、训练算力与推理算力，否则比较本身就没有意义。
基本信息
| 容易混淆的术语 | 总参数、激活参数、训练算力、推理算力、量化位宽 |
|---|---|
| 稀疏结构 | 部分架构每个 token 只激活部分参数，总参数远超单次激活量 |
| 量化影响 | 低位宽降低显存与延迟，也可能带来精度损失 |
| 容量相关量 | 词表大小、上下文长度、层数与宽度共同决定实际可用范围 |
| 判断口径 | 以同任务同语言的实测通过率与成本为准 |
| 信息核对 | 规格数字以厂商官方文档与模型卡为准 |
典型使用场景
- 部署选型：在显存、延迟与质量之间找到可交付的组合
- 成本估算：区分参数量与每次都跑满全部参数的误解
- 私有化评估：判断某档位权重能否在既有硬件上稳定服务
- 架构理解：看懂稀疏与稠密模型在同参数下的性能差异
- 汇报沟通：向非技术同事解释为什么大不等于好
- 故障排查：区分「模型太小」与「提示词、检索或解析有问题」
误区与更准确的说法
| 常见误区 | 更准确的说法 | 怎么验证 |
|---|---|---|
| 参数越大越聪明 | 同代际内大致相关，跨代际不成立 | 同任务实测通过率对比 |
| 参数越大越慢 | 稀疏架构的激活量、量化与批处理更影响延迟 | 测首字节时间与吞吐 |
| 小模型不能做复杂任务 | 窄任务上常可，开放式多步推理差距更明显 | 按任务类型分别测 |
| 蒸馏就是压缩文件 | 蒸馏是重新训练，能力分布会被重塑 | 测分布外与长尾样本 |
| 开源权重等于可商用 | 许可条款与用途限制需单独核对 | 读模型卡与许可原文 |
| 容量大就能装下长文档 | 标称窗口与有效长度是两件事 | 测各长度下的定位正确率 |
规格记录应写全的字段
规格记录应写全的字段
# 只写「70B」这类数字，事后无法解释任何性能差异
model: 供应商/名称
dense_or_moe: moe # 稀疏结构会改变容量解读
total_params: 只作量级参考
active_params: 单 token 激活量 # 与延迟更相关
quantization: int8 # 量化位宽影响显存与精度
context_window: 标称值
max_output: 输出上限
training_stage: base/instruct/chat
license: 许可与用途限制摘要 # 以许可原文为准
native_lang_share: 中文训练数据占比说明（如公开）能力与规模的关系更接近「容量上限 + 数据与后训练效率」。同样的参数量下，数据配比与后训练方法的改进常常带来比放大参数更明显的收益，这也是同代际内难以用参数排序的原因。
推理时算力是一个被低估的变量：允许模型展开推理、重试或多次采样时，小模型的窄任务表现会明显改善，代价是延迟与单位成本上升。比较模型时必须把这一项显式写进条件。
不要用参数量推算显存与并发，也不要凭参数判断可商用性。显存需求还取决于量化位宽、批处理与 KV 缓存策略，许可限制则取决于模型卡与许可原文，具体以厂商官方文档为准。