LLM Gateway so với Router so với Inference Provider: Ranh giới kiến trúc

LLM gateway, router và inference provider là ba lớp khác nhau trong ngăn xếp phục vụ mô hình (model-serving stack), và việc nhầm lẫn giữa chúng là sai lầm phổ biến nhất mà các đội ngũ thường mắc phải khi thiết kế kiến trúc cho các sản phẩm AI. Gateway nằm gần ứng dụng của bạn nhất và xử lý xác thực, chuẩn hóa và khả năng quan sát (observability); router quyết định mô hình hoặc nhà cung cấp nào sẽ xử lý một yêu cầu nhất định; còn inference provider là thực thể thực sự chạy các trọng số (weights) và trả về các token.

Việc xác định sai ranh giới này dẫn đến các tích hợp thiếu linh hoạt: các đội ngũ lập trình cứng (hardcode) SDK của một nhà cung cấp duy nhất, rồi vài tháng sau mới phát hiện ra rằng việc thêm một mô hình dự phòng hoặc so sánh chi phí giữa Claude Sonnet 5, GPT-5.5 và DeepSeek V4 Flash đồng nghĩa với việc phải viết lại phần lớn logic xử lý yêu cầu. Bài viết này phân tách ba lớp, chỉ ra nơi các trách nhiệm thực sự nằm ở đó và cung cấp một khung quyết định để đánh giá các nhà cung cấp trong từng danh mục.

Các điểm chính cần lưu ý

• Inference provider chạy các trọng số mô hình và cung cấp API (OpenAI, Anthropic, Google, DeepSeek hoặc một engine tự lưu trữ như vLLM); router lựa chọn giữa các nhà cung cấp hoặc mô hình cho mỗi yêu cầu; gateway là lớp hướng ứng dụng giúp thống nhất xác thực, định dạng, ghi nhật ký và chuyển đổi dự phòng (failover) trên cả hai lớp kia.
• Logic định tuyến (lựa chọn dựa trên chi phí, độ trễ hoặc khả năng) có thể tồn tại như một dịch vụ độc lập hoặc là một tính năng bên trong gateway; nó không phải là chính bản thân gateway.
• Việc tự lưu trữ (self-hosting) một inference provider, sử dụng nhà cung cấp dựa trên API và sử dụng gateway đa nhà cung cấp không loại trừ lẫn nhau; các hệ thống sản xuất thường kết hợp cả ba tùy thuộc vào mô hình và khối lượng công việc.
• Hãy đánh giá các nhà cung cấp bằng cách hỏi xem họ thực sự hoạt động ở lớp nào, vì một sản phẩm được quảng bá là "router" có thể chỉ định tuyến giữa các endpoint tương thích với OpenAI mà họ không lưu trữ, trong khi một "gateway" có thể bao gồm cả định tuyến cộng với các tính năng quản trị mà bạn có thể chưa cần đến.

Inference Provider thực sự làm gì?

Inference provider là lớp sở hữu các trọng số mô hình, GPU (hoặc các bộ tăng tốc tương đương) và engine phục vụ cấp thấp. Điều này bao gồm các nhà cung cấp API thương mại như Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI (GPT-5.5), Google (Gemini 3.5 Flash), Zhipu (GLM-5.2) và DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash), cũng như các triển khai tự lưu trữ của các mô hình mở như Qwen3.7 Plus, MiniMax M3 hoặc Kimi K2.7 Code.

Nếu bạn tự lưu trữ, lớp inference provider là phần mềm do chính bạn vận hành. Tài liệu phục vụ của vLLM mô tả một engine suy luận được xây dựng dựa trên cơ chế batching liên tục và xử lý attention tiết kiệm bộ nhớ để phục vụ khối lượng công việc LLM ở quy mô lớn, đây là loại thành phần nằm ngay dưới một triển khai mô hình tự lưu trữ. Việc chạy vLLM (hoặc một engine tương đương) biến bạn thành inference provider cho mô hình đó, chịu trách nhiệm lập kế hoạch dung lượng GPU, mở rộng và thời gian hoạt động, đổi lại bạn có quyền kiểm soát chi phí và vị trí dữ liệu.

Nếu bạn sử dụng API thương mại, cơ sở hạ tầng và giới hạn tốc độ (rate limit) của nhà cung cấp sẽ trở thành ràng buộc của bạn. Mỗi nhà cung cấp có lược đồ xác thực, lược đồ yêu cầu và phản hồi, mã lỗi và hành vi giới hạn tốc độ riêng. Đây là lớp mà chất lượng mô hình, cửa sổ ngữ cảnh (context window) và độ trễ thô thực sự được xác định. Không router hay gateway nào có thể thay đổi khả năng của một inference provider; chúng chỉ thay đổi cách bạn tiếp cận nhà cung cấp đó.

Router làm gì?

Router là logic quyết định chọn đích đến, mô hình hoặc nhà cung cấp cho một yêu cầu gửi đến. Việc định tuyến có thể xảy ra trên nhiều trục: chi phí (gửi các truy vấn đơn giản đến mô hình rẻ như DeepSeek V4 Flash hoặc Gemini 3.5 Flash, dành riêng Claude Opus 4.8 cho các truy vấn phức tạp), độ trễ (ưu tiên nhà cung cấp nào hiện đang phản hồi nhanh nhất cho một mô hình nhất định) hoặc tính khả dụng (chuyển sang nhà cung cấp thứ hai nếu nhà cung cấp đầu tiên bị suy giảm hiệu năng).

Giải thích công khai của OpenRouter về định tuyến mô hình mô tả mô hình này ở cấp độ mô hình: các yêu cầu cho một mô hình mở có thể được định tuyến qua nhiều nhà cung cấp lưu trữ cùng các trọng số đó, vì vậy một lệnh gọi mô hình logic duy nhất có thể được thực hiện bởi bất kỳ backend nào trong số đó. Tài liệu lựa chọn nhà cung cấp của OpenRouter mô tả thêm các tham số để thể hiện ưu tiên thứ tự và loại trừ các nhà cung cấp cụ thể khỏi việc xem xét, đây là cơ chế mà người gọi thể hiện ý định định tuyến một cách rõ ràng thay vì để hoàn toàn cho nền tảng quyết định.

Điểm kiến trúc quan trọng là định tuyến là một chính sách, không phải là một danh mục sản phẩm tự thân. Bạn có thể tự triển khai định tuyến cơ bản trong mã ứng dụng (một câu lệnh if/else đơn giản dựa trên loại tác vụ hoặc vòng lặp thử lại khi có lỗi), mua nó dưới dạng lớp định tuyến chuyên dụng hoặc nhận nó được tích hợp bên trong một gateway rộng hơn. Hãy đánh giá khả năng định tuyến bằng cách hỏi xem nó sử dụng các tín hiệu nào (giá, độ trễ, tỷ lệ lỗi, khả năng mô hình) và liệu các tín hiệu đó có thể cấu hình được hay cố định.

Gateway làm gì?

Gateway là lớp mà mã ứng dụng của bạn thực sự giao tiếp. Công việc của nó là cung cấp một giao diện nhất quán bất kể inference provider nào cuối cùng phục vụ yêu cầu đó. Một gateway thường bao gồm:

• Lược đồ yêu cầu và phản hồi thống nhất giữa các nhà cung cấp, vì vậy việc chuyển từ GPT-5.5 sang Claude Sonnet 5 không yêu cầu viết lại logic phân tích cú pháp của bạn.
• Quản lý xác thực và khóa, để thông tin xác thực của nhà cung cấp không bị rải rác khắp mã ứng dụng.
• Ghi nhật ký, theo dõi sử dụng và phân bổ chi phí trên mọi mô hình và nhà cung cấp đang sử dụng.
• Hành vi chuyển đổi dự phòng và thử lại khi nhà cung cấp chậm, bị giới hạn tốc độ hoặc trả về lỗi.
• Tùy chọn, logic định tuyến như một tính năng trong số nhiều tính năng khác, thay vì là toàn bộ sản phẩm.

Trang nghiên cứu mô hình của TokenLab liệt kê các mô hình hiện tại trên các nhà cung cấp, bao gồm các mô hình tiên phong (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), các mô hình hướng tới lập trình (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash) và các ứng viên định tuyến chi phí thấp (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3), đây là loại tài liệu tham khảo mà người dùng gateway cần khi quyết định định tuyến đến đâu. Xem bài viết của TokenLab về lý do tại sao một AI API gateway thống nhất lại quan trọng vào năm 2026 để có cái nhìn đầy đủ hơn về vấn đề thống nhất.

Ranh giới kiến trúc, một cách cụ thể

Ranh giới này dễ thấy nhất bằng cách theo dõi một yêu cầu duy nhất qua cả ba lớp.

1. Ứng dụng của bạn gửi yêu cầu hoàn thành chat (chat completion) đến endpoint của gateway, chỉ định loại tác vụ hoặc ưu tiên mô hình.
2. Gateway xác thực yêu cầu, chuẩn hóa nó thành lược đồ mong đợi của từng nhà cung cấp ứng viên và chuyển cho logic định tuyến.
3. Router đánh giá chính sách đã cấu hình (trần chi phí, mục tiêu độ trễ hoặc thứ tự nhà cung cấp rõ ràng) và chọn đích đến, ví dụ: Claude Sonnet 5 thông qua API của Anthropic hoặc một instance DeepSeek V4 Pro tự lưu trữ được phục vụ qua vLLM.
4. Inference provider thực thi mô hình và trả về các token.
5. Gateway chuẩn hóa phản hồi trở lại thành một hình thái nhất quán và ghi lại kết quả (độ trễ, chi phí, nhà cung cấp đã sử dụng, thành công hay thất bại) cho lớp khả năng quan sát của bạn.

Mỗi lớp có thể thất bại độc lập. Sự cố nhà cung cấp là vấn đề ở lớp suy luận; quyết định định tuyến sai (gửi các yêu cầu ngữ cảnh dài đến một mô hình có cửa sổ ngữ cảnh nhỏ) là vấn đề ở lớp router; lược đồ phản hồi không nhất quán làm hỏng trình phân tích cú pháp của bạn là vấn đề ở lớp gateway. Hiểu được lớp nào tạo ra lỗi nhất định là điều giúp việc gỡ lỗi trở nên dễ dàng. Bài viết của TokenLab về cơ sở hạ tầng độ tin cậy cho AI API đề cập sâu hơn về việc cô lập lỗi trên các lớp này.

Danh sách kiểm tra quyết định

Sử dụng danh sách kiểm tra này khi đánh giá xem bạn có cần gateway, router, tích hợp nhà cung cấp trực tiếp hay sự kết hợp nào đó.

Câu hỏi	Nếu có	Nếu không
Bạn có gọi nhiều hơn một mô hình hoặc nhà cung cấp hiện nay, hoặc dự kiến trong 12 tháng tới không?	Bạn cần một lớp gateway hoặc router, không phải các lệnh gọi SDK trực tiếp cho từng nhà cung cấp.	Tích hợp SDK nhà cung cấp trực tiếp có thể đủ trong ngắn hạn.
Bạn có cần tự động chuyển đổi dự phòng khi nhà cung cấp bị suy giảm hoặc giới hạn tốc độ không?	Bạn cần logic cấp router với kiểm tra sức khỏe và thứ tự dự phòng.	Thử lại thủ công trong mã ứng dụng có thể chấp nhận được ban đầu.
Bạn có cần khả năng hiển thị chi phí và mức sử dụng theo từng mô hình trên các nhà cung cấp tại một nơi không?	Bạn cần ghi nhật ký và phân bổ ở cấp gateway.	Bảng điều khiển gốc của nhà cung cấp có thể đáp ứng nhu cầu hiện tại của bạn.
Bạn có đang tự lưu trữ bất kỳ mô hình mở nào (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code) không?	Bạn cũng đang vận hành một lớp inference provider và cần cơ sở hạ tầng phục vụ như vLLM.	Bạn có thể hoàn toàn dựa vào các nhà cung cấp API thương mại.
Bạn có cần định tuyến theo loại tác vụ (mô hình rẻ cho phân loại, mô hình tiên phong cho suy luận) không?	Bạn cần chính sách router rõ ràng, không chỉ là chuyển đổi dự phòng.	Một mô hình mặc định duy nhất có thể là đủ.

Ví dụ về hình thái yêu cầu

Ví dụ dưới đây minh họa hình thái chung của một yêu cầu kiểu gateway thể hiện cả ưu tiên mô hình chính và danh sách dự phòng, một mô hình nhất quán với cách tài liệu lựa chọn nhà cung cấp của OpenRouter mô tả việc thể hiện các ưu tiên định tuyến. Hãy coi tên các trường là minh họa; hãy xác minh các tham số chính xác so với tài liệu API hiện tại của gateway bạn chọn trước khi triển khai.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

Trong hình thái này, gateway sở hữu việc chuẩn hóa yêu cầu và hợp đồng phản hồi, router sở hữu việc diễn giải routing_policy và fallback_models, và bất kỳ nhà cung cấp nào được chọn cuối cùng sẽ sở hữu việc thực sự tạo ra kết quả hoàn thành. Hãy xác nhận lược đồ yêu cầu và phản hồi chính xác so với tài liệu hiện tại trước khi dựa vào bất kỳ tên trường cụ thể nào trong môi trường sản xuất.

Hạn chế

Tài liệu công khai từ OpenRouter và vLLM mô tả các cơ chế định tuyến và phục vụ chung, không phải là các đảm bảo phổ quát. Độ trễ, giá cả và hành vi chuyển đổi dự phòng chính xác thay đổi theo từng nhà cung cấp và thay đổi theo thời gian, vì vậy hãy xác minh các con số hiện tại trực tiếp so với tài liệu của nhà cung cấp thay vì bài viết này. Tự lưu trữ với vLLM chuyển trách nhiệm vận hành (lập kế hoạch dung lượng, mở rộng, vá lỗi) sang đội ngũ của bạn; nó không loại bỏ công việc cơ sở hạ tầng, nó chỉ di dời nó. Không chính sách định tuyến nào có thể bù đắp cho một lựa chọn mô hình sai lệch về cơ bản, chẳng hạn như gửi một tác vụ yêu cầu suy luận ngữ cảnh dài đến một mô hình không phù hợp với nó; cấu hình router không phải là sự thay thế cho việc đánh giá khả năng mô hình so với khối lượng công việc của bạn, đó là lý do tại sao việc duy trì một tài liệu tham khảo mô hình cập nhật như nghiên cứu mô hình của TokenLab là rất quan trọng.

Câu hỏi thường gặp

Gateway có giống với router không? Không. Router là logic quyết định để chọn mô hình hoặc nhà cung cấp; gateway là lớp hướng ứng dụng rộng hơn bao gồm định tuyến như một tính năng có thể có bên cạnh xác thực, chuẩn hóa và ghi nhật ký.

Tôi có thể tự làm inference provider của riêng mình và vẫn sử dụng gateway không? Có. Các mô hình tự lưu trữ được phục vụ thông qua một engine như vLLM có thể nằm sau cùng một gateway với các nhà cung cấp API thương mại, miễn là gateway hỗ trợ các endpoint tùy chỉnh hoặc tương thích với OpenAI.

Tôi có cần cả ba lớp ngay từ ngày đầu tiên không? Không nhất thiết. Tích hợp trực tiếp một nhà cung cấp là hợp lý cho một bản mẫu ban đầu. Ngay khi bạn cần chuyển đổi dự phòng, kiểm soát chi phí đa mô hình hoặc so sánh nhà cung cấp, việc giới thiệu một gateway với định tuyến sẽ trở nên xứng đáng với chi phí kỹ thuật.

Nếu bạn đang đánh giá lớp nào cần áp dụng trước, hãy xem lại các tùy chọn mô hình hiện tại tại trang nghiên cứu mô hình của TokenLab và Bắt đầu với một thiết lập gateway cho phép bạn thêm định tuyến và nhà cung cấp một cách tăng dần thay vì cam kết với một tích hợp ngay từ đầu.