How a global fintech scaled coding agent traffic with Dedicated Model Inference
TL;DR · AI 摘要
Title: How a global fintech scaled coding agent traffic with Dedicated Model Inference URL Source: Published Time: 2026-...
核心要点
- 主题聚焦：How a global fintech scaled coding agent traffic
- 来源：Together AI Blog，建议结合原文判断细节。
- AI 分析暂不可用，本条为保底评分与摘要。
全球金融科技公司如何通过专用模型推理扩展代码代理流量
我们使用必要的 cookie 来使网站正常运行。经您同意后，我们可能还会使用非必要的 cookie 来提升用户体验并分析网站流量。点击“接受”即表示您同意我们的 cookie 使用方式（详见《Cookie 政策》）。您随时可通过点击“偏好设置”更改 cookie 设置。
偏好设置 接受
📈 GLM-5.3 与 GLM 5.3 Flash 在 DeepSWE 上的对比 →
🚀 DeepSeek V4 Pro 0813 与 GPT-5.6 Sol 在 DeepSWE 上的对比 →
⚡ Together GPU 集群现已提供按需 B200s →
[](https://www.together.ai/)
- 
- 
- 
- 
- 
Gemma 4 31B 
DeepSeek V4 Pro 
GLM-5.2 
kimi K2.7 Code 
gpt-oss-120B 模型库 浏览顶级开源模型](https://www.together.ai/models)
探索顶级开源模型
加速计算
- 
- 
开发环境
- 
存储
- 
- 
- 
- 
Gemma 4 31B-it FP8 GLM 5.1 FP4 gpt-oss-120b 
Qwen3.5 397B A17b 
Llama 4 Maverick 模型库 对顶级开源模型进行微调](https://www.together.ai/models)
- 
- 
特色论文
- 
- 
- 
- 
- 
资源
- 
- 
- 
- 
- 
公司
- 
- 
- 
*
- 
- 
- 
- 
- 
探索顶级开源模型
* 加速计算
- 
- 
开发环境
- 
存储
- 
*
- 
- 
- 
*
- 
- 
精选论文
*
- 
- 
- 
- 
- 
* 资源
- 
- 
- 
- 
- 
公司
- 
- 
- 
推理
发布于2026年9月18日
全球金融科技公司如何通过专用模型推理扩展代码代理流量
- 作者 Ankit Goyal
- 目录
摘要
A global fintech company runs its coding assistant on GLM 5.2 through Together's Dedicated Model Inference, handling traffic that spikes during engineering hours—something static capacity planning couldn't keep up with.
With DMI, the customer's engineers can scale endpoints, roll out models, and test changes themselves, without submitting tickets or waiting on Together. The result: infrastructure that keeps pace with the speed of the teams adopting it.
The workload
This customer delivers financial products to millions of users across dozens of markets, and growth shows no signs of slowing. Maintaining this pace is an engineering challenge above all else, and the company's engineers rely on AI coding agents to achieve it.
This places inference on the critical path of how quickly the company ships products, rather than being confined to any single customer-facing feature. The workload runs on GLM-5.2, a mixture-of-experts model designed for long-horizon coding and agentic work, hosted on Together. Traffic follows working hours: spiky, concentrated during engineering hours, and increasing each time another team integrates agents into its workflow.
The constraint: capacity planning couldn't keep up with adoption
Operational control
The customer turned to Together after using other inference providers for coding workloads, initially consolidating onto our earlier dedicated offering. While that solution worked, it wasn't designed for how this workload actually behaves. Coding-assistant traffic isn't steady—it's peak-load with relatively low TPS, concentrated during engineering hours, and marked by sharp bursts in concurrency and prompt size as more teams integrate agents into their daily workflows. This pattern is precisely why concurrency, not raw throughput, became the design priority when the workload moved to GLM-5.2.
Under the previous model, absorbing such bursts required someone to anticipate them. Teams ready to adopt agents into their workflows often waited for capacity rather than provisioning it themselves, and the customer's platform team handled coordination for all of them, filing requests and sizing clusters. While the team worked to plan ahead, planning became ineffective once adoption became unpredictable in both timing and scale. You can't forecast bursts driven by a hundred different engineering teams independently deciding to rely more heavily on their coding agents this week.
When capacity is provisioned based on yesterday's forecast and traffic is genuinely spiky, prefill capacity and KV cache headroom get exhausted precisely during the burst—when it matters most—resulting in exactly the kind of multi-minute request queuing that agentic coding workflows can't tolerate. Fixing this after the fact, versus giving the customer's own teams the ability to see load and scale ahead of it, is the difference between a coordination problem and an infrastructure one.
What the customer required: self-service, observability, concurrency
The customer set requirements for the Together team around autonomy, in addition to raw performance, and the workload's own shape makes clear why. The coding-assistant traffic runs at ISL p50/p90/p95 of roughly 81K/163K/178K tokens and RPS p50/p90/p95 of 3/6/7, a peak-load, relatively-low-TPS pattern where bursts in concurrency matter far more than raw tokens-per-second. That's the backdrop for what the customer asked of Together:
- 自助式配置：工程团队应能够自主创建自己的端点并部署流量，无需提交请求或等待平台团队处理。这与早期模式不同，早期模式下每个新团队的容量请求都需经过 Together 和客户平台团队的审批流程。
- 可观测性：使团队能够自主行动：通过编程方式获取使用和性能数据，使容量决策由使用这些数据的团队自主完成，而无需因缓存命中率下降等问题进入支持队列。
- 集中负载下的吞吐量和快速扩展：在工作时间高峰期间保持持续性能，而非仅在基准测试条件下运行。通过多副本配置运行数十个 B200 实例，上下文规模设定为 256K，专门用于保留并发容量余量。
- 模型灵活性：随着技术前沿推进，能够无缝切换模型而无需重新协商。例如，同一账户从 GLM 5.1 切换到 GLM 5.2 的实践，以及通过配置更新而非重新部署，实时调整缓存和负载均衡参数的案例。
**已上线功能：完整的端点控制、指标 API 和模型灵活性**
通过 API、UI 或 CLI 进行端点配置
专用模型推理功能完全暴露端点生命周期：创建、规模调整、扩展策略和配置变更。当客户迁移重构其 GLM 5.2 端点时，客户基础设施团队正是使用了这一功能，将端点从更多小副本转向更少大副本，保持总体资源占用不变，但调整了副本数量与每副本芯片数的比例。几天后，当该调整使预填充容量接近 100% 时，请求排队时间达到 1-3 分钟，解码吞吐量骤降至每秒约 5 个 token，修复方案并非新部署或联系 Together 重新提交请求，而是通过实时配置变更：将 DMI 默认的哈希感知缓存路由策略，替换为客户调优后的缓存会话感知路由策略，并扩大每个工作线程的最大并发请求数阈值。所有变更均在同一天完成，且零停机时间。
指标 API
通过程序访问端点使用和性能数据，是定位根本原因的关键。Together API 支持团队通过指标数据追踪一个耗时 192 秒的慢请求，发现其并非计算瓶颈，而是因其他请求产生的 2.3M-token 预填充待处理队列导致，而非自身 250K-token 的提示。这就是自助式可观测性的具体价值：客户团队自行诊断出排队问题而非容量问题，无需等待 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的客户体验团队将客户GLM 5.2端点迁移至DMI自助服务平台，使客户获得对扩展、自定义权重发布和蓝/绿测试的控制权，Together的解决方案架构师/高级解决方案架构师团队随时待命进行性能调优。
结果
更改配置或部署模型更新所需时间
在DMI之前，更改配置或增加容量需要通过Together进行：提交请求、规划集群、等待重新部署。每个希望采用代理的工程团队都需排队等待，导致客户平台团队最终代表整个组织进行协调。
在DMI上，整个流程已转移至客户内部：
- 扩展： 客户可直接调整容量，无需向Together提交工单。
- 自定义权重发布： 新模型版本无需重新部署周期即可上线。
- 蓝/绿测试： 客户可按照自身时间表，使用生产流量验证变更。
下一步：第二个工作负载和区域
部署不再只是一个端点，而是成为创新的载体。这一模式现在以流水线形式重复，而非一次性任务。客户团队已开始规划在新区域部署专用GLM 5.1节点，其规模基于真实生产工作负载。与原始代码助手不同，这是另一种工作负载形态：基于聊天风格的客户支持NLP工作负载，而非长期视角的智能体编码，但使用相同的基础设施和配置模式。