Tác giả: Trương Ái Lạp
Hôm nay chúng ta cùng bàn về trạm trung chuyển.
Nói một cách đơn giản, trạm trung chuyển mô hình chính là việc kết nối các mô hình khác nhau như OpenAI, Claude, Gemini, DeepSeek... vào cùng một cửa ngõ phía sau, cho phép nhà phát triển sử dụng một bộ giao diện lập trình ứng dụng (API), một tài khoản và một hóa đơn thống nhất để gọi nhiều mô hình khác nhau, đồng thời lựa chọn, chuyển đổi và có giải pháp dự phòng giữa các mô hình hoặc nhà cung cấp.
Tất nhiên, đối với người dùng trong nước, lý do lớn hơn để sử dụng trạm trung chuyển là muốn dùng các mô hình nước ngoài, và rẻ hơn.
Điều này ai cũng hiểu, các trạm trung chuyển trong nước chúng ta sẽ không nói nhiều, hôm nay chủ yếu giới thiệu OpenRouter.

Đến năm 2026, OpenRouter đã huy động được 113 triệu USD ở vòng B, định giá đã gần 1.3 tỷ USD.
Tức là, nó đã là một công ty kỳ lân.
Chúng ta hãy cùng phân tích, một trạm trung chuyển mô hình "không tạo ra mô hình", tại sao lại có thể đáng giá như vậy?
OpenRouter cuối cùng làm gì?
OpenRouter định vị chính mình là: Giao diện thống nhất cho các mô hình lớn.
OpenRouter hiện hỗ trợ hơn 400 mô hình, hơn 70 nhà cung cấp mô hình.
Trang web chính thức cũng tiết lộ, lượng xử lý hàng tháng của nền tảng đã đạt 100 nghìn tỷ tokens, người dùng toàn cầu vượt quá 10 triệu.
Trong thông báo gọi vòng B tháng 5 năm 2026 cũng đề cập, trong 6 tháng qua, lượng xử lý hàng tuần của OpenRouter đã tăng từ 5 nghìn tỷ tokens lên 25 nghìn tỷ tokens, và phục vụ hơn 8 triệu nhà phát triển.

Những con số này nói lên một điều:
OpenRouter không còn là một công cụ dành riêng cho nhà phát triển nhỏ lẻ nữa, mà đã là một cửa ngõ gọi AI rất lớn.
Cách các nhà phát triển sử dụng nó cũng rất đơn giản.
Trước đây bạn phải kết nối riêng với các mô hình của OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI,...
Mỗi khi kết nối với một nhà cung cấp, đều phải xem tài liệu, đăng ký API key, liên kết hóa đơn, xử lý sự khác biệt về giao diện, xem quy tắc giới hạn lưu lượng, xử lý ngoại lệ.
Sau khi sử dụng OpenRouter, các nhà phát triển có thể gọi các mô hình khác nhau thông qua cùng một giao diện.
Thường thì, mã code sử dụng giao diện OpenAI trước đây, chỉ cần thay đổi base URL, đổi API key, rồi chỉ định tên mô hình, là có thể thông qua OpenRouter để gọi mô hình khác.
Đây cũng là một trong những lý do tăng trưởng nhanh chóng ban đầu của nó: chi phí di chuyển thấp.
Tại sao nhà phát triển không trực tiếp kết nối với công ty mô hình?
Có vẻ như, các nhà phát triển hoàn toàn có thể bỏ qua OpenRouter, trực tiếp đến trang web chính thức của công ty mô hình để mở API.
Nhưng trong việc phát triển thực tế, việc này không đơn giản như vậy.
Nếu một sản phẩm AI chỉ là demo, chỉ cần một mô hình là đủ. Nhưng chỉ cần bước vào hoạt động kinh doanh thực tế, rất khó chỉ phụ thuộc vào một mô hình duy nhất.
Ví dụ, một công cụ viết lách AI, có thể có vài loại nhiệm vụ khác nhau:
- Tạo tiêu đề, dùng mô hình rẻ là đủ;
- Viết bài dài, cần khả năng văn bản mạnh hơn;
- Phân tích tài liệu, cần mô hình có ngữ cảnh dài;
- Kiểm duyệt nội dung, cần khả năng phân loại chi phí thấp, ổn định cao;
- Khách hàng doanh nghiệp yêu cầu dữ liệu không được lưu trữ, phải chọn nhà cung cấp phù hợp với chính sách dữ liệu;
- Trong giờ cao điểm mô hình bị giới hạn lưu lượng, còn phải tự động chuyển sang mô hình dự phòng.
Lúc này, vấn đề không chỉ là "kết nối một API".
Nhóm phải duy trì một hệ thống gọi mô hình hoàn chỉnh:
Mô hình nào chịu trách nhiệm nhiệm vụ nào, mô hình nào rẻ hơn, nhà cung cấp nào tốc độ nhanh hơn, nhà cung cấp nào tỷ lệ thất bại thấp hơn, xảy ra vấn đề làm thế nào chuyển đổi, hóa đơn quy kết thế nào, dữ liệu của khách hàng doanh nghiệp cách ly ra sao.
Phiền phức hơn là, thị trường mô hình thay đổi quá nhanh.
Hôm nay Claude phù hợp viết code, ngày mai ngữ cảnh dài của Gemini có ưu thế hơn, ngày kia DeepSeek hoặc một mô hình mã nguồn mở nào đó kéo giá xuống.
Năng lực mô hình, giá cả, độ dài ngữ cảnh, chính sách nhà cung cấp, luôn luôn thay đổi.
Giá trị của OpenRouter cũng nằm ở đây.
Nó không thay nhà phát triển viết ứng dụng AI, mà là thay nhà phát triển quản lý việc "dùng mô hình nào, gọi thế nào, dự phòng ra sao, kiểm soát chi phí thế nào".
Không chỉ là siêu thị mô hình, mà là tầng điều phối mô hình
Nếu chỉ hiểu OpenRouter là "siêu thị mô hình", sẽ đánh giá thấp nó.
Siêu thị mô hình giải quyết vấn đề "ở đây có nhiều mô hình, bạn có thể chọn".
Nhưng khả năng thực sự quan trọng của OpenRouter, là điều phối giữa các mô hình và nhà cung cấp.
Cùng một mô hình, có thể do các nhà cung cấp dịch vụ suy luận khác nhau cung cấp.
Ví dụ một mô hình mã nguồn mở, có thể được nhiều nhà cung cấp dịch vụ đám mây hoặc nhà cung cấp dịch vụ suy luận lưu trữ. Giá cả, tốc độ, độ ổn định của các nhà cung cấp khác nhau không giống nhau.
Trong tài liệu của OpenRouter có một khả năng gọi là provider routing, tức là định tuyến nhà cung cấp.
Các nhà phát triển có thể dựa trên các điều kiện như giá cả, độ trễ, thông lượng, thứ tự nhà cung cấp..., để yêu cầu tự động đi qua nhà cung cấp khác nhau.
Nó còn hỗ trợ fallback, tức là khi một mô hình hoặc nhà cung cấp nào đó thất bại, hệ thống tự động chuyển sang tùy chọn dự phòng.

Đối với nhà phát triển, OpenRouter tương đương với việc tách "lựa chọn mô hình" và "xử lý sự cố" ra khỏi mã nghiệp vụ, giao cho một nền tảng chuyên biệt xử lý.
Tại sao doanh nghiệp lại cần tầng này?
Doanh nghiệp ứng dụng AI, vấn đề ban đầu thường là "có dùng được không", nhưng rất nhanh sẽ trở thành "quản lý thế nào".
Bên trong một công ty có thể có rất nhiều nhóm đều đang sử dụng AI.
Nhóm thị trường dùng để viết nội dung, nhóm dịch vụ khách hàng dùng để trả lời người dùng, nhóm nghiên cứu phát triển dùng để viết code, nhóm vận hành dùng để phân tích dữ liệu, nhóm pháp lý dùng để xử lý hợp đồng.
Nếu mỗi nhóm đều tự kết nối mô hình, vấn đề sẽ ngày càng nhiều:
- Hóa đơn không phân rõ; Lựa chọn mô hình không thống nhất;
- Chính sách dữ liệu không minh bạch; Các nhóm khác nhau kết nối trùng lặp;
- Xảy ra vấn đề không ai biết là lời gọi từ đường nào;
- Nhà cung cấp mô hình thay đổi, hệ thống rất khó điều chỉnh thống nhất.
Khu vực làm việc, kiểm soát ngân sách, nhật ký gọi, chiến lược nhà cung cấp, định tuyến không lưu trữ dữ liệu mà OpenRouter cung cấp, đều là để giải quyết những vấn đề này.

Ví dụ như không lưu trữ dữ liệu.
Đối với nhiều doanh nghiệp, không phải tất cả yêu cầu đều có thể tùy tiện gửi cho bất kỳ nhà cung cấp mô hình nào. Thông tin khách hàng, nội dung hợp đồng, dữ liệu y tế, dữ liệu tài chính, đều có thể có yêu cầu nghiêm ngặt.
Trong tài liệu OpenRouter hỗ trợ Zero Data Retention, tức là không lưu trữ dữ liệu.
Nhà phát triển có thể thiết lập chỉ gửi yêu cầu cho những nhà cung cấp không lưu trữ dữ liệu. Chiến lược này có thể thực hiện theo toàn cục, nhóm mô hình, quy tắc an toàn hoặc từng yêu cầu đơn lẻ.
Lại ví dụ như prompt caching, tức là bộ nhớ đệm lời nhắc.
Nhiều ứng dụng AI sẽ sử dụng lặp đi lặp lại các lời nhắc hệ thống rất dài, nội dung cơ sở kiến thức hoặc ngữ cảnh. Nếu mỗi lần đều tính toán lại, chi phí sẽ rất cao.
OpenRouter hỗ trợ tăng tỷ lệ trúng bộ nhớ đệm thông qua định tuyến dính liền nhà cung cấp, cố gắng để các yêu cầu tiếp theo đi qua cùng một đầu cuối nhà cung cấp, từ đó giảm chi phí ngữ cảnh trùng lặp.
Loại chức năng này nghe không hấp dẫn, nhưng rất thiết thực, và quy mô ứng dụng AI càng lớn, chi phí tiết kiệm được càng rõ ràng.
OpenRouter kiếm tiền thế nào?
Mô hình kinh doanh của OpenRouter rất rõ ràng: Kiếm tiền theo lượng sử dụng.
Nhà phát triển trước tiên mua hạn mức nền tảng, sau đó thanh toán theo mô hình và tokens thực tế gọi.
OpenRouter chính thức viết rất rõ:
Nền tảng thu phí 5.5% khi mua hạn mức, tối thiểu 0.8 USD; giá nhà cung cấp mô hình cơ sở chuyển cho người dùng theo giá gốc, không tăng thêm giá trên giá suy luận mô hình.
Đây là một mô hình kinh doanh "phí qua đường" điển hình.
Ưu điểm của mô hình này là, thu nhập gắn liền với lượng sử dụng.
Nhà phát triển gọi càng nhiều, thu nhập nền tảng càng cao; ứng dụng AI càng nhiều, tokens tiêu thụ càng lớn, kinh doanh của OpenRouter càng lớn.
Nhưng nó cũng có một đặc điểm: tỷ lệ chia phần mỗi lần không cao, nên phải dựa vào quy mô.
Đây cũng là lý do tại sao lượng xử lý tokens quan trọng đối với OpenRouter.
Chỉ số cốt lõi của nó không phải số lượng người dùng đăng ký, mà là mỗi tuần, mỗi tháng có bao nhiêu tokens chảy qua nó.
Năm 2025, lượng xử lý hàng năm của OpenRouter đã tăng từ khoảng 10 nghìn tỷ tokens lên hơn 100 nghìn tỷ tokens.
Đến năm 2026, OpenRouter đã đạt đến lượng xử lý hàng năm hóa khoảng 1.5 triệu tỷ tokens.
Đây là logic cơ bản của mô hình kinh doanh này.
Chỉ cần ngày càng có nhiều ứng dụng AI chạy trên hệ thống đa mô hình, OpenRouter có thể liên tục thu phí dịch vụ từ những lời gọi này.
Tại sao gần đây tăng trưởng nhanh như vậy?
Tăng trưởng của OpenRouter, tóm lại là nắm bắt được ba thay đổi.
Thay đổi thứ nhất, là ngày càng nhiều mô hình.
Trước đây làm ứng dụng AI, nhiều nhóm mặc định dùng OpenAI trước. Bây giờ không giống vậy nữa.
Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, cùng với lượng lớn mô hình mã nguồn mở và trọng số mở, đều có ưu thế trong các tình huống khác nhau.
Đây không phải là một thị trường "ai thay thế hoàn toàn ai".
Có mô hình viết code tốt, có mô hình rẻ, có mô hình văn bản dài mạnh, có mô hình tốc độ nhanh, có mô hình phù hợp đóng vai, có mô hình phù hợp tài liệu doanh nghiệp, có mô hình phù hợp đa phương thức.
Mô hình càng nhiều, chi phí lựa chọn càng cao; chi phí lựa chọn càng cao, tầng trung gian càng có giá trị.
Thay đổi thứ hai, là ứng dụng AI bắt đầu quan tâm đến chi phí.
Nhiều sản phẩm ban đầu dùng mô hình mạnh nhất, vì trước tiên phải làm ra hiệu quả.
Nhưng sản phẩm một khi có người dùng, chi phí mô hình sẽ nhanh chóng trở thành vấn đề.
Một robot dịch vụ khách hàng, sản phẩm tìm kiếm AI, trợ lý code, công cụ tạo nội dung, nếu tất cả yêu cầu đều đi qua mô hình đắt nhất, lợi nhuận gộp rất dễ bị ăn mất.
Cách làm chín chắn hơn là, tách nhiệm vụ ra:
- Nhiệm vụ đơn giản dùng mô hình rẻ;
- Nhiệm vụ phức tạp dùng mô hình mạnh;
- Nhiệm vụ tần suất cao ưu tiên mô hình độ trễ thấp;
- Thất bại thì chuyển sang mô hình dự phòng;
- Liên quan đến dữ liệu nhạy cảm thì chỉ đi qua nhà cung cấp phù hợp chính sách dữ liệu.
Đây chính là tình huống sử dụng của OpenRouter.
Nó không nhất định giúp bạn tìm "mô hình mạnh nhất", nhưng nó có thể giúp bạn cân bằng giữa hiệu quả, giá cả, tốc độ và tính ổn định.
Thay đổi thứ ba, là ứng dụng AI từ hộp chat tiến tới tác nhân thông minh.
Tác nhân thông minh sẽ gọi công cụ, đọc file, tìm kiếm trang web, thực thi nhiệm vụ, cũng sẽ liên tục gọi mô hình nhiều vòng.
So với chat thông thường, tác nhân thông minh sẽ tiêu thụ nhiều tokens hơn, cũng phụ thuộc nhiều hơn vào tính ổn định.
Điều này có lợi cho OpenRouter.
Vì số lần gọi càng nhiều, đường dẫn càng dài, nhà phát triển càng cần định tuyến, dự phòng, nhật ký, kiểm soát chi phí và quản lý nhà cung cấp.
Đây cũng là lý do tại sao trong thông báo gọi vốn của OpenRouter nhấn mạnh, AI đang từ thử nghiệm tiến tới ứng dụng sản xuất quan trọng và tình huống tác nhân thông minh.
Tăng trưởng của nó, về bản chất đến từ sự gia tăng lượng gọi AI.
Mô hình kinh doanh này cũng có rủi ro
Vị trí của OpenRouter rất tốt, nhưng không an toàn.
Nó kẹp giữa công ty mô hình, nhà cung cấp đám mây và nhà phát triển ứng dụng. Vị trí này vừa có giá trị, cũng dễ bị chèn ép.
Rủi ro thứ nhất, là các công ty lớn có thể tự xây dựng.
Đối với nhóm nhỏ, OpenRouter rất tiện lợi.
Nhưng đối với doanh nghiệp lớn, định tuyến mô hình, quyền hạn, nhật ký, quản lý chi phí, cũng có thể tự làm, hoặc giao cho nhà cung cấp đám mây làm.
Đặc biệt là khách hàng tài chính, y tế, chính phủ doanh nghiệp, có thể quan tâm hơn đến khả năng kiểm soát dữ liệu và triển khai riêng tư.
OpenRouter muốn tiếp cận những khách hàng này, không thể chỉ dựa vào "nhiều mô hình". Nó phải làm đủ sâu về quyền hạn, kiểm toán, chính sách dữ liệu, quản lý nhà cung cấp và hỗ trợ doanh nghiệp.
Rủi ro thứ hai, là nhà cung cấp đám mây cũng sẽ làm cổng mô hình.
Các nền tảng đám mây như AWS, Google Cloud, Azure, vốn đã có khách hàng doanh nghiệp, hệ thống hóa đơn, hệ thống quyền hạn và khả năng tuân thủ.
Chúng hoàn toàn có thể biến việc gọi đa mô hình, định tuyến, giám sát và quản lý chi phí thành một phần của dịch vụ đám mây.
Ưu thế của OpenRouter là mở và trung lập, phủ sóng mô hình rộng hơn, kết nối nhanh hơn.
Nhưng ưu thế của nhà cung cấp đám mây là quan hệ khách hàng và quy trình mua sắm doanh nghiệp, đây là một cuộc cạnh tranh lâu dài.
Rủi ro thứ ba, là quan hệ với nhà cung cấp mô hình.
OpenRouter mang lại lưu lượng cho công ty mô hình, nhưng cũng khiến công ty mô hình cách xa nhà phát triển cuối cùng thêm một tầng.
Khi nền tảng ngày càng lớn, nó sẽ nắm giữ nhiều quan hệ người dùng và dữ liệu sử dụng mô hình hơn.
Nhà cung cấp mô hình vừa hy vọng có được phân phối, cũng lo ngại quyền thương lượng bị suy yếu.
Loại nền tảng tầng trung gian này, ban đầu thường được bên cung cấp hoan nghênh; quy mô lớn lên, quan hệ sẽ tế nhị hơn.
Rủi ro thứ tư, là phí nền tảng có thể bị ép giảm.
OpenRouter thu phí nền tảng 5.5%, bây giờ có vẻ không cao.
Nhưng nếu dịch vụ tương tự ngày càng nhiều, các nhà phát triển sẽ so sánh giá cả, tính ổn định, phủ sóng mô hình và chức năng doanh nghiệp.
Nếu một số đối thủ cạnh tranh sẵn sàng tỷ lệ phí thấp hơn, hoặc nhà cung cấp đám mây đóng gói loại khả năng này vào dịch vụ sẵn có, OpenRouter cần chứng minh mình không chỉ là một "bộ chuyển tiếp yêu cầu".
Nó phải liên tục cung cấp định tuyến tốt hơn, phủ sóng mô hình mạnh hơn, giá cả minh bạch hơn, dịch vụ ổn định hơn và kiểm soát doanh nghiệp hoàn chỉnh hơn.






