Cách đánh giá hiệu năng các nhà cung cấp LLM: Độ trễ, thông lượng và thời gian hoạt động

Các nhà phát triển thường bắt đầu quá trình lựa chọn LLM bằng cách chọn một mô hình như Claude, Llama, Gemini hoặc DeepSeek, sau đó mới coi nhà cung cấp là yếu tố quyết định thứ yếu. Điều này hoàn toàn dễ hiểu. Tuy nhiên, việc chỉ chọn mô hình thôi là chưa đủ để biết mô hình đó hoạt động như thế nào thông qua một endpoint cụ thể của nhà cung cấp.

Cùng một mô hình có thể chạy qua nhiều endpoint của các nhà cung cấp khác nhau, và mỗi endpoint lại mang đến cơ sở hạ tầng, cơ chế định tuyến, lựa chọn lượng tử hóa (quantization) và các kiểu lỗi khác nhau. Người dùng và hệ thống của bạn sẽ thấy rõ những khác biệt này trong thực tế. Một nhà cung cấp có thể trả về token đầu tiên rất nhanh nhưng lại chậm dần trong phần còn lại của phản hồi. Một nhà cung cấp khác có thể phục vụ biến thể có độ chính xác thấp hơn, dẫn đến sai lệch trên các câu lệnh (prompt) khó. Một nhà cung cấp khác nữa có thể hoạt động tốt trong điều kiện lưu lượng bình thường nhưng lại thất bại khi chịu tải cao.

Đánh giá nhà cung cấp là việc so sánh các môi trường phục vụ thay vì coi mô hình như một sản phẩm độc lập. Việc này đặt ra các câu hỏi: người dùng phải chờ bao lâu để nhận được token đầu tiên, phần còn lại của phản hồi đến nhanh như thế nào, nhà cung cấp phản ứng ra sao khi chịu tải và mô hình đang chạy ở mức độ chính xác nào.

Hướng dẫn này sẽ giải quyết các câu hỏi đó theo thứ tự mà bạn có thể thực hiện: độ trễ (latency), thông lượng (throughput), thời gian hoạt động (uptime) và lượng tử hóa (quantization). Khi đã đo lường được những sự đánh đổi này, bước tiếp theo là chuyển đổi kết quả thành logic định tuyến để ứng dụng của bạn không bị "cứng nhắc" (hard-code) vào bất kỳ nhà cung cấp nào trông có vẻ nhanh nhất trong một lần chạy benchmark duy nhất.

Tóm tắt (Tl;dr)

4 chỉ số để đánh giá hiệu suất nhà cung cấp

Một sản phẩm chat, một quy trình tạo tài liệu và một tác vụ tóm tắt chạy ngầm không cần cùng một cấu hình hiệu suất. Nhà cung cấp phù hợp phụ thuộc vào khối lượng công việc cụ thể.

Một nhà cung cấp có thể trông rất nhanh ở phần đầu phản hồi nhưng lại trở nên chậm chạp khi hoàn tất toàn bộ câu trả lời. Thời gian đến token đầu tiên (TTFT) nắm bắt phần đầu của trải nghiệm đó. Tốc độ đầu ra (output speed) nắm bắt phần thứ hai vì nó đo lường số lượng token mà nhà cung cấp tạo ra mỗi giây sau khi quá trình tạo bắt đầu. Một nhà cung cấp có TTFT tốt vẫn có thể mang lại trải nghiệm kém cho các văn bản dài nếu tốc độ token duy trì bị giảm, trong khi một nhà cung cấp có thông lượng tốt vẫn có thể tạo cảm giác tệ trong giao diện chat nếu token đầu tiên đến muộn.

Thời gian hoạt động (uptime) bổ sung lớp sản xuất mà các chỉ số tốc độ không thể bao quát hết. Một nhà cung cấp hoạt động tốt trong điều kiện benchmark vẫn có thể gây hại cho ứng dụng nếu nó gặp sự cố trong thời gian cao điểm, giới hạn tốc độ (rate-limit) bất ngờ hoặc tạo ra các đợt lỗi đột biến buộc phải thử lại.

Khi các phép đo này đã được tách biệt, bước tiếp theo là đọc chúng ở mức độ tin cậy phù hợp. Độ trễ trung vị (median latency) có thể mô tả yêu cầu thông thường, nhưng các hệ thống sản xuất cũng cần biết có bao nhiêu yêu cầu mất nhiều thời gian hơn mức thông thường. Đó là lúc các chỉ số phân vị (percentile) như p50, p75, p90 và p99 trở nên hữu ích hơn so với các giá trị trung bình cộng.

Cách đọc độ trễ và thông lượng theo phân vị

Các giá trị trung bình thường che giấu những yêu cầu tạo ra trải nghiệm người dùng tồi tệ nhất. Nếu một nhà cung cấp phục vụ hầu hết các yêu cầu nhanh chóng nhưng thỉnh thoảng lại bị khựng nghiêm trọng, giá trị trung bình có thể vẫn trông ổn, nhưng người dùng của bạn sẽ ghi nhớ yêu cầu bị khựng đó.

Chúng tôi theo dõi các chỉ số độ trễ và thông lượng cho từng mô hình và nhà cung cấp bằng cách sử dụng thống kê phân vị trên cửa sổ trượt 5 phút. Các phân vị khả dụng là p50, p75, p90 và p99.

Giá trị độ trễ p50 mô tả yêu cầu trung vị, nhưng nó có thể che giấu các yêu cầu nằm xa hơn trong phân phối. Một nhà cung cấp có thể có p50 tốt nhưng p99 yếu, nghĩa là yêu cầu thông thường vẫn ổn nhưng một phần nhỏ các yêu cầu quan trọng lại mất đủ thời gian để tạo ra độ trễ có thể nhận thấy được.

Phân vị phù hợp phụ thuộc vào việc độ trễ gây hại cho quy trình làm việc ở đâu. Trong giao diện chat, độ trễ xuất hiện trước khi token đầu tiên đến, vì vậy độ trễ p90 và p99 cho biết liệu trải nghiệm có duy trì tính nhất quán ngoài các yêu cầu thông thường hay không. Trong một tác vụ hàng loạt (batch job), người dùng không chờ đợi từng phản hồi bắt đầu, vì vậy tốc độ đầu ra duy trì cung cấp cái nhìn tốt hơn về khối lượng công việc mà hệ thống có thể hoàn thành theo thời gian.

Ví dụ cụ thể, vào ngày 24 tháng 6 năm 2026 UTC, hai nhà cung cấp phục vụ anthropic/claude-sonnet-4.5 đã cho thấy các đường cong độ trễ khác nhau trong cửa sổ 1 ngày, và cả hai đều có phần đuôi p99 rộng hơn nhiều so với giá trị p50 của chúng.

Các phân vị cho thấy mức độ phản hồi nhất quán của nhà cung cấp, nhưng chúng không giải thích được mọi khác biệt giữa hai nhà cung cấp cùng phục vụ một mô hình. Khi độ trễ và thông lượng đã rõ ràng, câu hỏi tiếp theo là liệu cả hai nhà cung cấp có đang phục vụ mô hình đó dưới cùng một hình thức hay không.

Tại sao lượng tử hóa (quantization) làm thay đổi kết quả của nhà cung cấp

Lượng tử hóa là một trong những khác biệt dễ bị bỏ qua nhất của nhà cung cấp vì tên mô hình không phải lúc nào cũng tiết lộ cách mô hình đang được phục vụ. Hai nhà cung cấp có thể hiển thị cùng một slug mô hình trong khi chạy nó ở các mức độ chính xác khác nhau. Một lộ trình có thể bảo toàn nhiều hơn độ chính xác trọng số gốc của mô hình, trong khi lộ trình khác có thể giảm độ chính xác để giảm mức sử dụng bộ nhớ, cải thiện hiệu quả phục vụ hoặc làm cho endpoint rẻ hơn để vận hành.

Việc giảm độ chính xác làm thay đổi cách mô hình hoạt động dưới các loại câu lệnh khác nhau. Độ chính xác thấp hơn có thể làm cho mô hình nhanh hơn và rẻ hơn để phục vụ, nhưng nó cũng có thể thay đổi cách mô hình xử lý các câu lệnh đòi hỏi suy luận cẩn thận, tính chính xác của mã, ngữ cảnh dài hoặc tuân thủ chỉ dẫn nghiêm ngặt.

Chúng tôi đưa lượng tử hóa vào như một quyết định định tuyến vì việc lựa chọn nhà cung cấp không nên coi mọi endpoint có cùng tên mô hình là tương đương. Trường quantizations cho phép bạn chọn các mức độ chính xác mà ứng dụng của bạn có thể sử dụng, vì vậy rủi ro về chất lượng trở thành một phần của chính sách định tuyến thay vì là một chi tiết ẩn của nhà cung cấp.

Hãy đọc bảng này như một cách để quyết định mức độ chính xác mà khối lượng công việc của bạn có thể đánh đổi để lấy chi phí phục vụ thấp hơn hoặc tốc độ cao hơn. Một quy trình tóm tắt có thể chấp nhận một endpoint có độ chính xác thấp hơn nếu đầu ra vẫn ổn định trên tập kiểm thử của riêng bạn. Một quy trình chỉnh sửa mã, tác nhân gọi công cụ (tool-calling agent) hoặc tác vụ nặng về suy luận sẽ cho bạn ít dư địa hơn cho sự suy giảm chất lượng âm thầm, vì một sai lệch nhỏ có thể thay đổi câu trả lời, làm hỏng lệnh gọi hoặc tạo ra mã trông có vẻ hợp lý nhưng lại bị lỗi.

Khi đánh giá cho thấy khối lượng công việc cần độ chính xác cao hơn, hãy sử dụng trường quantizations để giới hạn các endpoint của nhà cung cấp mà ứng dụng của bạn có thể sử dụng:

Bạn cũng có thể loại trừ một nhà cung cấp nếu đánh giá cho thấy endpoint của nó hoạt động kém đối với các câu lệnh của bạn:

Tên mô hình bắt đầu quá trình đánh giá, nhưng endpoint của nhà cung cấp mới là yếu tố hoàn thiện nó. Lượng tử hóa là một lý do khiến các benchmark công khai và hành vi thực tế trong sản xuất có thể khác biệt.

Cách đọc benchmark của nhà cung cấp mà không bị đánh lừa

Một bảng xếp hạng công khai giúp bạn thu hẹp danh sách ứng viên, nhưng nó không thể mô tả lộ trình sản xuất của bạn. Các benchmark đo lường các endpoint được chọn tại một thời điểm, sử dụng các câu lệnh, tham số, khu vực và phương pháp chấm điểm riêng của họ. Ứng dụng của bạn có thể sử dụng một endpoint, hình dạng câu lệnh hoặc lộ trình định tuyến khác với những gì benchmark đã đo lường.

Một bài đánh giá benchmark nhà cung cấp hữu ích nên kiểm tra phương pháp luận đã công bố của benchmark trước khi coi kết quả đó là bằng chứng sản xuất:

Kết quả benchmark trở nên hữu ích khi nó dẫn đến vòng kiểm thử thứ hai dưới khối lượng công việc của riêng bạn. Nếu một bảng xếp hạng chỉ ra một nhà cung cấp nhanh, câu hỏi tiếp theo là liệu endpoint đó có duy trì tốc độ với độ dài câu lệnh, lộ trình định tuyến và yêu cầu chất lượng của bạn hay không. Nếu có, hãy chuyển đổi kết quả đó thành một quy tắc định tuyến.

Việc "cứng nhắc" (hard-code) một nhà cung cấp duy nhất từ một bảng xếp hạng tĩnh sẽ tạo ra một thiết lập mong manh. Hành vi của nhà cung cấp thay đổi theo lưu lượng, sự cố, lộ trình định tuyến và cấu hình phục vụ. Đó là những gì lớp định tuyến của chúng tôi được thiết kế để xử lý.

Tại sao định tuyến đa nhà cung cấp làm thay đổi việc đánh giá nhà cung cấp

Đánh giá một nhà cung cấp một cách riêng lẻ chỉ cho bạn biết nhà cung cấp đó hoạt động như thế nào trong các điều kiện bạn đã đo lường. Nó không cho bạn biết điều gì sẽ xảy ra khi nhà cung cấp đạt giới hạn tốc độ, chậm lại khi chịu tải hoặc tạm thời không khả dụng. Nếu ứng dụng của bạn phụ thuộc vào một endpoint của nhà cung cấp, mọi lỗi từ phía nhà cung cấp sẽ trở thành một phần hành vi của ứng dụng của bạn.

Một lớp định tuyến thay đổi việc đánh giá từ một lựa chọn nhà cung cấp một lần thành một vấn đề lựa chọn liên tục. Thay vì coi mọi sự cố, giới hạn tốc độ hoặc chậm trễ của nhà cung cấp là lỗi ứng dụng, bạn có thể tự động định tuyến xung quanh các điều kiện đó.

Chúng tôi giám sát thời gian phản hồi, tỷ lệ lỗi và tính khả dụng trên các nhà cung cấp trong thời gian thực. Định tuyến mặc định của chúng tôi sẽ giảm ưu tiên các nhà cung cấp gặp sự cố đáng kể trong 30 giây qua, cân bằng tải trên các nhà cung cấp ổn định với trọng số ưu tiên giá thấp hơn và giữ phần còn lại làm phương án dự phòng.

Định tuyến đa nhà cung cấp không đảm bảo thời gian hoạt động hoàn hảo. Nó làm giảm sự phụ thuộc vào một endpoint duy nhất bằng cách cung cấp một lộ trình thay thế khi nhà cung cấp gặp sự cố hoặc không khả dụng.

Các phương án dự phòng mô hình (model fallbacks) áp dụng nguyên tắc tương tự khi định tuyến ở cấp độ nhà cung cấp là không đủ. Nếu mô hình chính không thể hoàn thành yêu cầu vì các nhà cung cấp của nó bị sập, bị giới hạn tốc độ hoặc không thể trả lời, OpenRouter có thể thử mô hình tiếp theo trong danh sách dự phòng.

Một chiến lược định tuyến thực tế nên trả lời ba câu hỏi:

Chuyển đổi đánh giá nhà cung cấp thành chính sách định tuyến

Các điều khiển định tuyến chính nằm bên trong đối tượng nhà cung cấp. Chúng cho phép bạn sắp xếp các nhà cung cấp, ưu tiên các ngưỡng hiệu suất, chọn hoặc tránh các endpoint của nhà cung cấp, lọc theo lượng tử hóa và quyết định xem các phương án dự phòng có được chạy hay không. Các phương án dự phòng mô hình sử dụng mảng models.