这一页讲什么
内联补全这类交互，四个事实：
- 请求体积：单次几 KB，带宽几乎不是变量
- 请求频率：每分钟几十次，随打字节奏波动
- 敏感项：时延抖动与丢包，不是峰值带宽
- 影响面：补全不出来时，多数人直接关掉功能
AI 工具 · IDE 与毫秒量级交互
GitHub Copilot 网络方案
这个工具的请求小到几乎不占带宽，但请求极其频繁 —— 每敲几个字符就发一次。它挑的不是带宽，是这条线有没有尖峰。
这里讲的是团队在使用海外 AI 工具时，网络这一层能改善什么：请求往返的时延、长会话的连续性、素材上传与产物下载的带宽。我们提供的企业跨境网络接入与线路优化，只是把这段网络变稳变快，不改变任何服务本身的可访问范围与使用规则；工具能否使用、怎么用，以服务商的条款与所在地法律法规为准。线路与节点以实际开通时的分配结果为准。
业务特点
这类工具失效，是「悄悄地失效」
它不会报错，只会让人慢慢不用。
补全偶尔不出现，以为是自己没触发
请求超时之后客户端不提示，表现就是「这次没有建议」。用的人会归因为工具不行，而不是网络。
平均 60 毫秒，偶尔跳到 800
平均值很好看，但每次尖峰都对应一次失败的补全。写代码是连续动作，一次打断就要重新进入状态。
全组十几个人挤一条出口
请求频率随人数线性增长，一条出口的排队与重传互相放大，越到下午大家都忙的时候越明显。
线路与能力
把尖峰压掉，而不是把均值再压低
这一项看的是分布尾部，不是平均值。
按抖动选线路，不按均值
连续测一段时间，看时延的尾部区间。两条线平均一样时，取尖峰更小的那条 —— 写代码时体感差别就在这儿。
先治丢包，再谈其它
丢包带来的是重传与以秒计的停顿，比时延慢几十毫秒严重得多。先把丢包压到很低，剩下的时延才值得优化。
按小组分出口
一组一条出口，负载可预期；全员一条出口时，任何一个人的大请求都会波及所有人。
适用场景
研发团队用得最深的场景
工具用得越顺手，越依赖这条线的稳定性。
常见问题
内联补全相关的常问几点
围绕为什么时好时坏、要不要加带宽、怎么分组。
补全时好时坏，怎么确认是网络？
同一时段对照测：一个持续的小请求（比如反复拉一个很小的页面）如果也偶发变慢，问题在链路；只有补全慢，要往账号与客户端看。
加带宽有用吗？
基本没用。这类请求的带宽占用可以忽略，卡的是时延与丢包。把预算花在降低抖动上，收益比加带宽大得多。
一定要每人一条线吗？
不需要。但一条出口上的人数和请求密度要有上限，人多了按小组分开就行 —— 分组比一人一条便宜，也够用。
可以先测试再决定吗？
可以先开通 3 天免费测试，用实际链路数据判断。测试期间按正式环境同样的方式接入，测完再决定要不要签。
