很多人第一次在本机部署 DeepSeek V3，卡在两处：一是不确定自己这张卡扛不扛得住，下载几十上百 GB 权重下到一半才发现装不下；二是模型下完了，框架选错，起服务各种报错。这篇按「先算账、再选框架、最后跑通并验证」的顺序走一遍，每一步都给可执行动作，具体参数量和显存数字请以站内模型库和部署测算页当时的口径为准。
本地部署 DeepSeek V3 这类大模型，第一次做最容易死在两个地方：一是卡还没摸清能吃多大，权重先下了几十上百个 GB，下到一半发现磁盘或显存根本装不下；二是模型文件躺在那，框架挑错，起服务一路报错，日志翻半天不知道从哪看。所以顺序很重要：先算账，再选框架，最后跑通并验证。
下面按这个顺序走一遍，每一步都给能直接动手的动作和判断标准。文中不写死任何参数量、显存占用和延迟数字，那些随版本和量化档位一直在变，请以站内模型库和部署测算页当时的口径为准。先记住一句话：预算和目标决定你下哪个权重，而不是反过来。
第一步：先算显存，再决定下载哪个版本
动手前先做测算，不要凭感觉买卡也不要凭感觉点下载。到站内 /models/deploy 按目标参数规模、量化档位、上下文长度三项输入，拿到显存占用和大概需要几张卡的初判。这个结果是你后面所有决策的地基，权重版本、框架路线的选择都从它来。
| 判断维度 | 先看什么 | 不通过的后果 |
|---|---|---|
| 显存容量 | 测算给出的占用值 vs 你卡的实际可用显存 | 起服务直接 OOM，反复重试白折腾 |
| 量化档位 | 用途是跑通演示还是长期干活 | 档位选错，要么跑不动要么质量不能接受 |
| 磁盘余量 | 权重体积 vs 目标盘剩余空间 | 下到一半中断，重下更浪费时间 |
| 部署形态 | 单卡、多卡并行还是 CPU offload | 形态和硬件不匹配，服务起不来或慢到没法用 |
量化档位本质上是个取舍：精度越高越吃显存，低位量化能把占用压下来，但输出质量会有损失。先问自己这机器是拿来做演示跑通就行，还是要长期接业务干活，两种目标选的档位完全不同。别一边想着省钱一边抱怨质量差，那是选型没对齐目标。
- 打开站内 /models/deploy 做部署测算，把三项输入填准，拿到显存和卡数的初判
- 单卡装不下时的两条路：上多卡张量并行，或者用 CPU offload 把部分层放内存——后者能跑起来但出字速度会明显掉，先把预期放低
- 下载前确认磁盘空间和权重存放路径，权重体积普遍比多数人预估的大，中途空间不足是最常见的翻车点
- 把测算结果截图或记下来，后面排查性能问题时这是唯一能对照的基线
第二步：挑推理框架，按你的用途决定
框架不是越新越好，是越贴合你的用途越好。只想单机自己用、图省事，Ollama 或 LM Studio 这类封装工具最省心，一条拉取命令就能跑起来，代价是高并发和精细调参空间有限。要给团队或应用提供稳定接口、在意吞吐和并发，就走 vLLM 这条路线，容器镜像部署干净，参数可控，但要照着显存和并发把参数调对，报错得会看日志。
- 想省心、单机自用：先试封装工具路线，命令行拉取即跑，出问题也能快速重来
- 要对外提供接口、在意并发：走容器化的高吞吐路线，启动参数按测算结果配
- 机器是国产加速卡或 Mac：先确认框架适配分支和权重能不能加载，再开始下载
- 不要在部署当天顺带做框架选型，框架对比先看站内栈目录页面，选好了再动手
还有一条经验：不要一上来同时试三套框架。先把一套跑通，拿到能用的接口，再考虑换。同时开三条线，报错信息混在一起，你连哪套是通的都分不清。框架本身的横向对比去站内 /stacks 看目录页，别在部署现场临时做决策。
第三步：起服务、验证接口、确认能对外用
- 起服务后打一次最简请求确认模型真的加载成功、能正常返回内容，再去接上层应用；这一步不过，后面都是空谈。
- 暴露成本地 API 地址要接自己的程序，就把服务暴露成接口，先本地调通，再考虑对外。
- 量一次延迟基线到站内 /tools/speed-test 跑一遍你这条链路的延迟，记下数字，以后排查慢的时候有对照。
- 记录三件事启动命令、模型文件路径、监听端口，换机器或重启直接复用，省得重新试参数。
- 失败时按顺序排查显存不足 → 权重路径或格式不匹配 → 端口被占用 → 缺少依赖，先看日志里第一处报错，不要跳到最后一行的总结语。
验证接口通不通，最简单的方法就是用通用客户端发一个短问题，看返回是否正常、是否出现截断或乱码。这一步过了，才算真正部署完成。接口通了之后再去接上层应用，把问题隔离开，出毛病时容易定位。
curl -s http://127.0.0.1:<你的端口>/v1/chat/completions -H 'Content-Type: application/json' -d '{"messages":[{"role":"user","content":"ping"}]}'什么情况下这套做法不适用
不是所有场景都值得自己在本机部署，下面几种情况硬上就是浪费时间和卡。判断标准很简单：你的硬件或需求已经越过了本地部署的合理边界，这时候换方案比继续调参划算。
- 显存明显低于测算结果：硬上只会反复 OOM，应该换更小的模型或更低的量化档位，而不是继续调参
- 要的是高并发对外服务：单机自部署的稳定性和扩缩容都不如租卡集群或直接调接口，算总账可能更贵
- 只是想试效果：做几个问答看质量，先按量调接口试完再决定要不要落地，别折腾本地部署
- 团队没有维护精力：起服务容易，持续可用难，没人盯日志和升级的话，别把它当生产环境用
至于租卡和调接口哪个更划算，价格是动态的，去站内 /price-watch 核对当时的数字再算总账，别拿记忆里的旧价格做决策。中转站能不能用、稳不稳，也有专门的检测口径，去站内 /sites 看当时的结果，不要只看宣传页。
下一步先用测算页确认你的卡能吃多大的模型和哪个量化档位，再决定下载路径，别急着拉权重。→常见问题
我只有一张消费级显卡，能跑 DeepSeek V3 吗？
能不能跑主要看显存和量化档位，不看显卡是不是消费级。先用站内 /models/deploy 按你的显存和想要的量化档位算一遍，能放下就单卡跑，放不下就降量化或者上多卡。别凭别人一句「能跑」就下单，配置差异很大。
部署完之后，怎么确认它真的在正常工作？
三步：发一条最简单的请求看有没有正常返回；用站内的接口测速工具量一次延迟，留个基线；再看显存占用是否稳定、有没有随请求慢慢涨上去。如果占用只涨不降，多半是缓存或并发配置的问题，要回头调参。
本地部署好了，还需要按 token 付费吗？
自己机器上跑不产生按量调用费，但电费、硬件折旧和你花进去的时间都是成本。如果是租卡部署，那租用时长照样计费，具体口径去站内 /compute 相关页面看当时的说明，别拿「本地等于免费」当结论。
