deepseek 32b 本地部署 硬件要求

打算自建大模型的团队常卡在同一处：模型标签上那串参数到底对应多大显存、几张什么卡、内存留多少，问谁都说「看情况」。这篇按参数量、量化档位、上下文长度、并发四件事拆开算一遍，给出一套能自己走完的估算步骤和验收清单。读完你能拿到一张属于自己场景的配置表，也能判断哪些情况下单机方案根本不该考虑。

为什么没有一张万能配置表

很多人问「deepseek 32b 本地部署要什么显卡」，其实这个问题本身就没法直接回答——同一份权重文件，你选不同的量化档位，显存占用能差出好几倍。所以任何配置建议，前面都必须跟一句「在什么精度下」。不声明精度的硬件清单，基本没有参考价值。

先分清你是哪一档需求

• 自己试问两句：偶尔跑跑、能接受慢，门槛最低，重点是有卡能加载进来
• 给五人左右的小团队做内部问答：要接受同时两三个人提问，得留出并发余量
• 当服务给几十人用：要同时考虑吞吐、排队和显存峰值，已经不是单机随便跑的事

动手前先做三个声明

1. 声明精度写清楚用哪个量化档位，别只说「我要跑 32b」。同一权重不同档位显存差数倍，不写精度等于没写需求。
2. 声明上下文确认你要支持的对话长度，并按这个长度预留 KV Cache，别拿短上下文的测试结果去预估长上下文。
3. 声明并发说清楚同时会有几个人提问。单人跑通不代表多人能跑通，这一步不确认，上线就等着爆显存。

想对照具体档位和硬件组合，可以到站内的模型资料库与测评页面核对当时的数字，那里会按精度和场景分列，比记一张固定表靠谱。判断类结论比如「能不能跑得动」，在你只做短对话、或者根本不在乎响应速度时，标准会宽松很多，这点要自己想清楚。

从参数量到显存：一条通用估算线

先把估算拆成三笔账：权重、运行开销、KV Cache。很多人只算第一笔，结果卡在加载阶段或跑几十个 token 就爆。三笔账各管各的，缺一笔就会在部署时踩坑。下面的口径是粗算用的，落地前建议去站内计算器按你的实际参数代一遍。

• 权重账：参数量 × 每参数字节数，半精度、8 位、4 位分别对应不同字节数，这条线只负责告诉你「模型本身占多少」。
• 开销账：推理框架自身的常驻、CUDA 上下文、图编译和临时缓冲都会占一部分，一般要在权重之上再留出一截，具体比例随框架和批大小变化。
• 内存账：加载时往往先要一份完整副本，量化反算和 CPU 卸载也都吃内存，内存不够的典型现象是加载到一半直接失败。
• KV Cache 账：按上下文长度和并发数估，长窗口或高并发场景它可能超过权重本身，是最容易被忽略的一笔。
• 结论：显存和内存都要分别留余量，别按权重数字卡满，预留多少要看你自己的并发和窗口设定。

1. 先定精度确定你要跑半精度、8 位还是 4 位，这决定权重那笔账的量级。精度越高，后面几笔账的余量也要跟着放大。
2. 再算权重用参数量乘以对应的每参数字节数，得到一个大概的权重占用。这个数字只当起点，不要当预算上限。
3. 预留运行开销在权重之上再留一截给框架常驻、CUDA 上下文和临时缓冲。如果你的框架支持批处理，批越大这一截越明显。
4. 单独核对内存显存够不代表内存够。加载、量化反算、CPU 卸载都会占内存，内存不足会直接表现为加载中途报错。
5. 最后算 KV Cache按你打算用的上下文长度和并发数估。长窗口场景下这笔账可能比权重还大，尤其别忽略并发叠加。

窗口长度和并发数到底怎么影响这张账，不用自己硬推。站内有一个现成的计算器页面，把参数量、精度、上下文长度和并发数填进去，它会把权重、开销和 KV Cache 分项算给你看。先代一遍再决定买什么卡或租什么机器，比拍脑袋靠谱。地址在站内计算器页，部署前顺手核对一下当时的数字。

按尺寸分档：小模型、中等模型、大模型的部署形态

先把话说在前面：下模型之前，先定档位。同一家的模型往往有小、中、大三档同系列版本，能力差多少、你的任务吃不吃得住，直接决定你要不要买显卡、买几张、换不换机箱。按参数量粗分三档：1B 上下的、30B 上下的、70B 及以上的，下面按档说形态。

1B 上下这一档是门槛最低的。重点是内存和量化格式选对，基本不涉及独立显卡——核显机器、迷你主机、普通办公本都能把它拉起来，量化压缩得越狠、占用越低，代价是效果和上下文长度可能打折。判断标准很朴素：内存够装下量化后的权重加运行时开销就行，具体要留多少，去站内模型资料库对应条目看当时标注的显存与内存占用，再到 模型资料库（/models） 对照同系列小版本的参数与定位，别拿别人的机器规格硬套。

30B 上下是多数团队真正想自建的那一档：效果能干活，模型又不至于大到买不起卡。这一档消费级显卡单卡通常放不下全精度权重，必须上量化；但很多人只盯容量，忽略了一个更坑的指标——显存带宽。容量是能不能装下，带宽是装下之后跑不跑得顺：带宽不足时，解码速度会明显拖后腿，交互体感先崩。所以选卡顺序应该是先看量化后能不能塞进显存，再看带宽能不能撑住你要的响应速度，最后才比价格。什么情况下不看带宽？如果你只做离线批处理、能接受排队等结果，那带宽优先级可以往后放。

70B 及以上进入另一个世界：多卡或专业卡，单机能不能塞下是第一个问题。这一步要开始算张量并行怎么切、卡间互联走不走得通、机箱装不装得下、电源喂不喂得饱，四者缺一都开不了机。跨档位的判断标准建议按顺序走：先确认模型是否有更小的同系列版本能满足你的任务，能就降档；再问自己要不要为了这一个尺寸把整机换掉，如果换机成本远高于任务收益，就说明该回来的不是硬件，是需求。需要对照具体卡型与互联规格时，去 显卡与硬件（/gpus） 看当期整理，参数不要凭记忆。

1. 定任务下限先用最小的同系列版本跑一遍真实任务，记录哪些场景不达标。达标就别升档。
2. 算显存账按量化后的权重占用加运行时开销估算，去站内资料库核对当期数字，别用过时印象。
3. 比带宽容量够之后看显存带宽，带宽低的卡在交互式场景体感差，离线批处理可放宽。
4. 查单机边界70B 及以上先确认单机能否装下卡、供电与散热是否够，装不下就转多机或换方案。

量化档位怎么定，别只看显存省多少

先把顺序摆正：不是先把显存榨到极限、跑起来再说，而是先问「这批任务最多能接受掉多少精度」，再按这个下限往上加显存预算。顺序反了，后面会一直补坑：今天能跑，明天换一批输入就发现抽取字段开始漏、摘要开始编。

• 先写死精度下限：哪几类输出错一次就算失败，列出来。
• 按这个下限挑量化档位，而不是按显存挑。
• 确认推理框架吃不吃这个量化格式，别转完才发现不认。
• 用业务里的一小批真实样本跑对照，别只看通用榜单。
• 对照通过再往上压一档试，压不动就退回上一档。

1. 定下限从业务里挑出最不能错的那类输出（比如抽取的金额、编号），明确它错一次就不能上线，这就是你的精度红线。
2. 试档位从偏保守的量化档位开始跑这批红线样本，记录错了几个、错在哪类输入上，而不是只看跑得快不快。
3. 对框架确认你用的推理框架支持哪些量化格式，不支持的先换框架或换格式，避免白折腾一轮转换。
4. 真样本对照拿一小批脱敏后的真实业务样本，同一提示词分别跑量化和未量化版本，人工看差异，比通用榜单更说明问题。

量化档位是跟着任务精度要求走的，不是跟着显存余额走的。

同一个量化档位，在不同任务上的体感能差很远，所以别拿一次测试的结论套所有场景。各档位的具体取舍站内已有专文，这里只给决策顺序；实际跑起来遇到的具体报错和对不上号的现象，到 指南中心（/guide） 按症状查排查顺序，硬件侧的预算怎么估到 硬件要求（/hardware） 页面对照看当时的口径。

单卡够不够：什么时候必须上多卡

先说结论：能不能单卡跑，不看卡的数量，看「加载完还剩多少显存」。加载模型只是把权重塞进去，真正吃显存的是上下文缓存和并发请求。所以经常出现一种情况——加载成功，一提问就爆。判断单卡够不够，标准就两条：量化到最低档还加载失败，或者加载成功但一提问就显存溢出。出现任意一条，才说明这张卡确实兜不住。

多卡不是免费加速

很多人觉得「一张不够就上两张，吞吐翻倍」。实际不是这样。多卡跑一个模型，卡之间要同步中间结果，这个通信开销是实打实的。扩卡之后吞吐涨多少，取决于通信带宽、切分方式和实际负载，跟卡数不成正比。所以别按卡数推测性能，要按实测：同一批请求，在单卡和双卡上各跑一遍，看每秒能处理多少，再决定值不值。

• 没有高速互联（比如普通 PCIe 互联）时，卡间通信慢，多卡跑大模型可能比单卡跑小模型还卡顿
• 这一点在小团队预算里最容易被忽略：钱花在第二张卡上，体验反而下降
• 扩卡前先确认机器有没有足够带宽的互联通道，没有就别急着加
• 按实测吞吐判断，不要按「卡多了肯定快」判断
• 如果瓶颈是并发而不是模型容量，加卡解决不了，限并发或排队更实际

判断顺序：三招都不行再加卡

1. 第一步：降量化档位把模型换到更激进的量化版本，重新加载。如果能加载且提问不爆，说明单卡够用，问题只是档位选高了。注意量化越低，输出质量可能下降，要拿自己的任务实测。
2. 第二步：缩上下文把最大上下文长度调小，再发请求。上下文缓存是显存大户，很多「一提问就爆」其实是上下文开太大。缩到业务真正需要的长度，观察是否还爆。
3. 第三步：限并发把并发请求数压到 1 或 2，串行跑一批真实请求。如果串行能稳、并发就崩，说明是并发吃穿了余量，加卡之前先考虑排队或错峰。以上三招都不行，再考虑加卡或换机型；换机型时优先看单卡容量和互联带宽，而不是只看卡数。

补一句适用范围：如果业务本身就是高并发、低延迟，缩上下文和限并发会直接影响体验，这时硬件的取舍要按业务能接受的延迟来定，不能只按「能不能跑起来」判断。具体到某张卡跑某个尺寸模型的实际表现，去站内的硬件对照页核对当时的数据，别照搬别人机器上的结论。

整机清单：显卡之外的几项硬指标

盯着显卡买整机，是本地部署最常见的翻车方式。卡选对了，内存不够会一直触发 CPU 卸载，速度掉到没法用；盘买小了，几份量化副本加缓存一塞就满；电源按待机功率配，跑长任务时整机降频。这几项跟显卡没有直接关系，但每一项都能决定你这台机器到底跑不跑得动。

内存：不是够开机，是够卸载

显存装不下整份权重时，框架会把一部分层丢给内存和 CPU 算，这部分占用必须提前留出来。判断标准是看你的量化方案下权重总量，再按「显存装不下的那部分 + 系统本身 + 推理时的临时缓冲」去配，而不是按操作系统的最低要求配。多开一份量化副本或同时跑别的服务，占用还会往上叠。

• 先确认要跑哪一档参数量和哪种量化精度，权重总量按这个估
• 显存之外预留的那块内存，要能覆盖可能被卸载的层，否则会频繁换进换出
• 系统和其他常驻服务的内存单独算，不要和权重混在一起看
• 机器只跑一个模型、也不打算加卡，可以按刚够配；一旦要多开或长期挂服务，就往上加一档
• 具体容量对照去站内空间测算页按当时的方案核对，别看旧帖子的固定数字

存储：权重、副本、缓存、日志四笔账

存储最容易低估。一份权重是大头，但真正吃盘的是多份量化副本、加载时的缓存、推理框架的临时文件，还有长期跑下来不断增长的日志。只留一份权重的空间，过两周就会发现系统盘见底，而盘满会直接让推理进程崩掉。

盘的类型也分两说：系统盘和权重盘分开，系统盘别塞满；权重放在读写稳定的盘上，加载速度会顺很多。具体容量到站内空间测算页按你要跑的方案核算一遍，比拍脑袋靠谱。

电源与散热：按满载配，不按待机配

很多机器开机没事、跑短测试也没事，一跑长任务就开始降频，原因基本都是电源余量不足或散热压不住。判断标准很简单：按所有卡同时满载的功耗加平台功耗来配电源，并且留出余量；散热按持续满载设计，不是按开机温度设计。多卡机器这两项尤其容易踩坑，卡挨得越近越热。

1. 先算满载总功耗把所有卡和 CPU 的峰值功耗加一起，再看电源额定功率能不能覆盖，别用待机功耗当依据
2. 看机箱风道能不能把热排出去多卡机器重点看卡与卡之间的间距和进风位置，封闭小机箱塞多卡基本注定降频
3. 用长任务验证跑一段持续负载，观察是否出现频率下降或吞吐随时间走低，短测试看不出这个问题
4. 留出升级余量电源和散热按未来可能加的卡来配，改这两样比换主板省事得多

主板与机箱：决定后期能不能加卡

这一项在采购阶段几乎不花钱，事后改却要换主板甚至换机箱。判断标准是看 PCIe 通道数够不够分给每张卡，以及机箱物理尺寸能不能塞下更长的卡。如果你现在只打算上一张卡，也要问一句：以后想加第二张，这块板子和这个箱子还接得住吗？接不住，就等于把整机锁死在当前规模。

PCIe 通道

决定每张卡能分到多少带宽，通道不够时加卡会互相抢

卡槽间距

双槽以上的卡挨太近会互相加热，加卡前先量间距

机箱限长

很多卡装不进去不是接口问题，是长度超了

扩展余量

现在就按可能加一张卡预留电源、散热和空间

装完怎么验收：三步确认配置真的够用

模型加载成功、对话能回，不代表这套配置就够用。真正的验收是看它在你的实际用法下稳不稳。下面三步按顺序做，全部通过才算过关。任何一步崩了，都说明硬件余量不够，别硬撑。

第一步：量加载——冷启动反复试几次

1. 关掉所有占用显存/内存的程序浏览器、编辑器、其他推理进程全退掉，模拟真实空闲环境，避免别的东西抢资源掩盖问题。
2. 连续冷启动多次同一套配置重复启动，至少跑三轮，每轮都从完全退出状态开始，记录每次是成功还是报错。
3. 判断标准与不适用情况如果偶尔失败、报内存或显存相关错误，说明余量不足。若每次都稳定通过，进入第二步。注意：如果你平时机器上还跑着数据库、前端服务，验收时就得把这些也开着，否则测出的余量是假的。

第二步：量体感——用真实业务提示词跑一批

别拿「你好」这种短句测，那看不出问题。把团队平时真会问的提示词整理一批，长短混合、包含长输入和长输出，逐条跑，记录首字延迟和生成速度这两个体感指标。具体怎么测、用什么口径，参考站内页面 延迟测试方法（/guide/latency-benchmark） 里的做法，保持口径一致，后面才有对比意义。

第三步：量并发——按团队实际人数同时提问

一个人用着顺，不代表三个人一起用还顺。拉上实际会用这套部署的同事，按团队真实人数同时发问，观察显存占用和响应时间随人数变化怎么走。找到那个「再加一个人就明显变慢或报错」的临界点，临界点之前的那档人数，才是你的稳定区间。

• 先单人跑，记下显存占用和响应时间作为底数
• 逐步加到两人、三人、团队实际人数，每档稳定跑几分钟再记录
• 盯住显存占用是不是接近上限，响应时间是不是成倍拉长
• 找到第一个出现明显劣化或报错的档位，它前档就是稳定区间
• 把稳定区间人数写下来，超了就得考虑错峰或加硬件

三步跑完，把结果记成一份基线：加载成功次数、首字延迟和生成速度的大致范围、并发稳定人数、当时的显存与内存余量。之后换模型版本、调上下文窗口、加插件，都拿这份基线对照，才看得出是变好还是变坏。没基线的话，出了问题只能靠猜。

哪些情况不该走本地部署这条路

本地部署不是「越重越专业」。它更像买台机床：用得频繁、对时延敏感、数据不能出内网，才值得把机器和运维一起扛下来。反过来，只要你的场景踩中下面任意一条，先别急着买卡，把这条路换掉往往更省事。

• 调用是偶发、探索性的，比如做几个 demo 或内部试点；
• 峰值压力靠几个人同时问，没有并发堆积；
• 团队里没人愿意长期负责权重更新、显存优化和故障排查；
• 合规要求还停留在「别拿去训练」，没要求数据必须留在内网；
• 预算买到的卡，离你目标模型能舒服跑起来的档位差得比较远。

1. 先算清调用频次和等待容忍度把最近一段时间的调用量拉出来，看是每天几十次还是每天上万次；再问业务方，慢几秒能不能接受。次数少又不怕慢，本地这条路的性价比就很低。
2. 再看有没有人接维护本地部署不是装完就完，模型更新、驱动和框架适配、显存不够时换量化方案，都要人跟。没人接，版本就会停在装好的那一天。
3. 拿合规口径去对直接问法务或安全：要求是「数据不用于训练」，还是「数据不能出内网」？前者托管接口通常就能满足，后者才轮到本地。别自己替监管下结论。
4. 预算不够就规划降级路线如果买到的硬件明显撑不起目标尺寸，别硬上。改成小参数模型加检索增强，把外挂知识做扎实，先满足可用性，再谈升级。

还有一类情况也建议先不本地：你只是想验证「这件事用大模型能不能做」。这种阶段模型选型和提示词都在变，硬件方案今天定明天就过期。先跑通流程，等需求和调用量稳定下来，再回头算本地部署这笔账，顺序反了很容易白买一批设备。