Chọn nhà cung cấp LLM dựa trên điểm benchmark cũng giống như chọn nhà hàng dựa trên ảnh trong thực đơn. Mô hình quan trọng, nhưng mọi thứ xung quanh mô hình cũng quan trọng, và chính những thứ xung quanh đó mới là thứ thực sự gây khó cho bạn trong môi trường production. Đây là danh sách kiểm tra mà tôi áp dụng cho một nhà cung cấp trước khi tôi hướng bất cứ thứ gì thực sự vào nó.
Uptime và SLA
SLA là một lời hứa gắn với các con số, nên hãy đọc các con số đó. Các tỷ lệ phần trăm uptime trông có vẻ gần nhau đến mức gây nhầm lẫn cho đến khi bạn quy đổi chúng:
| SLA | Thời gian downtime mỗi năm | Thời gian downtime mỗi tháng |
|---|---|---|
| 99.9% | 8.76 giờ | 43.8 phút |
| 99.95% | 4.38 giờ | 21.9 phút |
| 99.99% | 52.6 phút | 4.4 phút |
99.9% nghe có vẻ xuất sắc và vẫn cho phép gần một giờ gián đoạn mỗi tháng. Nếu sản phẩm của bạn phụ thuộc vào endpoint, thì 99.9% so với 99.99% là sự khác biệt giữa "khó chịu" và "đáng quên". Cũng hãy kiểm tra hai điều ngoài con số hàng đầu:
•Điều gì được tính là downtime. Một số SLA chỉ bao gồm tình trạng ngừng hoạt động hoàn toàn, không bao gồm thông lượng suy giảm hoặc tỷ lệ lỗi cao.
•Bạn nhận được gì khi họ không đạt cam kết. Một khoản tín dụng có rất ít giá trị nếu khoản tín dụng đó bị giới hạn hoặc yêu cầu bạn phải nộp đơn khiếu nại. Biện pháp khắc phục phải cụ thể.
Một nhà cung cấp không chịu công bố SLA là đang nói với bạn điều gì đó, và điều đó không tốt.
Độ trễ và thông lượng
Độ trễ có hai con số mà bạn quan tâm và chúng đo lường những thứ khác nhau:
•Thời gian đến token đầu tiên (TTFT). Mất bao lâu trước khi phản hồi bắt đầu được stream. Đây là thứ người dùng cảm nhận là "nhanh nhạy".
•Token mỗi giây (thông lượng). Phần còn lại của phản hồi đến nhanh đến mức nào. Đây là thứ quyết định liệu một câu trả lời dài có cảm giác chậm hay không.
Cả hai đều thay đổi theo mô hình và theo tải, nên đừng tin vào một con số tiếp thị. Hãy tự đo lấy:
import time
from openai import OpenAI
client = OpenAI(base_url="https://api.token8341.com/v1",
api_key="sk-your-key")
start = time.perf_counter()
stream = client.chat.completions.create(
model="deepseek-chat",
messages=[{"role": "user", "content": "Write 200 words about caching"}],
stream=True,
)
ttft = None
tokens = 0
for chunk in stream:
if ttft is None:
ttft = time.perf_counter() - start
tokens += 1
elapsed = time.perf_counter() - start
print(f"TTFT: {ttft:.2f}s, total: {elapsed:.2f}s, "
f"{tokens / elapsed:.1f} tok/s")Hãy chạy đoạn đó vào vài thời điểm khác nhau trong ngày và dưới mức đồng thời mà bạn dự kiến. Một nhà cung cấp nhanh lúc 10 giờ sáng và chậm lúc 7 giờ tối có vấn đề về năng lực mà bạn cần biết.
Chi phí
Giá trên mỗi token là phần dễ nhất. Bức tranh chi phí đầy đủ bao gồm:
•Giá đầu vào so với đầu ra, vì đầu ra thường đắt gấp vài lần đầu vào.
•Giá khi cache trúng. Với các khối lượng công việc lặp đi lặp lại, một prompt cache có thể cắt giảm chi phí nhiều hơn bất kỳ mức giảm giá nào.
•Giới hạn tốc độ và điều tiết. Một endpoint rẻ mà bạn chỉ có thể gọi một cách hạn chế thì không còn rẻ nữa khi bạn cộng thêm việc xếp hàng và thử lại.
•Tiền tệ và ma sát thanh toán. Phí thẻ xuyên biên giới và chi phí chuyển đổi là có thật đối với các nhóm nhỏ.
Hãy hỏi giá cho khối lượng công việc thực tế của bạn, không phải giá trên mỗi triệu token một cách tách rời.
Độ bao phủ mô hình và khả năng tương thích
•API có tương thích với OpenAI không? Nếu có, bạn có thể dùng các SDK tiêu chuẩn và chuyển đổi sau này mà không cần viết lại. Nếu là độc quyền, bạn đang gắn chặt với nhà cung cấp đó.
•Bạn có thể truy cập nhiều dòng mô hình khác nhau qua một key không? Một danh mục chỉ có một hoặc hai mô hình sẽ trói buộc bạn chặt chẽ như một API độc quyền. Một danh mục có nhiều mô hình cho bạn một phương án dự phòng và một con đường để định tuyến rẻ hơn.
•Có hỗ trợ embeddings, function calling và streaming không, chứ không chỉ chat đơn thuần? Đây là những tính năng quyết định liệu endpoint có phù hợp với một ứng dụng thực thụ hay chỉ là một bản demo.
Xử lý dữ liệu và hỗ trợ
•Lưu trữ dữ liệu. Nhà cung cấp có giữ lại prompt và completion của bạn để huấn luyện không? Hãy yêu cầu điều này bằng văn bản.
•Khu vực và nơi lưu trú dữ liệu. Các yêu cầu được xử lý ở đâu? Với một số người dùng, đây là một yêu cầu pháp lý, không phải sở thích.
•Chất lượng hỗ trợ. Hãy thử mở một ticket hỗ trợ trước khi bạn cam kết. Tốc độ và tính hữu ích của phản hồi đầu tiên là một dự báo mạnh mẽ về việc một sự cố ngừng hoạt động sẽ diễn ra như thế nào.
•Tính minh bạch về trạng thái. Một trang trạng thái công khai và lịch sử sự cố cho bạn biết liệu nhà cung cấp có trung thực về độ tin cậy của chính họ hay không.
Phiên bản ngắn gọn
Hãy đưa mọi ứng viên qua năm câu hỏi sau:
1.SLA là gì, và biện pháp khắc phục khi không đạt là gì?
2.TTFT và thông lượng đo được dưới tải của tôi là bao nhiêu?
3.Khối lượng công việc thực tế của tôi tốn bao nhiêu, tính cả cache trúng?
4.API có tương thích với OpenAI không, với nhiều mô hình đằng sau một key?
5.Họ có cho tôi biết dữ liệu được xử lý ở đâu và hỗ trợ phản hồi như thế nào không?
Không điều nào trong số này đòi hỏi chuyên môn sâu. Chúng đòi hỏi bạn phải hỏi trước khi sự cố xảy ra, chứ không phải sau đó. Những nhà cung cấp trả lời thoải mái những điều này thường là những nhà cung cấp đã thực sự vận hành lưu lượng production, chứ không chỉ liệt kê một mô hình.
SiCore TokenWorks là một lựa chọn dễ dàng đáp ứng hầu hết danh sách này: SLA 99.9%, endpoint tương thích với OpenAI tại https://api.token8341.com/v1, một key bao phủ GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark và Pangu, cùng với tính phí theo token với giá khi cache trúng.