Model Parameters

大语言模型有多个可配置参数，分为模型架构参数（决定模型的容量和计算量）和推理参数（控制输出行为）。理解这些参数的作用和影响，能帮助你选择合适的模型和配置。

模型架构参数

架构参数在训练前确定，一旦训练完成就无法更改。它们共同决定了模型的总参数量和推理速度。

核心参数：

参数	含义	典型值
`hidden_size`（`d_model`）	每个 token 的向量维度	4096（7B）、8192（70B）
`num_hidden_layers`	Transformer 层数	32（7B）、80（70B）
`num_attention_heads`	注意力头数	32（7B）、64（70B）
`intermediate_size`	FFN 中间层维度	11008（7B）、28672（70B）
`vocab_size`	词表大小	32000~152064
`max_position_embeddings`	最大上下文长度	4096~131072
`num_key_value_heads`	KV 头数（GQA 架构）¹⁾	8（7B）、8（70B）

参数量估算：

Transformer Decoder-only 模型的参数量主要由以下部分构成：

# 粗略估算（以 LLaMA 架构为例）
embedding: vocab_size x hidden_size
attention: 4 x hidden_size^2（Q/K/V/O 四个投影矩阵）
FFN: 3 x hidden_size x intermediate_size（gate/up/down 三个门控）
layer_norm: 2 x hidden_size（每层两个 LN）

总参数量 ≈ (embedding + num_layers x (attention + FFN + LN)) x 2（K=V 共享时需调整）

以 LLaMA 7B 为例：hidden_size=4096、num_layers=32、intermediate_size=11008、vocab_size=32000，套入公式约为 6.7B 参数。

这些参数之间的比例关系也很重要——增加层数（num_layers）提升深度推理能力，增加 hidden_size 提升表示能力，两者需要平衡。

总参数量与激活参数量

对于传统的密集模型（Dense Model），所有参数在每次推理时都会参与计算，总参数量 = 激活参数量。

但 MoE（Mixture of Experts，即稀疏混合专家模型）²⁾ 架构不同——它将模型拆分为多个「专家」子网络，每次推理只激活其中一部分。因此 MoE 模型有两个参数量：

总参数量：所有专家的权重之和，决定存储空间
激活参数量：每次推理实际参与计算的参数，决定推理速度和显存需求

模型	架构	总参数量	激活参数量
LLaMA 3 70B	Dense	70B	70B
Mixtral 8x7B³⁾	MoE（8专家，每token激活2个）	47B	13B
DeepSeek R1⁴⁾	MoE（256专家，每token激活8个）	671B	37B
Qwen2.5-MoE⁵⁾	MoE	42B	14B

MoE 的优势在于用接近密集小模型的推理成本，获得接近密集大模型的能力。例如 DeepSeek R1 总参数量 671B 但激活仅 37B，其推理速度与 37B 密集模型相当，但能力接近 671B 级别。

但在选择模型时要注意：总参数量决定存储（硬盘/Ollama pull 的大小），激活参数量决定推理（显存/速度）。

量化等级

量化（Quantization）是将模型权重从高精度浮点数压缩为低精度整数，以减小模型体积、降低显存需求、提高推理速度。量化等级是选择模型时的关键权衡指标。

常见量化精度⁶⁾⁷⁾⁸⁾：

精度	位宽	每参数占空间	占用为FP16的	性能损失（参考MMLU）
FP16 / BF16	16-bit	2 bytes	1x（基准）	0%（基线）
INT8	8-bit	1 byte	50%	<5%，通常 1~2%
INT4	4-bit	0.5 byte	25%	3~8%，取决于量化方法和模型大小
INT2	2-bit	0.25 byte	12.5%	10~20%，仅可用于极限场景

每参数占空间由位宽决定：16-bit = 2B、8-bit = 1B、4-bit = 0.5B、2-bit = 0.25B，这是数学关系而非测量值。

从表格可以看出：INT4 是性价比最高的选择——性能仅下降 3~8%，但显存占用降到 FP16 的四分之一。INT8 性能损失最小（<5%），适合对质量敏感的推理场景；INT4 适合显存有限的部署场景；INT2 仅用于极端边缘设备。

GGUF 量化等级详解：

GGUF（GPT-Generated Unified Format）是 llama.cpp⁹⁾ 生态使用的模型文件格式，将权重、分词器和配置打包为单个文件，支持多种量化精度。Ollama、LM Studio 等工具都依赖 GGUF 格式。其核心特点是 当显存不足时，自动利用系统内存（RAM）和 CPU 进行代偿计算，不会因显存不够而直接失败——模型能跑多快取决于显存能装下多少权重，剩下的部分由 CPU 和内存接力处理。代价是 推理速度大幅下降：GPU 推理可达数十 tokens/秒，CPU 推理通常只有 1~5 tokens/秒，且依赖 CPU 核心数、内存带宽和 AVX 指令集支持。其命名规则反映了精度和量化方法：

GGUF 标识	实际位宽	7B模型体积	占用为FP16的	性能损失	推荐场景
`f16`	16-bit	~14GB	100%	0%（基线）	二次开发、微调
`q8_0`	8-bit	~7.5GB	54%	<2%	追求质量，显存充裕
`q5_K_M`	5-bit	~5.5GB	39%	2~4%	质量与体积的平衡
`q4_K_M`	4-bit	~4.5GB	32%	3~6%¹⁰⁾¹¹⁾	最常用，推荐
`q4_K_S`	4-bit	~3.5GB	25%	5~8%	显存紧张时
`q3_K_M`	3-bit¹²⁾	~3.0GB	21%	6~12%¹³⁾	极端节省显存
`q2_K`	2-bit	~2.5GB	18%	10~20%	仅用于极限测试

其中 K-quant（K_ M/S 等）是 llama.cpp 的改进量化方法¹⁴⁾，比基础 q4_0/q5_0 质量更好。q4_K_M 是绝大多数场景的推荐选择。

从 GGUF 表格可以看出：q4_K_M 在体积（32%）、性能损失（3~6%）和可用性之间取得了最佳平衡，是通用场景的首选。q8_0 在显存充裕时提供接近无损的质量（<2%损失）；q5_K_M 适合需要在质量和体积之间较精确权衡的任务；q3_K_M 则是极限节省显存时的务实选择——以 6~12% 的性能损失换取 7B 模型仅 3GB 的体积。

FP16 需要 16GB 显存，超过多数消费级显卡；q4_K_M 降至 6GB，RTX 3060 12GB 即可运行；q3_K_M 降至 4.5GB，甚至能在 6GB 显卡上运行 13B 模型。

量化等级的选择策略：

质量优先（数学、代码、推理密集型）：q8_0 或 q5_K_M
均衡推荐（通用对话）：q4_K_M
显存受限（4~6GB 显卡）：q4_K_S 或 q3_K_M
极致压缩（边缘设备）：q2_K

一条实用经验：在相同显存下，选量化的小模型不如选低量化的大模型。例如 70B q4_K_M（~40GB）在大多数任务上优于 7B f16（~16GB）¹⁵⁾

推理参数

推理参数在模型生成时设置，不影响模型本身，只控制输出行为。

Temperature（温度）

控制输出随机性的核心参数，取值范围通常为 0~2。

Temperature	效果	适用场景
0	确定性输出，每次相同	数学题、代码生成、事实问答
0.3~0.7	适度随机，平衡创意与准确	一般对话、翻译、摘要
0.8~1.0	高随机性	创意写作、头脑风暴
>1.0	极高随机性	特殊实验场景

Temperature 通过缩放 Softmax 输出的概率分布起作用：温度越低，高概率 token 的概率被放大，低概率 token 被压制；温度越高，概率分布越平滑，低概率 token 也有机会被选到。

Top-p（Nucleus Sampling）

从累积概率达到 p 的最小 token 集合中采样¹⁶⁾。

top_p=0.9：只从概率和达到 90% 的 token 中选
top_p=1.0：考虑所有 token（相当于关闭 top-p）
top_p=0.1：只从概率和达到 10% 的 token 中选，输出很保守

Top-p 比 fixed top-k 更灵活——当概率分布集中时选少量 token，分布平坦时选更多 token。

Top-k

只从概率最高的 k 个 token 中采样¹⁷⁾。

top_k=40：LLaMA 的默认值，效果较好
top_k=1：等同于贪心解码
top_k=100：几乎不限制

Top-k 的问题在于 k 是固定值——如果概率分布很集中（例如只有 3 个合理选项），top_k=40 仍会引入不必要的噪声。因此 top-p 通常优先于 top-k。

Max Tokens

控制单次生成的最大 token 数。注意 token 数不等于字数——中文约 1.5~2 个字符对应 1 个 token，英文约 0.75 个词对应 1 个 token。

场景	建议值
简短问答	512
一般对话	1024~2048
代码生成	2048~4096
长文写作	4096~8192
文档分析	取决于模型上下文窗口

设置过小会被截断，设置过大会浪费计算资源和时间。

Frequency Penalty 与 Presence Penalty

这两个参数控制输出中的重复程度：

Frequency Penalty（频率惩罚）：根据 token 已出现的频次降低其被再次选中的概率。值范围 0~2，越大越不易重复
Presence Penalty（存在惩罚）：只要 token 出现过就降低其概率，与出现次数无关。值范围 0~2

参数	典型值	效果
frequency_penalty=0	不惩罚，允许重复
frequency_penalty=0.5	适度减少重复
presence_penalty=0.6	鼓励引入新概念
presence_penalty=1.0	强制多样性，可能偏离主题

两者结合使用效果更好。例如 frequency_penalty=0.3 + presence_penalty=0.5 在减少重复术语的同时保持话题集中。

Stop Sequences

指定一个或多个字符串作为停止条件，当模型生成到该字符串时立即停止输出。常用于：

停止序列：[“User:”, “Human:”, “\\\\n”] 等
结构化输出：[“```”] 或 [“<|im_end|>”] 等

采样参数的配合

Temperature、Top-p、Top-k 不是独立生效的。通常的配合方式：

高确定性场景（数学、代码）：temperature=0.1, top_p=0.1, top_k=10
平衡场景（通用对话）：temperature=0.7, top_p=0.9, top_k=40
高创意场景（写作、故事）：temperature=0.9, top_p=0.95, top_k=60

参数之间存在覆盖关系——某些实现中 top-k 优先于 top-p 执行，或 temperature 先作用于 logits 后再进行采样。

硬件需求与部署

模型参数、量化等级和上下文长度共同决定了运行模型所需的硬件配置。

参数量与硬件要求

模型大小	半精度显存	GGUF q4_K_M 显存	推荐显卡
1.5B	~3GB	~1GB	任何 4GB+ 显卡
7B	~14GB	~4.5GB	RTX 3060 12GB / 4090
13B	~26GB	~8GB	RTX 3090 / 4090
34B	~68GB	~20GB	A100 40GB / 双卡 3090
70B	~140GB	~40GB	A100 80GB / 双卡 4090
405B	~810GB	~243GB	多卡 A100 / H100

显存需求可以通过量化（GGUF/GPTQ/AWQ）大幅降低，q4_K_M 量化约压缩到半精度大小的 30%。

上下文长度与显存

KV Cache 的显存占用随上下文长度和 batch size 线性增长：

KV Cache ≈ 2 x num_layers x (num_kv_heads x head_dim) x seq_len x batch_size x 2 bytes

以 7B 模型为例，单 batch 下不同上下文长度的 KV Cache 显存占用：

上下文长度	KV Cache 显存
4096	~1GB
8192	~2GB
32768	~8GB
131072	~32GB

长上下文推理时 KV Cache 可能超过模型权重本身的显存占用，这是长上下文推理的主要瓶颈。Flash Attention¹⁸⁾ 和 PagedAttention¹⁹⁾ 等技术通过优化显存管理来缓解这一问题。

实用工具

CanIRun.ai 是一个纯前端的在线硬件检测与模型匹配工具，由 midudev 开发，所有检测在浏览器本地完成，不上传任何数据。

工作原理：

浏览器通过 WebGL、WebGPU、navigator.deviceMemory 等 API 检测硬件信息（GPU 型号、显存、CPU 核心数、内存大小）
根据模型参数量计算 7 个量化等级（Q2_K → F16）下的 VRAM 需求
结合运行状态、预估 tokens/秒、剩余显存给出 S~F 等级评分

支持 68+ 开源模型，涵盖 LLaMA、Qwen、Gemma、DeepSeek、Mistral、Phi 等主流系列，覆盖 Chat、Code、Reasoning、Vision 等类型。每个模型页面提供各量化等级的兼容性表格和 Ollama／LM Studio／llama.cpp 的一键安装命令。

对于不确定自己的显卡能跑什么模型的用户来说，比查硬件对照表更直观。