很多团队跑通了模型加载，就以为部署完了，结果内网一上线才发现：并发一上来就排队、流式输出中途断、显存不够只能降上下文、出问题查不到是哪个环节慢。这篇不讲怎么装驱动，只讲上线前该确认哪些事、按什么顺序做，以及哪些情况下本地部署根本不划算。
很多团队把模型权重拉下来、能吐出一段中文，就认为部署完成了。结果一到内网试运行才发现：三个人同时提问就开始排队、流式输出打到一半断了、显存不够只好把上下文砍短、出了故障谁都说不清是网络慢还是服务端慢。本地化部署的难点从来不是「装上」，而是「上线后扛得住、查得清、能升级」。
这篇按落地顺序走一遍：先定验收线，再算推理服务和显存的口径，然后补齐超时并发、降级日志、评测升级。中间会明确哪些情况本地部署根本不划算，省得团队花几周做完才发现方向错了。
先定验收线：什么样的部署才算能用
验收线不写出来，后面所有技术选型都是拍脑袋。先把需求拆成三类硬指标：单次响应时长能接受什么区间、同时在线大概多少人、允不允许排队。这三项业务方说不出个区间，就先别买卡，也别选推理框架，回去把需求问清楚再来。
- 跑通
- 能对一个问题返回一段通顺的话，仅此而已
- 可用
- 高峰时段不超时、断线能恢复、出错能定位到环节
- 把峰值并发、可接受的等待上限、每天调用量三件事写进一页纸，作为验收依据
- 明确离线边界：内网是完全断网还是能出网、权重和依赖怎么进来、以后升级走哪条通道
- 约定失败的定义：超时算失败还是降级返回也算成功，这个口径直接影响后面的监控指标
- 如果调用量很小、数据出网没有硬性合规要求，本地部署的维护成本通常高于直接用官方接口，先去 /api-vs-self-host-decision 把账算一遍
推理服务与显存口径：怎么估、怎么留余量
估显存最容易犯的错是只看模型权重大小。实际占用里，长上下文场景的 KV 缓存经常比权重更吃显存，所以要按「并发数 × 上下文长度」来估，而不是按权重文件大小估。并发翻倍和上下文翻倍，对显存的压力是叠加的。
| 变量 | 怎么影响显存 | 怎么定 |
|---|---|---|
| 并发数 | 每个活跃请求都要独立缓存 | 按峰值并发估，不按平均值 |
| 上下文长度 | 序列越长缓存越大 | 取业务里最长的那一档 |
| 量化精度 | 越低越省但要验证质量 | 先小范围试用再定 |
| 并行策略 | 切分方式不同占用不同 | 和框架配置一起算 |
量化版本能换来更大的并发或更长的上下文，但会带来输出质量波动，所以别直接全量切。正确做法是同一批测试样例跑量化前后对比，重点看格式稳定性有没有掉。具体口径可以去 /models/deploy 和 /compute/sizing 对照自己的场景，再拿 /compute/gpus 核对手头或计划采购的卡。
- 按峰值并发再上浮一档配置，不要按平均水平配
- 显存跑满时的典型表现是请求排队或直接失败，不是自动变慢，别指望它自己退化
- 把「最长上下文 + 最高并发」这个组合单独测一次，这是最容易崩的边界
超时、并发与队列：上线前必须定的三个数
离线部署的服务都在内网，网络层的风险比公网小，但不代表可以不给超时。超时要分三层设：连接超时、首字超时、整体超时。连接层可以设短，首字和整体要给足，因为首次加载和长上下文推理本身就慢，卡太紧会把正常请求也掐掉。
- 设超时三层连接、首字、整体分别给值，写进配置文件；用一个长问题实测首字耗时，确认阈值不误杀
- 限并发按服务端实测能力设上限，超出部分进队列；无上限放行会让所有请求一起变慢直到集体超时
- 定排队规则写明谁能插队、最大等待多久、超时后返回什么提示；这些直接决定用户感知
- 单测流式专门测断流与恢复，可参考 /streaming-output-troubleshoot 的排查思路作为固定检查项
并发和队列的处理思路可以参考 /qps-concurrency-limits-dev，核心是把「服务端能力」和「用户耐心」两个约束分开管：前者靠限流，后者靠排队提示。两者混在一起设，结果通常是该排队的直接报错。
降级路径与日志：出事时怎么兜
本地部署大概率会遇到服务重启、显卡异常、显存被打满这些情况，所以降级路径要提前设计，而不是等出事再想。建议分两级：本地服务不可用时切到备用实例或更小的模型，再不行切到缓存答案或人工。降级开关要能一键切换，并且可回滚。
| 日志字段 | 为什么必须记 |
|---|---|
| 请求 ID | 把一次调用串起来，跨服务排查 |
| 输入长度 | 判断是不是长上下文拖慢的 |
| 首字耗时 | 区分加载慢还是生成慢 |
| 总耗时与输出长度 | 算吞吐和单位成本 |
| 模型与版本 | 换版本前后对比的基准 |
监控盯三个信号就够起手：排队长度、首字耗时、失败率。其中排队长度是最早的预警指标——它一涨，说明容量已经贴近上限，接下来就是超时。日志字段建议一次记全，缺了首字耗时这一项，慢了贵了都复盘不了。
评测与升级：换版本之前先跑一遍
本地部署最容易被忽略的一环是评测。换权重、调参数、改量化之后，如果没有回归集，就只能靠感觉判断变好还是变坏。做法很简单：固定一批几十条真实业务问题，每次变更都跑一遍，记录通过率而不是印象。
- 评测分三块：答不答得对、格式稳不稳、速度和单位成本能不能接受
- 只看答案质量会漏掉后两块，而这两块恰恰是本地部署最容易退化的地方
- 回归集用真实业务问题，别用公开测试集，后者和你的场景差太远
- 把评测做成常设动作，参考 /tools/quality-monitor 与 /tools/quality-check 的做法
- 备份现状记录当前配置、权重标识和参数，确保能还原
- 旁路验证在旁路实例加载新版本，跑完整回归集
- 对比通过率三项指标都不明显退步才进入下一步
- 切流量留回滚小流量切换并保留回滚窗口，观察排队和失败率
这套流程的价值不在严谨，而在于把「换版本」从一次冒险变成一次可比较的操作。版本相关的具体数字和对照结果，到站内对应页面核对当时的记录即可。
常见问题
本地部署是不是就等于数据绝对安全？
不等于。数据不出内网只是其中一环，还要看日志里有没有落原文、缓存怎么存、运维人员有没有读取权限。如果日志把用户输入完整记下来，风险只是从网络搬到了数据库。建议把日志字段分等级，敏感字段只记长度和哈希。
单机能跑通，多人用就卡，先调哪里？
先看排队长度和显存占用，而不是先加卡。常见原因是并发上限设太松、上下文给太长、或者量化没开。把并发限制收紧一档、缩短默认上下文，多数情况下能立刻缓解；确实不够再考虑加卡或换更高吞吐的推理服务。
怎么判断该不该继续自建，还是切回接口调用？
看三件事：有没有硬性合规要求、日常调用量是否足以摊薄维护成本、团队里有没有人能长期负责这套服务。三项里合规是唯一硬门槛，其余两项都可以量化算账。具体口径先到 api接入和本地部署的区别（/api-vs-self-host-decision-2） 和 本地化部署需要多少钱（/deepseek-self-host-cost） 对照自己情况。
