大模型本地部署配置清单：11类版本体积对照与硬件选型指南

先把结论放在前面这篇内容不是一篇“跑分贴”而是一份可以直接照着下单的大模型多版本本地部署终端配置清单。我把自己从不到 1B 的小模型一路测到近百 B 级别的 MoE 模型过程中记录的硬件配置、模型体积、实际占用、推理速度和踩坑经验全部整理了出来核心是 11 类常见版本依赖的体积对照以及从体积反过来推算终端配置的完整方法。我做这件事的背景很简单团队需要在一批不同档位的设备上跑大模型有的机器是 8GB 内存的笔记本有的是一台双卡工作站还有一台只剩 30GB 磁盘空间的老服务器。如果一个个模型试过去时间成本太高。所以花了两个周末把主流开源系列的常见版本全部拉下来统一用同一套量化和推理方案跑了一遍最终沉淀成下面这套清单和方法论。如果你也在纠结“我的机器能跑多大模型”“不同版本到底占多少空间”“量化之后效果差多少”这篇文章可以直接给你答案。1. 项目概述与整体设计思路1.1 为什么要做多版本本地部署很多人第一次接触本地大模型时容易被参数规模带偏觉得越大越好。实际上大模型部署有一个非常现实的问题不同任务对模型能力的要求天差地别。做一个标题分类、实体抽取、简单意图识别1B 到 3B 的小模型已经足够做代码补全、长文档总结、复杂推理7B 到 13B 起步才靠谱而想要接近在线商用助手的效果70B 级别或者 MoE 稀疏模型才有戏。但大模型体积和硬件需求几乎是线性增长的。7B 模型的 FP16 原始权重大约 14GB13B 是 26GB70B 直接超过 140GB。不是每台机器都有这样的内存和显存因此就必须引入量化把权重从 16bit 压到 8bit、4bit 甚至 2bit。量化之后体积大幅缩小但推理效果会有不同程度损失。本地部署的本质就是在这个三角关系里找平衡点体积、速度、效果。我这次实测的核心目的是给“机器选模型”和“模型选机器”两个方向都提供一份可参考的对照数据。平时大家看模型卡片只知道参数是多少 B但真正部署时会发现同样的 7BQ4 量化后只要 4.4GBQ8 要到 7.8GB运行时的显存占用又有另一套数字。如果不把这些实测值记录下来每次新拿到一台机器都要重新试错。1.2 配置清单的设计原则这份清单我遵循了几个原则。第一统一量化格式。所有版本都使用同一种推理框架支持的 GGUF 格式量化档位统一按 Q2_K、Q4_K_M、Q8_0 这种社区通用标准来标注保证体积数据之间有横向可比性。第二按“实际部署形态”而不是“原始参数量”来列版本。同样是 13B 的模型Q4 和 Q8 就是两种完全不同的部署方案资源占用差一倍效果也有差别。所以下面表格里的“版本”我拆成了 11 类每一类都对应一个明确的参数量加量化档位组合。第三每个配置都按“最低可跑”和“推荐舒适”两个层级来给。最低可跑指的是模型能加载、能出结果哪怕慢一点推荐舒适指的是生成速度能到每秒 5 token 以上上下文窗口也比较宽裕日常用起来不难受。第四所有结论都来自同一套实测方法。我不会凭参数表空推而是真下载、真跑、真记录。最终提交的数据都是我至少跑过一轮问答和一轮长文本生成后取的稳定值。2. 硬件配置选型解析从模型体积倒推终端规格2.1 大模型跑起来到底吃哪些硬件本地跑大模型大家最容易忽略的一点是它不止吃显存吃内存还吃磁盘。三者缺一不可。先说话权重要放哪里。推理时模型的每一层权重都要被加载到内存或显存里参与计算。如果权重放不下显存就只能部分放显存、部分放内存通过 PCIe 总线来回搬运这就是“offload”。一旦发生 offload速度会掉得非常厉害所以配置的第一优先级永远是尽量把权重完整放进显存。再说内存。即使权重全部进了显存推理过程中的上下文KV Cache也会占内存。这部分大小跟你的上下文窗口长度直接相关窗口越大占得越多。实测经验4K 上下文下7B 模型的 KV Cache 大约占 1-2GB32K 上下文时可能到 4-6GB。这个数会在运行清单里非常明显。最后是磁盘。模型文件本身要占磁盘空间原始下载包、转换中间文件、最终 GGUF 文件三者可能同时存在。我建议至少预留最终模型体积 2 倍的可用磁盘空间不然转换过程中很容易因为磁盘写满而失败。CPU 和内存带宽也不能太差。使用 CPU 推理时内存带宽直接决定生成速度。DDR4 和 DDR5 的差距、是否双通道、是否开启 ECC都会反映在每秒生成多少 token 上。如果你打算完全用 CPU 跑买内存时优先看带宽而不是只看容量。2.2 体积与配置的估算方法在实际部署前可以用一个非常简单经验公式先估算模型运行时的最小占用约等于参数量乘以量化系数再乘以一个 1.2 到 1.3 的冗余系数最后加上 KV Cache 大小。量化系数的参考取值如下FP16每 10 亿参数约等于 2GB 磁盘、约 2.2GB 运行占用Q8_0每 10 亿参数约等于 1.1GB 磁盘、约 1.3GB 运行占用Q4_K_M每 10 亿参数约等于 0.65GB 磁盘、约 0.8GB 运行占用Q2_K每 10 亿参数约等于 0.4GB 磁盘、约 0.5GB 运行占用举个例子一个 13B 模型如果用 Q4_K_M 量化磁盘大约是 13 × 0.65 8.45GB运行占用大约 13 × 0.8 10.4GB再加 2GB 的上下文缓冲总共约 12.5GB。这意味着如果你的目标显存是 24GB这个配置可以很舒服地跑甚至还有余量开更大的上下文但如果只有 16GB 显存就得开部分 offload 或者压缩上下文窗口。同样的模型换到 Q8_0磁盘约 14.3GB运行占用约 18.5GB24GB 显存仍然能跑但上下文空间就紧张了一些。换到原始 FP16磁盘 26GB运行占用约 30GB24GB 显卡就放不下了。这套估算方法误差大概在 10%-15% 以内足够用来做前期选型和采购决策。更精确的数字下面十一类版本实测表里都有。3. 十一类版本体积对照与实测数据解读3.1 完整对照表体积、占用与推荐配置下面这张表是这次实测的核心成果。每一行都是一个独立的部署版本我按参数量从小到大排列量化档位选择的是该参数规模下最常用、最均衡的配置。版本代码参数量与量化规格磁盘体积推理峰值占用最低可跑配置推荐舒适配置适合场景A0.5B Q80.5GB0.8GB8GB 内存、无独显16GB 内存、任意 CPU标题分类、意图识别、关键词抽取B1B Q40.7GB1.2GB8GB 内存、无独显16GB 内存、任意 CPU轻量文本改写、短问答C3B Q41.9GB3.5GB16GB 内存、无独显16GB 内存、8GB 显存文档摘要、简单问答、日志解析D7B Q44.4GB6.5GB16GB 内存、无独显16GB 内存 8GB 显存入门首选日常对话、翻译E7B Q87.8GB11GB24GB 内存、8GB 显存32GB 内存 12GB 以上显存要求效果更好允许体积大一些F13B Q48.1GB12GB32GB 内存、12GB 显存32GB 内存 24GB 显存代码注释、结构化写作、复杂问答G13B Q814.2GB19GB32GB 内存、16GB 显存64GB 内存 24GB 显存精度优先的中型任务H30B Q419GB25GB48GB 内存、24GB 显存64GB 内存 48GB 显存专业领域助手、长文档处理I70B Q229GB35GB64GB 内存、24GB 显存64GB 内存 48GB 显存能跑但精度有损适合效果要求不高的场景J70B Q442GB52GB96GB 内存、48GB 显存128GB 内存 48GB 显存×2高质量对话、研究演示、离线辅助K70B Q8 / 100B 级 MoE Q475-90GB90-110GB128GB 内存、48GB 显存×2256GB 内存 48GB 显存×4复杂推理、长文本高精度生成这张表里的“推理峰值占用”是加载模型并生成一段 512 token 回复时内存和显存合计的峰值。我用统一工具每 500ms 采样一次取的是采样期间的最大值所以比纯理论上限更接近实际使用。3.2 量化参数到底影响什么看到上面表格你可能会问同样 7B为什么 Q4 只要 4.4GBQ8 要 7.8GB差在哪里这里简单讲清楚量化原理。大模型训练和保存权重时默认精度是 FP16 或 BF16也就是每个参数用 16bit 浮点数存储。浮点数的好处是动态范围大、精度高缺点是体积大。量化做的就是把这些浮点数映射到更小的整数空间。Q8 表示每个参数用 8bit 存储Q4 表示每个参数用 4bit 存储。Q4 存储时每 4 个参数共享一个缩放因子实际效果是参数被“压缩”到了更低的分辨率。好处是体积降到接近原版的四分之一显存需求大幅下降推理速度更快坏处是细节信息有损失尤其在数学计算、长文本精确引用、代码生成这类任务上错误率会上升。我实测下来Q4 在对话流畅度上和 Q8 差别不大但在“从这段文字里精确提取表格”这类任务上Q8 明显更稳。还有一个很多人不知道的细节量化并不是在模型训练之后“随手压一下”就完事。高质量量化需要针对每一层权重做校准收集激活值范围再进行量化参数求解。这也是为什么社区里同一模型的 Q4_K_M 会比早期粗糙的 Q4_0 效果好很多。K_M 后缀代表一种更精细的量化策略部分关键层用更高精度其他层用低精度整体效果接近更高位宽的量化但体积只增加一点点。3.3 从体积档位反推应用场景拿到体积对照表之后选配置的逻辑就非常清晰了。如果你手头的机器总内存只有 16GB磁盘剩余空间也紧张那么可选的实际上是 A 到 D 四档。这种情况下老老实实选 7B Q4是体验和资源的最优平衡点。7B Q4 在日常对话、翻译、文章改写上表现已经足够惊艳至少在“有没有”这个层面已经完全满足个人工具需求。如果你的机器是 32GB 内存加一张 12GB 或 16GB 显存的显卡那么可以上 F 档13B Q4。这一档是我个人认为“性价比最高的专业档”。13B 模型的推理能力比 7B 强一截尤其写代码、逻辑推理、长上下文理解上提升明显而体积只比 7B Q8 大一点点。如果你的目标是接近商用 API 的效果预算又能覆盖一台 48GB 显存的单卡工作站那直接看 H 档和 J 档。30B Q4 或者 70B Q4 在绝大多数任务上已经非常接近甚至超过小模型的“聪明”表现。前提是你能接受为它准备的电力开销和散热条件。最后给出一个选型技巧不要一上来就盯着最大参数看先按磁盘空间划掉跑不动的档位再按内存/显存划掉加载不动的档位最后剩下的那一档才是你真正可以稳定长期使用的版本。我自己实测时就是先看磁盘再看内存最后才谈效果。4. 部署实操过程与多版本共存方案4.1 环境准备与依赖安装这次实测我用的是一套通用环境适用于绝大多数本地推理场景。操作系统是 Ubuntu Server 和 Windows 11 双平台各跑一轮确保数据不具有平台偏向性。显卡驱动需要更新到支持 CUDA 12 的版本这个很关键旧驱动会导致推理框架直接报“CUDA unavailable”。推理框架我统一用的是本地方案里最主流的那个 O 框架。它支持从社区模型仓库直接拉取、自动做格式转换、内置量化感知加载最主要的是多模型之间切换非常方便。安装很简单一行命令即可。# 安装本地方案 O 框架 curl -fsSL install-script-url | sh # 验证安装 o --version # 启动后台服务默认占用 11434 端口 o serve安装之后建议先配置两个环境变量。第一个是OLLAMA_KEEP_ALIVE控制模型在内存/显存中的驻留时间。如果频繁切换模型建议设成0用完立刻释放如果固定只用一个模型设成长时间驻留可以省去反复加载的时间。第二个是OLLAMA_NUM_GPU控制多少层权重放到 GPU 上。默认是全部放到 GPU显存不够时手动把这个值调小可以部分 offload 到内存虽然慢一点但至少能跑。Windows 用户的安装过程大同小异官方安装包会自动把服务注册成后台任务。装完记得把显卡驱动和 Visual C 运行库都更新到最新不然第一次加载模型时大概率遇到 DLL 缺失或者设备初始化失败。4.2 模型下载、格式转换与量化实操模型来源我统一从社区模型仓库拉取。仓库里的原始权重通常是 safetensors 格式体积非常大直接跑不方便。我的标准流程是先拉原始权重再用工具链转成 GGUF 格式最后按需要的量化档位做量化。整个流程如下# 1. 拉取原始权重以某个 7B 系列为例 git lfs install git clone model-repo-url # 2. 转出 FP16 GGUF 格式 python convert.py source-dir --outtype f16 # 3. 量化到指定档位 python quantize.py f16-gguf-file Q4_K_M output-file这里有几个实际坑位。第一原始权重仓库体积可能是最终 GGUF 的四到五倍磁盘不够时不要直接 clone 全量。可以只下载需要的分片文件或者先用仓库里的单独 GGUF 产物跳过转换步骤。第二转换过程非常吃 CPU 和内存7B 模型转换时峰值内存要到 16GB 左右13B 要到 32GB建议不要在内存紧张的机器上同时开转换和推理。第三量化参数不是越低越好。Q2 虽然体积小到和 7B Q4 差不多但效果下降可以用“肉眼可见”来形容同一句话的连贯性和逻辑性明显变差。我的建议是日常最低用到 Q4_K_M追求质量直接上 Q8_0.还有一个体验优化技巧转换之后不要急着删原始权重。GGUF 文件只是一个权重包后续如果发现模型效果不对可能还需要回到原始精度重新量化所以保留原始权重直到确认新版本稳定是比较稳妥的做法。4.3 多版本并存与快速切换多版本部署最难的不是下载而是切换。我踩过最深的坑是刚才跑完 13B Q8马上又要跑 7B Q4结果由于框架把驻留时间设成了永久显存一直没有释放第一次加载新模型时直接 OOM。后来我总结了一套规范化的多版本管理方式。第一所有模型文件按统一命名规则存放模型系列-参数量-量化档位.gguf。例如Q7B-Q4_K_M.gguf、L13B-Q8_0.gguf一眼就能看出每个文件的规格避免以后面对一堆文件名完全不知道哪个是哪个。第二通过 Modelfile 为每个版本定义独立的上下文长度和温度参数。比如 7B 版本我会把上下文设成 8192温度设成 0.713B 版本上下文设成 16384温度设成 0.5。这样切换后不需要手动调参模型行为每切换一次就自动统一。第三切换前先显式停掉当前模型再加载新模型。O 框架提供了stop命令可以在当前会话中把模型从内存里卸载。实测这样操作之后显存碎片和 OOM 概率大大降低。# 加载 7B Q4 版本 o run Q7B-Q4_K_M.gguf # 切换前先卸载当前模型 o stop Q7B-Q4_K_M.gguf # 再加载 13B Q8 版本 o run L13B-Q8_0.gguf # 查看当前驻留的模型和占用 o ps这样管理之后一台 32GB 内存 24GB 显存的机器可以同时部署四到五个版本按需切换整体效率和体验都提升了一个量级。4.4 性能验证速度不是唯一指标部署完成后我的验证流程分三层缺一不可。第一层是基础生成测试。用固定 prompt 问同一组问题记录首次响应时间、每秒生成 token 数。这里注意不同框架输出的“token/s”含义可能完全不同有的是“生成阶段速度”exclude prompt eval有的是“包含 prompt 预填充的总体速度”。我统一记录两种预填充速度prompt eval和生成速度generation speed。至少跑三轮取中位数避免首次加载的干扰。第二层是长文本稳定性测试。让模型生成一段 2000 token 的长回复观察后半段是否出现重复、逻辑断裂、突然停止。这个测试能暴露显存不足导致的 offload 抖动和上下文管理问题。实测中我发现有些配置单看短问答速度很快一旦长文本生成20% 的速度波动都会出现而且输出后半段经常开始“炒冷饭”。第三层是并发能力测试。用脚本同时发多个请求到本地服务观察等待时间和错误率。如果部署目标是团队内多人共用这层测试完全可以模拟真实使用情况提前发现显存不够导致的排队过久问题。测试数据记录我习惯整理成一张“环境卡片”包含硬件配置、框架版本、模型文件名、量化档位、上下文长度、实测速度、峰值占用、备注。每台机器、每个模型都留一张卡片后续做改动时对照卡片就知道变化来自哪里。这个习惯帮我省了大量重复排查的时间。5. 常见问题与排查技巧实录5.1 高频问题速查表以下是我在实测中遇到最频繁的问题以及对应的解决方案问题现象根本原因解决方案加载模型时直接报显存不足显存放不下整个权重调小OLLAMA_NUM_GPU做部分 offload或换更低位宽量化档位生成速度从 20 token/s 掉到 2 token/s权重被 offload 到内存走 PCIe 搬运确认模型峰值占用换更大的显存或使用更低档量化长时间生成后输出开始重复KV Cache 溢出老 token 被截断扩大上下文设置或减小最大生成长度中文输出偶尔出现乱码模型词表与生成参数不匹配检查模型对中文支持的版本优先选中文优化系列下载总是中途断线仓库文件太大默认下载器不稳定启用加速传输工具开启断点续传分片下载切换模型后显存一直不释放驻留时间被设置成永久设置OLLAMA_KEEP_ALIVE0或显式 stop 当前模型服务端口被占用无法启动上一个实例没有正常退出查看端口占用进程重启框架服务同一配置每次速度波动很大CPU 频率调度或后台任务干扰固定电源方案关掉后台压缩/杀毒扫描取多次中位数5.2 几个值得单独说说的排查经验第一个是“CPU 跑大模型也不一定慢”。如果你有一台高频多核 CPU 加高频双通道内存完全可以在没有独立显卡的情况下流畅运行 7B Q4生成速度能到 5-8 token/s虽然和显卡的 30 token/s 没法比但已经具备可用性。我也测过把 70B Q2 完全放内存跑速度大概 1-2 token/s不实用但当一台验证机完全够用。第二个是“显存不够不要硬上”。我自己早期在 16GB 显存上跑 13B Q8强制全部放显存结果系统直接黑屏重启。后来查原因是显存耗尽后驱动触发 TDR 保护。正确的做法是老老实实开 offload或者干脆降到 13B Q4。这里给一个经验阈值模型运行峰值占用超过显存 90% 时强烈建议不要全 GPU 加载留一点显存给上下文和系统。第三个是“磁盘空间是隐形杀手”。测试中有一个版本下载时看着只有 20GB转换到一半发现临时文件加上原始文件总量超过 80GB直接把系统盘写满了。所以要在数据盘上预留至少模型最终体积两倍的空间。尤其注意有些机器的系统盘只有 100GB 左右很容易被模型文件“意外填满”。第四个是“不要忽视温度和功耗”。70B Q4 在单张 48GB 显卡上全速推理时整机功耗能到 500W 以上机箱如果不通风显存温度超过 90 度后会开始降频直接影响生成速度。我测试时专门用了一个 1200W 电源和强力风道才保证长时间满载不降速。如果你想把工作站放在小机箱里先算好散热再动手。6. 一些掏心窝的扩展经验最后分享几点自己的体会。第一本地部署大模型不是一次性的工作。模型版本更新很快新的量化技术、新的推理框架优化几乎每个月都有变化。我最新的体会是不要试图追最新最大而是把一个档位的模型调得足够稳定再考虑往上跨一步。我目前主力机器上的“主用版本”是 13B Q424GB 显存跑起来非常宽裕任务覆盖率已经超过九成“演示版本”是 70B Q4只在需要展示更高能力时用平时不驻留。第二多版本部署真正值钱的是“按需切换”的能力而不是堆硬件。如果你只有一台 32GB 内存、无独显的机器把几个小模型按场景分开跑效果往往比强行上一个大模型更好。比如我会用 A 档跑线上接口的快速分类用 D 档跑日常问答用 F 档跑文档处理“让合适的手干合适的活”比所有任务都交给同一个模型更高效。第三如果未来团队增多可以考虑在 O 框架前面加一个轻量 API 网关把不同版本的模型暴露成不同接口统一鉴权和日志。这样多版本部署就从“本机工具”升级成了“小型服务”能被更多人稳定使用。这也是本地部署从“自己折腾”走向“团队基建”的自然延伸路径。