直接答案：跑本地大模型不能只看“参数量对应哪张显卡”。先确定模型文件格式与量化、实际上下文、并发数和速度目标，再预算权重、KV cache、运行时工作区和系统余量。粗略的权重下限是“参数量 × 每权重位数 ÷ 8”，但真实文件和显存通常更大；上下文越长、并发越高，KV cache 占用也越高。最可靠的选型方法，是先下载目标模型的实际文件，在现有机器上跑固定任务并记录加载、首 token、生成速度、峰值显存和输出质量。
先问五个问题，再谈配置
- 做什么任务：短对话、长文档、代码补全、图片理解还是批量 API？不同任务的上下文和吞吐差异很大。
- 模型是什么：稠密模型还是 MoE，参数总量、激活参数、层数、隐藏维度和注意力结构分别是什么。
- 使用哪种文件与后端：GGUF/llama.cpp、Transformers + bitsandbytes、vLLM 或 Ollama 的支持矩阵不同。
- 需要多长上下文和多少并发：单人 4K 对话与 64K、四路并发不是同一内存预算。
- 什么速度算可用：能加载、能回复和交互顺畅是三个不同标准；还要区分提示处理速度与逐 token 生成速度。
若还不熟悉显存、内存和带宽，可先看站内的GPU 并行计算基础与模型量化与精度边界。本文不推荐具体显卡价格，因为库存、地区、驱动和二手风险变化很快。
权重占用怎样做第一轮估算
只计算模型权重时，可以先用：
理论权重字节 ≈ 参数数量 × 每个权重的位数 ÷ 8例如 7B 参数在理想 4-bit 下约为 3.5GB，14B 约 7GB，32B 约 16GB，70B 约 35GB。这只是数学下限，不是购买承诺。实际量化格式可能为缩放因子、元数据、部分高精度张量、词表、输出层或对齐增加空间。llama.cpp 官方量化说明给出的具体 GGUF 文件也会高于简单的 4-bit 下限。
| 模型参数量 | FP16/BF16 理论权重 | 8-bit 理论权重 | 4-bit 理论下限 | 使用时要加什么 |
|---|---|---|---|---|
| 1B | 约 2GB | 约 1GB | 约 0.5GB | 格式开销、KV cache、工作区与系统余量 |
| 7B | 约 14GB | 约 7GB | 约 3.5GB | 同上；实际 GGUF/量化检查点通常更大 |
| 14B | 约 28GB | 约 14GB | 约 7GB | 同上；长上下文可能明显增加缓存 |
| 32B | 约 64GB | 约 32GB | 约 16GB | 同上；CPU/GPU 混合还需足够内存 |
| 70B | 约 140GB | 约 70GB | 约 35GB | 同上；多卡划分与通信会影响速度 |
MoE 模型要同时看总参数和每 token 激活参数：权重存储通常更接近总参数需求，而单步计算量与激活专家有关，不能看到“只激活 3B”就按 3B 模型准备磁盘和内存。
从文件大小到运行内存，中间还差四层
模型文件大小是最容易拿到的数字，却只解决“权重从磁盘读入后占多少”的一部分问题。不同后端可能使用内存映射、把部分层留在系统内存、把部分张量复制到 GPU，或者为 CUDA graph、算子临时缓冲和多模态编码器继续分配空间。配置单必须把磁盘、系统内存和显存分开写，不能用一个数字互相替代。
| 预算层 | 主要由什么决定 | 如何取得真实值 | 常见漏项 |
|---|---|---|---|
| 磁盘 | 模型分片、tokenizer、量化文件、视觉投影与缓存副本 | 核对实际下载清单和文件哈希 | 同时保留多个量化、转换临时文件 |
| 权重内存 | 参数量、格式、offload 比例与内存映射方式 | 加载后读取进程 RSS 与设备分配 | 把 4-bit 理论下限当实际占用 |
| KV cache | 层数、KV 头、头维、上下文、并发与 cache dtype | 按后端日志和逐级上下文压测记录 | 只按单用户、短提示估算 |
| 运行工作区 | 后端内核、batch、图捕获、采样和多模态组件 | 记录完整请求期间峰值而非加载后静态值 | 视觉编码器、并发峰值与临时张量 |
| 安全余量 | 桌面显示、其他服务、碎片和异常请求 | 在峰值之上保留可观察余量 | 用“刚好启动一次”作为稳定标准 |
把容量预算写成一张可复核的工作表
配置讨论最容易出错的地方，是把不同口径的数字相加：模型仓库标注的是磁盘文件大小，后端日志可能只显示已卸载到 GPU 的权重，系统监控又可能包含桌面和其他进程。可复核预算应在同一轮请求中分别记录“加载前基线、加载后静态值、最长提示预填充峰值、生成峰值和并发峰值”，并注明是设备已用、进程已分配还是后端预留。
设备容量需求 = 权重设备占用 + KV cache 峰值 + 运行工作区峰值 + 其他常驻占用 + 安全余量这条式子不是让人凭经验填百分比，而是提供缺项检查。权重可用文件与后端加载日志做预估；KV cache 应按目标上下文、并发和缓存 dtype 实测；运行工作区要覆盖 prefill 与 decode；安全余量则用于吸收碎片、显示占用、监控进程和输入波动。若任一项无法测量，就把它标成“未知”，不要把未知默认为零。
| 工作表字段 | 必须记录的口径 | 验证动作 | 通过条件 |
|---|---|---|---|
| 权重与常驻组件 | 模型 revision、量化文件、视觉编码器、offload 层数 | 加载前后分别采样 RAM/VRAM，并保存后端日志 | 重启三次后分配位置和静态占用可解释 |
| KV cache | 上下文、并发、cache dtype、是否复用 | 按 4K、8K、16K 等目标档逐级运行 | 峰值增长与日志一致，不发生交换或 OOM |
| 运行工作区 | batch、图捕获、采样、多模态与临时张量 | 分别运行最长输入和最长输出任务 | 记录的是请求峰值，而非加载完成后的截图 |
| 系统与服务余量 | 显示、桌面、API 网关、监控和其他模型 | 在真实部署进程同时运行时复测 | 高峰仍有明确回退空间，未触发系统交换 |
| 停止条件 | OOM、驱动重置、错误输出、P95 超标或温度降频 | 逐级加压且保留首次失败的完整日志 | 采购结论只使用失败边界以下的稳定档 |
为什么上下文会吃掉剩余空间
自回归生成通常需要保存历史 token 的 key/value 状态。KV cache 大小取决于层数、KV 头、头维度、缓存 dtype、token 数量和并发序列；采用 GQA、MQA、滑动窗口或缓存量化的模型会不同，因此不存在适用于所有模型的“每 1K token 固定占多少显存”。上下文窗口的输入输出关系可参考站内上下文窗口指南。
Ollama 官方文档明确说明，提高上下文长度会增加模型运行所需内存，并提供 ollama ps 查看实际分配和 CPU/GPU offload。vLLM 则提供独立的 KV cache 配置、显存利用率、缓存字节数和 CPU offload 选项。不要在模型刚好塞满显存时再把上下文从 4K 改到 64K；先逐级增加并观察峰值。
还要区分模型“声称支持的最大上下文”和你“配置并稳定验收的上下文”。截至 2026 年 7 月 18 日，Ollama 文档给出的默认分档是：显存低于 24GiB 时为 4K、24–48GiB 时为 32K、不低于 48GiB 时为 256K，并建议 Web 搜索、智能体和编码工具至少配置 64K；同一页也明确说明增大上下文会增加内存需求。这里的数值只是 Ollama 当前调度默认值，不是任意模型的能力、质量或显卡购买承诺，后续版本还可能变化。采购时应按真实提示长度的分布预算，而不是只追求产品页上的最大数字。
量化降低的是什么，牺牲的可能是什么
量化把部分权重或激活从高精度表示转换为更少位数，以换取更小内存和可能更快的推理。Hugging Face 的 bitsandbytes 文档分别提供 8-bit 和 4-bit 加载方式；vLLM 当前支持多种量化后端，但硬件兼容并不一致。格式名字相同也不代表内核、速度和质量完全相同。
- 先选后端支持的格式：不要只因文件更小就下载；确认操作系统、GPU 架构、驱动和后端真正支持。
- 避免反复再量化：llama.cpp 的量化说明警告，从已量化权重再次量化可能明显损害质量。
- 按任务做质量回归：固定 20–50 个真实提示，比较事实、格式、代码、长上下文和中文表现，不只看聊天第一句。
- 保留原始信息：记录基础模型、量化方法、位数、校准或 importance matrix、文件哈希和生成参数。
“4-bit”也不是单一格式。分组粒度、缩放因子、零点、混合精度张量、校准数据和执行内核都会影响实际文件大小、质量与速度。Transformers 当前整合 bitsandbytes、torchao、compressed-tensors 等多种后端；bitsandbytes 的硬件支持也按 LLM.int8、NF4/FP4 和优化器分别列条件。因此，量化方法必须与目标后端和硬件一起选择，不能只比较位数。
| 比较维度 | 至少测试什么 | 错误结论示例 |
|---|---|---|
| 容量 | 文件、加载后 RAM/VRAM、峰值工作区 | “文件 6GB，所以 6GB 显存一定够” |
| 质量 | 中文、代码、事实、格式、长上下文与业务评分 | “聊天第一句正常，所以无质量损失” |
| 速度 | prefill、decode、首 token、并发吞吐 | “位数更低，所以所有设备都更快” |
| 兼容 | 操作系统、GPU 架构、驱动、后端和算子 | “文件能下载，所以当前软件一定能加载” |
| 可追溯 | 基础模型 revision、量化配置、哈希与许可证 | 只保留一个模糊文件名 |
先过兼容闸门，再比较速度
一个量化文件“容量放得下”，不等于当前机器“能正确执行”。后端可能尚未实现该模型架构或量化算子，GPU 架构可能没有对应内核，驱动与运行库也可能不匹配。先用目标文件完成最小加载与固定输出检查，再做容量和性能测试；否则速度为零的根因会被误判成显存不足。
| 闸门 | 要核对的证据 | 失败时先做什么 | 不要做出的结论 |
|---|---|---|---|
| 资产完整性 | 仓库、revision、文件列表、大小与哈希 | 重新核对下载与分片，不先转换或再量化 | “后端报错，所以显卡不兼容” |
| 架构与格式 | 模型架构、GGUF/检查点版本、量化类型 | 查后端发布说明和支持矩阵，使用已知可用的小样本 | “同为 4-bit，任意后端都能加载” |
| 运行环境 | 操作系统、驱动、CUDA/ROCm、后端版本与提交 | 保存完整环境清单，以官方组合重现 | “能识别 GPU，就能运行所有内核” |
| 最小正确性 | 固定短提示、贪心或固定种子、错误日志 | 先用短上下文单并发验证，再逐项打开优化 | “输出了文字，所以质量和稳定性已通过” |
| 回退路径 | CPU、较高精度文件、关闭图捕获或减少卸载 | 一次只改一个变量，定位是文件、内核还是容量 | “换更大显存一定能消除软件错误” |
CPU、GPU、混合卸载和多 GPU 怎么选
- 全 GPU：权重、缓存和工作区能留出安全余量，通常更适合低时延交互；但仍需用真实后端测试。
- CPU 推理：适合成本敏感、速度要求低、内存足够或没有兼容 GPU 的情况；内存带宽往往比核心数量更关键。
- CPU + GPU 混合：llama.cpp 支持将部分层卸载到 GPU，使超过总显存容量的模型仍可运行；层跨设备与数据移动可能降低速度。
- 多 GPU：可扩展容量或并发，但并非把显存数字简单相加就获得单卡同等效率；需核对张量/流水线切分、互联和后端实现。
涉及 NVIDIA 运行环境时，可结合CUDA 与驱动兼容说明；使用 Transformers 或自定义推理代码时，再阅读PyTorch 安装和设备检查。多卡容量决策还应核对 PCIe/NVLink 拓扑、后端切分方式和跨卡通信，站内的Megatron 多 GPU 拓扑与并行边界可作为进一步排查入口。
“能跑”与“好用”要用四个时延指标拆开
| 指标 | 回答的问题 | 记录方式 | 容易被什么干扰 |
|---|---|---|---|
| 加载/冷启动 | 从启动进程到模型可接收请求要多久 | 冷缓存重复启动，报告中位数与范围 | 磁盘缓存、编译、模型下载 |
| TTFT | 用户多久看到第一个 token | 固定输入长度，记录 P50/P95 | prefill、排队、上下文与网络 |
| Prefill | 长提示处理速度如何 | 固定输入 token 数，单独报告 tokens/s | 缓存复用、batch 和提示长度 |
| Decode | 连续生成是否流畅 | 固定输出长度，报告每 token 间隔或 tokens/s | 采样参数、并发和内存带宽 |
| 并发吞吐 | 多人或 API 服务的总容量 | 固定到达率与并发，记录吞吐和尾延迟 | 连续批处理、KV 分配和排队策略 |
llama.cpp 自带 llama-bench，可按模型、线程、GPU offload、上下文深度等参数记录结果；但工具输出仍需与真实请求、后端启动参数和质量集结合。服务端启用 prompt/KV cache 复用时，缓存命中和未命中必须分开报告，否则重复提示会把结果美化成生产环境无法稳定复现的数字。
看到“卡”或 OOM，按症状留下证据
诊断记录必须覆盖时间序列。只截一次 nvidia-smi 可能错过请求峰值，也无法分辨功耗或温度导致的时钟限制。NVIDIA 官方文档说明该工具可查询显存、利用率、温度、功耗、时钟和限制原因，并支持循环采样；这些指标能帮助定位相关性，但不能单独证明模型速度慢的因果。若用 PyTorch 自定义代码，还要区分张量实际分配与缓存分配器保留的空间。
| 症状 | 第一批证据 | 隔离实验 | 优先动作 |
|---|---|---|---|
| 加载即失败 | 完整报错、文件哈希、模型架构、后端和驱动版本 | 用已知支持的小模型或高精度原文件加载 | 先解决格式/版本，不盲目扩容 |
| 生成途中 OOM | 峰值 RAM/VRAM、上下文、batch、并发和 offload | 逐项减半上下文、batch 或并发 | 找出增长项，再调整缓存或卸载 |
| TTFT 高 | 排队时间、输入 token、prefill、冷/热启动 | 固定输出并改变输入长度、缓存命中 | 拆开排队、编译和提示处理 |
| Decode 慢 | 逐 token 间隔、GPU/内存利用、时钟、功耗与温度 | 固定输入输出，比较全 GPU 与不同 offload | 判断是算力、带宽、数据移动还是降频 |
| 并发才崩溃 | 每序列 KV、队列、连续批处理、P50/P95 和错误率 | 固定总 token，逐级增加并发 | 先限流和设上限，再考虑扩容 |
性能结论应至少附上模型与量化文件、后端版本、输入/输出 token、上下文、并发、缓存状态和采样区间。若需要设计更严格的 tokens/s 对比，可参考站内推理性能测试与结果复现方法；不要把不同输入长度、不同量化和不同并发的数字排成“显卡排行榜”。
一套不依赖品牌的验收方法
- 锁定资产：保存模型仓库、revision、文件名、哈希、后端提交或版本、驱动和启动参数。
- 确认真实分配：记录加载后的 RAM/VRAM、GPU offload 层数、KV cache、上下文和并发，不用模型文件大小代替运行占用。
- 分开测两个速度：提示处理（prefill）和逐 token 生成（decode）分别报告，并记录输入、输出 token 数。
- 测冷启动与稳态：首次加载、首次编译和缓存命中后的时延不同；各自至少重复多次并报告中位数。
- 跑质量集：包括中文、长输入、格式遵循、事实题、代码或你的真实业务；对关键结果人工复核。
- 逐级加压：先增加上下文，再增加并发；观察 OOM、交换、降速、温度和错误，而不是一次拉满。
- 保留余量：为桌面、显示、其他进程和峰值工作区留空间；不要用“勉强启动一次”作为稳定配置。
建议把结果写成一张配置验收卡：模型 revision 与哈希、量化文件、后端版本、完整启动参数、硬件与驱动、上下文/并发、峰值 RAM/VRAM、TTFT、prefill、decode、P95、质量集得分、OOM 边界和回退方案。只有这些字段在同一环境中完整，才可以把“这台机器够用”传递给采购或下一位运维。
采购前还应预先写下停止条件，而不是测试结束后再解释结果。例如：目标中文任务的质量回归超过可接受阈值、最长常用输入在单并发下仍会 OOM、P95 首 token 延迟超过业务上限、持续负载出现驱动重置或明显降频、目标后端无法稳定加载指定 revision，任何一项触发都应暂停购买结论。此时先比较更高精度或更兼容的模型文件、降低非必要上下文、调整并发上限、验证其他后端或租用目标规格复测。只有在同一验收卡上记录“失败条件、采取的单变量调整、复测结果和最终余量”，才能区分软件配置问题与真实硬件容量不足，也能避免因为一次短提示成功就购买无法承载生产负载的设备。
常见配置误区
- 把模型参数量当成文件大小，忽略 dtype、量化格式和额外张量。
- 只看显存，不看系统内存、磁盘空间、内存带宽和驱动兼容。
- 认为 4-bit 一定比 8-bit 更快；实际取决于内核、硬件和反量化开销。
- 把最大上下文当默认目标，忽略 KV cache、延迟和真实任务是否需要。
- 拿别人单次 tokens/s 当采购依据，却没有相同模型、量化、输入长度、并发和采样参数。
- 把推理需求与训练/微调需求混为一谈；训练还有梯度、优化器状态和激活等显著开销。
还要把隐私和维护成本纳入配置。模型放在本机并不自动等于数据安全：下载来源、远程接口、日志、插件、更新程序和局域网服务都可能产生新的边界。对敏感资料，应限制监听地址和访问账号，记录模型与软件更新，并准备删除缓存、撤销权限和恢复旧版本的流程。
官方资料与复核范围
本地 CPU/GPU 后端、混合卸载和量化能力见llama.cpp 官方说明；GGUF 量化、实际文件大小与再量化警告见llama.cpp Quantize 文档；GPU 层、设备和多 GPU 切分参数见llama.cpp CLI 文档；可复现微基准参数见llama-bench；服务并发、KV 与 prompt cache 参数见llama-server。Transformers 的当前 8-bit/4-bit 加载与硬件边界见Transformers bitsandbytes 官方源文档，量化方法与选择入口见Transformers Quantization overview。上下文与显存关系见Ollama Context length，设备支持入口见Ollama Hardware support；服务端量化硬件矩阵、KV cache 与性能调优见vLLM Quantization、vLLM CacheConfig和vLLM Optimization。GPU 显存、利用率、温度、功耗、时钟与限制原因的字段定义见NVIDIA nvidia-smi 官方文档。
资料复核日期：2026 年 7 月 19 日。本文的参数×位数表只计算理论权重，不是完整显存保证；模型架构、量化文件、后端和硬件支持会变化。购买设备前应使用目标文件与目标软件在现有、租用或可退换环境中复现。
编辑复核与纠错记录：原稿只有固定“高性价比配置”和简化显存建议，无法覆盖模型架构、KV cache、并发和后端差异。兰塞 AI 编辑流程于 2026 年 7 月 19 日完成 A 级候选复核：取消具体购买榜单，改为可计算的权重下限、磁盘/RAM/VRAM 分层预算、量化质量与兼容闸门、CPU/GPU/混合决策、冷启动/TTFT/prefill/decode 指标、故障诊断矩阵和七步验收；补充 Ollama 当前上下文默认分档、NVIDIA 监控字段及其适用边界，并移除主题会重复展示的正文首图。本文没有接受硬件厂商赞助，也没有声称亲自测试某张显卡；本站的来源、更新与纠错原则见关于本站与编辑规范。
