Tinh chỉnh Flame serving để đạt hiệu suất tương đương vLLM độc lập

Các nhà nghiên cứu đã so sánh hiệu suất của Flame, một framework phục vụ dựa trên Python tích hợp vLLM, với các instance vLLM độc lập. Nghiên cứu được công bố vào ngày 24 tháng 10 năm 2026, chi tiết cách các chiến lược tinh chỉnh cụ thể giúp Flame đạt hiệu suất gần như ngang bằng với engine tham chiếu trên hai GPU NVIDIA B200. Kết quả nhấn mạnh tầm quan trọng của việc cache tiền tố và cơ chế tiếp nhận yêu cầu bất đồng bộ trong việc giảm thiểu overhead cho các triển khai mô hình ngôn ngữ lớn.

Chuyện gì đã xảy ra

Đánh giá tập trung vào hai loại khối lượng công việc riêng biệt sử dụng mô hình Llama 3.1 8B Instruct. Khối lượng công việc đầu tiên bao gồm 64 yêu cầu không có sự tái sử dụng tài liệu, trong khi khối lượng thứ hai bao gồm 256 yêu cầu, nơi bốn câu hỏi được đặt ra cho mỗi một trong bốn tài liệu, cho phép tái sử dụng tiền tố. Trong cả hai kịch bản, hệ thống xử lý các đợt lưu lượng ngắn, hữu hạn thay vì tải ổn định kéo dài. Mục tiêu là xác định xem Flame có thể duy trì ít nhất 99% thông lượng mà một thiết lập vLLM độc lập được cấu hình cẩn thận đạt được hay không.

Các thử nghiệm ban đầu cho thấy khoảng cách đáng kể khi sử dụng cấu hình mặc định. Tuy nhiên, sau khi triển khai vị trí worker bền vững (persistent worker placement) để cải thiện việc tái sử dụng cache, các nhà nghiên cứu đã thu hẹp phần lớn khoảng cách đó. Các tối ưu hóa tiếp theo bao gồm tăng kích thước batch, chuyển sang cơ chế tiếp nhận engine bất đồng bộ và áp dụng nén không mất dữ liệu (lossless compression) cho đầu vào. Trong cấu hình cuối cùng, thông lượng hoàn thành trung vị của Flame chỉ thấp hơn 0,55% so với vLLM độc lập khi không tái sử dụng tài liệu và thấp hơn 0,86% khi có tái sử dụng tiền tố. Mặc dù hai trong số năm cặp thử nghiệm bỏ lỡ mục tiêu nghiêm ngặt 99% trong các bài kiểm tra tái sử dụng, độ lệch trường hợp xấu nhất chỉ là 2,03%.

Cách thức hoạt động

Cơ chế cốt lõi để cải thiện hiệu suất ở cả hai hệ thống là tính liên kết tiền tố (prefix affinity). Khi một trợ lý trả lời nhiều câu hỏi về cùng một tài liệu, nó lặp lại việc xử lý các token khởi đầu giống nhau. Bằng cách giữ tiền tố đó trên một GPU duy nhất, hệ thống tránh phải xây dựng lại các khóa và giá trị attention từ đầu. Các nhà nghiên cứu đã triển khai một bản đồ phía client băm các khối token để gán các tiền tố chưa từng thấy cho shard có khối lượng công việc prefill ước tính thấp nhất. Điều này đảm bảo rằng các câu hỏi tiếp theo về một tài liệu cụ thể luôn đến cùng một worker, cho phép vLLM tái sử dụng hiệu quả các block KV đang cư trú.

Ngoài việc caching, nhóm đã giải quyết cách các yêu cầu được tiếp nhận vào engine suy luận. Adapter Flame gốc truyền các batch một cách đồng bộ, khiến các tác vụ sau phải chờ cho đến khi các lần gọi hiện tại hoàn tất. Phiên bản được tối ưu hóa sử dụng API bất đồng bộ để tiếp nhận tất cả các yêu cầu trong một batch đồng thời. Nó cũng sử dụng nén zlib mức 1 để giảm kích thước của các đầu vào được truyền đi, đặc biệt hiệu quả đối với các prompt nặng về văn bản. Cuối cùng, việc đóng băng heap khởi động Python đã giảm các tạm dừng do garbage collection trong quá trình suy luận, giúp ổn định thêm thông lượng.

Chi tiết chính

• Các thí nghiệm sử dụng hai GPU NVIDIA B200 chạy vLLM 0.28.0 và Torch 2.13.0+cu130.
• Tính liên kết tiền tố đã tăng thông lượng trung vị lên 77,5% đối với vLLM độc lập và 73,4% đối với Flame trong các kịch bản tái sử dụng.
• Thông lượng trung vị cuối cùng của Flame là 7,586 req/s khi không tái sử dụng và 28,350 req/s khi có tái sử dụng.
• Việc nén đầu vào đã giảm kích thước đầu vào dịch vụ được mã hóa cho đợt burst tái sử dụng từ hơn 6 MB xuống còn khoảng 388 KB.
• Đóng băng heap khởi động đã giảm tạm dừng garbage collection tối đa mỗi worker từ 8,80 ms xuống còn 4,59 ms.
• Nghiên cứu không chứng minh được lợi thế hiệu suất từ scheduler nhận biết dữ liệu (data-aware scheduler) của Flame trong các bài kiểm tra cụ thể này.

Tại sao điều này quan trọng

Đối với các kỹ sư xây dựng dịch vụ LLM production, sự so sánh này làm rõ nguồn gốc thực sự của overhead trong các framework phục vụ dạng wrapper. Nó cho thấy cái giá phải trả khi sử dụng một lớp điều phối cấp cao hơn như Flame không phải là đặc tính cố hữu của kiến trúc, mà bắt nguồn từ các mặc định batching và synchronization chưa tối ưu. Bằng cách hiểu rằng tính cục bộ của tiền tố (prefix locality) và cơ chế tiếp nhận bất đồng bộ là yếu tố then chốt, các nhà phát triển có thể tinh chỉnh stack của mình để giảm thiểu các đỉnh latency và tối đa hóa mức sử dụng GPU.

Các phát hiện cũng cảnh báo chống lại giả định rằng các tính năng của framework tự động chuyển đổi thành lợi ích hiệu suất. Scheduler nhận biết dữ liệu trong Flame đã không vượt trội hơn so với phương pháp ánh xạ client tường minh đơn giản hơn được sử dụng trong các bài kiểm tra. Điều này gợi ý rằng đối với nhiều trường hợp sử dụng, các chiến lược định tuyến thẳng thắn kết hợp với quản lý tài nguyên cẩn thận có thể hiệu quả hơn các thuật toán lập lịch phức tạp. Các đội ngũ nên ưu tiên các yếu tố đo lường được như tỷ lệ hit cache và mức độ lấp đầy batch hơn là các lợi thế lập lịch lý thuyết.

Bạn có thể làm gì

• Triển khai tính liên kết tiền tố trong định tuyến client của bạn để đảm bảo các yêu cầu chia sẻ context truy cập vào cùng một replica GPU.
• Chuyển sang API bất đồng bộ cho việc tiếp nhận engine để ngăn chặn việc xử lý batch làm阻塞 các yêu cầu mới.
• Bật nén không mất dữ liệu cho các đầu vào nặng về văn bản để giảm overhead mạng và bộ nhớ trong quá trình truyền tải.
• Tinh chỉnh cửa sổ và giới hạn hình thành batch để cân bằng giữa latency và thông lượng dựa trên mẫu lưu lượng của bạn.
• Giám sát các tạm dừng garbage collection và cân nhắc đóng băng các đối tượng tồn tại lâu dài trong quá trình khởi tạo worker.
• Xác thực hiệu suất bằng các bài kiểm tra burst hữu hạn mô phỏng mẫu sử dụng thực tế của bạn, bao gồm cả các kịch bản tái sử dụng tiền tố.