====== 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 架构）(([[https://arxiv.org/abs/2305.13245|GQA: Training Generalized Multi-Query Transformer for Multi-Head Attention]])) | 8（7B）、8（70B） |

**参数量估算：**

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

<code>
# 粗略估算（以 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 共享时需调整）
</code>

以 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，即稀疏混合专家模型）**(([[https://arxiv.org/abs/1701.06538|Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer - Shazeer et al. 2017]])) 架构不同——它将模型拆分为多个「专家」子网络，每次推理只激活其中一部分。因此 MoE 模型有**两个参数量**：

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

^ 模型 ^ 架构 ^ 总参数量 ^ 激活参数量 ^
| LLaMA 3 70B | Dense | 70B | 70B |
| Mixtral 8x7B(([[https://arxiv.org/abs/2401.04088|Mixtral of Experts - Jiang et al. 2024]])) | MoE（8专家，每token激活2个） | 47B | 13B |
| DeepSeek R1(([[https://arxiv.org/abs/2412.19437|DeepSeek-R1]])) | MoE（256专家，每token激活8个） | 671B | 37B |
| Qwen2.5-MoE(([[https://qwenlm.github.io/blog/qwen2.5-moe/|Qwen2.5-MoE Technical Report]])) | MoE | 42B | 14B |

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

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

===== 量化等级 =====

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

**常见量化精度**(([[https://arxiv.org/abs/2306.00978|AWQ: Activation-aware Weight Quantization - Lin et al. 2023]]))(([[https://arxiv.org/abs/2210.17323|GPTQ: Accurate Post-Training Quantization - Frantar et al. 2023]]))(([[https://github.com/ggerganov/llama.cpp/pull/1684|llama.cpp K-quants 实现与评测]]))：

^ 精度 ^ 位宽 ^ 每参数占空间 ^ 占用为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(([[https://github.com/ggml-org/llama.cpp|llama.cpp GitHub]])) 生态使用的模型文件格式，将权重、分词器和配置打包为单个文件，支持多种量化精度。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%(([[https://arxiv.org/abs/2306.00978|AWQ 论文]]))(([[https://arxiv.org/abs/2210.17323|GPTQ 论文]])) | **最常用，推荐** |
| ''q4_K_S'' | 4-bit | ~3.5GB | 25% | 5~8% | 显存紧张时 |
| ''q3_K_M'' | 3-bit((3-bit 并非标准整型位宽，q3_K_M 实际是混合精度：大部分权重用3bit，关键权重用更高精度)) | ~3.0GB | 21% | 6~12%(([[https://github.com/ggml-org/llama.cpp/pull/1684|llama.cpp K-quants 实测]])) | 极端节省显存 |
| ''q2_K'' | 2-bit | ~2.5GB | 18% | 10~20% | 仅用于极限测试 |

其中 K-quant（K_ M/S 等）是 llama.cpp 的改进量化方法(([[https://github.com/ggerganov/llama.cpp/pull/1684|K-quants 实现说明]]))，比基础 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）(([[https://arxiv.org/abs/2306.00978|AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration - Lin et al. 2023]]))

===== 推理参数 =====

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

==== 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 集合中采样(([[https://arxiv.org/abs/1904.09751|The Curious Case of Neural Text Degeneration - Holtzman et al. 2020]]))。

  * ''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 中采样(([[https://arxiv.org/abs/1805.04833|Hierarchical Neural Story Generation - Fan et al. 2018]]))。

  * ''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 线性增长：

<code>
KV Cache ≈ 2 x num_layers x (num_kv_heads x head_dim) x seq_len x batch_size x 2 bytes
</code>

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

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

长上下文推理时 KV Cache 可能超过模型权重本身的显存占用，这是长上下文推理的主要瓶颈。**Flash Attention**(([[https://arxiv.org/abs/2205.14135|Flash Attention: Fast and Memory-Efficient Exact Attention - Dao et al. 2022]])) 和 **PagedAttention**(([[https://arxiv.org/abs/2309.06180|Efficient Memory Management for Large Language Model Serving with PagedAttention - Kwon et al. 2023]])) 等技术通过优化显存管理来缓解这一问题。

==== 实用工具 ====

[[https://www.canirun.ai/|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 的一键安装命令。

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

===== 总结 =====

架构参数决定了模型的能力上限和资源需求，推理参数控制输出的具体行为。选择模型时：

  * 根据硬件和场景选择合适参数量和量化级别
  * 根据任务类型调整 temperature 和采样参数
  * 注意上下文长度对显存的非线性影响
  * 利用 Frequency/Presence Penalty 控制输出质量