本地部署 deepseek 的 api

本地把 DeepSeek 跑起来只是第一步，真正难的是让手里的应用像调云端接口一样调它：路径怎么写、鉴权怎么加、多轮对话和流式怎么传、并发一上来就超时怎么办。这篇按「起服务—对接口—压一遍—排错」的顺序走一遍，只讲能动手做的动作。

本地把 DeepSeek 跑起来只是第一步，真正卡人的是让手里的应用像调云端接口一样调它：路径写什么、密钥怎么填、多轮对话谁负责拼、流式一开就报错、并发一上来全是超时。这篇按「起服务—对应用—压一遍—排错」的顺序走，只讲能动手做的动作。

先把判断标准放前面：如果你的应用本身支持自定义 base_url，改造量就小；如果它把接口地址写死，那要么换客户端要么在前面套一层适配。改造前先确认这一点，能省掉一半返工。

先把服务起成接口，再谈调用

选推理框架时先看它自带哪种 HTTP 接口，多数框架能直接给 OpenAI 兼容路径，这一步决定了后面应用要改多少代码。启动时固定四样：监听地址与端口、模型名别名、显存占用比例、最大上下文长度。先用短上下文跑通，再一点点往上加，别一上来就拉满。

1. 起服务指定模型路径、端口和显存占比启动，看日志里有没有出现监听地址那一行。
2. 验证存活本机用 curl 打一下健康检查或最简单的补全请求，确认端口是通的。
3. 确认别名用一条最简请求试探模型名该填什么，别名写错是最常见的 404 来源。
4. 放开访问只本机用就保持监听 127.0.0.1；要给局域网其他机器调，再改成 0.0.0.0，同时处理防火墙和鉴权，别先开后想。

让应用认这个地址：路径、密钥与流式

应用侧只要支持自定义 base_url，就能指向本地端口。密钥字段通常必填，但值可以随便填，除非你在网关层加了校验。多轮对话靠客户端自己拼消息数组，本地服务不记你的会话，别指望它帮你保存历史。

流式开关和超时时间要一起调。本地首 token 本来就慢，客户端默认超时往往撑不住，先把等待时间放宽再谈优化。不同编程工具的配置字段不一样，按你正在用的那个工具的配置页改，不要照搬另一个工具的写法。

压一遍：并发、显存与超时

压测别用混合流量。用短输入加固定输出的小脚本，从单并发往上加，记录每档的首 token 延迟和总耗时，找到延迟开始跳变的那一档，就是这台机器的实际可用并发。长请求和短请求要分开压，混在一起算出来的平均延迟没有参考价值。

• 显存被占满时，先降并发或降上下文长度，再考虑换量化档位，顺序反了会白折腾一轮
• 想估算一张卡能扛多少并发，按模型参数量和量化档位粗估显存占用，具体数字到 /models/deploy 按手上的卡对一遍
• 超时先分清楚是首 token 慢还是整体太慢，前者放宽等待，后者降并发
• 压测脚本固定随机种子和输入长度，否则两轮结果没法比

加一层壳：鉴权、日志与常见报错

对外暴露前建议前置一层反向代理或网关，加 token 校验、限流、请求日志，顺便把 HTTPS 也解决掉。裸端口直接开到公网等于把算力白送人，尤其是家里或办公室的机器。

排错按固定顺序走，别东一榔头西一棒子，顺序对了能少查一半。

1. 先看端口telnet 或 curl 打一下端口，不通就是服务没起或防火墙拦了。
2. 再看别名别名不对返回 404，对照启动日志里注册的模型名改。
3. 再看上下文输入超长会直接报错或截断，把请求长度压到上下文窗口以内。
4. 再看显存显存溢出通常是进程直接崩或卡住，看服务端日志里的显存报错。
5. 最后看客户端前面都正常还超时，就是客户端等待时间太短或流式解析有问题。

长期跑要留一份启动脚本和版本记录，换推理框架或换量化档位时才知道能回退到哪一版。至于该不该换更重型的推理服务，判断依据是并发和吞吐的实际表现，不是名字听起来够不够专业；跑出来的数字到 /tools/speed-test 记一笔，方便以后对比。