代码补全场景选型：为什么延迟比倍率更重要
编辑器里的补全延迟每增加 300 毫秒，你就会被从心流里打断一次。本文说明这类场景为什么应该优先看延迟、怎么看，以及成本该怎么控制。
补全场景的特殊性
代码补全和「提问-回答」式使用完全不同：
| 对话式 | 补全式 | |
|---|---|---|
| 单次请求 | 大（几千 token） | 小（几百 token） |
| 频率 | 低（几分钟一次） | 高（每分钟数次） |
| 延迟敏感度 | 一般 | 极高 |
| 上下文 | 完整对话 | 文件片段 |
高频 + 低延迟敏感，这两个特征决定了选择标准。
延迟为什么比钱重要
人的交互窗口大约在 200-500 毫秒。补全结果超过 500 毫秒才出现，你就会不自觉地转移注意力。
一旦被打断，重新进入状态需要十几秒。所以延迟的代价不是「等了半秒」，而是「效率下降」。
换算一下：如果补全延迟从 300ms 升到 1200ms，一天被打断几百次，损失的时间远超省下的 API 费用。
该看什么延迟指标
不要看「平均延迟」，要看首字节时间（TTFB）。
原因：补全的体验取决于第一个字符多快出现。一个站可能总耗时 2 秒但首字节 200ms（流式），另一个总耗时 1.5 秒但首字节 1.5 秒（缓冲整包）。后者体感差得多。
测法：用 curl -N 加 stream:true 发一个请求，看拿到第一块数据的时间。
成本怎么控制
补全场景的 token 量看着小，但频率极高，总量可能很大。
三个手段：
一、按任务分层用模型。
行内补全（几个词） → 最便宜的模型
函数级生成 → 中等模型
跨文件重构 → 强模型（手动触发）全用强模型做补全，成本会高到离谱，而且更慢。
二、控制上下文长度。 补全不需要整份文件，把上下文限制在光标附近的一段，能显著降低 token 量，也降低延迟。
三、依赖缓存。 同一个文件的多次补全请求，上下文重复度极高。编辑器场景里，缓存的价值比任何场景都大。
选站的优先级
1. 首字节延迟低 ← 影响每一次输入体验
2. 支持 prompt caching ← 影响成本，可差数倍
3. 协议兼容编辑器工具 ← 不兼容直接不能用
4. 并发上限够高 ← 编辑器会并发请求
5. 倍率 ← 影响有限，且常被 2、3 项抵消一个实用配置
把编辑器场景和业务场景分开用不同的站：
- 编辑器：选低延迟、支持缓存的站（对价格不敏感，对体验敏感）
- 业务：选成本低、稳定性好的站（对延迟不敏感）
两类流量特征相反，混在一起会互相干扰 —— 编辑器的突发请求可能触发风控，影响业务。
相关阅读
- Cursor 与 Cline 使用中转站的配置要点
- prompt caching 在中转站上到底生效吗
- 中转站的「响应延迟」该怎么看
这篇文章对你有帮助吗？如果你在实际使用中发现了文中没提到的情况，欢迎 提交纠错或补充，我们会核验后更新到正文里。
相关文章
顺着看下去：本站收录的部分中转站
本文没有指向特定模型系列，下面是本站收录站点中综合评分靠前的几家，供你顺着看下去。排序依据是评分与可用率，不构成推荐。