摘要
一家全球金融科技公司通过 Together 的专用模型推理（Dedicated Model Inference，DMI），在 GLM 5.2 上运行其编码助手，应对静态容量规划无法跟上的、集中在工程师工作时段的尖峰流量。
借助 DMI，客户的工程师可以自行扩缩端点、上线模型、测试变更，无需提工单，也无需等待 Together。结果是：基础设施的演进速度，与采用它的团队一样快。
工作负载
这家客户向数十个市场的数百万用户提供金融产品，增长丝毫没有放缓的迹象。要维持这样的节奏，首先是一个工程问题，而公司的工程师依靠 AI 编码智能体来解决它。
这使得推理位于公司交付速度的关键路径上，而不是某个面向客户的功能内部。该工作负载运行在 GLM-5.2 上，这是一款专为长程编码和智能体工作打造的混合专家（mixture-of-experts）模型，由 Together 提供服务。流量随工作日起伏：尖峰明显，集中在工程师工作时段，而且每当又有一个团队把智能体纳入其工作流，流量就会攀升。
约束：容量规划跟不上采用速度
运维控制权
该客户此前与其他推理服务商一起运行编码工作负载，之后来到 Together，起初整合到我们早期的专用产品上。那个产品可以用，但并不是为这种工作负载的实际行为而设计的。编码助手流量并不平稳；它是峰值型、TPS 相对较低的负载，集中在工程师工作时段，随着更多团队把智能体纳入日常工作流，并发数和提示词长度会出现陡峭的突发。正是这种形态，决定了工作负载迁移到 GLM-5.2 时，设计优先级是并发而不是原始吞吐量。
在早期模式下，要吸收这种突发，就得有人预见到它。准备把智能体纳入日常工作流的团队，往往是在等待容量，而不是自行配置容量，客户的平台团队要为每一个这样的团队承担协调工作，提交申请、规划集群规模。团队努力提前规划，但一旦采用的时机和规模都变得不可预测，规划就失效了。你无法预测这样的突发：它来自上百个工程团队各自独立决定本周更多地依赖其编码智能体。
当容量按昨天的预测配置，而流量确实呈尖峰状时，预填充（prefill）容量和 KV 缓存余量恰恰会在突发期间耗尽，而这正是最关键的时刻，由此产生了智能体编码工作流无法容忍的、长达数分钟的请求排队。事后去修复这个问题，与让客户自己的团队有能力查看负载并提前扩容相比，区别就在于一个是协调问题，一个是基础设施问题。
客户的要求：自助服务、可观测性、并发
除了原始性能，客户还向 Together 团队提出了围绕自主权的要求，而工作负载自身的形态说明了原因。编码助手流量的输入序列长度（ISL）p50/p90/p95 约为 81K/163K/178K 个词元，每秒请求数（RPS）p50/p90/p95 为 3/6/7，这是一种峰值型、TPS 相对较低的模式，其中并发突发远比每秒原始词元数重要。以此为背景，客户向 Together 提出了以下要求：
- 自助配置：工程团队应能自行搭建端点并把流量切上去，而无需提交申请或等待平台组，这与早期模式不同：在早期模式下，每个新团队的容量申请都要经过 Together，再经过客户的平台团队。
- 其团队可据以行动的可观测性：以编程方式获取使用量和性能数据，使容量决策可以由做决策的团队自己做出，而不必在缓存命中率之类的指标下降时，被送进支持队列。
- 集中负载下的吞吐量与快速扩容：在工作时段高峰期间保持持续的性能，而不是基准测试条件下的性能；在多副本配置中运行数十块 B200，上下文长度为 256K，专门为保留并发余量而设定规模。
- 模型灵活性：随着前沿推进，可以更换模型而无需重新谈判。这一点在实践中体现为同一账户下从 GLM 5.1 迁移到 GLM 5.2，以及对缓存和负载均衡参数所做的在线调优，这是通过配置更新而非重新部署完成的。
交付成果：完整的端点控制、指标 API 与模型灵活性
通过 API、UI 或 CLI 配置端点
专用模型推理开放了端点的完整生命周期：创建、规模设定、扩缩策略和配置变更。当一次迁移改变了其 GLM 5.2 端点的形态，转向更少、更大的副本，总体规模不变，只是副本数与每个副本所用芯片数的比例不同时，客户的基础设施团队用的正是这些能力。几天后，这一调整导致预填充容量接近 100%，请求排队一到三分钟，解码吞吐量骤降到每秒约 5 个词元，而修复方式不是新的部署，也不是回头给 Together 提工单。而是一次在线配置变更：恢复经过调优的缓存会话感知路由策略，取代 DMI 默认的按哈希缓存感知策略，并放宽每个 worker 的最大在途请求数（max-inflight-per-worker）阈值。所有这些改动当天推送，零停机。
指标 API
正是通过以编程方式访问端点的使用量和性能数据，才找到了根本原因。Together API 支持团队通过指标数据端到端追踪了一个耗时 192 秒的慢请求，发现它并不受计算限制，而是几乎整个耗时都在排队，排在其他请求积压的 2.3M 词元待预填充队列之后，而不是它自己的 250K 词元提示词。这就是自助可观测性的具体价值：客户自己的团队诊断出的是排队问题，而不是容量问题，无需等待 Together 去拉取日志。
快速获取丰富的模型库
专用模型推理让用户可以自助使用前沿开源模型，以及感知性能的配置，帮助客户在 TTFT、TPS、TPM 等指标的任意组合之间做出选择。随着其编码智能体使用方式的演变，客户团队与 Together 的前线部署工程师（forward-deployed engineers）密切合作，持续优化这些配置。
这体现在同一账户和端点模式下，从 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，生产端点开始以 256K 上下文在 56 块 B200（14 个副本，每个副本 4 块 B200）上运行它，优先考虑并发而非原始吞吐量，以匹配客户峰值型、TPS 相对较低的流量形态。
- 自助迁移到 DMI：Together 的客户体验（CX）团队将客户的 GLM 5.2 端点迁移到 DMI 自助平台，把扩缩、自定义权重上线和蓝绿测试的控制权交给客户，同时 Together 的 SA/FDE 团队随时待命，负责任何性能调优。
成果
修改配置或发布模型更新所需的时间
在使用 DMI 之前，修改配置或增加容量意味着要经过 Together：提交申请、规划集群规模、等待重新部署。每个想采用智能体的工程团队都会加入同一个队列，因此客户的平台团队最终要为整个组织代为协调。
在 DMI 上，整个流程转移到了内部：
- 扩缩：客户直接调整容量，无需向 Together 提工单。
- 自定义权重上线：新的模型版本无需经历重新部署周期即可上线。
- 蓝绿测试：客户按自己的时间表，用生产流量验证变更。
下一步：第二个工作负载与新区域
这次部署不再只是一个单一的端点，而是成了创新的平台。这种模式如今正以流水线的方式重复出现，而不是一次性的个案。客户团队已经在规划在新区域部署一个专用的 GLM 5.1 节点，并按真实的生产工作负载来确定规模。这是一种与最初的编码助手不同形态的工作负载：它是对话式的客户支持 NLP 工作负载，而不是长程智能体编码，但落在同样的基础设施和配置模式上。