Benchmark vLLM: Tái lập độ trễ, thông lượng và chi phí GPU trước khi triển khai

Một benchmark vLLM chỉ hữu ích khi nó giống với lưu lượng mà ứng dụng của bạn thực sự gửi. Một con số token mỗi giây nổi bật có thể che giấu token đầu tiên chậm, hàng đợi quá tải hoặc phân phối prompt không bao giờ xuất hiện trong môi trường production. Hướng dẫn này cung cấp cho bạn một benchmark phục vụ có thể lặp lại: chọn khối lượng công việc, quét tải được cung cấp, ghi lại đồng thời phân phối độ trễ và thông lượng, rồi so sánh các cấu hình GPU ở cùng mục tiêu chất lượng.

Trả lời nhanh: Dùng vllm bench serve với một phiên bản vLLM và model đã được cố định trên máy chủ GPU chuyên dụng. Giữ cố định model, độ chính xác, độ dài prompt và đầu ra, thiết lập lấy mẫu, trạng thái cache và vị trí client. Chạy nhiều mức tốc độ yêu cầu, thu thập TTFT, TPOT, độ trễ đầu cuối, tốc độ yêu cầu thành công và token đầu ra mỗi giây, sau đó chọn cấu hình có chi phí thấp nhất đáp ứng mục tiêu dịch vụ của bạn tại tải đỉnh. Một lần chạy thông lượng tối đa đơn lẻ không phải là kế hoạch năng lực.

Cần đo lường gì trong một benchmark vLLM

Tài liệu benchmark vLLM định nghĩa TTFT, độ trễ giữa các token và TPOT theo các điểm đo của chúng. Hãy dùng các định nghĩa đó khi so sánh công cụ. Cụ thể, TTFT phía client bao gồm công việc vận chuyển và frontend; các chỉ số tùy chọn phía server có thể tách thời gian chờ scheduler khỏi quá trình thực thi model, nhưng việc bật chúng sẽ thêm overhead. Hãy tách riêng các lần chạy chẩn đoán khỏi kết quả chính thức.

Cố định một phép so sánh công bằng trước khi chạy

Ghi lại revision model và tokenizer, phiên bản vLLM, loại và số lượng GPU, kích thước tensor parallel, các cờ phục vụ, định dạng lượng tử hóa, độ dài ngữ cảnh và môi trường phần mềm. Dùng cùng các prompt và mục tiêu đầu ra cho mọi phương án. Nếu bạn thay đổi đồng thời model, độ chính xác và GPU, kết quả không thể cho biết thay đổi nào đã cải thiện hiệu năng.

Chọn ít nhất hai khối lượng công việc. Khối lượng công việc tổng hợp có độ dài cố định hữu ích cho các lần quét được kiểm soát; một trace đã được làm sạch của độ dài yêu cầu thực tế phù hợp hơn cho quyết định production. Bảo toàn phân phối của prompt dài, câu trả lời ngắn và các đợt tăng vọt. Với sản phẩm chat, hãy đo endpoint chat bằng backend benchmark tương ứng. Với khối lượng công việc completions, hãy dùng backend completions. Đừng so sánh các con số của chúng như thể định dạng yêu cầu là giống nhau.

Quyết định tiêu chí đạt trước khi chạy. Ví dụ, hãy nêu rõ tốc độ yêu cầu thành công bắt buộc và TTFT p95 tối đa cùng độ trễ đầu cuối p95 tối đa cho chính khối lượng công việc của bạn. Chúng tôi không công bố một ngưỡng chung: điều đó phụ thuộc vào trải nghiệm người dùng và kích thước đầu ra. Một bảng chấp nhận với các ngưỡng, kết quả đo được và lý do đạt/không đạt sẽ hữu ích hơn một điểm hiệu năng đơn lẻ.

Chạy thử nghiệm phục vụ được kiểm soát

Hướng dẫn CLI vLLM hiện tại liệt kê vllm bench serve cho các phép đo phục vụ trực tuyến và khuyến nghị bench extra cho các dependency của nó. Dàn ý sau sử dụng ví dụ completions được ghi chép của vLLM. Thay model và dataset bằng các tài nguyên mà bạn được cấp phép chạy và phù hợp với phần cứng của mình. Các lệnh này là mẫu có thể tái lập, không phải kết quả Flatkey đã được đo lường.

python -m pip install 'vllm[bench]'
vllm serve YOUR_MODEL_ID

Trong một shell thứ hai, sau khi server sẵn sàng:

vllm bench serve \
  --backend vllm \
  --model YOUR_MODEL_ID \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 1 \
  --save-result \
  --save-detailed

Sau đó lặp lại với một chuỗi ngắn các giá trị --request-rate cao hơn, đồng thời giữ cố định các đầu vào khác. Hãy dùng đủ số lượng prompt để tránh coi một vài yêu cầu là một phân phối độ trễ đuôi. Lưu kết quả thô và câu lệnh chính xác cho mỗi lần chạy. Ví dụ benchmark trực tuyến chính thức cho thấy các trường đầu ra và giải thích cách --save-result và --save-detailed lưu giữ bằng chứng. Đối với các yêu cầu chat, hãy sử dụng backend openai-chat được tài liệu hóa và endpoint /v1/chat/completions cùng với tập dữ liệu và mô hình hỗ trợ định dạng chat.

Không chạy benchmark này trên một endpoint production dùng chung nếu không có kế hoạch lưu lượng. Nó chủ đích tạo tải. Hãy sử dụng một bản triển khai thử nghiệm tách biệt hoặc một khoảng thời gian bảo trì được kiểm soát, đồng thời ghi lại mọi hoạt động nền có thể ảnh hưởng đến kết quả.

Quét cho đến khi tìm thấy điểm gấp khúc độ trễ

Vẽ tốc độ yêu cầu được đưa vào trên trục hoành. Vẽ số yêu cầu hoàn thành mỗi giây, TTFT p95, độ trễ đầu cuối p95 và số token đầu ra mỗi giây dưới dạng các chuỗi riêng biệt. Lúc đầu, thông lượng có thể tăng gần tương ứng với tải được đưa vào. Vượt quá vùng bền vững, hàng đợi tăng lên, độ trễ đuôi tăng, và thông lượng thành công có thể chững lại. Điểm chuyển tiếp đó quan trọng hơn con số lớn nhất được in trong một lần chạy.

Giữ riêng một lần chạy khởi động. vLLM cảnh báo rằng việc lặp lại benchmark trên cùng một máy chủ có thể tái sử dụng các tiền tố đã được cache và làm tăng giả tạo thông lượng. Nếu tái sử dụng cache không phải là một phần của khối lượng công việc sản phẩm, hãy thay đổi seed hoặc đặt lại máy chủ hoặc cache theo hướng dẫn benchmark chính thức. Nếu tái sử dụng cache có tính thực tế, hãy báo cáo tỷ lệ cache-hit và bao gồm so sánh cache lạnh. Một benchmark không nêu rõ chính sách cache thì khó tái lập.

Khi một lần chạy không đạt mục tiêu, hãy kiểm tra trình tự. TTFT tăng cùng với hàng đợi tăng có thể cho thấy bão hòa hoặc kiểm soát tiếp nhận. TPOT kém trong khi thời gian hàng đợi ổn định có thể cho thấy vấn đề ở giải mã, băng thông bộ nhớ, tính song song hoặc một lựa chọn độ chính xác không hiệu quả. Nếu lỗi tăng lên, hãy xem thời gian chờ, OOM và nhật ký máy chủ trước khi điều chỉnh cài đặt mô hình. Thay đổi nhiều biến cùng lúc sẽ che giấu nguyên nhân.

So sánh các lựa chọn GPU theo công việc được chấp nhận, không phải tốc độ thô

Một GPU lớn hơn có thể tạo ra nhiều token đầu ra hơn mỗi giây nhưng lại tốn nhiều chi phí hơn cho mỗi yêu cầu được chấp nhận. Hãy tính chi phí gần đúng cho mỗi cấu hình:

GPU cost per 1,000 successful requests = hourly GPU cost ÷ successful requests per hour × 1,000

Sử dụng báo giá hiện tại cho đúng khu vực và cam kết, đồng thời tính cả hạ tầng không phải GPU hoặc các mức tăng thanh toán tối thiểu nếu chúng quan trọng. Chỉ so sánh các lần chạy đáp ứng mục tiêu về độ trễ và lỗi của bạn. Một cấu hình rẻ hơn nhưng không đạt TTFT p95 không phải là cách rẻ hơn để cung cấp cùng một dịch vụ.

Đối với so sánh đám mây ban đầu, hãy giữ cố định mô hình và cấu hình phục vụ, chỉ thay đổi loại GPU. Sau đó thử một số ít thay đổi tinh chỉnh, chẳng hạn như cài đặt batch và bộ nhớ, từng thay đổi một. Ghi lại mức sử dụng, dung lượng VRAM còn trống, độ sâu hàng đợi, tỷ lệ yêu cầu thành công và artifact benchmark. Flatkey Compute có thể là một lựa chọn dung lượng để đánh giá; hãy xác minh GPU được cung cấp, khu vực và báo giá hiện tại trước khi sử dụng nó trong so sánh chi phí. Hướng dẫn này không tuyên bố rằng một GPU cụ thể luôn nhanh hơn hoặc rẻ hơn.

Kết quả benchmark vLLM mà bạn có thể gửi cho người đánh giá

Với mỗi lần chạy, hãy ghi lại: mô hình và bản sửa đổi; phiên bản vLLM và driver; GPU và topology; câu lệnh và checksum tập dữ liệu; phân phối độ dài đầu vào/đầu ra; vị trí client; chính sách cache; tốc độ yêu cầu; số yêu cầu hoàn thành và thất bại; TTFT p50/p95/p99; độ trễ đầu cuối p50/p95/p99; thông lượng token đầu ra; mức sử dụng GPU và VRAM; báo giá theo giờ; chi phí mỗi yêu cầu được chấp nhận; và đạt/không đạt so với mục tiêu đã định trước.

Đây cũng là thời điểm để duy trì khả năng hiển thị về bảo mật và chất lượng. Các prompt benchmark cần được loại bỏ dữ liệu khách hàng, và chất lượng đầu ra cần được kiểm tra khi so sánh các mô hình lượng tử hóa hoặc các bản sửa đổi mô hình khác nhau. Một cải thiện tốc độ rõ ràng nhưng làm thay đổi chất lượng tác vụ không phải là một lợi ích so sánh tương đương.

Câu hỏi thường gặp

Liệu vllm bench throughput có giống với vllm bench serve không?

Không. Lệnh đầu tiên nhắm đến thông lượng suy luận ngoại tuyến; lệnh thứ hai gửi các yêu cầu trực tuyến đến một máy chủ đang chạy và đo lường hành vi phục vụ mà phía máy khách nhận thấy. Hãy dùng bench serve để lập kế hoạch độ trễ và năng lực cho một lần triển khai API. Tài liệu tham khảo CLI của vLLM liệt kê cả hai lệnh.

Tôi nên tối ưu chỉ số nào trước?

Hãy bắt đầu với mục tiêu dịch vụ: tỷ lệ thành công và độ trễ đuôi tại mức lưu lượng đỉnh dự kiến. Sau đó, giảm thiểu chi phí trong số các cấu hình đáp ứng tiêu chí. Thông lượng token tổng hợp hữu ích để chẩn đoán năng lực, nhưng không thể thay thế mục tiêu độ trễ hướng đến người dùng.

Tôi có thể so sánh các số liệu benchmark đã công bố từ những nhà cung cấp khác nhau không?

Chỉ khi mô hình, độ chính xác, khối lượng công việc, độ dài đầu ra, endpoint, chính sách cache, chế độ tốc độ yêu cầu và các định nghĩa đo lường tương đồng. Trong hầu hết trường hợp, chạy lại cùng một khối lượng công việc trên cả hai môi trường sẽ cho ra so sánh đáng tin cậy hơn.

Bước tiếp theo: lấy một trace đại diện, cố định các tiêu chí đạt, chạy một đợt quét tốc độ ngắn trên hai cấu hình GPU và lưu giữ đầy đủ kết quả cùng với quyết định. Nếu bạn cũng đang thay đổi độ chính xác, hãy dùng riêng hướng dẫn lượng tử hóa vLLM để đánh giá bộ nhớ và chất lượng trước khi quy bất kỳ chênh lệch tốc độ nào cho GPU.