deepseek-v3怎么部署

接入与开发

面向自部署用户,讲清 DeepSeek-V3 本地跑起来要准备什么环境、按什么顺序装、怎么验证服务通了,以及显存不够时怎么退。

你可能已经拿到模型权重,也可能只想先在一台机器上把它跑通看看效果,结果卡在「显存要多少、用哪个推理框架、装完怎么确认服务真的起来了」这几步上。这篇不讲原理,只给一条从环境准备到连通验证的顺序:先算硬件账,再选部署方式,然后装依赖、起服务、发一次请求确认,最后补上日志和并发这两件上线前必做的事。数字类的规格和租金,统一去站内对应页面看当时的。

你手上可能已经有模型权重,也可能只是想先在一台机器上把它跑通看看效果。真正卡住人的通常不是模型本身,而是三件事:显存到底要多少、用哪个推理框架、装完怎么确认服务真的起来了。这篇只给一条顺序:先算硬件账,再选部署方式,然后装依赖、起服务、发一次请求确认,最后补上日志和并发。

注意,凡是规格、租金、延迟这类会变的数字,都不在本文里写死,统一去站内对应页面看当时的。你抄下来的那份结论,就是你后面验收的标准。

先算账再动手:环境与硬件怎么核对

很多人估硬件只按参数量乘一个系数,结果装到一半发现爆显存。真实门槛是三块相加:权重本身占的显存、推理框架自己的开销、以及上下文长度带来的 KV 缓存增长。上下文开得越长,第三块涨得越凶,而它往往被忽略。

  • 权重占用:按精度档位估算,精度越低占用越小,但效果可能变化,先想清楚能不能接受
  • 框架开销:不同推理框架的额外占用差别明显,选之前去站内模型页看对应的部署说明
  • KV 缓存:跟着上下文长度和并发数走,这是最容易把「刚好够」变成「不够」的一项
  • 别只按参数量拍脑袋,三项相加才是真实门槛

动手前先做一次部署测算,再去对加速卡规格、看几张卡够用,把结论抄下来当验收标准。软件侧要确认驱动、显卡计算平台版本和推理框架要求是否对得上,版本错配是装完起不来的头号原因。

核对项看哪里抄什么结论
硬件够不够站内部署测算页最低卡数、推荐卡数
卡型规格站内加速卡规格页显存、互联方式、支持精度
成本取舍站内整体成本页自建还是租卡更划算
验收标准上面三处汇总达到什么状态算跑通

选部署方式:三种走法各自适合谁

选哪条路,不该看哪个框架流行,而要先回答三个问题:谁调用它、并发大概多少、要不要计费。这三个答案基本就决定了走法。

单机直跑
装好框架直接加载权重,最快,适合验证和个人使用;并发和稳定性得自己兜
容器化部署
把依赖和权重挂载关系写进配置,换机器只改路径不重装,适合要复现要迁移的场景
带网关部署
前面加一层转发统一做鉴权、限流和日志,模型进程不直接暴露,适合对外提供服务

如果你后面还要对接多个上游或者做统一转发,选型时顺手把网关那层的能力一起考虑进去,能少一次返工。

装之前先固定两件事

  • 固定权重存放路径和读写权限,别装到一半才发现进程没权限读
  • 固定服务监听的地址和端口,提前确认这个端口没被别的服务占着
  • 固定一份依赖清单,把驱动与框架版本写进去,方便下次复现

按顺序装起来:从依赖到服务起来

顺序建议固定下来,别跳步。跳过任何一步,后面报错都会伪装成别的问题,查起来很费时间。

  1. 装驱动与运行时按显卡厂商文档装好驱动和计算平台,装完用一条查询命令确认版本能被识别
  2. 装推理框架用官方推荐的安装方式,装完跑一次版本查询,确认框架能认到显卡
  3. 下载并校验权重权重下完先做完整性校验,半截文件导致的加载失败最难查
  4. 设启动参数重点盯四项:显存占用比例、最大上下文长度、并行路数、显存不足时的降级策略
  5. 确认监听地址起服务后看清它监听的是哪个地址和端口,本地测试和生产对外地址常常不是一回事
# 起服务后用最小请求验证一次,具体字段按你的框架文档调整
curl -s http://127.0.0.1:<port>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"hi"}]}'

注意,上面的地址和端口换成你自己配的。如果这一步返回结构不对,先别接业务,回头查请求格式和服务监听地址。

验证、日志与并发:上线前必做的三件事

连通验证要分三层做:进程活着、端口能连、一次请求有正常返回。很多人看到进程在跑就以为服务可用,实际上端口可能压根没起来,或者请求进来直接报错。

层次怎么验证不通过时先查
进程看进程列表和启动日志依赖是否装全、权重路径对不对
端口从另一台机器连一次端口监听地址、防火墙、端口占用
请求发一次最小请求看返回请求格式、鉴权、超时设置

日志至少记四样:请求耗时、输入输出长度、是否命中降级、失败原因。少了这几样,出问题只能靠猜。并发不要一次放开,从小批量开始逐步加压,看显存和延迟的曲线拐点,拐点位置就是你的实际上限。

上线前先量一次基线延迟,后面所有「变慢了」的判断都拿这次当参照。到站内测速页面跑一次,把结果存下来。

起不来、跑不动时的排查顺序

报错信息往往指向的不是根因,按固定顺序查比逐条试错快得多。

  • 先看依赖版本报错,版本对不上后面全是白搭
  • 再查权重路径与文件权限,路径错或没权限会伪装成框架报错
  • 然后看显存是否不足,优先降上下文或降并行数,而不是立刻加卡
  • 接着确认端口是否被占用或被防火墙挡
  • 最后核对请求格式,字段名和结构错也会表现为「没响应」
很多所谓「装不下」,其实是参数没调,不是硬件不够。
下一步把本地服务跟官方和中转渠道的实际表现比一比,再决定生产环境走哪条路。站内价格追踪页有你关心的实时数字,对照着看更省事。

常见问题

本地部署 DeepSeek-V3 到底要什么显卡配置?

没有一句话答案,因为需求取决于上下文长度、并发路数和量化方式。正确做法是先到站内 /models/deploy 做部署测算,再结合 /compute/gpus 的加速卡规格和 /compute/sizing 的按模型估算,得出你这套用法下的实际门槛,别照抄别人的配置单。

部署好了,怎么确认服务真的能用?

分三层验:进程在不在、端口通不通、一次真实请求有没有正常返回。前两层通过不代表第三层没问题,最好用一段最小请求跑通并检查返回结构。延迟基线可以去 /tools/speed-test 量一次,作为以后判断是否变慢的参照。

本地部署和直接调 API 相比,什么时候选哪个?

看你是否必须把数据留在自己机器上、是否需要断网可用、以及调用量是否稳定到能摊平硬件成本。数据敏感、要求离线、长期高频这三条里占了两条以上再考虑自建;否则 API 更省事。取舍口径可以先看 /api-vs-self-host-decision-2。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。