方法论：每个数字是怎么算出来的

本站的显存需求、速度估算、判定结论都不是拍脑袋给的，也不是跑出来的实测，而是一组固定公式的计算结果。这页公开全部公式、参数来源与假设。你在任何页面看到的数字，都可以按这里的方法手动复算——如果发现页面上某个结果与公式对不上，那是 bug，请告诉我们。公式实现见仓库中的 src/lib/vram.ts 与 src/lib/speed.ts，页面展示的数值与代码严格一致。

显存需求：三部分相加

总显存需求 = 权重 + KV 缓存 + 固定开销。所有计算使用 GB（10⁹ 字节）口径，不是 GiB。

1. 权重显存

权重 GB = 参数量(B) × bpw ÷ 8，其中 bpw 是每权重比特数（bits per weight）。MoE 模型按总参数量计算——所有专家都要加载进显存，即使每个 token 只激活其中一部分。bpw 不用 llama.cpp 的理论比特率，而是用实测 GGUF 文件大小反推：例如 Q4_K_M 理论值 4.83，我们按 Llama 3.1 8B 各档位 GGUF 的实际字节数校准为 4.9（含 embedding 与元数据开销，小模型偏离理论值更多，大模型更接近）。

2. KV 缓存

标准 GQA 架构（绝大多数模型）：

KV 缓存 GB = 2 × 层数 × KV头数 × headDim × 每元素字节数 × 上下文长度 ÷ 10⁹

系数 2 是 K 和 V 两份；每元素字节数默认 2（fp16 KV），选择 q8 KV 量化时为 1。DeepSeek 的 MLA 架构走另一条分支：层数 × (kvLoraRank + qkRopeHeadDim) × 字节数 × 上下文长度，因为 MLA 缓存的是压缩潜向量而非完整 K/V。KV 缓存随上下文长度线性增长——8K 和 128K 上下文下的显存需求可以差出一个数量级，这就是为什么本站所有组合页都标注上下文长度。

3. 固定开销

固定加 1.5 GB，覆盖 CUDA context、运行时、框架缓冲区等。这是一个估算系数（配置项），不是实测值。它对所有模型与显卡一视同仁：对 3B 小模型它占比偏高，对 70B 大模型则几乎可忽略——我们宁可统一取一个偏保守的常数，也不按模型规模引入更多估算参数。

手算示例：Llama 3.1 8B @ Q4_K_M / 8K 上下文

架构常数（来自 HF config.json）：8.03B 参数，32 层，8 个 KV 头，headDim 128。

权重 = 8.03 × 4.9 ÷ 8 ≈ 4.9 GB
KV 缓存 = 2 × 32 × 8 × 128 × 2 × 8192 ÷ 10⁹ ≈ 1.1 GB
固定开销 = 1.5 GB
合计 ≈ 7.5 GB

所以一张 8GB 卡跑 8B Q4_K_M / 8K 属于"勉强能跑"（见下面的阈值），12GB 卡则很宽裕。把上下文拉到 128K，KV 缓存变成约 17 GB，结论完全不同。

判定阈值：能不能跑的四档结论

先定义"可用显存"：独显直接取标称显存（12GB 卡即 12GB 可用）；Apple 统一内存按标称 × 0.75 折算（macOS 默认只允许 GPU 使用约 75% 内存）。多卡可用显存为各卡直接求和，不打折。然后比较总需求与可用显存：

✅ 宽裕（comfortable）：需求 ≤ 可用 × 80%。留有余量，可以开更长上下文或并行其他任务。
⚠️ 勉强（tight）：需求 ≤ 可用 × 100%。能跑，但余量很小，上下文加长或系统占用波动可能 OOM。
🔀 需多卡（needs-multi）：可用 × 100% < 需求 ≤ 可用 × 120%。单卡放不下，但差距不大，两张卡通常能解决。
❌ 不可行（infeasible）：需求 > 可用 × 120%。单卡无望，需要多卡、更高量化档或更短的上下文。

推荐量化档的逻辑：按精度从高到低（Q8_0 → Q2_K）找第一个能装下（comfortable 或 tight）的档位。tight 的 Q4 优于 comfortable 的 Q2——量化带来的质量损失比显存余量更影响实际体验。

速度估算：带宽除以每 token 字节数

解码阶段每生成一个 token 都要把相关权重完整读一遍，因此推理速度基本由显存带宽决定：

tok/s ≈ 显存带宽(GB/s) × 0.75 ÷ 每 token 读取字节数(GB)

每 token 读取字节数：稠密模型按全部权重（参数量 × bpw ÷ 8）；MoE 模型只按激活参数部分——这是 MoE 推理快的根本原因。0.75 是效率系数【估】，覆盖带宽利用率损失。两个修正：同型号多卡的等效带宽为 Σ带宽 × 0.85（卡间通信开销）；部分卸载到 CPU 时等效带宽取 min（显存带宽，系统内存带宽），系统内存按 80 GB/s 口径——速度会出现断崖式下降。

所有速度数字都是理论估算，误差 ±30%。实际速度受框架（llama.cpp / vLLM / Ollama）、驱动版本、批大小、CPU 与散热影响。这个数字用于比较"哪张卡更快"是可靠的，用于承诺"你能跑到 X tok/s"则不是。

价格口径

MSRP 为各厂商官方发售价。二手价只维护发布 ≥2 年的卡，采样自 eBay 已售/挂牌口径的第三方追踪快照（buysellram、gpupoet、gpudojo 等美国市场来源），是带日期的估算快照而非实时行情，采样区间记录在各卡的 _note 字段中。为 0 表示该卡只显示 MSRP。价格数据每月更新一次。

数据来源与核实节奏

模型架构参数（层数、KV 头数、headDim、上下文窗口）取自 Hugging Face 各仓库 config.json 原文，抓取存档于 research/hf-configs/。上下文窗口取官方标称的原生长度，不用 YaRN 外推值。
量化 bpw：实测 GGUF 文件字节数（HF 的 x-linked-size 响应头）反推，校准文件与日期记录在 quant-presets.json 的 _meta 字段。
显卡规格（显存、带宽）：NVIDIA / AMD / Apple 官方规格页，TechPowerUp 交叉核实。

全部数据集在每月第一个周末重新核实，核实日期见页脚与 site-config.json 的 verifiedAt，每次变更记录在数据更新日志。

局限性

都是理论值，不含实测。我们没有在每张卡上跑每个模型。显存公式与实测高度吻合（权重与 KV 都是确定性的），但不同运行时会有 ±5-10% 的出入；速度则是 ±30% 量级的估算。
滑窗与混合架构的 KV 会保守高估。对滑动窗口注意力（如 Mistral）或层间混合架构的模型，我们按全量上下文计算 KV 缓存，结果偏保守——实际需求会更低。
不含并发与批处理。所有数字按单请求、batch=1 的交互式使用场景计算。
不构成购买建议。详见免责声明。发现与实测明显不符的数字，欢迎到联系页面反馈。