一家全球金融科技公司如何用 Dedicated Model Inference 支撑编码智能体流量

工作负载

该客户向数十个市场的数百万用户交付金融产品，增长毫无放缓迹象。维持这一速度首先是一个工程问题，而公司的工程师们依靠 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，再轮到客户的平台团队。
其自身团队可据以行动的可观测性：使用情况和性能数据可通过编程方式获取，这样容量决策就可以由做出决策的团队掌握，而不是在缓存命中率下降之类的情况发生时被转到一个支持队列中。
集中负载下的吞吐量与快速扩展：在工作时间高峰期间保持持续性能，而非基准测试条件，以多副本配置运行数十块 B200，上下文长度为 256K，专门预留并发余量。
模型灵活性：随着前沿技术发展，有空间更换模型而无需重新协商，这在实际中得到了验证——同一账户从 GLM 5.1 迁移到 GLM 5.2，并且对缓存和负载均衡参数进行了实时调优，作为配置更新而非重新部署。

交付内容：完整的端点控制、指标 API 和模型灵活性

通过 API、UI 或 CLI 进行端点配置

专用模型推理暴露了完整的端点生命周期：创建、规模调整、扩展策略和配置变更。当一次迁移重塑了他们的 GLM 5.2 端点时，客户的基础设施团队正是使用了这一点，转向更少、更大的副本，总占用不变，但副本数与每副本芯片数的比例不同。几天后，当这种重塑达到接近 100% 的预填充容量时，请求排队一到三分钟，解码吞吐量骤降至约每秒 5 个 token，修复方法不是新部署或向 Together 提交工单。而是一次实时配置更改：恢复调优后的缓存会话感知路由策略，替代 DMI 默认的基于哈希的缓存感知策略，并扩大每个工作线程的最大在途请求阈值。所有这些都在当天推送，零停机。

指标 API

以编程方式访问端点使用情况和性能数据是找到根本原因的方式。Together API 支持团队通过指标数据端到端追踪了一个 192 秒的慢请求，发现它并非受计算限制，而是几乎整个时间跨度都排在其他请求造成的 230 万 token 待处理预填充积压之后，而非其自身的 25 万 token 提示。这就是自助可观测性的具体价值：客户自己的团队诊断出的是排队问题，而非容量问题，无需等待 Together 拉取日志。

快速访问丰富的模型库

专用模型推理为用户提供对前沿开源模型的自助访问，以及性能感知配置，帮助客户选择 TTFT、TPS、TPM 和其他指标的任意组合。客户的团队与 Together 的前沿部署工程师密切合作，随着其编码代理用例的发展不断优化这些配置。

这体现在 GLM 5.1 到 GLM 5.2 以及上下文长度的迭代在同一账户和端点模式上过渡，无需重新协商。这也体现在客户团队自己做出的有意配置权衡：鉴于他们的流量特征，他们评估了 100 万上下文的配置并拒绝了它，因为将上下文加倍到 100 万会削减其高峰负载、低 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 工作负载，而非长周期智能体编码，落在相同的基础设施和配置模式上。

‍