Đánh giá hiệu suất suy luận ở quy mô lớn: các tác nhân lập trình

Trên khối lượng công việc của tác nhân mã hóa sản xuất, Together Inference Engine mang lại hiệu suất TPS (giao dịch mỗi giây) cao hơn 31% so với công cụ OSS (mã nguồn mở) nhanh nhất tiếp theo trên cùng một phần cứng và duy trì TTFT (thời gian đến token đầu tiên) tốt hơn gấp 2 lần khi đạt đến điểm bão hòa. Những cải tiến này có được nhờ tối ưu hóa toàn diện: ThunderMLA, viết lại kernel tùy chỉnh và phân tích hiệu suất đầu cuối trên lưu lượng truy cập thực tế. Hầu hết các tiêu chuẩn suy luận đo lường một người dùng truy cập một điểm cuối chuyên dụng. Các con số trông rất ấn tượng. Tuy nhiên, chúng vô dụng khi lập luận về sản xuất. Trong môi trường sản xuất, hàng chục hoặc hàng trăm yêu cầu đồng thời được thực hiện. Chúng cạnh tranh để giành cùng một bộ nhớ đệm KV, cùng một băng thông bộ nhớ, cùng một chu kỳ GPU. Điều quan trọng là điều gì xảy ra với mỗi người dùng khi hệ thống chịu tải. Chúng tôi đã xây dựng tiêu chuẩn này để trả lời câu hỏi đó cho các tác nhân mã hóa. Đây là một khối lượng công việc tác động mạnh đến suy luận: đầu vào dài, độ đồng thời cao và không chấp nhận suy giảm độ trễ khi chịu tải. Đây là phiên bản đầu tiên. Chúng tôi sẽ cập nhật nó khi chúng tôi xây dựng. **Khối lượng công việc của tác nhân mã hóa trông như thế nào** Các yêu cầu của tác nhân mã hóa mang nhiều ngữ cảnh. Tệp đang được chỉnh sửa, mã xung quanh, lịch sử hội thoại, đoạn trích được truy xuất. Đầu vào dài. Đầu ra có ý nghĩa nhưng bị giới hạn; bạn đang tạo một hàm, không phải một bài luận. Thử thách khó khăn hơn là tính đồng thời. Nhiều người dùng truy cập điểm cuối đồng thời và các yêu cầu đó tương tác theo những cách mà các tiêu chuẩn người dùng đơn lẻ không bao giờ nắm bắt được. Khi lưu lượng truy cập tăng, bộ nhớ đệm KV đầy. Áp lực lập lịch tăng lên. Thông lượng trên mỗi người dùng giảm. Thời gian đến mã thông báo đầu tiên (TTFT) tăng. Đến một lúc nào đó, hệ thống ngừng hữu ích. Các công cụ khác nhau đạt đến điểm đó ở các mức lưu lượng truy cập rất khác nhau. Chúng tôi đã thiết kế một tiêu chuẩn lưu lượng truy cập cao để kiểm tra căng thẳng điều này, mô phỏng các phân phối yêu cầu mà chúng tôi thấy phục vụ lưu lượng tác nhân mã hóa sản xuất ở quy mô lớn. Độ dài lời nhắc dao động từ ~45k đến 200k mã thông báo, mô phỏng sự phát triển phiên mã hóa thực tế và độ dài tạo trung bình khoảng 450 mã thông báo. Các chỉ số chính là TPM (mã thông báo đầu vào mỗi phút), TPS (mã thông báo mỗi giây) trên mỗi người dùng và p50 TTFT. **Những gì suy luận phải làm đúng** Đối với các tác nhân mã hóa, TTFT là chỉ số quyết định liệu công cụ có cảm thấy nhanh hay bị hỏng. Một nhà phát triển gửi yêu cầu không thấy gì cho đến khi mã thông báo đầu tiên đến. Khoảng cách đó — giữa gửi và luồng — là nơi niềm tin được tạo dựng hoặc mất đi. Tốc độ đầu ra quan trọng, nhưng nó là thứ yếu: một khi các mã thông báo đang được truyền, trải nghiệm sẽ cảm thấy trôi chảy ngay cả ở tốc độ tạo vừa phải. Hạn chế thứ hai là tính đồng thời trong ngữ cảnh dài. Các yêu cầu của tác nhân mã hóa không chỉ dài — chúng dài và đồng thời. Hàng chục nhà phát triển truy cập cùng một điểm cuối cùng một lúc, mỗi người mang theo hơn 80k mã thông báo ngữ cảnh, tạo ra áp lực bộ nhớ đệm KV mà các tiêu chuẩn người dùng đơn lẻ không bao giờ thể hiện. Khi bộ nhớ đệm đầy, bộ lập lịch có ít không gian để điều động hơn. Độ trễ tiền nạp tăng. TTFT suy giảm. Ở lưu lượng truy cập đủ cao, hệ thống ngừng hữu ích trước khi nó chính thức thất bại. Hạn chế thứ ba là hình dạng đầu ra. Bạn đang tạo một hàm, không phải một bài luận. Độ dài tạo bị giới hạn — trung bình khoảng 450 mã thông báo — có nghĩa là thông lượng ở mức bão hòa trông khác ở đây so với trong các khối lượng công việc tóm tắt hoặc tạo tài liệu. Hệ thống không chịu áp lực giải mã liên tục; nó chịu áp lực tiền nạp liên tục, với các đợt giải mã ngắn thường xuyên. Các công cụ được tối ưu hóa cho các lần giải mã dài sẽ không nhất thiết giành chiến thắng ở đây. Ba hạn chế này — độ nhạy TTFT, tải ngữ cảnh dài đồng thời và hình dạng đầu ra nặng tiền nạp — là những gì tiêu chuẩn được thiết kế để kiểm tra. **Phương pháp luận** Phần cứng: 4× NVIDIA B200 trên mỗi công cụ (SGLang: 8× B200 — xem ghi chú bên dưới). Khối lượng công việc: Lời nhắc dài, độ đồng thời cao, biến động thực tế. Độ dài lời nhắc dao động từ ~45k đến 200k mã thông báo, mô phỏng sự phát triển phiên mã hóa thực tế. Độ dài tạo trung bình 450 mã thông báo (p50: 293, p99: 2.230). Độ khó tăng theo lưu lượng truy cập: ở QPS cao hơn, các lời nhắc dài hơn và bộ nhớ đệm KV ngày càng tăng tạo ra nhiều áp lực tiền điền hơn, nhiều ngữ cảnh hơn để duy trì và nhiều sự xáo trộn bộ nhớ đệm KV hơn khi số lượng phiên tăng lên. Giải mã suy đoán EAGLE: 3 mã thông báo nháp. Tỷ lệ chấp nhận (~70%) xuất hiện tự nhiên từ dữ liệu lời nhắc tổng hợp thực tế — chúng tôi không ép buộc. Cấu hình công cụ: TensorRT-LLM được điều chỉnh tốt cho khối lượng công việc này và đại diện cho một đường cơ sở mạnh mẽ. SGLang được cấu hình để phù hợp khi có thể; chúng tôi không chạy các thử nghiệm điều chỉnh toàn diện, vì vậy có thể có một chút cải thiện. Tất cả các công cụ được cấu hình cho độ trễ thấp. Điều này khác với cấu hình tối ưu hóa thông lượng, vốn sẽ tăng kích thước lô giải mã tối đa và sử dụng phân tách tiền điền-giải mã để đổi TPS đầu ra lấy TPM đầu vào cao hơn. Những gì chúng tôi đã tối ưu hóa Những cải tiến về hiệu suất của chúng tôi đến từ việc coi suy luận là một vấn đề toàn diện: lập hồ sơ từ đầu đến cuối, xác định các hoạt động tốn kém nhất và loại bỏ chúng từng bước một. ThunderMLA. Kimi K2.5 sử dụng kiến trúc Multi-head Latent Attention (MLA) của DeepSeek. Các triển khai tiêu chuẩn chạy hai lần khởi chạy kernel riêng biệt cho mỗi bước giải mã. ThunderMLA của chúng tôi — một phần của thư viện kernel ThunderKittens — hợp nhất chúng thành một megakernel duy nhất, loại bỏ chi phí khởi chạy và các hiệu ứng đuôi giữa chúng. Trên các khối lượng công việc giải mã điển hình, ThunderMLA nhanh hơn 20–35% so với FlashMLA của DeepSeek. Ngoài ThunderMLA, chúng tôi đã lập hồ sơ toàn bộ hệ thống — hành vi trình điều khiển, bố cục bộ nhớ, thực thi kernel — và loại bỏ mọi nút thắt mà chúng tôi tìm thấy. Một số yêu cầu thay đổi cấu hình. Những cái khác yêu cầu viết kernel từ đầu. Các kernel chúng tôi đã viết vượt trội hơn các kernel mã nguồn mở tương đương của TensorRT-LLM trên khối lượng công việc này. Đây là cách điều đó chuyển thành hệ thống đầy đủ khi chịu tải. Kết quả Chúng tôi đã so sánh Together Inference Engine với hai đường cơ sở trên Kimi K2.5 với giải mã suy đoán EAGLE: TensorRT-LLM — 4 GPU NVIDIA B200 SGLang — 8 GPU NVIDIA B200 Lưu ý về SGLang: Chạy Kimi K2.5 với EAGLE trên SGLang ở TP4 đã hết bộ nhớ — triển khai EAGLE của SGLang yêu cầu nhiều bộ nhớ hơn so với TensorRT-LLM trên mô hình này.