先给结论：本周最值得后端团队关注的，不是又出了哪门新语言，而是AI推理带来的“词元级”流量正在改变IDC带宽模型。传统按请求数估算的微服务容量规划，正在被“每秒词元数+流式响应时长”打穿。以下5条清单，每条都配一个可执行建议。
1. 把“词元/秒”纳入API网关限流维度
近期多个团队反馈：同一个接口，请求数没涨，但响应体因流式输出变得极长，出口带宽先爆。建议本周就在网关层增加token速率限制，而不是只限QPS。可先用日志采样统计P95词元长度，再设阈值。
2. 重新算IDC机柜的“上行带宽账”
AI词元服务器往往下行小、上行大，尤其流式SSE。传统IDC按下行峰值卖带宽的套餐会吃亏。可执行动作：拉出近7天每台推理服务器的出向流量，按1.5倍冗余重新申请上行带宽，避免微服务间调用被误伤。
3. 网络软件层：给服务网格加“流式超时豁免”
Istio、Linkerd默认超时对长流式响应不友好，容易在词元还没吐完就断连。建议为AI相关路由单独配置stream idle timeout，并关闭对SSE的缓冲。本周就能在测试环境验证。
4. 微服务拆分别按“业务”拆，按“词元生命周期”拆
把提示词预处理、推理调度、后处理拆成独立服务，而不是塞进一个“AI服务”。这样带宽和CPU能分别扩缩。可执行：先画一张词元从进入到返回的调用链，标出每跳的字节放大倍数，>3倍的那一跳优先拆。
5. 监控加两个指标：首词元延迟和出口字节/词元
本周很多SRE群在讨论这两个指标。首词元延迟影响体验，出口字节/词元影响带宽成本。建议在现有Prometheus里加自定义指标，并设告警：当出口字节/词元周环比涨20%时，检查是否被恶意长提示词打爆。
一句话攻略：微服务架构本身没变，变的是流量单位。把“词元”当成新的容量单位，IDC带宽和网络软件配置才不会被动。
0 留言