LLM Router: Định Tuyến Request, Cắt 60% Chi Phí [2026]

LLM Router: Định Tuyến Request, Cắt 60% Chi Phí [2026]

LLM router là một lớp mỏng nằm giữa ứng dụng của bạn và một vài language model, có nhiệm vụ chọn model nào xử lý từng request. Nó xem xét request (loại tác vụ, độ phức tạp, ngân sách token), chuyển tiếp đến model phù hợp nhất, và chuyển sang model dự phòng nếu model kia lỗi. Mục tiêu: câu trả lời đúng tầm với chi phí token thấp nhất.

Trả tiền cho model frontier để trả lời "chính sách hoàn tiền của bạn là gì?" là cách hóa đơn phình to. AWS đã đo phương án thay thế vào tháng 4 năm 2025: router dạng classifier thêm 0,53 giây độ trễ, router ngữ nghĩa thêm 0,10 giây, và giảm tới 30% hóa đơn khi định tuyến trong cùng một họ model. Tính lại bài toán đó xuyên suốt các nhà cung cấp với bảng giá tháng 7 năm 2026, như chúng tôi làm bên dưới, mức cắt giảm chạm 70%. Phần lớn khoản tiết kiệm đến từ một quyết định duy nhất, được đưa ra trước khi một token nào được sinh ra.

Ý Chính

• LLM router quyết định model nào xử lý từng request, dựa trên loại tác vụ, chi phí, hoặc chất lượng đã đo.
• Có năm chiến lược: theo luật, theo chi phí, theo độ trễ, ngữ nghĩa (embedding), và định tuyến bằng classifier LLM.
• Định tuyến theo luật thêm ~0 ms và $0; định tuyến bằng classifier thêm 300-800 ms cộng chi phí token của classifier cho mỗi request.
• Định tuyến có thể cắt tới 60% chi tiêu token khi phần lớn lưu lượng đơn giản chuyển sang model rẻ hơn 10-20 lần.
• Một nhà cung cấp duy nhất, dưới 10k request mỗi ngày, không áp lực chi phí? Bỏ qua router. Fallback đơn thuần là đủ.

LLM Router Thực Sự Làm Gì?

LLM router chạy một bước quyết định nhỏ trước mỗi lệnh gọi model: đọc request, chấm điểm theo một luật định tuyến, chọn model, gửi lệnh gọi, và thử lại trên fallback nếu model đầu tiên lỗi. Không có gì khác trong ứng dụng của bạn thay đổi. Bạn vẫn gửi một request và nhận về một phản hồi.

Vòng đời của request, theo thứ tự:

1. Request đến endpoint của router, y hệt như khi nó đến API của model.
2. Phân tích. Router xem xét prompt: từ khóa, số token, một embedding, hoặc điểm từ classifier.
3. Chọn. Chiến lược định tuyến ánh xạ tín hiệu đó sang một tầng model (rẻ, trung, frontier, hoặc local).
4. Chuyển tiếp. Lệnh gọi đi tới model đã chọn qua một API tương thích OpenAI.
5. Fallback. Khi hết thời gian chờ, chạm giới hạn tốc độ, hoặc lỗi, request được thử lại ở tầng kế tiếp trong chuỗi.

Mọi người hay tìm "llm gateway vs router" vì tài liệu của các nhà cung cấp làm mờ hai thuật ngữ này. Một câu là đủ rõ: gateway là đường ống; router là quyết định. Chúng là các lớp, không phải đối thủ, và hầu hết gateway đều nhúng một router bên trong.

Theo tài liệu của LiteLLM, chính cái proxy giữ virtual key của bạn cũng đồng thời chạy router. Muốn so sánh riêng các công cụ cấp đường ống? Bài tổng hợp công cụ LLM gateway tốt nhất của chúng tôi xếp hạng mười công cụ.

Bạn Có Thực Sự Cần LLM Router Không?

Hầu hết ứng dụng nhỏ thì không. Router đáng công khi lưu lượng chia thành các loại tác vụ rõ ràng khác biệt, khi hóa đơn token là khoản hạ tầng lớn nhất của bạn, hoặc khi bạn chạy nhiều hơn một nhà cung cấp và cần failover. Dưới các ngưỡng đó, retry đơn thuần cộng một model fallback mua cho bạn độ tin cậy mà không cần thêm bộ phận chuyển động.

Nói thẳng, vì trong ngành này chẳng ai khác chịu nói: nếu bạn chạy một nhà cung cấp với dưới 10k request mỗi ngày, router là phần thừa bạn không cần. Fallback đơn thuần thắng.

Vì sao phải thẳng vậy? Mỗi route là một lời khẳng định ("lớp tác vụ này an toàn trên model rẻ") và nó mục dần khi model, giá, và sản phẩm của bạn thay đổi. Chỉ mua chi phí bảo trì đó khi khoản tiết kiệm rõ ràng lớn hơn nó.

5 Chiến Lược Định Tuyến LLM (Và Khi Nào Dùng Từng Loại)

Mọi chiến lược định tuyến LLM đều trả lời một câu hỏi: tín hiệu nào đủ tin cậy để bạn chọn model? Luật tin vào từ khóa. Định tuyến chi phí tin vào ngân sách token. Định tuyến độ trễ tin vào đồng hồ bấm giờ. Định tuyến ngữ nghĩa tin vào embedding. Định tuyến bằng classifier tin vào một LLM khác. Sự đánh đổi luôn cùng một hình dạng: tín hiệu chất lượng hơn thì thêm độ trễ và chi phí cho mỗi request.

Các công cụ gợi ý tự động hay hiển thị những truy vấn như "llm routing strategies", "llm task routing", "llm intent routing", và "llm dynamic routing". Chúng ánh xạ thành năm pattern:

Một pattern cắt ngang cả năm: cascade, còn gọi là phân tầng model. Bắt đầu rẻ và chỉ nâng cấp khi thất bại hoặc độ tin cậy thấp. Bot hỗ trợ trả lời từ model giá $0,25 mỗi triệu token; nếu độ tin cậy tụt dưới 0,7, chính request đó được thử lại trên model frontier. Bạn chỉ trả tiền cho trí thông minh khi tầng rẻ thừa nhận nó bế tắc.

Về chiều sâu học thuật, thư viện LLMRouter của ulab-uiuc liệt kê hơn 16 thuật toán định tuyến đã được nghiên cứu (KNN, SVM, MLP, matrix factorization, Elo, graph, và dạng BERT). Nếu định tuyến ngữ nghĩa là lựa chọn của bạn, các embedding mẫu quyết định gần như mọi thứ; bài model embedding tốt nhất của chúng tôi nói rõ những model nào trụ vững trên corpus thực tế.

Xây LLM Router Bằng Python Như Thế Nào?

Bạn xây nó với khoảng 80 dòng Python thuần, chạy với bất kỳ endpoint nào tương thích OpenAI. Không cần framework. Bốn router bên dưới tăng dần về độ tinh vi: luật từ khóa, ngưỡng chi phí, độ giống embedding, và model classifier kèm failover. Mỗi router đều in ra model nó đã chọn, để bạn xem quyết định diễn ra.

Nếu bạn từng tìm "how to build an llm router" và chỉ thấy toàn stack AWS CDK với repo học thuật, thì phần này chính là câu trả lời mộc. Reference implementation của AWS chắc chắn nhưng hàn chặt vào Bedrock, Lambda, và CDK. Bản của chúng tôi chạy ở bất cứ đâu client OpenAI trỏ tới: OpenAI, Anthropic qua proxy, Ollama trên laptop, vLLM trên máy GPU. Đây là router chúng tôi phác cho khách hàng trước tiên.

Bước 1: Router theo luật (từ khóa sang model)

Baseline zero độ trễ. Một bản đồ regex quyết định; mọi thứ không khớp thì sang tầng frontier.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Đầu vào: một câu hỏi hỗ trợ. Quyết định: regex khớp "cancel". Model được chọn: gpt-5-mini. Không cần lệnh gọi API nào để định tuyến nó, đó là lý do đây vẫn là mặc định.

Bước 2: Router theo chi phí (ngưỡng ngân sách token)

Cùng ý tưởng, nhưng tín hiệu là kích thước request thay vì từ khóa. Prompt ngắn với ngân sách đầu ra nhỏ thì đi đường rẻ; mọi thứ khác sang frontier.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Thô? Đúng. Hiệu quả? Cũng đúng, vì lượng token tương quan với kích thước tác vụ tốt hơn hầu hết mọi người nghĩ. Đây là toàn bộ chiến lược đằng sau vài sản phẩm "cheap llm router" trả phí.

Bước 3: Router ngữ nghĩa (embedding so với mẫu chuẩn)

Với đầu vào người dùng mơ hồ, né tránh từ khóa, hãy embed prompt và so nó với các prompt mẫu đã embed. Cụm nào gần nhất thì sở hữu request.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

Lệnh gọi định tuyến tốn một embedding (vài trăm token) và 50-150 ms. Tính sẵn các centroid lúc khởi động, đừng tính mỗi request.

Bước 4: Router dùng classifier LLM kèm fallback

Tín hiệu mạnh nhất: một model rẻ đọc prompt và chấm độ khó. Đây là chiến lược AWS đo được 0,53 giây độ trễ thêm, nên chúng tôi bọc nó trong một chuỗi fallback.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Đó là toàn bộ ví dụ llm router: bốn hàm, một client, không hạ tầng nào ngoài những gì bạn đã chạy. Hardening cho production là phần kế tiếp.

Định Tuyến LLM Thực Sự Tiết Kiệm Bao Nhiêu?

AWS đo chi phí của router ở mức $107,90-$188,90 mỗi tháng cho 100.000 câu hỏi mỗi ngày, trong đó định tuyến bằng classifier thêm 0,53 giây mỗi request và định tuyến ngữ nghĩa thêm 0,10 giây. Phía tiết kiệm áp đảo chi phí đó. Ví dụ tính toán bên dưới của chúng tôi, dựng trên bảng giá tháng 7 năm 2026, ra mức giảm 70,7% chi tiêu. Cái bẫy là cấu trúc lưu lượng: bạn cần phần lớn request đủ điều kiện vào tầng rẻ.

Hai bảng. Trước tiên, bản thân router khiến bạn tốn bao nhiêu cho mỗi 1.000 request:

Bài viết tháng 4 năm 2025 của AWS là bộ đo lường độc lập duy nhất được công bố trong lĩnh vực này, nên chúng tôi neo vào đó và dán nhãn các phần mở rộng của mình là ước tính, không phải số chúng tôi tự chạy. Theo AWS, Bedrock Intelligent Prompt Routing cắt tới 30% chi phí trong cùng một họ model.

Thứ hai, ví dụ tính toán tiết kiệm chống lưng cho tiêu đề của chúng tôi:

Các giả định, đã dán nhãn: 100.000 request mỗi tháng; trung bình 800 token đầu vào cộng 200 token đầu ra mỗi request; tỷ lệ 80% đơn giản / 20% phức tạp; bảng giá từ trang giá của Anthropic và trang giá của OpenAI tính đến tháng 7 năm 2026, với bảng giá đầy đủ trong bài so sánh giá API LLM của chúng tôi. Toán mỗi request: Sonnet 4 tốn 800 x $3/M + 200 x $15/M = $0,0054; GPT-5 mini tốn 800 x $0,25/M + 200 x $2/M = $0,0006.

Kết quả là mức giảm 70,7%, đó là nguồn gốc con số 60% trong tiêu đề của chúng tôi, và còn dư dả biên. Những lưu ý thành thật: đây là ví dụ tính toán, không phải benchmark chúng tôi tự chạy. Nó giả định tầng rẻ của bạn rẻ hơn 10-20 lần và 80% lưu lượng thực sự đủ điều kiện. Định tuyến trong cùng một họ model, kịch bản của AWS, chỉ loanh quanh 30%. Và định tuyến chỉ là một trong nhiều đòn bẩy; prompt caching và cắt gọn thường hoàn vốn nhanh hơn, và bài giảm chi phí API LLM của chúng tôi xếp hạng cả mười hai cách.

Các Pattern Định Tuyến Trong Production

Router đồ chơi thì chọn model. Router production còn retry, cân bằng tải, cache các lần lặp lại, và cô lập API key theo từng team. Vượt qua vài nghìn request mỗi ngày, hãy ngừng tự viết những thứ đó và chạy một gateway có nhúng router.

Bốn pattern đáng kể:

• Chuỗi fallback. Tầng rẻ trước, frontier khi lỗi hoặc hết thời gian chờ. Pattern giá trị nhất; phần lớn độ tin cậy của bạn đến từ riêng nó.
• Cân bằng tải. Rải lệnh gọi qua các deployment hoặc API key nhân bản để né giới hạn tốc độ trên từng key.
• Cache phản hồi. Prompt giống hệt nhau trả về câu trả lời đã cache. Lưu lượng hỗ trợ lặp lại nhiều hơn bạn tưởng; tỷ lệ trúng 10-30% là thường.
• Virtual key và ngân sách. Cấp key theo từng team với trần hàng tháng để một vòng lặp mất kiểm soát không thể đốt cháy cả hóa đơn.

Đây gần với cấu hình chúng tôi chạy trên stack agent staging của mình (file: litellm-router.yaml, mount vào container LiteLLM proxy):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Mỗi công cụ hợp với đâu, kèm quan điểm:

• LiteLLM. Chọn nếu bạn muốn tự host, mã nguồn mở, và đã chạy Docker. Bài hướng dẫn dựng LiteLLM proxy của chúng tôi đi qua toàn bộ deployment, gồm cả key và ngân sách.
• OpenRouter. Chọn nếu bạn muốn hàng trăm model sau một key và zero vận hành. Trang xếp hạng của họ kiêm luôn dữ liệu throughput.
• Portkey. Chọn nếu yêu cầu doanh nghiệp (SSO, audit log, báo cáo tuân thủ) chi phối quyết định.
• Code tự viết từ bài này. Chọn nếu bạn dưới ~50k request mỗi ngày và muốn zero hạ tầng mới.

Dù bạn chọn gì, bài tổng hợp công cụ LLM gateway so sánh đối đầu mười công cụ.

Có Thể Định Tuyến Giữa Model Local Và API Hosted Không?

Được, và bài toán token rất quyến rũ: model local tính $0 mỗi token, nên mọi request mà Ollama hoặc vLLM trả lời đều là tiết kiệm ròng. Sự đánh đổi là độ trễ và chất lượng trên mỗi watt. Local thắng ở các tác vụ đơn giản, lưu lượng lớn trên phần cứng bạn đã sở hữu; API hosted hứng mọi thứ cần bộ não frontier.

Cơ chế thì chẳng có gì kịch tính, và đó chính là điểm hay. Ollama phơi một endpoint tương thích OpenAI tại localhost:11434/v1, và vLLM phục vụ cùng hình dạng. Nên mọi router ở trên hoạt động không đổi: trỏ base_url vào server local, đặt qwen3:8b vào ô rẻ, và giữ gpt-5 làm tầng fallback. Cho một hộp router tự host, LiteLLM có sẵn Docker image, đó chính là setup "llm router docker" mà mọi người tìm.

Hai lưu ý thành thật. Model 70B trên một A100 phục vụ khoảng 30-40 token mỗi giây; API hosted thắng về throughput bùng phát, nên định tuyến local hợp với lưu lượng nền đều đặn hơn là chat dành cho người dùng vốn tăng đột biến. Và model 8B local lúng túng với lệnh gọi tool nhiều bước, nên giữ các route khó trỏ về cloud. Nếu bạn đang chọn chính engine phục vụ, bài vLLM vs SGLang benchmark cả hai.

Định tuyến cũng tiếp sức cho các setup coding-agent đa model. Proxy kiểu LiteLLM để Claude Code nói chuyện với model local và hosted qua một endpoint duy nhất; xem cách dùng các model khác nhau trong Claude Code để biết cách đấu dây chính xác.

Làm Sao Biết Định Tuyến Có Hiệu Quả Không?

Bạn đo nó, hoặc bạn đang đoán. Log lại model nào đã trả lời từng request, chấm điểm một mẫu đầu ra theo một rubric, và nạp điểm số ngược vào luật định tuyến. Các team bỏ qua bước này rốt cuộc có một cấu hình tĩnh, âm thầm mục ruỗng khi model và giá thay đổi bên dưới nó.

Lộ trình trưởng thành chạy luật, rồi chi phí, rồi chất lượng đã đo:

1. Log route. Lưu model được chọn, độ trễ, và số token mỗi request thành một cột trong trace hiện có của bạn.
2. Chấm điểm đầu ra hàng tuần. LLM judge hoặc mẫu người chấm, đậu/rớt theo từng lớp request. Năm mươi đầu ra được chấm mỗi lớp là đủ để điều hướng.
3. Tinh chỉnh lại. Nếu tầng rẻ đậu 95%+ ở một lớp, hãy nới luật của nó để hứng thêm lưu lượng đó. Nếu nó tụt dưới 90%, siết lại.

Đây là câu chúng tôi lặp đi lặp lại với khách hàng: router không bao giờ được tinh chỉnh lại chỉ là một cấu hình tĩnh có thêm độ trễ. Log model được chọn, chấm điểm đầu ra, nạp điểm số ngược lại.

Vòng lặp đó chính là eval cộng observability áp dụng vào định tuyến. Bài hướng dẫn eval LLM của chúng tôi nói về rubric chấm điểm; bài hướng dẫn observability AI nói về nơi trace nằm.

Nghiên Cứu Về Định Tuyến LLM Đang Đi Về Đâu?

Giới học thuật coi định tuyến là một bài toán học máy, không phải một file cấu hình. LLMRouter của ulab-uiuc, thư viện xếp hạng nhất cho từ khóa này, cài đặt hơn 16 thuật toán (KNN, SVM, MLP, matrix factorization, Elo, graph, BERT, và router RL) với pipeline benchmark trên 11 dataset. Bài báo gần đây được trích dẫn nhiều nhất, RouteLLM (Ong và cộng sự, arXiv:2406.18665), huấn luyện router trên dữ liệu sở thích của con người và báo cáo mức giảm chi phí hơn 2 lần mà không mất chất lượng trên MMLU và MT-Bench. Điểm mới nhất: router prefill-activation, nhánh "prefill is all you need", đọc các activation nội bộ của model trong lúc prefill để dự đoán độ khó trước khi quá trình sinh bắt đầu. Hướng đi là những router tự huấn luyện từ dữ liệu eval của bạn, chính xác là vòng lặp phản hồi từ phần trước.

Cách Techsy tiếp cận chuyện này: các stack agent chúng tôi giao cho khách hàng B2B chạy chính xác pattern này, một router theo tầng chi phí với chuỗi fallback đấu vào gateway, cộng tinh chỉnh theo eval. Nếu bạn đang cân nhắc liệu định tuyến có hợp với stack của mình, hãy nhận tư vấn miễn phí và chúng tôi sẽ cùng bạn lập bản đồ cấu trúc lưu lượng.

Về Tác Giả

Mert Batur là Đồng sáng lập Techsy.io, nơi team giao các AI agent, hệ thống tự động hóa, và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà team Techsy thực sự dùng trong production. Kết nối trên LinkedIn.

Câu Hỏi Thường Gặp

LLM router là gì?

LLM router là một lớp nằm giữa ứng dụng của bạn và nhiều language model, quyết định model nào xử lý từng request. Nó kiểm tra loại tác vụ, kích thước, hoặc độ khó của request, rồi chuyển tiếp đến model phù hợp nhất, kèm fallback nếu model đó thất bại. Hãy coi nó như người điều phối giao thông cho các lệnh gọi API model của bạn.

Định tuyến LLM hoạt động thế nào?

Định tuyến LLM hoạt động qua năm bước: request đến, router xem xét nó (từ khóa, số token, hoặc một embedding), một chiến lược chọn tầng model, lệnh gọi được chuyển tiếp, và một model fallback hứng mọi thất bại. Toàn bộ quyết định diễn ra trước khi quá trình sinh bắt đầu, nên nó chỉ thêm mili giây, không phải giây, trừ khi một model classifier đứng ra chấm điểm.

LLM router có giống LLM gateway không?

Không. Gateway là đường ống: API key, giới hạn tốc độ, ngân sách, và log. Router là quyết định: model nào trả lời. Chúng là các lớp, không phải đối thủ, và hầu hết gateway (LiteLLM, Portkey, OpenRouter) đều nhúng một router bên trong. Bạn có thể chạy router mà không cần gateway, nhưng trong production bạn thường muốn cả hai đi cùng nhau.

Định tuyến model có thực sự tiết kiệm tiền không?

Có, khi phần lớn lưu lượng của bạn đủ điều kiện vào một tầng rẻ hơn nhiều. Ví dụ tính toán của chúng tôi chuyển 80% request từ model giá $3/$15 mỗi triệu token sang model $0,25/$2 và cắt 70,7% hóa đơn. AWS báo cáo tới 30% cho định tuyến trong cùng một họ model. Nếu lưu lượng của bạn đồng đều phức tạp, khoản tiết kiệm co về zero.

LLM router mã nguồn mở tốt nhất là gì?

Cho production, LiteLLM: tự host, được bảo trì tích cực, và kết hợp gateway với router. Cho thuật toán cấp nghiên cứu, LLMRouter của ulab-uiuc cài đặt hơn 16 chiến lược định tuyến từ tài liệu học thuật. RouteLLM là router có chất lượng trên mỗi đô la mạnh nhất được huấn luyện trên dữ liệu sở thích. Hầu hết các team nên bắt đầu với LiteLLM và chỉ với tới các thư viện nghiên cứu khi cần chấm điểm tùy biến.

Xây LLM router bằng Python thế nào?

Bắt đầu với client OpenAI và khoảng 80 dòng code: một bản đồ luật từ từ khóa sang model, một ngưỡng chi phí trên số token, độ giống embedding với prompt mẫu, hoặc một model classifier rẻ chấm độ khó. Cả bốn pattern đều có ở phần xây dựng bên trên, chạy được với OpenAI, Ollama, hoặc vLLM mà không cần sửa gì.

Có thể định tuyến giữa model local và API cloud không?

Được. Ollama (localhost:11434/v1) và vLLM đều phơi endpoint tương thích OpenAI, nên cùng một code router trỏ vào model local cho lưu lượng rẻ và API hosted cho lưu lượng khó. Token local giá $0, nhưng bạn sở hữu phần cứng và độ trễ. Đây là pattern đằng sau hầu hết setup Claude Code đa model.

Định tuyến ngữ nghĩa là gì?

Định tuyến ngữ nghĩa embed mỗi prompt đến và so nó với các prompt mẫu đã embed, gửi request đến model sở hữu cụm mẫu gần nhất. Nó xử lý đầu vào người dùng mơ hồ, đã paraphrase mà luật từ khóa bỏ sót, với cái giá 50-150 ms cộng token embedding mỗi request. AWS đo được 0,10 giây độ trễ thêm.

Router dùng classifier LLM thêm bao nhiêu độ trễ?

AWS đo được 0,53 giây độ trễ thêm cho phân loại có LLM hỗ trợ, so với 0,10 giây của định tuyến ngữ nghĩa. Định tuyến theo luật và theo chi phí thêm xấp xỉ zero, vì chúng là đường code thuần. Nếu sản phẩm của bạn có SLA thời gian phản hồi ngặt, hãy ưu tiên luật, ngưỡng chi phí, hoặc embedding, và dành classifier cho workload offline hoặc xếp hàng.

Nguồn

• Seifi, N. and Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (accessed July 30, 2026)
• AWS sample code: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (accessed July 30, 2026)
• LiteLLM documentation. https://docs.litellm.ai (accessed July 30, 2026)
• Anthropic pricing. https://www.anthropic.com/pricing (accessed July 30, 2026)
• OpenAI API pricing. https://openai.com/api/pricing (accessed July 30, 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (accessed July 30, 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (accessed July 30, 2026)
• OpenRouter rankings. https://openrouter.ai/rankings (accessed July 30, 2026)