你可能是在某篇帖子里看到「7B 本地跑 DeepSeek」就动手了，结果卡在三件事上：不知道 7B 跟 V3 到底是不是一个东西、不确定自己显卡要选哪档量化、跑起来了又不知道算不算跑通。这篇按「先选对版本 → 算清资源 → 落地跑通 → 拿到能用的速度」给一条顺序，每步都告诉你去看站内哪个页面的当时数字，不替你写死结论。
你可能是在某篇帖子里看到「7B 本地跑 DeepSeek」就动手了，结果卡在三件事上：不知道 7B 跟 V3 到底是不是一个东西、不确定自己显卡该选哪档量化、跑起来了又不知道算不算跑通。这篇按「先选对版本 → 算清资源 → 落地跑通 → 拿到能用的速度」给一条顺序，每步都告诉你去看站内哪个页面的当时数字，不替你写死结论。
本地部署的坑很少出在命令敲错，多半出在动手前没把「我要跑哪个权重、我这张卡能扛哪档、我接受多慢」这三个问题答清楚。下面每一步都配了验证动作，走完再回头调，比反复重装省事。
先分清你要跑的是哪一个 DeepSeek，7B 和 V3 不是一回事
搜「deepseek v3 7b 本地部署」的时候，这两个词经常被拼在一起，但它们指向的是不同维度的东西。V3 更像是系列标签，7B 说的是参数量级。动手前先把「系列名」「具体权重版本」「参数量」三个概念拆开看，否则你下的权重可能根本不是你要的那个。
- 把系列名、权重版本、参数量三个概念拆开：同一系列下有不同参数规模的权重，标着大版本号的那批和标着 7B 的那批，参数规模、显存需求、硬件门槛都不同
- 动手前去 /models 里按参数量筛一遍，确认你下载的那份权重真实参数和精度，别只看标题里的大版本号
- 小团队常见场景是几个人共用一台机器做代码补全或文档问答，这类任务先看权重是否够小、能不能塞进单卡，再谈效果
- 什么情况下不适用：如果你的目标是复现官方对话质量，本地小参数权重基本给不到，直接看 /official-api 的按量口径更省事
| 你要做的事 | 先确认的维度 | 去哪核对 |
|---|---|---|
| 只是想本地跑起来看看 | 参数量、精度标识 | /models 按参数量筛 |
| 团队共用做补全/问答 | 单卡能不能装下、并发几人 | /compute/gpus 对照显存 |
| 要接近官方对话质量 | 别耗在本地小权重上 | /official-api 看按量口径 |
算清显存、内存和并发上限，别先买卡再发现跑不动
资源不够多半不是「模型太大」，而是量化档位、上下文长度、并发数三个变量一起顶上去。按 /models/deploy 的测算思路，先把这三个数写下来，再决定用哪张卡或租哪档机器。
- 写下三个数量化档位、目标上下文长度、同时几个人用。这三个数不写下来，后面全是拍脑袋。
- 换算显存占用用 /tools 里的换算工具把目标档位对应的显存占用量出来，再看 /compute/gpus 的当时数字，比对手里或打算租的卡。
- 留出上下文开销长上下文要额外预留显存，别按短对话的占用去规划，否则一上长文档就爆。
- 验证按测算结果跑一次你真实场景里最长的那类输入，看有没有触发显存不足。
落地跑通的顺序：拉权重 → 起服务 → 打通调用
这一节只讲通不通，速度与输出质量另说。顺序错了最直接的表现是报错混在一起，你分不清是网络问题、加载问题还是调用参数问题。
- 先拉权重再起服务，权重没落盘前不要急着调接口，否则报错会混在一起看不出是网络问题还是加载问题
- 跑起来后第一次验证不要用复杂问题，用一个固定的、答案唯一的短问题确认链路通了，再去调参数
- 服务起来后把调用地址记下来，后面接知识库、接本地工具都靠它，具体口径去看 /ai-dict/category/infra 里的术语对照
- 换权重或改量化档位后，把同一个验证问题再跑一遍，确认是配置变了还是真出错
# 先确认权重落盘，再起服务；服务起来后用固定短问题打一次
# 具体命令与端口按你用的推理框架文档来，这里只强调顺序
ls /your/model/path
# 起服务后，先用最简单的一问一答验证链路
curl http://127.0.0.1:PORT/v1/chat/completions -H 'Content-Type: application/json' -d '{"messages":[{"role":"user","content":"1+1等于几"}]}'通不通和好不好用是两件事：量一遍再决定留不留
能跑出结果和能拿来做活是两码事。用 /tools/speed-test 先量一条你自己的延迟基线，本地跑和调接口的体感差异要拿数字比，不能凭感觉。
| 观察量 | 它决定什么 | 体感表现 |
|---|---|---|
| 首字延迟 | 交互像不像卡死 | 等半天不出第一个字 |
| 生成速度 | 能不能做批量活 | 一个长回答要等很久 |
| 稳定性 | 能不能长期开着 | 跑一阵就崩或掉速 |
如果本地速度还不如直接调 API，那这不是部署失败，而是这条路在当前任务上不划算，具体分界线别在这篇抄结论，到 /tools/speed-test 和 /price-watch 核对当时的数字自己算。什么情况下不适用：离线、断网、数据不能出内网这些硬约束下，速度慢也得认，这时候比的是能不能跑而不是快不快。
几个容易踩的坑：许可证、版本名字和迁移成本
跑通之后还有三件事容易被忽略，它们不报错，但会在你准备对外用或者换版本的时候冒出来。
- 许可证
- 下载权重前先确认授权范围，本地自用和对外提供服务是两回事，边界去哪看别凭印象
- 版本名后缀
- 后缀不同往往对应不同权重和配置，换版本时配置要跟着改，不能直接套旧参数
- 迁移成本
- 从小权重换到另一个小权重，先跑一遍同样的验证问题做对比，再决定要不要替换掉在用的那个
常见问题
deepseek v3 7b 本地部署，7B 到底能不能算 V3？
这是命名混在一起造成的误解。V3 是系列/版本标识，7B 是参数量档位，两者描述的不是同一件事。多数情况下标着 7B 的权重只是同一系列下的小体量版本，能力和官方线上版本差距明显。先去 /models 上按参数量和精度把你手上那份权重的真实规格核对清楚，再决定要不要拿它当线上模型的替代。
我显卡不算差，为什么本地跑起来还是很慢或者直接爆显存？
先别怪显卡，按顺序查三样：量化档位是不是选低了（占显存更多）、上下文长度是不是设得过长、有没有开并发或批处理。用 /tools 里的换算工具把目标档位在不长上下文下的占用算出来，再对 /compute/gpus 的规格核一遍。三样都降到保守值还爆，那就是这张卡对这份权重确实不够，换更小的权重比调参更直接。
本地部署和直接用官方 API，我该怎么定这个分界？
看你有没有「必须本地」的硬理由：数据不能出内网、要断网可用、要自己改权重或加私有知识库。有这些理由，慢一点贵一点也得本地；没有的话，直接走官方按量更省心，价格和规格去 /official-api/providers/deepseek 看当时的数字。中间地带（比如只是嫌调用麻烦）不建议为了省事自己搭一套运维。
