摘要
一家全球金融科技公司通过 Together 的专用模型推理（Dedicated Model Inference）在 GLM 5.2 上运行其编码助手，处理静态容量规划无法跟上的、集中在工程时段的高峰流量。
借助 DMI，该客户的工程师可以自行扩展端点、部署模型并测试变更，无需提交工单，也无需等待 Together。结果是：基础设施的扩展速度与采用它的团队一样快。
工作负载
该客户向数十个市场的数百万用户交付金融产品，增长丝毫没有放缓的迹象。维持这一速度首先是一个工程问题，而该公司的工程师依赖 AI 编码代理来完成。
这使得推理处于公司交付速度的关键路径上，而不是仅仅存在于某个面向客户的功能内部。该工作负载运行在 GLM-5.2 上——这是为长周期编码和代理式工作构建的混合专家模型，由 Together 提供服务。流量跟随工作日变化：呈尖峰状，集中在工程时段，并且每当另一个团队将代理引入其工作流时就会攀升。
约束：容量规划跟不上采用速度
运营控制
该客户在与其他推理提供商运行编码工作负载后来到 Together，并首先整合到我们早期的专用产品上。该产品可以运行，但并非针对此工作负载的实际行为方式而构建。编码助手的流量并不稳定；它是峰值负载且 TPS 相对较低，集中在工程时段，随着更多团队将代理投入日常工作流，并发量和提示大小会出现急剧爆发。这种形态正是为什么当工作负载迁移到 GLM-5.2 时，并发量而非原始吞吐量成为设计优先事项。
在早期模式下，吸收这种爆发意味着必须有人预见到它的到来。准备将代理投入日常工作流的团队往往要等待容量，而不是主动配置容量，而客户的平台团队为每一个这样的团队承担了协调工作，提交请求并确定集群规模。该团队努力提前规划，但一旦采用在时间和规模上都变得不可预测，规划就不再奏效。你无法预测由上百个不同的工程团队各自决定本周更依赖其编码代理所驱动的爆发。
当容量按昨天的预测进行配置，而流量确实是尖峰状时，预填充容量和 KV 缓存余量恰恰会在爆发期间耗尽——而这正是最关键的时刻——从而产生代理式编码工作流无法容忍的多分钟请求排队。事后修复这一点，与让客户自己的团队能够看到负载并提前扩展，是协调问题与基础设施问题之间的区别。
客户的要求：自助服务、可观测性、并发量
除了原始性能外，客户还围绕自主性向 Together 团队提出了要求，而工作负载自身的形态清楚地说明了原因。编码助手流量以约 81K/163K/178K token 的 ISL p50/p90/p95 和 3/6/7 的 RPS p50/p90/p95 运行，这是一种峰值负载、TPS 相对较低的模式，其中并发量的爆发远比原始每秒 token 数重要。这就是客户向 Together 提出要求的背景：
自助服务开通：工程团队应能够自行搭建端点并投入流量，无需提交请求或等待平台团队，这标志着从早期模式的转变——在早期模式中，每个新团队的容量请求都要经过 Together，然后由客户的平台团队依次处理。
团队可自主采取行动的可观测性：使用情况和性能数据可通过编程方式获取，因此容量决策可以由做出决策的团队负责，而不是在缓存命中率下降等问题出现时通过支持队列来路由。
集中负载下的吞吐量和快速扩展：在工作时间高峰期间保持持续性能，而非基准测试条件，在 256K 上下文中跨多副本配置运行数十个 B200，专门调整规模以保持并发余量。
模型流动性：随着前沿技术的发展，有空间更换模型而无需重新协商，实践中通过在同一账户上从 GLM 5.1 迁移到 GLM 5.2 来证明，此外还通过配置更新而非重新部署对缓存和负载均衡参数进行了实时调优。
交付内容：完整的端点控制、指标 API 和模型流动性
通过 API、UI 或 CLI 进行端点配置
专用模型推理暴露了完整的端点生命周期：创建、规模调整、扩展策略和配置更改。客户的基础设施团队正是使用了这一点，当一次迁移重塑了他们的 GLM 5.2 端点时，转向更少、更大的副本，总占用空间相同，但副本数量与每个副本芯片数量的比例不同。当这种重塑在几天后达到接近 100% 的预填充容量时，请求排队 1 到 3 分钟，解码吞吐量骤降至大约每秒 5 个令牌，修复方法不是新部署或向 Together 提交工单。而是一次实时配置更改：恢复调优后的缓存会话感知路由策略，替代 DMI 的默认基于哈希的缓存感知策略，并扩大每个工作线程的最大在途请求阈值。所有这些都在同一天推送，零停机时间。
指标 API
以编程方式访问端点使用情况和性能数据是找到根本原因的方法。Together API 支持团队通过指标数据端到端追踪了一个 192 秒的慢请求，发现它不是计算受限的，并且几乎整个时间跨度都排在其他请求的 230 万令牌待处理预填充积压之后，而不是它自己的 25 万令牌提示。这就是自助可观测性的具体价值：客户自己的团队诊断出的是排队问题，而不是容量问题，无需等待 Together 拉取日志。
快速访问丰富的模型库
专用模型推理为用户提供对前沿开源模型的自助访问，以及性能感知配置，帮助客户选择 TTFT、TPS、TPM 和其他指标的任意组合。客户的团队与 Together 的前沿部署工程师密切合作，随着其编码代理用途的发展，持续优化这些配置。
这体现为 GLM 5.1 到 GLM 5.2 以及上下文长度的迭代在同一账户和端点模式下切换，且不涉及重新协商。这也体现为客户团队自己做出的有意配置权衡：鉴于他们的流量特征，他们评估了 1M 上下文配置并拒绝了它，因为将上下文翻倍到 1M 会削减其峰值负载、低 TPS 工作负载实际依赖的并发余量。团队选择保持在 256K/512K。
时间线：从早期负载测试到规模化生产端点
编码助手关系早于 GLM 5.2 生产端点数月。Together 的解决方案架构团队已经构建了专用负载测试基础设施，模拟客户的实际使用模式，最初针对较早的 GLM 版本进行验证。
这些基础工作直接延续到 GLM 5.1。早期，客户的项目负责人在一个周末要求对 GLM 5.1 在 8 到 16 个 B200 上进行复选框式并发测试，明确针对编码用例，且不同于此前面向消费者、关注延迟的测试。Together 当天就完成了测试端点，GLM 5.1 通过了标准并进入生产：两个专用端点，按可访问性拆分，作为客户内部面向开发者的编码助手运行。
转向 GLM 5.2：客户将编码工作负载迁移到 GLM 5.2，生产端点开始在 56 个 B200（14 个副本 × 4 个 B200）上以 256K 上下文运行它，优先考虑并发而非原始吞吐量，以匹配客户的峰值负载、相对较低 TPS 的流量形态。自助迁移到 DMI：Together 的 CX 团队将客户的 GLM 5.2 端点迁移到 DMI 自助平台，将扩展、自定义权重发布和蓝绿测试的控制权交给客户，Together 的 SA/FDE 团队随时待命进行任何性能调优。
结果
更改配置或发布模型更新的时间
在 DMI 之前，更改配置或增加容量意味着通过 Together 进行：提交请求、确定集群规模、等待重新部署。每个想要采用代理的工程团队都会加入同一个队列，因此客户的平台团队最终代表整个组织进行协调。
在 DMI 上，整个流程转移到内部：
扩展：客户直接调整容量，无需向 Together 提交工单。自定义权重发布：新模型版本无需重新部署周期即可上线。蓝绿测试：客户按照自己的时间表针对生产流量验证更改。
下一步：第二个工作负载和区域
部署不再是一个单一端点，而开始成为创新的平台。这种模式现在正作为一条流水线重复，而不是一次性事件。客户团队已经在规划在新区域中建立一个专用 GLM 5.1 节点，并根据真实生产工作负载进行规模设定。这是一种与原始编码助手不同的工作负载形态：聊天式客户支持 NLP 工作负载，而非长周期代理编码，落在相同的基础设施和配置模式上。