文档
了解本地大模型运行所需的关键概念与技术指标。
参数规模（Parameters）
参数量决定了模型的"大脑容量"，通常以十亿（B）为单位。参数越多，模型能力越强，但需要的 VRAM 越多、速度越慢——这是能力与速度的核心权衡。
| 规模 | 典型大小 | 能力评价 |
|---|---|---|
| 1–3B | 最快 | 极速响应，适合简单任务和低端设备 |
| 7–8B | 好 | 消费级 GPU 首选，通用能力良好 |
| 13–14B | 更好 | 明显优于 7B，推理更准确 |
| 27–34B | 棒 | 接近 GPT-4 早期水平，需要高端 GPU |
| 70B | 极佳 | 旗舰本地模型，需多 GPU 或大显存 |
| 405B+ | 前沿 | 当前最强开源模型，服务器级硬件 |
量化（Quantization）
量化将模型权重从高精度浮点数（FP16）压缩为低位整数，以换取更小的文件体积和更快的推理速度，代价是轻微的质量损失。以 7B 模型为例：
| 格式 | 大小（7B） | 质量保留 | 备注 |
|---|---|---|---|
| F16 | 13 GB | 100% | 原始精度，VRAM 需求最高 |
| Q8_0 | 6.7 GB | 99% | 几乎无损，体积减半 |
| Q6_K | 5.3 GB | 95% | 高质量，轻量化 |
| Q4_K_M ★ | 3.9 GB | 88% | 推荐首选，质量/大小最优平衡 |
| Q2_K | 2.5 GB | 60% | 最小体积，质量损失明显 |
本站所有评分和 VRAM 估算均以 Q4_K_M 为基准，便于横向比较。
VRAM（显存）
模型权重必须完整装入 VRAM 才能实现 GPU 全速推理。如果显存不够，模型无法加载或被迫卸载到系统内存——这会导致速度极慢甚至程序崩溃。
MoE（混合专家模型）
MoE（Mixture of Experts）架构包含多个"专家"子网络和一个路由层。每次推理时，路由层只选择激活其中少数几个专家——这使得模型在拥有庞大总参数量的同时，每次推理只需计算一小部分参数。
top-2
关键点：MoE 需要将全部专家参数载入 VRAM（路由时才决定激活哪几个），因此 VRAM 需求与总参数量挂钩，而非激活参数量。
Dense vs MoE
| 特性 | Dense（密集） | MoE（混合专家） |
|---|---|---|
| 每次激活参数 | 全部 | 少数专家（稀疏） |
| 推理计算量 | 与总参数成正比 | 远低于总参数量 |
| VRAM 需求 | 由激活参数决定 | 由全部参数决定 |
| 生成速度 | 受总参数限制 | 比同 VRAM 的 Dense 更快 |
| 典型代表 | Llama 3, Qwen 2.5 | Mixtral, DeepSeek, Qwen MoE |
上下文长度（Context Length）
上下文长度是模型在单次会话中能"记住"的最大 token 数。128K tokens 大约相当于 100,000 个英文单词——足以装下整本书。但更长的上下文需要更多 VRAM 存储 KV 缓存。
本地运行建议使用 4K–8K 上下文，既满足日常对话需求，又不会大量消耗显存。超长上下文（如 128K）通常只在需要分析完整文档时才有必要。
Tokens per Second（生成速度）
t/s 衡量模型每秒能生成多少 token，1 个 token 约等于 0.75 个英文单词。速度主要由 GPU 内存带宽决定，与 VRAM 容量关系不大。
GGUF 格式
GGUF 是 llama.cpp 推出的标准模型文件格式，已成为 Ollama、LM Studio 等本地推理工具的通用格式。
| 特性 | 说明 |
|---|---|
| 单文件 | 权重、分词器、元数据全部打包，无需额外配置 |
| 多量化支持 | 同一模型提供 Q2_K 到 F16 多个量化版本供选择 |
| 混合推理 | 支持 CPU + GPU 混合推理（层卸载），适应不同显存 |
| 兼容性 | llama.cpp、Ollama、LM Studio、Jan、KoboldCpp 均支持 |
在 HuggingFace 搜索模型时，选择后缀为 .gguf 的文件即可直接使用。
内存带宽（Memory Bandwidth）
LLM 推理是典型的内存带宽密集型任务——每生成一个 token，GPU 几乎需要读取一遍模型权重。因此带宽越高，速度越快，这就是为什么高带宽的 GPU 在本地推理上优势巨大。
估算公式：tok/s ≈ 带宽(GB/s) ÷ 模型VRAM(GB) × 效率系数。效率系数：NVIDIA GPU 约 70%，Apple Silicon 约 65%。