Định tuyến thông minh: nhà cung cấp rẻ nhất đủ nhanh cho prompt của bạn

Tại sao nhà cung cấp rẻ nhất lại không đủ tốt

Một mô hình như DeepSeek V4.1 Flash được bán bởi nhiều nhà cung cấp với các mức giá khác nhau. Gửi mọi yêu cầu đến nhà cung cấp rẻ nhất hoạt động tốt cho các prompt ngắn. Nó gặp vấn đề với các prompt dài, bởi vì trước khi một mô hình viết từ đầu tiên, nó phải đọc toàn bộ prompt, và một số nhà cung cấp đọc các prompt dài chậm hơn nhiều so với những nhà cung cấp khác.

Chúng tôi đã đo lường điều này trên lưu lượng truy cập thực tế vào 28 tháng 10, 2026. Với DeepSeek V4.1 Flash, nhà cung cấp rẻ nhất mất 15 giây để gửi từ đầu tiên cho các prompt có 32k–128k tokens, và 34 giây cho các prompt trên 128k. Một nhà cung cấp khác mất 1.5–2 giây cho cùng các prompt đó.

Điều đó quan trọng nhất đối với các tác nhân lập trình (coding agents). Claude Code, Cline và các công cụ tương tự gửi toàn bộ ngữ cảnh làm việc trong mỗi lượt, thường là 60k–130k tokens, và phần lớn trong số đó là đọc từ bộ nhớ đệm (cache read).

Chỉ riêng giá cả cũng đã chọn sai cho những prompt đó. Việc xếp hạng theo giá đầu vào thông thường đã bỏ qua giá của các lần đọc từ bộ nhớ đệm (cache reads), vì vậy một prompt dài được lưu trong bộ nhớ đệm có thể được gửi đến một nhà bán lại tính phí $0.07 cho mỗi triệu cached tokens trong khi một nhà cung cấp khác tính phí $0.0013. Cuộc gọi đó chậm hơn và đắt hơn khoảng 50x.

Điều gì xảy ra với mỗi yêu cầu

1. Đo tốc độ theo kích thước prompt. UberLLM ghi lại thời gian đến token đầu tiên của mỗi nhà cung cấp cho mỗi model, trong bốn nhóm kích thước: dưới 8k token, 8k–32k, 32k–128k và trên 128k. Cùng một nhà cung cấp đã trả lời một prompt 31-token trong 1.7 giây và một prompt 105k-token trong 15.5 giây, vì vậy một con số duy nhất cho mỗi nhà cung cấp sẽ không chính xác. Dữ liệu này đến từ các cuộc gọi thực tế. Các kiểm tra tốc độ riêng biệt mỗi 5 phút với khoảng 20k, 60k và 150k token giúp phát hiện sự chậm lại ở một kích thước ngay cả khi các cuộc gọi ngắn nhanh.
2. Tính phí yêu cầu chính xác này trên mỗi nhà cung cấp. Đầu vào, đầu vào được lưu trong bộ nhớ cache và đầu ra được tính phí riêng biệt, dựa trên sự kết hợp token của yêu cầu này. Đối với các prompt agent dài, giá đọc từ bộ nhớ cache thường chiếm phần lớn hóa đơn.
3. Giữ lại các nhà cung cấp đủ nhanh. Một nhà cung cấp đủ điều kiện khi thời gian đến token đầu tiên điển hình của nó nằm trong khoảng 2x so với nhà cung cấp nhanh nhất được đo lường, hoặc dưới 1 giây. Tốc độ được đánh giá dựa trên giá trị trung vị. Các trường hợp ngoại lệ chậm được tính với trọng số một phần tư một khi nhà cung cấp có ít nhất 10 mẫu, để một cuộc gọi kém không loại bỏ một nhà cung cấp tốt.
4. Gửi yêu cầu đến nhà cung cấp rẻ nhất trong số đó. Nhà cung cấp nhanh nhất chỉ thắng khi những nhà cung cấp rẻ hơn quá chậm.
5. Giữ dữ liệu luôn cập nhật. 5% các yêu cầu được gửi đến một nhà cung cấp mà chúng tôi có quá ít dữ liệu, để một nhà cung cấp trở nên nhanh hơn sẽ được chú ý. Một nhà cung cấp từ chối một cuộc gọi được coi là không sử dụng được và được thử lại trong vòng 15 phút.

Khi chưa có dữ liệu tốc độ cho một model, yêu cầu sẽ được gửi đến nhà cung cấp rẻ nhất có sẵn. Một nhà cung cấp có giá cao hơn giá thông thường của model chỉ được chọn vì tốc độ khi nó vẫn còn ít nhất 50% dưới giá niêm yết chính thức của model.

Prompt dài: nhà cung cấp thứ hai khi nhà cung cấp đầu tiên chậm

Ngay cả một nhà cung cấp nhanh cũng đôi khi khởi động chậm. Với một prompt 120k-token được cache, cùng một nhà cung cấp đã khởi động trong 0.45, 3.7 và 8.5 giây trong ba lần gọi liên tiếp. Việc chọn đúng nhà cung cấp không thể khắc phục điều đó, vì vậy các yêu cầu streaming dài sẽ có một phương án dự phòng:

• Prompt từ 32k–128k token: nếu không có từ đầu tiên nào đến sau 1 giây, yêu cầu tương tự cũng được gửi đến một nhà cung cấp nhanh khác.
• Prompt trên 128k token: cả hai yêu cầu bắt đầu cùng lúc.
• Nhà cung cấp đầu tiên trả lời sẽ streaming phản hồi. Yêu cầu còn lại sẽ bị hủy ngay khi từ đầu tiên đến.

Bạn nhận được một phản hồi và trả tiền cho một phản hồi. Chúng tôi trả tiền cho yêu cầu bị hủy, từ một ngân sách cố định hàng ngày. Khi ngân sách đó hết, các yêu cầu dài sẽ đến một nhà cung cấp cho đến ngày hôm sau (UTC).

Thử lại với nhà cung cấp khác

Nếu một cuộc gọi thất bại trước khi bất kỳ phản hồi nào đến được bạn, UberLLM sẽ thử lại trên một tuyến đường khác, tối đa 4 lần thử. Trước khi có định tuyến thông minh, một lần thử lại có thể lại rơi vào cùng một nhà cung cấp chậm chạp đó. Một cuộc gọi thất bại ở mọi lần thử có giá $0. Thông tin chi tiết có trong mô hình và định tuyến.

Kết quả trên lưu lượng truy cập thực tế

DeepSeek V4.1 Flash, thời gian phản hồi từ đầu tiên:

Kích thước prompt	Trước đây	Sau này
32k–128k tokens	18 s	3.3 s
Trên 128k tokens	40 s	3.4 s

Đối với các cuộc gọi streaming trên 32k token (28 tháng 10, 2026), 10% cuộc gọi chậm nhất đã giảm từ 57 giây xuống còn 8.7 giây. Chi phí của 1,000 trong số các cuộc gọi đó đã giảm từ $2.49 xuống $1.04, vì giá cache-read hiện được tính vào lựa chọn. Vào ngày 29 tháng 10, một prompt 203k token bắt đầu phản hồi trong khoảng 4 giây.

Một hạn chế: không nhà cung cấp nào bắt đầu một prompt 100k token ngay lập tức. Tất cả đều mất vài giây. Định tuyến thông minh loại bỏ thời gian chờ đợi thêm từ các nhà cung cấp chậm. Nó không thể loại bỏ thời gian mà một nhà cung cấp nhanh cần để đọc prompt.

Bạn trả bao nhiêu

Mỗi yêu cầu được tính phí theo mức mà nhà cung cấp đã phục vụ nó tính, không có phí UberLLM nào được thêm vào. Mọi cuộc gọi và chi phí của nó được liệt kê trong Dashboard → Activity. Để giới hạn giá, hãy gửi provider.max_price cùng với cả prompt và completion. Định tuyến thông minh sau đó chỉ chọn các nhà cung cấp dưới mức giới hạn của bạn, và một yêu cầu sẽ không bao giờ bị tính phí vượt quá mức đó.

Sử dụng định tuyến riêng của bạn thay thế

Bạn không cần thay đổi bất cứ điều gì để có được định tuyến thông minh. Nếu bạn chỉ định nhà cung cấp trong provider.only, provider.ignore hoặc provider.order, đặt provider.sort, hoặc thêm hậu tố :floor hoặc :nitro vào ID mô hình, lựa chọn của bạn sẽ được sử dụng và định tuyến thông minh sẽ không chạy cho yêu cầu đó:

{
  "model": "deepseek/deepseek-v4.1-flash",
  "provider": { "sort": "price" },
  "messages": [{ "role": "user", "content": "Hello" }]
}

provider.max_price là một ngoại lệ: nó hoạt động cùng với định tuyến thông minh. Tất cả các tùy chọn được liệt kê trong mô hình và định tuyến.

Đọc thêm

• Cách định tuyến UberLLM chọn nhà cung cấp khỏe mạnh rẻ nhất
• Sử dụng UberLLM với Claude Code
• Giá trực tiếp theo từng model