大模型参数大致分为三类：模型结构参数决定模型规模和每次推理要动用多少权重，输入输出限制决定一次请求能处理多少 Token，生成参数决定如何从候选 Token 中选择答案。量化精度则是部署方式，不等于模型能力分数。比较模型时，必须连同模型版本、Prompt、推理参数和服务环境一起记录。
这几个概念经常同时出现在模型介绍页，却回答着不同问题。70B 不能直接告诉你模型回答是否准确，128K context 不代表每次都应塞满 128K，temperature: 0 也不能保证所有平台逐字复现。要判断一个模型是否适合业务，应先读懂规格，再用固定测试集验证。具体评分指标可继续阅读大模型评测指标完全指南，评测实验的控制变量见大模型对比评测规则。
一张表看懂常见大模型参数
| 参数 | 它描述什么 | 主要影响 | 常见误解 |
|---|---|---|---|
| 总参数量 | 模型全部权重的数量 | 权重存储、加载和训练资源 | 参数越多就一定越聪明 |
| 激活参数量 | MoE 模型一次前向计算实际使用的部分权重 | 单 Token 计算量与延迟 | 只报总参数就能估算推理成本 |
| 上下文窗口 | 一次推理可容纳的输入与输出 Token 总预算 | 长文、对话历史和 KV Cache | 标称窗口等于有效记忆长度 |
| 最大输出 Token | 单次允许生成的上限 | 回答长度、时间和费用 | 只要上下文有空间就能无限输出 |
| Temperature | 对下一 Token 概率分布进行缩放 | 输出随机性和多样性 | 温度低等于事实更正确 |
| Top-p | 只在累计概率达到阈值的最小候选集合中采样 | 候选范围与长尾词概率 | 与 Temperature 可跨模型照搬 |
| Top-k | 只保留概率最高的 k 个候选 Token | 候选数量 | k 是输出 Token 数量 |
| Seed | 随机采样的种子或提示值 | 在相同实现中的复现机会 | 设置 Seed 就能绝对复现 |
| FP16/BF16/INT8/INT4 | 权重或计算使用的数值格式 | 显存、速度、兼容性与质量 | 位数越低就按同一比例变快 |
这张表适合定位问题，不能替代模型卡。相同名称在不同 API 中可能有不同默认值、边界条件或实现方式；有些托管服务还会忽略未支持的字段。
参数量：B 代表什么
模型名称中的 7B、70B 通常表示约 70 亿、700 亿个可学习参数。参数是训练后保存的权重，不是“知识条数”，也不是上下文里的 Token 数。更大的参数量通常意味着更多权重需要存储和参与计算，但最终能力还取决于训练数据、架构、训练方法、对齐方式和推理配置。
稠密模型与 MoE 不能只看总参数
稠密模型在每个 Token 的前向计算中通常使用大部分模型权重。混合专家模型（Mixture of Experts，MoE）包含多个专家，但路由器可能只为一个 Token 选择少数专家。因此规格页可能同时给出：
- 总参数（total parameters）：模型文件中全部权重；
- 激活参数（active parameters）：生成一个 Token 时实际参与主要计算的权重；
- 专家数量与每 Token 激活专家数：解释激活参数如何产生。
比较部署成本时，应同时记录总参数和激活参数。前者更接近权重存储与加载压力，后者更接近单步计算量，但两者都不能单独推导真实吞吐。专家通信、批处理、内存带宽和推理框架同样会影响结果。
用参数量粗估权重体积
不考虑量化元数据、分组比例和运行时缓存时，可以用下式做非常粗略的下限估算：
权重字节数 ≈ 参数数量 × 每个参数的字节数
例如，理论上 FP16/BF16 每个权重约 2 字节，INT8 约 1 字节，4-bit 约半字节。但实际显存还要容纳量化比例或零点、临时张量、运行时工作区和 KV Cache。不要把“参数量 × 位宽”当成整台服务的显存需求。
上下文窗口：不是模型可以无损记住的字数
上下文窗口一般用 Token 表示，是本次推理可处理序列的容量。它通常包含系统提示词、历史消息、用户输入、工具定义、检索片段以及模型输出。可把预算写成：
输入 Token + 预留输出 Token + 服务端开销 ≤ 上下文上限
Token 不是字符。中文、英文、数字、代码和不同分词器的换算比例都不同，因此“128K Token 等于多少汉字”没有跨模型恒定答案。容量规划应使用目标模型的 tokenizer 或 API 返回的 usage 字段实测。
标称长上下文不等于有效长上下文
一个模型接受长输入，只能说明请求没有因长度被拒绝，并不证明它能在任意位置稳定找回细节。长文场景至少应另外测试：
- 关键信息位于开头、中间和结尾时的检索准确性；
- 多个相似实体或相互冲突证据下的引用能力；
- 输入长度增加后，答案质量、首 Token 延迟和费用的变化；
- 截断发生在客户端、网关还是模型服务端；
- 输出预留是否导致最后一段输入被丢弃。
因此，评测报告不能只写“支持 128K”。还应公布实际输入长度、输出上限、文档位置分布、分词器版本和通过标准。
最大输出和上下文上限不是同一个字段
模型即使拥有较大的上下文窗口，API 仍可能对单次输出设置更小上限。max_tokens、max_output_tokens 或 max_new_tokens 一般控制本次最多生成多少新 Token；字段名称和计数规则以具体接口为准。
设置上限不表示模型一定生成这么多。当遇到停止序列、结束 Token、内容过滤或工具调用时，生成可能提前结束。记录评测数据时，应同时保存请求上限、实际输入 Token、实际输出 Token 和停止原因。
Temperature：改变分布，不是“创造力分数”
模型在每一步都会为下一 Token 产生一组分数，再转换为概率。Temperature 对这个分布进行缩放：较低值通常让高概率候选更集中，较高值通常让候选更分散。
这不代表：
temperature: 0会自动消除事实错误；- 较高温度一定写得更有创意；
- 不同模型的
0.7具有相同随机程度； - 关闭采样后，Temperature 仍一定生效。
Hugging Face 的生成文档把 Temperature 定义为调节下一 Token 概率的参数，并将它放在采样策略中。若使用贪心解码、束搜索，或供应商采用自己的解码逻辑，实际行为可能不同。对事实抽取、分类和结构化输出，较低随机性往往更便于回归；对创意候选，可以增加采样多样性，但仍要用质量规则筛选。
Top-p 与 Top-k：先裁剪候选，再采样
Top-p 又称 nucleus sampling。它按概率从高到低保留“累计概率达到 p 的最小候选集合”，再从集合中采样。假设下一 Token 的候选概率是：
A: 0.55 B: 0.25 C: 0.12 D: 0.08
当 top_p 设为 0.8 时，候选集合可能包含 A 和 B；它不是固定保留 80% 的词表。Top-k 则固定只考虑概率最高的 k 个候选。两者限制候选的角度不同。
Temperature、Top-p 和 Top-k 可以组合，但同时大幅调整会使原因难以解释。做对比实验时建议一次只改变一个变量，并记录供应商默认值。若 API 文档建议只调 Temperature 或 Top-p 其中一个，应遵循接口约束。
Seed：提高复现机会，不是结果指纹
随机种子用于初始化伪随机过程。在模型版本、硬件内核、并发调度、Prompt、采样参数和实现全部相同时，固定 Seed 可能让输出更稳定。但托管 API 可能更新模型快照、路由请求到不同后端，某些 GPU 运算也不保证确定性。
所以，评测复现至少需要保存：
{
"provider": "provider-name",
"model": "exact-model-or-snapshot",
"promptVersion": "eval-v3",
"temperature": 0,
"topP": 1,
"seed": 42,
"maxOutputTokens": 1024,
"startedAt": "2026-08-29T09:20:00.000Z"
}
即便如此，也应比较指标分布而非要求每次逐字相同。对随机性较强的任务重复运行多次，报告均值、离散程度和失败样本，比只展示一次“最好结果”更可信。
量化精度：FP16、BF16、INT8、INT4 分别意味着什么
量化用更低精度的数据表示权重，有些方案还会量化激活或 KV Cache。目标通常是降低存储和显存占用，并在兼容硬件上改善推理效率。Hugging Face Transformers 的量化文档同时支持多种后端和算法；这说明“INT4”只是精度标签，并不足以唯一确定实现。
浮点和整数格式的关注点
- FP32：精度较高、占用较大，常用于训练中的部分状态或基线验证；
- FP16/BF16：常见的半精度格式，都是 16 位，但指数和尾数分配不同；
- INT8/8-bit：可降低权重内存，某些算法会对离群值保留更高精度计算；
- INT4/4-bit：进一步压缩权重，但效果强烈依赖量化方法、校准数据、分组方式与算子支持；
- FP8：8 位浮点格式，需要结合具体硬件和推理引擎判断支持范围。
同为 4-bit，还可能是 GPTQ、AWQ、bitsandbytes NF4/FP4 或其他实现。它们的校准流程、文件格式、硬件支持和质量损失不能互换比较。vLLM 的量化文档也按方法列出硬件兼容性，因此部署前必须核验“算法 × GPU × 推理框架”的组合，而不能只问模型是不是 INT4。
量化不只测显存，还要重新测业务质量
低位宽可能让模型装进更小显存，却不保证端到端服务更快。若当前瓶颈在网络、排队、Tokenizer 或受限算子，压缩权重未必按比例降低延迟。评测量化版本时至少保持以下条件一致：
- 原始模型与精确版本；
- 推理引擎及版本；
- 量化算法、位宽、分组和校准设置；
- GPU 型号、数量和驱动环境；
- 输入与输出长度分布；
- 并发、批大小和缓存策略；
- 业务测试集、评分规则和失败处理。
然后分别报告显存峰值、首 Token 延迟、输出速度、吞吐、错误率和业务质量。怎样把质量、成本与延迟放入同一套回归，可参考用 Node.js 建立业务大模型评测集。
推理参数为什么会污染排行榜比较
假设两个模型使用不同的系统提示词、上下文模板、Temperature、输出上限和工具权限，即使题目相同，结果也不能被简单解释为模型能力差异。代码任务尤其容易受到采样次数影响：一次生成看 pass@1，允许生成多个候选再选答案时则是另一种实验条件。
发布对比时，应把以下字段当成结果的一部分，而不是脚注：
| 类别 | 最少需要公布的信息 |
|---|---|
| 模型 | 供应商、精确模型 ID、快照或访问日期 |
| 输入 | 数据集版本、Prompt、系统消息、Chat Template、Few-shot 数量 |
| 生成 | Temperature、Top-p、Top-k、Seed、最大输出、停止条件 |
| 工具 | 是否联网、代码执行环境、检索库版本、工具调用上限 |
| 部署 | 托管 API 或本地、量化方法、硬件、推理框架 |
| 统计 | 样本数、重复次数、失败与超时如何计分 |
缺少这些信息的榜单可以用于发现候选模型，却不适合作为采购或上线的唯一依据。不同评测站点的规则差异，可继续阅读大模型评测网站怎么看。
业务中怎样设置这些参数
不要从网上复制一组“万能参数”。更稳妥的顺序是：
- 选择业务真实输入，固定一批可复现测试样本；
- 使用供应商默认或明确推荐的生成配置建立基线；
- 固定模型、Prompt 和测试集，一次只改一个参数；
- 同时观察任务通过率、格式合规、事实错误、延迟和 Token 成本；
- 对候选配置重复运行，检查波动和最差案例；
- 保存完整请求配置与模型版本，通过后再进入灰度；
- 供应商模型或默认配置变化时，重新运行回归。
对于本站的 AI 内容场景，模型输出能被解析只是最低要求。事实一致性、关键点覆盖和失败回退需要独立验证，可参考AI 总结质量评估与回归测试。
常见错误
错误一：用参数量直接排能力名次
参数量是结构信息，不是统一考卷成绩。不同架构、训练数据和后训练方法会让同规模模型表现不同；MoE 的总参数与激活参数也不能和稠密模型直接对齐。
错误二：把上下文窗口当作免费数据库
输入越长，Token 成本、预填充延迟和 KV Cache 压力通常越大，模型也可能遗漏中间信息。应先检索和压缩上下文，再用长文测试验证关键证据能否被正确引用。
错误三：认为 Temperature 为零就没有随机性和幻觉
低温只影响解码选择，不能修复训练知识缺失、错误上下文或含糊 Prompt。托管服务的模型版本与底层实现变化也可能改变结果。
错误四：只写“4-bit 模型”
还需说明量化算法、权重与激活格式、校准方式、推理框架和硬件。否则读者无法复现，也无法判断质量差异来自模型还是部署。
错误五：只记录请求参数，不保存服务端结果
响应中的实际 Token 用量、停止原因、模型 ID、错误码和时间戳同样重要。它们能帮助判断输出被截断、配置未生效，还是服务端发生了版本变化。
上线前检查清单
- 区分总参数、激活参数和模型文件体积；
- 用目标 tokenizer 或 usage 统计 Token，不用字数硬换算；
- 同时记录上下文上限、实际输入和最大输出；
- 保存模型精确 ID、Prompt 版本和全部生成参数；
- 不把 Temperature 解释为准确率或创造力分数；
- 对 Seed 只承诺“提高复现机会”，不承诺逐字一致；
- 量化对比写明算法、位宽、框架、硬件与校准条件；
- 质量、延迟、吞吐、显存和成本分别测量；
- 参数或模型版本变化后重新跑固定测试集；
- 未完成真实实验前，不发布速度提升或质量无损百分比。
FAQ
Temperature 和 Top-p 应该同时调整吗？
技术上经常可以同时设置，但调参和评测时一次只改一个变量更容易解释结果。某些 API 也会建议优先调整其中一个。最终以目标供应商文档和业务回归数据为准。
上下文越大，模型就越适合长文吗？
不一定。标称窗口说明可接受的容量，不等于所有位置的细节都能稳定召回。需要在不同长度和证据位置上测试检索、归纳、引用与延迟。
量化一定会降低质量吗？
不能脱离算法和任务下结论。有些配置在特定测试集上差异很小，有些对数字、代码或长尾任务更敏感。应将全精度或较高精度版本作为基线，用同一业务测试集比较。
7B、70B 中的 B 和 Token 有关系吗？
没有直接关系。B 表示十亿级模型参数，Token 是输入输出被分词器切分后的单位。一个描述模型权重规模，一个描述请求序列长度。
总结
参数量、上下文和生成参数分别描述模型结构、请求容量与解码行为，量化则描述部署精度。它们会影响成本、延迟和输出，但没有任何一个字段能单独证明模型更适合你的业务。
可信的做法是把参数变成可复现的实验配置：固定数据集和 Prompt，记录精确模型版本、采样参数、输出限制、量化与硬件条件，再同时衡量质量、速度和成本。这样，规格页上的数字才会转化为可审核的选型依据。