2026-08-31

本地部署大模型显存怎么选：企业配置对比

详解本地部署大模型显存的计算方法，结合模型规模、量化方式、上下文长度与并发需求，对比单卡、多卡、Mac及CPU方案，帮助企业科学选型与采购。

一、企业选显存，不能只看模型参数量

企业评估本地大模型时，最常见的误区是把“参数规模”直接换算成“需要多大显存”。参数量只能说明权重数据的基础体量，不能代表服务运行后的完整占用。真正可执行的估算，需要同时考虑四个变量：模型规模、权重精度、请求并发和上下文长度。缺少其中任何一项，采购结论都可能停留在“模型勉强启动”，而不是“业务稳定运行”。

这四项并非彼此独立。低比特量化可以压缩权重，却不会按相同比例消除运行时开销；模型缩小后，如果并发数和上下文上限同步提高，节省出的显存可能很快被缓存消耗。反过来，同一模型在单人交互测试中运行正常，也不意味着它能承受多个长文本请求同时生成。因此，企业应先定义服务负载，再反推硬件，而不是先购买显卡，再寻找能够塞进去的模型。

采购沟通中还要明确三个不同口径，避免技术验证与上线目标混为一谈：

• 能加载：权重可以放入显存，推理进程能够启动并完成少量请求。这只验证了最低运行条件，通常不能说明延迟、吞吐和稳定性达标。
• 稳定可用：除权重外，还能容纳注意力缓存、推理框架工作区、临时张量及必要的系统占用，并在目标上下文范围内连续运行，不因短时峰值频繁溢出。
• 生产部署：在稳定运行的基础上，应覆盖业务并发高点，并为模型版本变更、推理引擎升级、提示词增长以及监控组件保留空间。生产配置不宜把显存长期压到极限。

从工程顺序看，显存通常是本地推理首先需要跨过的门槛，但它不是唯一决定性能的部件。CPU会影响分词、请求调度和部分算子处理；系统内存不足时，模型加载、权重映射乃至进程稳定性都会受影响；存储性能决定冷启动和模型切换速度；多卡环境下，卡间通信能力与拓扑结构会直接影响分片推理效率。显存总量相同的两套机器，如果一套依赖低速互联，另一套能够高效传输张量，其实际吞吐可能明显不同。

因此，本节可先形成一个简单判断：模型规模与量化精度用于估算“静态底座”，并发和上下文用于估算“动态增量”，再叠加框架开销与工程余量，才是企业应采用的显存口径。后续配置对比也应围绕这一口径展开，而不是用某张显卡能否启动某个模型作为最终采购依据。

二、显存怎么算：模型权重只是第一笔账

本地部署大模型时，最容易出现的误判是把模型文件大小当成显卡需求。模型文件只反映静态权重，实际推理还要为输入输出过程中的中间张量、上下文缓存以及运行时管理结构留出空间。因此，“文件能装下”只能说明模型可能加载成功，不能说明它能稳定服务请求。

第一步可以先按下面的方式估算权重显存：

权重显存 ≈ 参数量 × 单参数占用字节数

例如，一个参数规模为 7B 的模型，FP16 权重的理论值约为 14GB，INT8 约为 7GB，INT4 约为 3.5GB。这里的“约”很重要：量化格式通常还包含缩放因子、分组信息和对齐开销，实际文件大小不会严格等于参数量乘以理想字节数。模型加载时也可能发生格式转换或额外复制，所以不能拿这个结果直接对照显卡标称显存。

三类显存要分开记录

更实用的做法，是在部署表里拆出三个指标，而不是只登记一个模型大小。

• 静态权重显存：模型加载后长期占用的基础部分，通常由参数规模、量化方式和加载格式决定。
• 单请求峰值显存：一条请求在预填充和生成过程中额外消耗的显存，受输入长度、输出长度和模型结构影响。
• 目标并发峰值显存：达到业务并发目标时的总峰值，重点受 KV Cache、请求长度分布和调度策略影响。

在权重之外，激活值是计算过程中的临时空间，通常在预填充阶段更明显；KV Cache 则会随着上下文长度和同时处理的请求数增加。对于长文档问答、代码补全、批量摘要等业务，KV Cache 往往比单个请求的短时激活更容易成为瓶颈。推理框架本身还会占用一部分显存，包括算子工作区、通信缓冲区、内存管理结构和必要的临时张量。

如果当前只有模型参数量和量化格式，可以先在权重结果之上增加约 30% 的空间，作为低并发、常规上下文下的筛选线。例如，权重估算为 14GB，初步预算可按约 18GB 观察，而不是把 14GB 显卡当作合适配置。这只是早期排查工具，不是生产容量承诺。长上下文、多用户并行或输出长度波动较大的场景，额外空间可能明显超过这个比例。

正式规划时，建议建立一张简单的容量记录表：模型版本、量化格式、权重占用、输入长度、最大输出长度、单请求峰值、目标并发和总峰值。压测至少覆盖短请求、典型请求和接近上限的请求，并记录显存峰值而非平均值。只有把业务请求分布带入测试，才能判断是显存不足，还是吞吐、排队延迟先达到瓶颈。

采用带 PagedAttention 的推理框架，可以把 KV Cache 按页面管理，减少碎片并改善并发请求之间的显存利用。它解决的是缓存分配和复用效率问题，不会降低模型权重本身的常驻占用；如果权重已经超过单卡容量，换框架不能替代量化、分卡或更换硬件。最终容量应以目标模型、上下文上限和并发压测结果为准。

三、模型规模×量化方式：企业显存配置对照表

模型参数量只能决定权重的大致体积，不能直接等同于机器需要的显存。下面的数字按“权重加载到显卡、采用常见推理框架、保留基本运行空间”的工程口径估算；它们适合做采购初筛，不应替代真实压测。实际占用还会受到量化格式、推理框架、上下文长度和并发请求数影响。

7B 是最容易落地的一档。INT4 权重本身约占 4—5GB，但 8GB 显存并不意味着所有场景都能稳定运行：如果上下文较长，或者同时处理多个请求，缓存和框架开销会迅速压缩可用空间。因此，8GB更适合单用户、短输入的内部工具；需要轻并发时，12—16GB更合理。FP16版本通常要按约16GB权重空间准备，实际运行最好再留出余量。

13B—14B 是企业工作站中较常见的折中点。INT4大约需要9GB，12GB显卡可以完成基础部署，但余量较小；16GB更适合保留较长对话历史、接入检索结果，或承受少量并发。若坚持使用FP16，显存需求会上升到约28GB，单张常规消费级显卡通常不再合适。

32B 的 INT4 权重约20GB，24GB显存可以运行，但属于“能启动、需要精细控制”的档位：上下文过长、批量增大或同时服务多个请求，都可能触及上限。32GB则便于留出缓存和运行空间。FP16版本约64GB，通常需要高显存单卡或多卡切分，不宜按普通工作站方案采购。

70B 即使采用 INT4，权重也接近40GB，工程上应把48GB以上视为更可靠的起点。FP16约140GB，往往需要两张80GB级数据中心卡，或者采用多卡并行与切分部署。这里的“多卡可运行”不等于“多用户可用”：卡间通信、带宽和框架兼容性都会影响实际吞吐。

从选型顺序看，先确定业务允许的模型档位，再在 INT4、INT8 和 FP16 之间取舍。INT4适合显存受限、以生成和问答为主的部署；INT8通常在资源和精度之间更保守；FP16则主要用于显存充足、需要更稳定数值表现或已有数据中心资源的场景。表中的显存只能作为起始边界，最终仍要用目标上下文长度和目标并发量进行压测确认。

四、并发与上下文：为什么“能跑”不等于“能上线”

单轮短对话能正常返回，只能证明模型权重已经装入显存，并不能说明这台机器适合长期提供服务。权重通常在模型加载后保持相对稳定；真正会随着请求变化的，是推理过程中保存的 KV Cache。每个请求的输入越长、输出越多，缓存占用就越大；同时处理的请求越多，缓存还会按请求数叠加。模型层数、注意力头配置以及 KV Cache 使用的数据精度，也会改变这部分开销。

因此，显存预算至少要拆成三部分：模型权重、KV Cache，以及推理框架和运行时的额外空间。后两项决定了“加载成功”与“稳定运行”之间的差距。一个只输入几百字、一次只服务一个人的测试，往往看不出长文档检索、连续追问和多人同时请求带来的压力。尤其是 RAG 场景，检索结果会把输入上下文迅速拉长；如果还要求模型输出较完整的答案，缓存会在生成阶段继续增长。

不建议使用“每增加一个并发就固定增加若干 GB”的经验系数。不同模型的层数和注意力结构不同，量化格式也可能只压缩权重而不压缩缓存；推理框架对缓存分配和批处理的实现同样会影响结果。更可靠的做法是锁定模型文件、量化方案、推理框架、最大输入长度和最大输出长度，然后按并发数逐级测试，例如从 1、2、4、8 路开始。每一级都记录显存峰值、首 token 延迟、完整响应时间、生成吞吐，以及请求失败或排队比例。

测试时还要覆盖两类边界：一类是短输入高并发，观察多人同时访问时是否迅速耗尽缓存；另一类是长输入低并发，验证单个请求是否会因上下文上限触发 OOM。若业务是 RAG，还应固定检索片段数量或总 token 上限，否则每次测试的输入规模不同，结论无法比较。最终配置不应只看平均值，而要看高峰时段的显存峰值和最慢请求。

显存接近上限时，处理顺序通常应是先收紧最大上下文和最大生成长度，再限制批大小或同时处理的请求数；对突发流量，可以引入排队，让系统用可控的等待换取不崩溃。对于支持分页管理 KV Cache 的框架，可评估 PagedAttention 一类机制。vLLM 项目对该机制的设计目标，就是减少缓存碎片并提高并发下的显存利用率，但它不能消除模型权重、长上下文和高并发本身带来的资源需求。

只有当限制上下文、控制并发和优化缓存管理后，业务仍达不到目标吞吐，才应考虑更换模型、增加显卡或拆分服务。显存选型的结论，应该来自固定条件下的压测曲线，而不是来自一次“能生成答案”的演示。

五、按企业业务场景选择配置，而不是盲目追求大模型

显存规划应先从任务的错误成本、调用频率和数据形态倒推，而不是先确定一个最大的模型。企业内部问答、合同审核、代码生成和核心 API 服务，对模型能力、响应稳定性与并发的要求并不相同。相同的模型，在单人试用和多人同时访问时，也可能对应完全不同的硬件预算。

1. 办公类任务：8GB 是验证线，不一定是上线线

邮件改写、会议纪要、材料压缩和企业制度问答，通常不需要一开始就部署大参数模型。7B 级 INT4 模型可以作为入门方案，8GB 显存能够完成单用户或低并发验证。但实际部署还要容纳较长上下文、检索增强组件、服务框架以及后续版本切换，因此 12—16GB 往往更容易留下余量。这里的“余量”不是为了追求更高规格，而是避免模型勉强装入后，稍微增加输入长度就发生显存溢出。

2. 隐私文档与部门知识库：先保证可控，再追求参数规模

合同初筛、制度检索和部门级知识问答，问题通常带有固定格式、专业术语和内部敏感内容。13B—14B 的 INT4 配置、16GB 显存，可以作为较稳妥的起点。相比把更大的模型压缩到几乎没有运行空间，保留足够显存给上下文、向量检索和并发请求，往往更利于控制延迟。工程验收时，应重点检查引用是否准确、拒答边界是否稳定、相似问题的答案是否一致，而不是只看通用评测分数。

3. 代码和复杂推理：显存升级必须对应可观测收益

代码生成、数学题和复杂结构化抽取，对推理链完整性与格式遵循能力更敏感。可以从 14B、16GB 显存起步；如果内部测试显示小模型在关键任务上频繁出错，再评估 32B INT4 和 24—32GB 显存。测试集应来自真实代码仓库、历史工单、财务表格或业务文档，并记录一次通过率、人工修改时长、格式错误率和响应时间。若模型变大却没有减少返工，就不应仅凭参数量增加采购显存。

4. 核心推理服务：70B 方案要和调用经济性一起评估

复杂分析、跨文档判断和对质量要求较高的内部 API，才有理由考虑 70B INT4 级别的部署，显存通常需要 48GB 以上。低频调用时，本地多卡设备可能长期闲置；高峰期调用则还要考虑显存占用、卡间通信、故障切换和运维人力。因此应把本地设备折旧、电力、机房、备件与维护成本，与云端 GPU 的按量费用放在同一张表里比较。模型能力越强，越不能只用“能否启动”作为验收标准。

最终选择应以业务压测收口：固定模型版本、量化方式、上下文长度和并发数，分别记录首 token 延迟、完整响应时间、显存峰值及错误率，再决定是否需要更大显存。这样得到的是面向任务的配置，而不是脱离使用场景的显卡清单。

六、单卡、多卡、Mac 与 CPU 方案怎么取舍

显卡数量不是部署能力的直接指标。单卡的价值在于链路短、配置少、故障点少；多卡的价值在于把单张卡装不下的模型拆开，或用并行提高吞吐。Apple Silicon 和纯 CPU 则更适合特定成本、功耗或离线约束。选型时应先确定模型、量化格式、上下文长度和并发目标，再判断硬件形态。

单卡：优先解决上线复杂度

如果模型在单张卡中有足够余量，单卡通常是企业第一选择。8—16GB 显存可以覆盖不少 7B 至 14B 的 INT4 部署；24—32GB 更适合把 32B INT4 放进同一张卡，或者运行 14B 的 FP16 版本。显存达到 48GB 左右后，才进入量化 70B 的可行区间。

这里的“余量”不能只按权重大小计算。推理进程还要分配运行时缓冲、CUDA 工作区和 KV Cache。若目标是固定单用户、短上下文，勉强装入可能可以接受；若要承载多人请求，建议把显存使用率、首 token 延迟和持续生成速度一并纳入验收，而不是只看模型是否成功加载。

多卡：显存可以协同，但不是简单相加

多卡适用于两类问题：模型权重和运行时内存超过单卡容量，或者单卡吞吐不足。采用张量并行前，必须确认推理框架和模型实现支持对应的并行方式；有些软件只能让不同进程各用一张卡，并不能把一个模型高效拆开。

跨卡传输会带来额外成本。PCIe 通道较窄时，层间或张量间频繁同步可能抵消增加的计算资源；具备高速互联的服务器通常更适合这类部署。两张卡的显存容量也不能在所有框架中无条件合并，实际可用空间取决于分片策略、显存分配方式和通信缓冲。采购前应使用目标框架跑一轮真实模型，而不是只做显存数字相加。

Mac 与 CPU：适合低并发、离线和研发用途

Apple Silicon 的统一内存可以被模型和图形处理单元共同使用，因此 64GB 统一内存的机器可用于量化 32B，并尝试较紧凑的 70B 配置；128GB 档能为量化 70B 留出更宽松的空间。不过，统一内存并不等同于专业 GPU 显存。模型加载后还要与操作系统、上下文缓存和应用进程竞争内存，且推理框架的算子覆盖、批处理能力和服务化接口需要单独测试。

CPU 加系统内存是可行的保底路径。以 32GB 内存运行 7B INT4，适合文档离线处理、开发调试、低频问答或灾备节点；但生成速度通常只有每秒几个 token，和 GPU 常见的几十乃至更高水平存在明显差距。因此，CPU 方案应明确定位为低频任务或容灾能力，不宜直接承担实时高并发接口。

一个实用判断是：单卡优先看稳定性，多卡优先看框架和互联，Mac 优先看生态与内存余量，CPU 优先看业务是否允许等待。最终选择应由目标模型的实测吞吐和延迟决定，而不是由设备的理论显存总量决定。

七、采购与上线：用压测结果确认最终显存

显卡采购不应从“这张卡能否加载模型”开始，而应从“业务请求在什么条件下会把显存推到边界”开始。模型能够成功启动，只能说明权重和基础运行环境放得下，不能证明它能承受真实用户的并发、长上下文和复杂工具链。采购前最好先冻结一份脱敏测试集，并让候选硬件、模型版本、推理框架和量化配置使用同一套输入，避免不同测试条件造成错误比较。

测试集不能只放几条短问答。至少应覆盖以下几类请求：

• 短提示词与接近业务上限的长提示词，用来观察上下文长度对 KV Cache 的影响；
• 常见回答长度与较长输出，避免只按平均响应估算生成阶段的资源占用；
• 带检索片段的问答，把文档数量、片段长度和元数据一并纳入测试；
• 需要调用外部工具、分步执行或返回结构化结果的任务，验证中间状态是否造成额外峰值；
• 涉及权限判断、合同审阅、财务数据处理等敏感业务任务，确认实际提示模板不会改变资源需求。

每种场景都应重复测试，而不是只记录一次最好成绩。建议把请求按目标并发分组，分别观察单请求、低并发和目标并发下的表现，并保留原始日志。验收记录至少包括：模型加载完成后的显存占用、单请求运行时的最高显存、目标并发下的最高显存、首个 Token 返回时间、后续生成速度、整体吞吐量，以及超时、异常退出和结果不完整等失败情况。

压测时要特别检查系统的“退化路径”。当显存达到高位，推理框架是否会把部分数据转移到内存，是否因此触发 CPU 卸载，或者只是让首 Token 和生成速度突然变慢。后两种情况未必立刻报错，却可能使线上 SLA 失效。还要模拟峰值请求与普通请求同时到达，观察一个长上下文任务是否拖慢整批请求。

最终配置不能按测试期间出现过的最高占用来贴着采购。峰值是风险边界，不是建议的长期运行点；还要为驱动、进程波动、缓存增长、模型热更新以及突发并发保留安全空间。余量具体留多少，应结合测试结果、业务容忍的延迟和扩容周期确定，而不是套用一个脱离场景的固定比例。

采购评估也不能只比较显卡单价。应把整机功耗和电源规格、散热能力、机箱可安装空间、驱动与推理框架的适配情况纳入总成本；如果需要多卡，还要核对卡间通信、主板通道和部署复杂度。最后估算运维投入与后续模型升级成本：更大的模型、更长的上下文或新的量化方案，可能改变显存和软件栈要求。只有把这轮压测结果与完整运行成本放在一起，才能判断配置是“能启动”，还是足以稳定上线。

八、FAQ：本地部署显存选择的四个常见问题

8GB显存到底能不能部署企业大模型？

能，但更准确的说法是：8GB显存适合部署经过压缩的小模型，或承担低并发、短上下文的内部任务，不等于可以稳定承载所有企业模型。显存首先要容纳模型权重，运行时还要为上下文缓存、推理框架、临时张量和并发请求预留空间。权重刚好塞进去，往往意味着一拉长上下文或增加第二个请求就开始溢出。

实际判断可以按三步做：先确认模型的量化格式和文件大小，再给运行时开销留下余量，最后用真实业务提示词测试连续请求。8GB设备通常更适合知识库问答、文本分类、字段抽取等短输入任务；代码生成、长文档总结、多用户并发则应优先增加显存或降低模型规模。不要只看“模型能加载”，要看在目标上下文长度下是否能持续服务。

两张16GB显卡是否等于一张32GB显卡？

不等于。两张卡可以通过模型切分或张量并行共同承载一个模型，但可用容量不是简单相加后的单卡体验。跨卡传输会带来通信开销，主板插槽、PCIe带宽、显卡间互联方式以及推理框架的并行实现都会影响结果；部分框架还会因为分配策略，使其中一张卡先达到上限。

如果模型本身能完整放入一张16GB卡，两张卡主要增加的是并发能力，而不是自动把单请求速度翻倍。若模型必须拆到两张卡上，则应确认目标框架支持对应量化格式和多卡推理，并检查显存是否均衡。采购前最好用目标模型、目标上下文和目标并发做压测；“总显存达到要求”只能说明存在可行路径，不能直接代表生产性能。

INT4量化会不会明显降低业务效果？

会有影响，但影响大小取决于任务，而不是由“INT4”三个字符单独决定。量化把权重用更低精度表示，通常能显著减少显存占用，并改善本地推理的部署门槛；代价是在复杂推理、严谨代码、长链路规划和边界案例上，错误率可能比高精度版本更容易上升。

对普通检索问答、摘要、分类和结构化抽取，INT4往往是值得优先验证的起点。对财务计算、专业法规、代码审查等高风险流程，应同时保留高精度基线，用一组脱敏业务样本比较事实正确率、格式合规率、拒答质量和人工返工比例。若质量不达标，可以先换更稳健的量化方案或提高模型规模，而不是直接购买更大显卡。Q8通常更接近原始模型效果，但显存和吞吐成本也更高。

没有独立显卡，能否用系统内存或Mac统一内存部署？

可以。CPU推理框架能够把模型放进系统内存，Apple Silicon则可使用统一内存承载模型与运行时数据。不过，系统内存容量只是“装得下”的条件，内存带宽和处理器能力决定“跑得动”的程度。与GPU相比，CPU方案的首 token 延迟和持续生成速度通常更弱，适合低频、离线、单用户任务，不适合作为多人实时服务的默认配置。

普通电脑应重点检查内存余量、交换分区和长时间运行时的稳定性；不要让模型占满全部内存，否则系统和框架没有缓冲空间。Mac方案则要按统一内存总量扣除操作系统、应用和上下文缓存后再估算可用容量。容量较大的统一内存机型可以运行更大的量化模型，但仍需通过实际提示词测试响应速度。若业务要求稳定并发，应优先采用独立GPU或专用多卡主机，而不是只按内存容量做判断。