国内直连 DeepSeek 时，常见的卡点不是模型不行，而是延迟抖动、并发一提就 429、重试反而更慢更贵。这篇不承诺某个数字，只给一套可执行的思路：怎么量基线、怎么设并发与退避、怎么在不换业务代码的前提下准备备选通道，以及去哪几页核对当时的价格与限速口径。
国内直连 DeepSeek 的时候，最常见的抱怨其实不是「答得不好」，而是「一会儿快一会儿慢」「并发刚提上去就一堆报错」「加了重试反而整体更慢、账单还涨了」。这三个现象基本都不是模型本身的问题，而是链路和接入方式的问题。
这篇不给你任何承诺性的数字，只给一套可执行的动作：先量基线，再找并发拐点，然后给重试加上退避和上限，最后准备一条能切过去的备用通道。价格和限速口径这类会变的东西，一律去站内页面核对当时的数字。
先判断值不值得上中转：什么样的情况直连就够
很多人一遇到慢就想到中转，其实第一步应该反过来问：我现在的场景到底需不需要中转。中转不是免费的午餐，它多了一跳、多了一个可能出问题的环节，还会把「问题出在哪」变得更难定位。先看清楚症状属于哪一类，再决定要不要上。
- 先分清症状：如果只是首字慢但整段输出稳定，多半是链路或排队问题；如果是偶发超时、时好时坏，更像跨境链路抖动；如果是持续报错，那可能是额度或参数问题，中转也救不了。
- 调用量很小、对延迟不敏感、或者就是单机串行跑批的场景，中转基本没必要。这时候上中转，你只是多养了一层要维护的东西。
- 真正值得上中转的情况：团队分布在多个地域要统一出口、需要多条来源随时切换、需要按小组分摊和统计额度、或者希望把接入细节和业务代码解耦。
- 动手之前，先到站内工具页量一次自己的延迟基线，比如 /tools/speed-test 这类入口。没有基线，你后面根本没法判断加速到底有没有效果。
动手之前先量基线：把「慢」和「贵」拆成可测的指标
做优化最怕的就是没有基线。你今天觉得快、明天觉得慢，其实只是换了时段或者换了输入长度，根本没法比较。所以先把要测的东西固定下来：测什么、怎么测、记什么。
| 指标 | 怎么测 | 观察什么 |
|---|---|---|
| 首字时间 | 同一段提示词，多次调用取分布 | 反映链路和排队，波动大说明链路不稳 |
| 整体完成时间 | 固定输出长度，记录总耗时 | 反映吞吐，和首字分开看才不误判 |
| 单位时间成功请求数 | 逐步加压，记录成功率变化 | 用来找并发拐点，不是越高越好 |
| 失败类型分布 | 按状态码和错误信息分类统计 | 区分限流、超时、参数错误，改法完全不同 |
测法要固定：同一段提示词、同一输出长度、尽量在同一时段，至少跑几轮再下结论。单次结果什么都说明不了。日常排查建议自己维护一张表，记录请求时间、状态码、耗时、输入输出规模这几项，出问题时才有据可查。
- 首字时间和整体时间必须分开记录，混在一起看会把链路问题当成模型问题。
- 把测试用例固定下来存成文件，不要每次临时想一段提示词，那样没法对比。
- 记录里一定要有输入和输出的规模，否则你分不清是变慢了还是这次本来就更长。
- 测速结果留给站内工具页，日常的趋势跟踪靠自己那张表。
并发不是越大越快：先找出你自己的拐点
很多人调优的第一反应是把并发拉满，结果成功率崩了、平均耗时还涨了。原因是每个接入路径都有一个拐点，过了这个点，请求开始互相抢资源，整体反而更慢。你要找的是自己那条路径的拐点，而不是别人嘴里的推荐值。
- 从低并发起步先设一个明显偏低的并发数，跑固定用例，记录成功率和平均耗时作为基准。
- 每次只加一档逐步上调并发，每档跑同样轮数。一旦成功率开始明显下滑或平均耗时跳升，拐点就在这附近。
- 确认瓶颈在哪区分是上游限流（表现为限流类错误集中出现）还是本地连接池、线程池不够（表现为本地超时、连接堆积）。两者症状像，但一个要降并发，一个要先扩本地资源。
- 写进配置把确定下来的并发数做成配置项而不是写死在代码里，后续才好按任务类型分别设定。
- 交互式请求要留余量，用户体验优先，别把并发压到拐点上。
- 离线批处理可以更激进，但一定要有排队机制，而不是一次性全发出去。
- 不同任务类型用不同并发，一刀切往往会牺牲掉其中一类。
- 每次调整只改一个变量，否则你不知道是哪一项起了作用。
重试要带退避和上限：否则一次抖动会变成一次账单事故
重试本身没错，错的是无脑重试。上游一抖动，如果所有客户端都立刻重试，等于把一次小抖动放大成一次流量洪峰，最后大家都失败，钱还花了。
- 只重试值得重试的错误：超时、连接失败、限流类值得重试；参数错误、鉴权失败这类重试多少次都是白花。
- 退避策略用指数加随机抖动，并且给总时长设一个硬上限，超过就直接失败返回，不要无限等。
- 重试次数单独计数并打日志。不然你看到请求量涨，根本分不清是业务变多了还是一直在重试。
- 重试是实打实的成本项。重试之前先问一句：这一次重试的预期收益是什么，值不值。
多通道与降级：中转的真正价值在切换，不在单价
很多人选中转只看单价，其实中转最值钱的地方是「主路径出问题时能切走」。但要记住，切换本身也有成本，频繁切换会让问题更难定位，所以策略要提前写清楚。
| 场景 | 建议动作 | 注意点 |
|---|---|---|
| 主路径超时或限流 | 按设定的错误类型切到备选 | 别对所有错误都切，参数错误切了也没用 |
| 备选也失败 | 快速失败并告警，不要反复来回切 | 避免两个通道互相拖垮 |
| 非关键任务 | 可降级到更小模型或更短输出 | 提前约定好降级后的结果可接受 |
| 关键任务 | 宁可排队等待，不轻易降级 | 质量优先，别为了速度牺牲结果 |
切换前后的输出要能对得上。建议固定几条回归用例，切换通道后跑一遍，确认格式和内容没有悄悄变化。否则你以为只是换了个通道，实际上业务下游已经在报解析错误了。
低成本不等于低单价：先找钱的流向再谈省钱
一谈降本，大部分人的第一反应是找一个单价更低的来源。但实际账单一拆开，往往发现问题不在单价，而在浪费。先把成本拆成几块看清楚，再决定省哪里。
- 输入侧消耗
- 上下文里的无关内容、重复的前缀，都是在为没用的信息付费。
- 输出侧消耗
- 输出越长越贵，很多场景其实不需要那么长的回答。
- 重试浪费
- 无脑重试和失败请求也会产生消耗，这部分最容易被忽略。
- 缓存命中
- 能命中缓存的重复请求，成本差别很大，值得专门设计。
- 能压的地方：缩短无关上下文、减少重复前缀、把批处理挪到不着急的时段慢慢跑。
- 不要省的地方：失败重试的日志、质量校验的用例。这两块省掉之后，后面出问题的代价更高。
- 单价和限速口径随时会变，具体数字别记在脑子里，到站内比价入口核对当时的口径。
- 做优化前后都要记录单位任务的消耗量，否则你无法证明省钱到底省下来了没有。
落地清单：一周内能做完的接入与压测动作
- 第一天：固定测试用例与指标表选几段有代表性的提示词，固定输出长度，把要记录的字段列成一张表。
- 第二天：跑基线在当前直连状态下跑若干轮，记录首字时间、整体耗时、成功率和错误分布。
- 第三天：接一条备选通道做对照用同样的用例跑备选路径，和基线对比，重点是稳定性和错误类型，而不是谁快一点点。
- 第四到五天：调并发、退避和超时按前面找到的拐点设置并发，重试加上退避和上限，超时按任务类型分别设置。
- 第六天：跑真实批量任务用真实业务跑一轮，看总消耗和总耗时，验证前面的参数在真实负载下成立。
- 第七天：写进配置与文档把所有参数落到配置文件并写清为什么这么设，让团队里下一个人照着也能跑起来。
每一步都留记录。不然过两周出问题，大家又要从头猜一遍当初为什么这么配。
上线之后：怎么知道哪天开始变差了
接入做完不算结束，真正麻烦的是「不知道从哪天开始变差了」。所以要盯的是趋势，而不是某一次结果的好坏。
- 盯三个趋势：成功率、耗时分布、单位任务的消耗量。单次快慢没什么参考价值。
- 出现变化先做对照测试，排除是本地方案改了还是上游变了，不然容易改错方向。
- 把变更记录和指标放在一起看，绝大多数「突然变差」都能对应到某一次具体的改动。
- 留一份回退方案，明确回退到哪条路径、由谁来拍板，别等出事了再临时讨论。
中转省下来的不该只是单价，更该是「出问题时你还睡得着」这件事。
常见问题
走中转一定比直连快吗？
不一定。中转多一跳，如果中转节点本身慢或者与你之间链路差，反而更慢。它的主要价值在出口稳定、多源切换和统一管理。建议先用站内测速页量出直连基线，再接一条中转做同期对照，用数据决定，而不是听别人说快。
并发开到多少合适？
没有通用答案，取决于你的账号档位、上游限流口径和本机资源。做法是从低并发往上逐档加，观察成功率和耗时的变化，找到开始恶化的那个点，然后留出余量。把并发做成可配置项，按任务类型分开设，别写死在代码里。
重试是不是开得越多越稳？
不是。无上限重试会把一次上游抖动放大成大量重复请求，既拖慢整体又增加消耗。正确做法是只对超时、连接失败和限流类错误重试，配合指数退避加随机抖动，并设总时长上限。重试次数要单独打日志，否则你分不清是业务量大还是一直在重试。
想省钱，应该先砍哪一块？
先砍无效上下文和重复前缀，这两块通常占比最高且不影响结果质量。其次是重试浪费和低价值任务的模型档位。不建议砍日志和质量校验，那部分省下的钱通常会以更难排查的问题还回来。具体单价口径到站内比价入口看当时的数字。
换了通道之后输出格式变了怎么办？
准备一组固定用例，覆盖你最依赖的输出结构和边界情况，切换前后各跑一遍对比。发现差异先别急着改业务代码，先确认是新通道的默认参数、兼容层还是模型差异导致的。有回归用例，切换才敢做。
