Vấn đề chi phí ẩn trong hóa đơn của bạn
Hãy nhìn vào tham số model trong mã production của bạn. Với hầu hết các đội ngũ vận hành workload LLM đã vượt qua giai đoạn nguyên mẫu và có lưu lượng thật, tham số đó được thiết lập một lần (thường là mô hình mạnh nhất đội có khi phát hành) và không bao giờ được xem xét lại. Mỗi truy vấn, bất kể độ phức tạp, đều đi tới cùng một mô hình. Và đó chính là nơi vượt chi phí âm thầm tồn tại.
Trong bất kỳ workload production không tầm thường nào, truy vấn không đồng đều về độ khó. Một trợ lý hỗ trợ khách hàng có thể thấy 80% truy vấn là tra cứu đơn giản, phân loại hoặc phản hồi ngắn, và 20% thực sự cần suy luận ở biên tiên tiến. Một trợ lý lập trình có thể xử lý đều đặn các tinh chỉnh nhỏ và một đuôi dài các thay đổi kiến trúc nhiều tệp. Một pipeline nội dung có thể xử lý hàng trăm tác vụ tóm tắt cho mỗi tác vụ cần viết sáng tạo có cấu trúc. Hình dạng công việc không đều, nhưng việc định tuyến tới mô hình thì lại không.
Nếu hôm nay bạn đang chạy 100M tokens mỗi tháng trên GPT-5.5 và 70% số truy vấn đó có thể được trả lời tốt tương đương bởi một mô hình rẻ hơn, bạn đang trả khoảng $600 mỗi tháng cho năng lực mà bạn không dùng tới. Ở khối lượng cao hơn, cùng một quy luật sẽ cộng dồn tuyến tính: cứ mỗi 1B tokens, khoảng cách giữa thiết lập không định tuyến và có định tuyến là vài nghìn đô la mỗi tháng.
Định tuyến là câu trả lời kỹ thuật cho sự bất cân xứng đó. Nguyên tắc rất đơn giản: gửi mỗi truy vấn tới mô hình rẻ nhất có thể xử lý nó, và chỉ leo thang lên mô hình mạnh hơn khi cần. Việc triển khai mới là nơi các đánh đổi thú vị tồn tại, và hầu hết hướng dẫn công khai xử lý chúng không tốt. Bài viết này bao quát ba mẫu đã thực sự hoạt động trong production, phép toán chi phí làm rõ luận điểm, các chế độ lỗi sẽ làm bạn vấp ngã, và một lộ trình chuyển đổi để đi từ thiết lập một mô hình sang định tuyến mà không phải viết lại ứng dụng.
Dữ liệu định giá mà bài viết này dựa vào đến từ bài đi kèm (so sánh định giá API LLM năm 2026), thiết lập mức giá theo mô hình được tham chiếu xuyên suốt. Nơi nào hướng dẫn này trích dẫn một con số chi phí, nó được lấy từ dữ liệu đó.
Ba mẫu định tuyến hoạt động trong production
Có ba mẫu định tuyến lưu lượng LLM đã được xác lập. Chúng khác nhau về độ phức tạp triển khai, độ trễ phát sinh, và dạng tiết kiệm chi phí chúng mở khóa. Hầu hết hệ thống production cuối cùng sử dụng kết hợp cả ba; hiểu ưu thế của mỗi mẫu giúp bạn sắp xếp thứ tự thực hiện.
Mẫu 1: Quy tắc tĩnh
Mẫu đơn giản nhất. Bạn viết các quy tắc định tuyến truy vấn tới các mô hình khác nhau dựa trên những thuộc tính quan sát được của yêu cầu: độ dài đầu vào, hạng người dùng, loại truy vấn (nếu bạn đã có một bộ phân loại), endpoint API, hoặc logic nghiệp vụ. Truy vấn ngắn đi tới mô hình rẻ; truy vấn dài đi tới mô hình mạnh hơn. Người dùng miễn phí nhận mô hình rẻ hơn người dùng trả phí. Yêu cầu sinh mã đi tới mô hình tinh chỉnh cho mã; mọi thứ khác đi tới mô hình mục đích chung.
Định tuyến tĩnh có thể dự đoán, dễ gỡ lỗi và hầu như không thêm độ trễ: quyết định định tuyến chỉ là vài dòng mã chạy cục bộ. Trần cũng thấp hơn: bạn định tuyến dựa trên các thuộc tính có thể quan sát trước khi mô hình chạy, nghĩa là bạn không thể định tuyến theo “mức độ khó thực sự của truy vấn” vì bạn chưa biết điều đó. Với các workload mà thuộc tính đầu vào tương quan tốt với độ khó (tài liệu dài thường khó hơn; mã thường khác với văn xuôi; người dùng trả phí thường có truy vấn đòi hỏi hơn), quy tắc tĩnh có thể nắm bắt 30–50% phần tiết kiệm khả dụng với rất ít nỗ lực kỹ thuật.
Mẫu 2: Chuỗi thác
Mẫu có tính ứng dụng rộng nhất. Bạn gửi truy vấn tới một mô hình rẻ trước; nếu phản hồi đạt ngưỡng chất lượng, bạn trả về nó; nếu không, bạn leo thang tới mô hình mạnh hơn và dùng phản hồi đó thay thế. Tiết kiệm chi phí đến từ việc với các truy vấn mô hình rẻ có thể xử lý, bạn chỉ trả mức giá của mô hình rẻ.
Đặc trưng của mẫu chuỗi thác là quyết định định tuyến được thông báo bởi đầu ra của mô hình, không chỉ đầu vào: bạn để mô hình rẻ thử thực hiện công việc, rồi đánh giá liệu nỗ lực đó có đủ tốt. Việc đánh giá có thể được triển khai theo nhiều cách: điểm tự tin từ chính mô hình, xác thực đầu ra có cấu trúc (phản hồi có parse theo schema kỳ vọng không?), lời nhắc tự-đánh giá (hỏi một mô hình nhỏ liệu phản hồi có trả lời câu hỏi không), hoặc tín hiệu hành vi hạ nguồn (người dùng có chấp nhận câu trả lời hay diễn đạt lại và thử lại?).
Chuỗi thác là mẫu mà hầu hết hệ thống production cuối cùng áp dụng vì nó nắm bắt được khoản tiết kiệm mà quy tắc tĩnh không thể. Đánh đổi là với các truy vấn leo thang, bạn trả cho cả cuộc gọi đến mô hình rẻ và mô hình đầu bảng, vì vậy mức tiết kiệm phụ thuộc vào tỷ lệ truy vấn thành công ở tầng mô hình rẻ. Đây là mẫu chúng ta sẽ đi sâu chi tiết ở phần sau.
Mẫu 3: Định tuyến dựa trên bộ phân loại
Trần cao nhất và đầu tư kỹ thuật nhiều nhất. Một mô hình nhỏ, nhanh (thường là phiên bản fine-tuned của một mô hình dưới biên, hoặc một bộ phân loại chuyên dụng) nhìn vào mỗi truy vấn đến và dự đoán mô hình hạ nguồn nào nên xử lý. Bộ phân loại có thể quyết định dựa trên loại truy vấn (“có vẻ là tác vụ sinh mã; định tuyến tới mô hình tinh chỉnh cho mã”), ước lượng độ khó (“có vẻ là truy vấn suy luận khó; định tuyến tới GPT-5.5”), hoặc một chính sách định tuyến học từ lưu lượng lịch sử và kết quả.
Định tuyến dựa trên bộ phân loại có thể vượt chuỗi thác vì quyết định định tuyến diễn ra trước khi bất kỳ mô hình đắt tiền nào chạy, nên bạn không trả “thuế mô hình rẻ” cho những truy vấn chắc chắn cần tới mô hình đầu bảng. Cái giá là công sức kỹ thuật để xây, huấn luyện và duy trì chính bộ phân loại, cộng với độ trễ nhỏ của cuộc gọi định tuyến. Với workload rất lớn, đánh đổi này tự trả chi phí; với workload nhỏ, thường là không.
Bắt đầu với mẫu nào: Quy tắc tĩnh trước nếu workload của bạn có tín hiệu định tuyến rõ ràng (độ dài đầu vào, hạng người dùng, endpoint). Chuỗi thác nếu không có, hoặc khi bạn đã khai thác hết các quy tắc tĩnh hiển nhiên. Dựa trên bộ phân loại chỉ sau khi cả tĩnh và chuỗi thác đã có, và lưu lượng đủ lớn để biện minh cho đầu tư kỹ thuật. Nhảy thẳng tới bộ phân loại là cái bẫy over-engineering kinh điển mà đa số đội ngũ sẽ hối tiếc.
Cần đo lường gì trước khi bắt đầu định tuyến
Bạn không thể tối ưu thứ mình không đo. Trước khi đưa bất kỳ logic định tuyến nào vào hệ thống production, hãy instrument workload một-mô-hình hiện tại để có đường cơ sở để so sánh. Việc instrument không cần cầu kỳ: một log cơ bản của mọi yêu cầu với một tập trường nhỏ là đủ để bắt đầu.
Ghi nhận tối thiểu hữu ích:
- Theo yêu cầu: model dùng, số token đầu vào, số token đầu ra, chi phí (tính từ số token và bảng giá), độ trễ end-to-end, trạng thái phản hồi (thành công / lỗi / một phần), và nhãn loại truy vấn nếu bạn có.
- Theo cuộc hội thoại hoặc theo người dùng: độ dài phiên, số lần retry (ám chỉ người dùng không chấp nhận câu trả lời đầu tiên), tỷ lệ theo dõi (ám chỉ câu trả lời cần làm rõ).
- Một tập đánh giá giữ lại: 100–500 truy vấn đại diện mà bạn có thể chạy lại trên bất kỳ mô hình nào, với đầu ra tham chiếu bạn tin cậy. Đây là cách bạn đo liệu một mô hình rẻ hơn ứng viên có tạo chất lượng chấp nhận được trên workload của bạn. Không có nó, mọi quyết định định tuyến chỉ là đoán mò.
Tập đánh giá là nơi hầu hết các đội ngũ đầu tư chưa đủ, và nó là phần cơ sở hạ tầng đòn bẩy cao nhất cho bất kỳ dự án định tuyến nào. Công cụ nhẹ như Promptfoo hoặc Helicone evals có thể dựng nhanh; với workload giai đoạn sớm, một tập 50 truy vấn chọn tay với chấm điểm thủ công là đủ để khởi động.
Khi đã instrument, chạy workload như hiện tại ít nhất một tuần để thiết lập đường cơ sở. Hình dạng dữ liệu (phân phối độ dài đầu vào lệch đến đâu, bao nhiêu phần trăm truy vấn ngắn và đơn giản, bao nhiêu phần trăm trông khó) sẽ cho bạn biết nên bắt đầu với mẫu định tuyến nào.
Mẫu chuỗi thác chi tiết, kèm toán chi phí
Mẫu chuỗi thác xứng đáng nhiều không gian nhất vì nó áp dụng rộng và là mẫu hầu hết đội ngũ sẽ triển khai đầu tiên hoặc thứ hai. Phép toán cũng là nơi lập luận cho định tuyến trở nên cụ thể.
Xét một workload production đại diện đang chạy trên Claude Sonnet 4.6 hôm nay: 100 million tokens mỗi tháng, 80% đầu vào và 20% đầu ra, hóa đơn $475 mỗi tháng theo giá niêm yết. Giả sử ta đưa một chuỗi thác phía trước: truy vấn chạm Claude Haiku 4.5 trước, và chỉ leo thang tới Sonnet 4.6 nếu phản hồi của Haiku trượt kiểm tra chất lượng. Haiku 4.5 niêm yết $1.00 đầu vào và $5.00 đầu ra trên mỗi triệu token, bằng một phần ba mức của Sonnet.
Phép toán chi phí phụ thuộc vào hai tham số: phần trăm truy vấn thành công ở tầng Haiku (gọi là tỷ lệ thành công), và tỷ lệ đầu vào/đầu ra khác nhau thế nào giữa truy vấn thành công và truy vấn leo thang. Để đơn giản, giả định tỷ lệ đầu vào/đầu ra là như nhau cho cả hai, và tỷ lệ thành công là 70%, nghĩa là phản hồi của Haiku đủ tốt với 70% truy vấn, và 30% leo thang lên Sonnet.
| Kịch bản | Cách tính chi phí | Hóa đơn hàng tháng | Tiết kiệm |
|---|---|---|---|
| Một mô hình: 100% Sonnet 4.6 | 100M tokens × đơn giá Sonnet | $475 | n/a |
| Chuỗi thác: 70% Haiku, 30% Haiku→Sonnet | 100M Haiku + 30M Sonnet | $237 | 50% |
| Chuỗi thác với tỷ lệ thành công 80% | 100M Haiku + 20M Sonnet | $190 | 60% |
| Chuỗi thác với tỷ lệ thành công 60% | 100M Haiku + 40M Sonnet | $285 | 40% |
Điều này cho bạn thấy. Ngay cả ở mức 70% thành công (nghĩa là Haiku làm đúng 7 trên 10 lần), chuỗi thác cắt hóa đơn một nửa. Lý do là cuộc gọi mô hình rẻ rẻ hơn rất nhiều so với cuộc gọi đầu bảng nên việc trả cho cả hai trên 30% truy vấn leo thang vẫn thấp hơn nhiều so với trả cho mô hình đầu bảng trên mọi truy vấn. Điểm hòa vốn (nơi chuỗi thác bằng chi phí một mô hình) vào khoảng 33% tỷ lệ thành công. Thấp hơn mức đó, đi trực tiếp tốt hơn; cao hơn, chuỗi thác thắng.
Triển khai chuỗi thác khả dụng tối thiểu
Dưới đây là phiên bản đơn giản nhất của mẫu này, viết bằng Python với client tương thích OpenAI (có thể chạy với bất kỳ nhà cung cấp nào phơi bày endpoint tương thích OpenAI, gồm Claude qua lớp tương thích của Anthropic, Gemini và endpoint hợp nhất của CometAPI). Cấu trúc được cố ý tối giản; triển khai production sẽ thêm quan sát, xử lý lỗi và kiểm tra chất lượng tinh vi hơn.
from openai import OpenAI
import json
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.cometapi.com/v1", # or your provider of choice
)
CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"
def cascade(messages, output_schema=None):
"""
Run a query through a cascade.
Returns (response, model_used, escalated).
"""
# Step 1: try the cheap model
cheap_response = client.chat.completions.create(
model=CHEAP_MODEL,
messages=messages,
response_format=output_schema,
)
cheap_text = cheap_response.choices[0].message.content
# Step 2: judge whether the cheap response is good enough
if is_acceptable(cheap_text, output_schema):
return cheap_text, CHEAP_MODEL, False
# Step 3: escalate to the flagship
flagship_response = client.chat.completions.create(
model=FLAGSHIP_MODEL,
messages=messages,
response_format=output_schema,
)
flagship_text = flagship_response.choices[0].message.content
return flagship_text, FLAGSHIP_MODEL, True
def is_acceptable(response_text, output_schema=None):
"""
Quality gate.
Returns True if the cheap model's output is good enough.
"""
if not response_text or len(response_text.strip()) < 10:
return False
if output_schema:
# Structured output: it has to parse against the schema
try:
parsed = json.loads(response_text)
return validate_schema(parsed, output_schema)
except (json.JSONDecodeError, ValueError):
return False
# For free-form responses, plug in your own quality signal:
# - confidence score from the model
# - self-evaluation prompt to a small model
# - rules-based checks (length, format, refusal patterns)
return True
Đây là điểm xuất phát, không phải triển khai hoàn chỉnh. Ba thứ bạn sẽ thêm cho production:
- Cổng chất lượng thực sự. Hàm is_acceptable ở trên được cố ý tối thiểu. Trên thực tế, cổng là phần quan trọng nhất của chuỗi thác: quá dễ dãi thì bạn phát hành câu trả lời kém chất lượng; quá nghiêm thì bạn leo thang quá thường xuyên và mất tiết kiệm. Hầu hết chuỗi thác production dùng kết hợp xác thực đầu ra cấu trúc, phát hiện từ chối (mô hình rẻ nói “tôi không thể trả lời cái này”), và tự-đánh giá bởi một mô hình nhỏ được nhắc để chấm điểm phản hồi.
- Quan sát theo từng yêu cầu. Log mô hình đã dùng, yêu cầu có leo thang hay không, độ trễ ở mỗi tầng, và chi phí. Đây là thứ cho bạn biết, sau một tuần chạy chuỗi thác, liệu tỷ lệ thành công có như bạn giả định.
- Đường canary để đánh giá. Gửi một tỷ lệ nhỏ lưu lượng (nói 5%) qua mô hình đầu bảng ngay cả khi chuỗi thác thành công ở tầng rẻ. So sánh phản hồi trên một tác vụ chấm điểm giữ lại. Đây là cách bạn phát hiện suy giảm chất lượng âm thầm; xem phần tiếp theo.
Những nơi định tuyến gặp trục trặc
Phép toán tiết kiệm chi phí ở trên là thật, nhưng cũng là trường hợp lạc quan. Ba chế độ lỗi khiến các đội ngã ngựa, và gọi tên chúng một cách thẳng thắn là thứ phân biệt một triển khai định tuyến tạo giá trị cộng dồn với một triển khai âm thầm làm suy giảm sản phẩm.
Độ trễ tăng thêm trên các yêu cầu leo thang
Khi truy vấn leo thang, bạn trả cho cuộc gọi mô hình rẻ trước khi cuộc gọi mô hình đầu bảng bắt đầu. Nếu mô hình rẻ mất 800ms và mô hình đầu bảng mất 1.5s, truy vấn leo thang mất 2.3s end-to-end. Với workload nhạy cảm độ trễ, điều này quan trọng. Các biện pháp giảm thiểu gồm chọn mô hình rẻ nhanh (Haiku 4.5 và Gemini 3 Flash được thiết kế cho việc này), đặt timeout quyết liệt cho cuộc gọi mô hình rẻ, và cân nhắc gọi song song với các truy vấn bạn nghi ngờ có khả năng cao sẽ leo thang. Một số đội chấp nhận chi phí độ trễ vì tiết kiệm tiền lớn; số khác dùng quy tắc tĩnh để tránh gửi những truy vấn rõ ràng là khó qua chuỗi thác.
Suy giảm chất lượng âm thầm
Chế độ lỗi hiểm hóc nhất. Mô hình rẻ tạo phản hồi vượt qua cổng chất lượng của bạn nhưng tinh tế kém hơn phản hồi của mô hình đầu bảng: kém chính xác một chút, kém hữu ích một chút, dễ bỏ sót các biên hơn. Người dùng không phàn nàn ngay; các chỉ số bạn theo dõi (độ trễ phản hồi, tỷ lệ lỗi, tỷ lệ qua cổng) đều trông ổn; nhưng các chỉ số hạ nguồn (giữ chân người dùng, tỷ lệ chuyển đổi, escalations hỗ trợ) trôi dạt. Khi bạn nhận ra, bạn đã phát hành nhiều tuần chất lượng suy giảm.
Phòng thủ là đường canary đã đề cập: một tỷ lệ lưu lượng giữ lại chạy qua mô hình đầu bảng song song với chuỗi thác, với cả hai phản hồi được chấm theo tiêu chí đánh giá. Việc chấm có thể do chính mô hình đảm nhiệm (LLM đóng vai trò giám khảo), hoặc bởi đánh giá thủ công lấy mẫu. Mấu chốt là duy trì một tín hiệu chất lượng liên tục độc lập với cổng của chuỗi thác, để suy giảm nổi lên như một độ lệch tín hiệu đó thay vì một bất ngờ hạ nguồn.
Chi phí phức tạp trong mã và khả năng quan sát
Mỗi mô hình bổ sung trong đồ thị định tuyến là thêm một mô hình cần đánh giá, giám sát và cập nhật khi nhà cung cấp phát hành phiên bản mới. Một chuỗi thác hai tầng là quản lý được; một bộ định tuyến dựa trên bộ phân loại với năm mô hình, đường đi riêng cho code, RAG, chat, agent và edge case phức tạp hơn đáng kể so với thiết lập một mô hình nó thay thế. Độ phức tạp đáng giá khi lưu lượng đủ lớn; dưới ngưỡng đó, thời gian kỹ sư dành cho việc duy trì lớp định tuyến có thể vượt khoản tiết kiệm nó tạo ra. Hãy trung thực về ngưỡng lưu lượng của bạn.
Bộ tổng hợp giúp gì (và không giúp ở đâu)
Bộ tổng hợp LLM (dịch vụ phơi bày nhiều mô hình phía sau một API tương thích OpenAI) tương tác với định tuyến theo hai cách riêng. Cả hai đều đáng hiểu vì câu trả lời cho “tôi có muốn một bộ tổng hợp trong lớp định tuyến của mình không?” phụ thuộc vào tương tác nào bạn quan tâm.
Lợi ích thực sự: loại bỏ “thuế” tích hợp
Xây một chuỗi thác hoặc bộ định tuyến dựa trên bộ phân loại trên API trực tiếp của nhà cung cấp đồng nghĩa quản lý nhiều SDK, nhiều thông tin xác thực, nhiều bề mặt thanh toán, và nhiều đặc thù theo nhà cung cấp (hành vi timeout, định dạng lỗi, ngữ nghĩa giới hạn tốc). Với một thiết lập định tuyến đa mô hình, chi phí này là thật. Một bộ tổng hợp như CometAPI phơi bày mọi mô hình phía sau một endpoint tương thích OpenAI duy nhất, nghĩa là thay đổi trong mã để định tuyến chỉ là đổi tham số model, không cần chuyển nhà cung cấp, không cần khóa riêng, không cần lớp quan sát riêng. Với các đội mà trở ngại chính cho định tuyến là chi phí tích hợp hơn là chi phí đánh giá chất lượng, đây là quyết định.
Điều cần thận trọng: lớp định tuyến tích hợp sẵn
Một số bộ tổng hợp cung cấp tính năng “smart routing” hoặc “model optimiser” chọn mô hình cho bạn dựa trên truy vấn. Điều này hữu ích khi dựng thử nhưng thường là mặc định sai cho production. Lý do là quyết định định tuyến là một trong những thứ phụ thuộc workload nhất trong stack của bạn: cái gì được coi là “đủ khó để leo thang” phụ thuộc tiêu chí đánh giá, ngân sách độ trễ, tiêu chuẩn chất lượng và trần chi phí của bạn. Một lớp định tuyến chung không thể biết các yếu tố này. Hầu hết hệ thống production phù hợp hơn với một bộ tổng hợp mỏng, minh bạch (phơi bày cùng mô hình bạn sẽ truy cập trực tiếp, với một thông tin xác thực và một hóa đơn) cộng với logic định tuyến riêng bên trên, hơn là một lớp định tuyến hộp đen không thể tinh chỉnh.
Lộ trình chuyển đổi
Một con đường an toàn, từng bước từ workload production một mô hình sang có định tuyến. Nguyên tắc xuyên suốt là thực hiện các thay đổi có thể đảo ngược riêng lẻ và đo tác động của từng thay đổi trước khi làm bước tiếp.
- Instrument workload hiện tại. Log mọi yêu cầu với model, token vào/ra, chi phí, độ trễ, và nhãn loại truy vấn. Chạy ít nhất một tuần để có đường cơ sở. Không có cái này, mọi bước sau đều là đoán.
- Xây tập đánh giá. Chọn 100–500 truy vấn đại diện với đầu ra tham chiếu bạn tin cậy. Đây là tập giữ lại bạn sẽ dùng để so sánh chuỗi thác với đường cơ sở một mô hình ở mọi bước.
- Xác định loại truy vấn có lưu lượng cao nhất. Từ dữ liệu instrument, tìm hạng mục truy vấn chiếm nhiều lưu lượng nhất. Đây là nơi bạn sẽ thử nghiệm chuỗi thác. Không nhất thiết phải là hạng mục dễ nhất, chỉ cần lưu lượng cao nhất, vì tiết kiệm tập trung ở đó.
- Dựng nguyên mẫu chuỗi thác cho chính hạng mục đó. Hai tầng: mô hình rẻ trước, mô hình đầu bảng nếu trượt cổng chất lượng. Chạy trên tập đánh giá trước. So sánh chi phí và chất lượng với đường cơ sở một mô hình. Nếu chất lượng giữ và chi phí giảm, tiếp tục; nếu chất lượng giảm, siết cổng và thử lại.
- Triển khai sau một tỷ lệ lưu lượng. Bắt đầu với 5–10% lưu lượng production cho hạng mục chọn. Chạy ít nhất một tuần. Giám sát tỷ lệ leo thang của chuỗi thác, chi phí mỗi yêu cầu, độ trễ ở mỗi tầng, và so sánh chất lượng của đường canary. Nếu các chỉ số khớp dự đoán của nguyên mẫu, mở rộng lên 25%, rồi 50%, rồi 100%.
- Lặp cho loại truy vấn tiếp theo. Khi hạng mục đầu tiên đã chuyển hoàn toàn và hiện thực hóa tiết kiệm, chuyển sang hạng mục lưu lượng cao kế tiếp. Mỗi chuỗi thác là một quyết định riêng; đừng giả định một mẫu hiệu quả cho một hạng mục sẽ hiệu quả cho hạng mục khác.
- Thêm canary chất lượng liên tục. Khi nhiều hạng mục chạy trên chuỗi thác, thiết lập đường canary giữ lại vĩnh viễn, với 5% lưu lượng chạy qua mô hình đầu bảng để chấm. Đây là hệ thống cảnh báo sớm cho suy giảm âm thầm, và là thứ giữ cho lớp định tuyến đáng tin khi các mô hình cập nhật.
Khi định tuyến không đáng
Thừa nhận thẳng thắn. Có những workload mà đầu tư kỹ thuật cho định tuyến không hoàn vốn, và nhận ra sớm sẽ tiết kiệm thời gian:
- Workload một mô hình nơi một mô hình thực sự là câu trả lời đúng cho mọi thứ. Nếu tập đánh giá của bạn cho thấy sụt giảm chất lượng đáng kể ở tầng mô hình rẻ trên toàn bộ workload, chuỗi thác không có gì để khai thác. Một workload sinh mã bị giới hạn bởi năng lực suy luận là ví dụ: Haiku sẽ trượt cổng quá thường xuyên nên chuỗi thác không tiết kiệm.
- Workload lưu lượng rất thấp. Dưới khoảng $200/tháng chi tiêu LLM, thời gian kỹ sư xây và duy trì lớp định tuyến thường vượt khoản tiết kiệm tạo ra. Ngưỡng này phụ thuộc workload, nhưng là có thật. Hãy trung thực xem chi tiêu có đủ lớn để biện minh công việc không.
- Môi trường chịu quy định nơi vendor-of-record là điều quan trọng. Nếu tư thế tuân thủ của bạn yêu cầu toàn bộ lưu lượng production đi qua một mối quan hệ nhà cung cấp cụ thể, định tuyến đa mô hình làm phức tạp câu chuyện. Có thể vẫn có lựa chọn định tuyến trong cùng nhà cung cấp (Sonnet → Opus trên Anthropic; GPT-5 nano → GPT-5.5 trên OpenAI), nhưng định tuyến chéo nhà cung cấp khó biện minh hơn.
Cách đóng khung trung thực: định tuyến hoàn vốn khi workload của bạn có lưu lượng lớn, truy vấn không đồng đều về độ khó, và bạn có hạ tầng đánh giá để biết khi nào chuỗi thác tạo ra chất lượng chấp nhận được. Hầu hết workload production ở quy mô đáng kể khớp mô tả này; một số thì không, và phát hành nhanh hơn bằng cách gắn với một mô hình. Cả hai lựa chọn đều có thể bảo vệ.
Tiếp theo nên làm gì: Nếu bạn chưa xem qua bảng giá theo mô hình mà bài viết này dựa vào, bài đi kèm, So sánh giá API LLM năm 2026: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash và DeepSeek V4, là nền tảng. Dữ liệu định giá ở đó là thứ làm phép toán chi phí trong hướng dẫn này trở nên cụ thể với workload của bạn.