你可能已经拿到模型权重,也可能只想先在一台机器上把它跑通看看效果,结果卡在「显存要多少、用哪个推理框架、装完怎么确认服务真的起来了」这几步上。这篇不讲原理,只给一条从环境准备到连通验证的顺序:先算硬件账,再选部署方式,然后装依赖、起服务、发一次请求确认,最后补上日志和并发这两件上线前必做的事。数字类的规格和租金,统一去站内对应页面看当时的。
你手上可能已经有模型权重,也可能只是想先在一台机器上把它跑通看看效果。真正卡住人的通常不是模型本身,而是三件事:显存到底要多少、用哪个推理框架、装完怎么确认服务真的起来了。这篇只给一条顺序:先算硬件账,再选部署方式,然后装依赖、起服务、发一次请求确认,最后补上日志和并发。
注意,凡是规格、租金、延迟这类会变的数字,都不在本文里写死,统一去站内对应页面看当时的。你抄下来的那份结论,就是你后面验收的标准。
先算账再动手:环境与硬件怎么核对
很多人估硬件只按参数量乘一个系数,结果装到一半发现爆显存。真实门槛是三块相加:权重本身占的显存、推理框架自己的开销、以及上下文长度带来的 KV 缓存增长。上下文开得越长,第三块涨得越凶,而它往往被忽略。
- 权重占用:按精度档位估算,精度越低占用越小,但效果可能变化,先想清楚能不能接受
- 框架开销:不同推理框架的额外占用差别明显,选之前去站内模型页看对应的部署说明
- KV 缓存:跟着上下文长度和并发数走,这是最容易把「刚好够」变成「不够」的一项
- 别只按参数量拍脑袋,三项相加才是真实门槛
动手前先做一次部署测算,再去对加速卡规格、看几张卡够用,把结论抄下来当验收标准。软件侧要确认驱动、显卡计算平台版本和推理框架要求是否对得上,版本错配是装完起不来的头号原因。
| 核对项 | 看哪里 | 抄什么结论 |
|---|---|---|
| 硬件够不够 | 站内部署测算页 | 最低卡数、推荐卡数 |
| 卡型规格 | 站内加速卡规格页 | 显存、互联方式、支持精度 |
| 成本取舍 | 站内整体成本页 | 自建还是租卡更划算 |
| 验收标准 | 上面三处汇总 | 达到什么状态算跑通 |
选部署方式:三种走法各自适合谁
选哪条路,不该看哪个框架流行,而要先回答三个问题:谁调用它、并发大概多少、要不要计费。这三个答案基本就决定了走法。
- 单机直跑
- 装好框架直接加载权重,最快,适合验证和个人使用;并发和稳定性得自己兜
- 容器化部署
- 把依赖和权重挂载关系写进配置,换机器只改路径不重装,适合要复现要迁移的场景
- 带网关部署
- 前面加一层转发统一做鉴权、限流和日志,模型进程不直接暴露,适合对外提供服务
如果你后面还要对接多个上游或者做统一转发,选型时顺手把网关那层的能力一起考虑进去,能少一次返工。
装之前先固定两件事
- 固定权重存放路径和读写权限,别装到一半才发现进程没权限读
- 固定服务监听的地址和端口,提前确认这个端口没被别的服务占着
- 固定一份依赖清单,把驱动与框架版本写进去,方便下次复现
按顺序装起来:从依赖到服务起来
顺序建议固定下来,别跳步。跳过任何一步,后面报错都会伪装成别的问题,查起来很费时间。
- 装驱动与运行时按显卡厂商文档装好驱动和计算平台,装完用一条查询命令确认版本能被识别
- 装推理框架用官方推荐的安装方式,装完跑一次版本查询,确认框架能认到显卡
- 下载并校验权重权重下完先做完整性校验,半截文件导致的加载失败最难查
- 设启动参数重点盯四项:显存占用比例、最大上下文长度、并行路数、显存不足时的降级策略
- 确认监听地址起服务后看清它监听的是哪个地址和端口,本地测试和生产对外地址常常不是一回事
# 起服务后用最小请求验证一次,具体字段按你的框架文档调整
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。