Cách công ty Fintech toàn cầu tối ưu hóa AI lập trình GLM 5.2 với Together Dedicated Inference

Khối lượng công việc

Khách hàng này cung cấp các sản phẩm tài chính cho hàng triệu người dùng trên hàng chục thị trường, và sự tăng trưởng không có dấu hiệu chậm lại. Duy trì tốc độ đó trước hết là một bài toán kỹ thuật, và các kỹ sư của công ty dựa vào các AI coding agent để thực hiện điều này.

Điều đó đặt việc suy luận (inference) vào lộ trình quan trọng quyết định tốc độ phát hành sản phẩm của công ty, thay vì chỉ nằm trong một tính năng đơn lẻ hướng tới khách hàng. Khối lượng công việc này chạy trên GLM-5.2, mô hình mixture-of-experts được xây dựng cho các tác vụ lập trình dài hạn và công việc mang tính đại lý (agentic work), được phục vụ trên Together. Lưu lượng truy cập tuân theo ngày làm việc: tăng đột biến, tập trung vào giờ làm việc của kỹ sư và tăng lên mỗi khi một nhóm khác áp dụng các agent vào quy trình làm việc của họ.

Rào cản: lập kế hoạch năng lực không theo kịp tốc độ áp dụng

Kiểm soát vận hành

Khách hàng đã tìm đến Together sau khi chạy các khối lượng công việc lập trình với các nhà cung cấp dịch vụ suy luận khác, và ban đầu đã hợp nhất vào dịch vụ chuyên dụng (dedicated offering) trước đó của chúng tôi. Dịch vụ đó hoạt động hiệu quả nhưng không được xây dựng cho cách mà khối lượng công việc này thực sự vận hành. Lưu lượng truy cập của trợ lý lập trình không ổn định; đó là lưu lượng tải đỉnh và có TPS (giao dịch mỗi giây) tương đối thấp, tập trung vào giờ làm việc của kỹ sư, với các đợt bùng nổ mạnh về tính đồng thời (concurrency) và kích thước prompt khi ngày càng có nhiều nhóm đưa các agent vào quy trình làm việc hàng ngày của họ. Hình thái đó chính là lý do tại sao tính đồng thời, chứ không phải thông lượng thô (raw throughput), lại là ưu tiên thiết kế khi khối lượng công việc chuyển sang GLM-5.2.

Theo mô hình trước đây, việc hấp thụ kiểu bùng nổ đó đòi hỏi phải có người dự đoán trước. Các nhóm sẵn sàng đưa agent vào quy trình làm việc hàng ngày thường phải chờ đợi năng lực thay vì được cung cấp sẵn, và nhóm nền tảng của khách hàng phải đảm nhận việc điều phối cho từng nhóm một, gửi yêu cầu và định cỡ các cụm (cluster). Nhóm đã nỗ lực lập kế hoạch trước, nhưng việc lập kế hoạch không còn hiệu quả khi tốc độ áp dụng trở nên khó dự đoán cả về thời điểm lẫn quy mô. Bạn không thể dự báo một đợt bùng nổ được thúc đẩy bởi hàng trăm nhóm kỹ thuật khác nhau đang độc lập quyết định dựa dẫm nhiều hơn vào coding agent của họ trong tuần này.

Khi năng lực được cung cấp dựa trên dự báo của ngày hôm qua và lưu lượng truy cập thực sự tăng đột biến, năng lực tiền nạp (prefill capacity) và khoảng trống bộ nhớ đệm KV (KV cache headroom) sẽ bị cạn kiệt ngay trong đợt bùng nổ – thời điểm quan trọng nhất – tạo ra chính xác tình trạng xếp hàng yêu cầu kéo dài nhiều phút mà các quy trình lập trình agentic không thể chấp nhận được. Việc khắc phục sau khi sự việc đã xảy ra, thay vì trao cho các nhóm của chính khách hàng khả năng nhìn thấy tải và mở rộng quy mô trước khi nó xảy ra, chính là sự khác biệt giữa một vấn đề điều phối và một vấn đề cơ sở hạ tầng.

Những gì khách hàng yêu cầu: tự phục vụ, khả năng quan sát, tính đồng thời

Khách hàng đã đặt ra các yêu cầu cho đội ngũ Together về tính tự chủ, bên cạnh hiệu suất thô, và hình thái của chính khối lượng công việc đã làm rõ lý do tại sao. Lưu lượng truy cập của trợ lý lập trình chạy ở mức ISL p50/p90/p95 lần lượt là khoảng 81K/163K/178K token và RPS p50/p90/p95 là 3/6/7, một mô hình tải đỉnh với TPS tương đối thấp, nơi các đợt bùng nổ về tính đồng thời quan trọng hơn nhiều so với số token mỗi giây thô. Đó là bối cảnh cho những gì khách hàng yêu cầu ở Together:

Những gì đã được triển khai: kiểm soát endpoint toàn diện, API chỉ số và tính linh hoạt của mô hình

Cấu hình endpoint thông qua API, UI hoặc CLI

Dedicated Model Inference (DMI) cung cấp toàn bộ vòng đời của endpoint: tạo, định cỡ, chính sách mở rộng và thay đổi cấu hình. Nhóm cơ sở hạ tầng của khách hàng đã sử dụng chính xác điều này khi một quá trình di chuyển làm thay đổi endpoint GLM 5.2 của họ, chuyển sang ít bản sao (replica) hơn nhưng lớn hơn, với tổng dấu chân (footprint) không đổi nhưng tỷ lệ số bản sao trên mỗi chip khác nhau. Khi quá trình thay đổi hình thái đó đạt gần 100% năng lực tiền nạp vài ngày sau đó, với các yêu cầu xếp hàng từ một đến ba phút và thông lượng giải mã (decode throughput) giảm xuống còn khoảng 5 token mỗi giây, giải pháp không phải là một đợt triển khai mới hay một phiếu yêu cầu hỗ trợ gửi lại cho Together. Đó là một thay đổi cấu hình trực tiếp: khôi phục chính sách định tuyến nhận biết phiên bộ nhớ đệm (cache-session-aware) đã được tinh chỉnh thay cho chính sách mặc định nhận biết bộ nhớ đệm theo băm (cache-aware-by-hash) của DMI, và mở rộng ngưỡng max-inflight-per-worker. Tất cả đều được đẩy lên trong cùng ngày mà không có thời gian chết (zero downtime).

API chỉ số (Metrics API)

Truy cập theo lập trình vào dữ liệu sử dụng và hiệu suất của endpoint là cách tìm ra nguyên nhân gốc rễ. Bộ phận Hỗ trợ API của Together đã truy vết một yêu cầu chậm kéo dài 192 giây từ đầu đến cuối thông qua dữ liệu chỉ số và phát hiện ra rằng nó không bị giới hạn bởi tính toán, mà đã dành gần như toàn bộ thời gian chờ đợi phía sau một lượng backlog tiền nạp đang chờ xử lý 2,3 triệu token từ các yêu cầu khác, chứ không phải do chính prompt 250K token của nó. Đó là giá trị cụ thể của khả năng quan sát tự phục vụ: nhóm của chính khách hàng đã chẩn đoán được vấn đề xếp hàng, không phải vấn đề năng lực, mà không cần chờ Together lấy nhật ký (log).

Truy cập nhanh vào thư viện mô hình phong phú

Dedicated Model Inference cung cấp cho người dùng quyền truy cập tự phục vụ vào các mô hình mã nguồn mở tiên tiến, cũng như các cấu hình nhận biết hiệu suất để giúp khách hàng lựa chọn bất kỳ sự kết hợp nào giữa TTFT, TPS, TPM và các chỉ số khác. Nhóm của khách hàng làm việc chặt chẽ với các kỹ sư triển khai tại chỗ của Together để liên tục tối ưu hóa các cấu hình này khi việc sử dụng coding agent của họ phát triển.

Điều này thể hiện qua việc chuyển đổi từ GLM 5.1 sang GLM 5.2 và các lần lặp lại độ dài ngữ cảnh (context-length) trên cùng một tài khoản và mô hình endpoint, mà không cần đàm phán lại. Nó cũng thể hiện qua một sự đánh đổi cấu hình có chủ đích mà chính nhóm của khách hàng đã thực hiện: dựa trên hồ sơ lưu lượng truy cập của họ, họ đã đánh giá cấu hình ngữ cảnh 1M và từ chối nó, bởi vì việc tăng gấp đôi ngữ cảnh lên 1M sẽ làm giảm khoảng trống đồng thời mà khối lượng công việc tải đỉnh, TPS thấp của họ thực sự phụ thuộc vào. Nhóm đã chọn giữ ở mức 256K/512K thay vì tăng lên.

Dòng thời gian: từ các bài kiểm tra tải ban đầu đến endpoint sản xuất ở quy mô lớn

Mối quan hệ về trợ lý lập trình đã có từ vài tháng trước khi endpoint sản xuất GLM 5.2 ra đời. Nhóm Kiến trúc Giải pháp của Together đã xây dựng cơ sở hạ tầng kiểm tra tải chuyên dụng mô phỏng mô hình sử dụng thực tế của khách hàng, ban đầu được xác thực dựa trên một bản phát hành GLM trước đó.

Nền tảng đó được chuyển trực tiếp sang GLM 5.1. Ngay từ đầu, trưởng dự án của khách hàng đã yêu cầu vào một ngày cuối tuần về một bài kiểm tra tính đồng thời kiểu checkbox cho GLM 5.1 trên 8 đến 16 chip B200, dành riêng cho trường hợp sử dụng lập trình và khác biệt với các bài kiểm tra trước đây vốn tập trung vào người tiêu dùng và độ trễ. Together đã hoàn thành endpoint kiểm tra ngay trong ngày, và GLM 5.1 đã vượt qua tiêu chuẩn và chuyển sang sản xuất: hai endpoint chuyên dụng, được phân chia theo khả năng truy cập, chạy như trợ lý lập trình hướng tới nhà phát triển nội bộ của khách hàng.

Kết quả

Thời gian để thay đổi cấu hình hoặc cập nhật mô hình

Trước DMI, việc thay đổi cấu hình hoặc thêm năng lực đồng nghĩa với việc phải thông qua Together: gửi yêu cầu, định cỡ cụm, chờ triển khai lại. Mọi nhóm kỹ thuật muốn áp dụng các agent đều phải xếp vào cùng một hàng đợi đó, vì vậy nhóm nền tảng của khách hàng cuối cùng phải điều phối thay cho toàn bộ tổ chức.

Trên DMI, toàn bộ quy trình đó đã được chuyển vào nội bộ:

Tiếp theo là gì: khối lượng công việc thứ hai và khu vực mới

Việc triển khai không còn là một endpoint đơn lẻ mà đã trở thành một bề mặt cho sự đổi mới. Mô hình đó hiện đang lặp lại như một đường ống (pipeline), không phải là một lần duy nhất. Nhóm của khách hàng hiện đang lên kế hoạch cho một node GLM 5.1 chuyên dụng ở một khu vực mới, được định cỡ dựa trên khối lượng công việc sản xuất thực tế. Đó là một hình thái khối lượng công việc khác so với trợ lý lập trình ban đầu: một khối lượng công việc NLP hỗ trợ khách hàng kiểu trò chuyện thay vì lập trình agentic dài hạn, được triển khai trên cùng cơ sở hạ tầng và mô hình cung cấp.