编码助手流量不再排队等容量，金融科技公司自助调整推理负载

一家金融科技公司向全球数百万用户提供金融产品，覆盖数十个市场。工程师靠 AI 编程代理维持开发速度，模型推理因此落在发布关键路径上。负载跑在 GLM-5.2 上，由 Together 提供服务。这是为长时程编码和代理型工作设计的混合专家模型。

编码助手流量的形状可以用数字说明。输入序列长度（ISL）中位数约 81K token。90 分位约 163K，95 分位约 178K。每秒请求数（RPS）中位数只有 3，90 分位 6，95 分位 7。请求少而大。流量跟着工作日走，高峰集中在工程时段。每多一个团队把代理放进工作流，峰值就抬高一截。这种形态下，突发要靠余量扛，而余量不容易预知。

这家客户最初在其他推理提供商那里跑编码负载，后来整合到 Together 早期的一款专用产品上。旧模式靠人工预判容量：要消化一次突发，必须先有人看到它要来。团队把代理准备好，却常常停在“等容量”这一步。容量按昨天的预测布置，流量却按今天的速度增长。突发来临时，预填充容量和 KV 缓存余量在同一时刻耗尽，请求排队几分钟。几分钟的排队，对代理型编码工作流来说已经是事故。

Together 把控制权交到客户手里。DMI 的全称是 Dedicated Model Inference。这个平台覆盖完整的端点生命周期：创建、调整大小、扩展策略、配置更改。对前沿开源模型的自助访问和性能感知的配置也包含在内。客户这次提了四项要求。自助服务、自家团队能直接行动的观测、集中负载下的吞吐量与快速扩展、模型流动性。所谓流动性，就是能自由更换模型和权重、比较新旧版本。

在 DMI 之前，改配置或加容量都要经过 Together。流程是提交请求、定集群规模、等重新部署。现在客户直接调整容量，不需要开任何工单。Together 的客户成功团队把 GLM 5.2 端点搬上 DMI 平台。扩展、自定义权重发布、蓝绿测试的控制权都交到了客户手里。

控制权不久就经历了一次真实检验。基础设施团队通过 API/UI/CLI 对 GLM 5.2 端点做了一次重构。从更多小副本改为更少大副本。副本数与每副本芯片数的比例变了，总计算量不变。几天后，预填充容量接近 100%。请求排队 1 到 3 分钟，解码吞吐量掉到约每秒 5 个 token。根因靠指标 API 定位，端点使用和性能数据可以编程读取。一条耗时 192 秒的慢请求被端到端追踪后发现，它几乎整个时间都在排队。其他请求遗留下的 230 万 token 待处理预填充积压堵在前面。它自己的提示词只有 25 万 token。

修复是实时配置变更。恢复调好的缓存感知会话路由，替代 DMI 默认的按哈希缓存路由。同时放宽每个 worker 的最大并发请求数阈值。改动当天推送，零停机。

客户也主动决定不要什么。1M 上下文配置经过评估后被放弃。把上下文翻倍到 1M，会削减这种尖峰、低请求数负载真正依赖的并发余量。客户选择留在 256K/512K。生产端点最终以 256K 上下文、56 个 B200 运行，拆成 14 个副本。每个副本 4 个 B200。这个配置优先保并发，不追原始吞吐。

模型流动性随后也接受了检验。Together 的解决方案架构团队提前搭好专用的压测基础设施。它按客户真实使用模式制造负载。一个周末，客户项目负责人要求对 GLM 5.1 做并发测试。范围是 8 到 16 个 B200。Together 当天交付测试端点。GLM 5.1 通过测试进入生产。它被拆成两个按可访问性划分的专用端点，作为面向内部开发者的编码助手运行。这家客户已经在规划新区域的专用 GLM 5.1 节点，用来跑聊天式客户支持 NLP。同一个模型，开始承担另一种负载。