OpenRouter: Làm thế nào để trở thành công ty tỷ đô nhờ “trạm trung chuyển mô hình”?

Tác giả: Trương Ái Lạp

Hôm nay hãy nói về trạm trung chuyển.

Nói một cách đơn giản, trạm trung chuyển mô hình là kết nối các mô hình khác nhau như OpenAI, Claude, Gemini, DeepSeek vào cùng một cổng, cho phép nhà phát triển sử dụng một bộ API, một tài khoản và một hóa đơn thống nhất để gọi nhiều mô hình, đồng thời lựa chọn, chuyển đổi và dự phòng giữa các mô hình hoặc nhà cung cấp khác nhau.

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à giá rẻ hơn.

Cái này ai cũng hiểu, trạm trung chuyển trong nước chúng tôi 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 vòng B trị giá 113 triệu đô la Mỹ, định giá đã gần 1,3 tỷ đô la Mỹ.

Nghĩa là, nó đã trở thành một công ty kỳ lân.

Chúng ta hãy phân tích, tại sao một "trạm trung chuyển mô hình không tạo mô hình" lại có giá trị đến vậy?

OpenRouter thực sự làm gì?

OpenRouter chính thức tự định vị 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 và hơn 70 nhà cung cấp mô hình.

Trang web chính thức cũng tiết lộ rằng nền tảng xử lý hàng tháng đã đạt 100 nghìn tỷ token, với hơn 10 triệu người dùng toàn cầu.

Trong thông báo huy động vốn vòng B tháng 5 năm 2026, cũng đề cập rằng trong 6 tháng qua, khối lượng xử lý hàng tuần của OpenRouter đã tăng từ 5 nghìn tỷ token lên 25 nghìn tỷ token, phục vụ hơn 8 triệu nhà phát triển.

Những con số này cho thấy một điều:

OpenRouter không còn là một công cụ dành cho nhà phát triển nhỏ lẻ, mà là một cổng gọi AI 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 lẻ với các mô hình như OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI.

Mỗi lần kết nối, bạn phải xem tài liệu, xin API key, liên kết hóa đơn, xử lý sự khác biệt giao diện, xem quy tắc giới hạn tốc độ và xử lý ngoại lệ.

Sau khi dùng OpenRouter, 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ường, mã sử dụng giao diện OpenAI trước đây chỉ cần thay đổi base URL, đổi API key và chỉ định tên mô hình là có thể gọi các mô hình khác qua OpenRouter.

Đây cũng là một trong những lý do nó phát triển nhanh chóng ban đầu: chi phí chuyển đổi thấp.

Tại sao nhà phát triển không kết nối trực tiếp với các công ty mô hình?

Có vẻ như nhà phát triển hoàn toàn có thể bỏ qua OpenRouter và đến trực tiếp trang web của các công ty mô hình để đăng ký API.

Nhưng trong 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à bản demo, chỉ cần một mô hình là đủ. Nhưng khi bước vào kinh doanh thực tế, rất khó để chỉ phụ thuộc vào một mô hình.

Ví dụ, một công cụ viết AI có thể có nhiều loại nhiệm vụ khác nhau:

Tạo tiêu đề, chỉ cần 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 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 và ổn định cao;

Khách hàng doanh nghiệp yêu cầu không lưu trữ dữ liệu, phải chọn nhà cung cấp tuân thủ chính sách dữ liệu;

Trong thời gian cao điểm, mô hình bị giới hạn tốc độ, 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 cho nhiệm vụ nào, mô hình nào rẻ hơn, nhà cung cấp nào nhanh hơn, nhà cung cấp nào có tỷ lệ thất bại thấp hơn, cách chuyển đổi khi có sự cố, cách quy kết hóa đơn, cách cách ly dữ liệu khách hàng doanh nghiệp.

Rắc rối hơn, thị trường mô hình thay đổi quá nhanh.

Hôm nay Claude phù hợp để viết code, ngày mai Gemini có lợi thế về ngữ cảnh dài, ngày kia DeepSeek hoặc một mô hình mã nguồn mở nào đó giảm giá.

Khả năng, giá cả, độ dài ngữ cảnh, chính sách của nhà cung cấp liên tục thay đổi.

Giá trị của OpenRouter nằm ở đây.

Nó không thay thế nhà phát triển viết ứng dụng AI, mà giúp nhà phát triển quản lý "dùng mô hình nào, gọi như thế nào, làm sao dự phòng, kiểm soát chi phí".

Không chỉ là siêu thị mô hình, mà là lớp điều phối mô hình

Nếu chỉ hiểu OpenRouter là "siêu thị mô hình", thì sẽ đánh giá thấp nó.

Siêu thị mô hình giải quyết vấn đề "có nhiều mô hình ở đây, 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ể được cung cấp dịch vụ suy luận bởi các nhà cung cấp khác nhau.

Ví dụ, một mô hình mã nguồn mở có thể được lưu trữ bởi nhiều nhà cung cấp dịch vụ đám mây hoặc nhà cung cấp dịch vụ suy luận. Giá cả, tốc độ và độ ổn định của các nhà cung cấp khác nhau không giống nhau.

Tài liệu của OpenRouter có một khả năng gọi là định tuyến nhà cung cấp (provider routing).

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 đến các nhà cung cấp khác nhau.

Nó cũng hỗ trợ fallback, nghĩa là khi một mô hình hoặc nhà cung cấp nào đó thất bại, hệ thống sẽ 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ã kinh doanh và giao cho một nền tảng chuyên biệt xử lý.

Tại sao doanh nghiệp cần lớp này?

Khi doanh nghiệp áp dụng AI, vấn đề ban đầu thường là "có dùng được không", nhưng nhanh chóng trở thành "làm sao quản lý".

Trong một công ty, nhiều nhóm có thể đều đang sử dụng AI.

Nhóm marketing dùng để viết nội dung, nhóm hỗ trợ khách hàng dùng để trả lời người dùng, nhóm nghiên cứu và 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 tự kết nối mô hình, vấn đề sẽ ngày càng nhiều:

Hóa đơn không phân biệt được; 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;

Khi có sự cố, không ai biết đường gọi nào;

Nhà cung cấp mô hình thay đổi, hệ thống khó điều chỉnh thống nhất.

OpenRouter cung cấp không gian 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, tất cả đều 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 mọi yêu cầu đều có thể gửi đến 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.

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ể đặt chỉ gửi yêu cầu đến các 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 bảo mật hoặc từng yêu cầu riêng lẻ.

Ví dụ khác như prompt caching, tức là lưu cache cho prompt.

Nhiều ứng dụng AI sử dụng lặp lại các prompt hệ thống dài, nội dung 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 cache thông qua định tuyến nhà cung cấp có độ dính cao, cố gắng để các yêu cầu tiếp theo đi đến cùng một điểm cuối của nhà cung cấp, từ đó giảm chi phí ngữ cảnh lặp lại.

Những tính năng này nghe có vẻ không hấp dẫn, nhưng rất thực tế và khi quy mô ứng dụng AI càng lớn, chi phí tiết kiệm được càng rõ rệt.

OpenRouter kiếm tiền như thế nào?

Mô hình kinh doanh của OpenRouter rất rõ ràng: kiếm tiền theo khối lượng sử dụng.

Nhà phát triển mua hạn mức nền tảng trước, sau đó trả phí dựa trên mô hình và token thực tế được 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 đô la Mỹ; giá của nhà cung cấp mô hình cơ bản được chuyển nguyên bản cho người dùng, không cộng thêm phí trên giá suy luận mô hình.

Đây là một dạng kinh doanh "phí giao thông" điển hình.

Lợi thế của mô hình này là doanh thu gắn liền với khối lượng sử dụng.

Nhà phát triển gọi càng nhiều, doanh thu nền tảng càng cao; càng nhiều ứng dụng AI, token tiêu thụ càng lớn, kinh doanh của OpenRouter càng phát triển.

Nhưng nó cũng có một đặc điểm: phí mỗi lần không cao, do đó phải dựa vào quy mô.

Đây cũng là lý do tại sao khối lượng xử lý token rất quan trọng đối với OpenRouter.

Chỉ số cốt lõi của nó không phải là số lượng người dùng đăng ký, mà là có bao nhiêu token chảy qua nó mỗi tuần, mỗi tháng.

Năm 2025, khối lượng xử lý hàng năm của OpenRouter tăng từ khoảng 10 nghìn tỷ token lên hơn 100 nghìn tỷ token.

Đến năm 2026, OpenRouter đã đạt khoảng 15 nghìn tỷ token xử lý hàng năm hóa.

Đây là logic cơ bản của kinh doanh này.

Miễn là ngày càng nhiều ứng dụng AI chạy trên hệ thống đa mô hình, OpenRouter sẽ liên tục thu phí dịch vụ từ các cuộc gọi này.

Tại sao gần đây tăng trưởng nhanh như vậy?

Tổng kết lại, sự tăng trưởng của OpenRouter đến từ ba thay đổi.

Thay đổi đầu tiên là ngày càng nhiều mô hình.

Trước đây, khi làm ứng dụng AI, nhiều nhóm mặc định dùng OpenAI trước. Bây giờ khác rồi.

Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, cùng với nhiều mô hình mã nguồn mở và trọng số mở, đều có lợi thế trong các tình huống khác nhau.

Đây không phải là thị trường "ai thay thế hoàn toàn ai".

Một số mô hình viết code tốt, một số rẻ, một số văn bản dài mạnh, một số nhanh, một số phù hợp với nhập vai, một số phù hợp với tài liệu doanh nghiệp, một số phù hợp với đa phương thức.

Càng nhiều mô hình, chi phí lựa chọn càng cao; chi phí lựa chọn càng cao, lớp trung gian càng có giá trị.

Thay đổi thứ hai là các ứng dụng AI bắt đầu chú trọng chi phí.

Nhiều sản phẩm ban đầu dùng mô hình mạnh nhất, vì trước tiên cần tạo ra hiệu quả.

Nhưng khi sản phẩm có người dùng, chi phí mô hình nhanh chóng trở thành vấn đề.

Một chatbot hỗ trợ 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 dễ bị ăn mòn.

Cách tiếp cận trưởng thành hơn là tách nhiệm vụ:

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;

Khi thất bại, chuyển sang mô hình dự phòng;

Khi liên quan đến dữ liệu nhạy cảm, chỉ đi qua nhà cung cấp tuân thủ 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 thiết giúp bạn tìm "mô hình mạnh nhất", nhưng có thể giúp bạn cân bằng giữa hiệu quả, giá cả, tốc độ và độ ổn định.

Thay đổi thứ ba là các ứng dụng AI chuyển từ hộp thoại sang tác nhân thông minh.

Tác nhân thông minh sẽ gọi công cụ, đọc tệp, tìm kiếm web, thực thi nhiệm vụ và gọi mô hình nhiều vòng liên tiếp.

So với chat thông thường, tác nhân thông minh tiêu thụ nhiều token hơn và phụ thuộc nhiều hơn vào độ ổn định.

Điều này có lợi cho OpenRouter.

Vì số lần gọi càng nhiều, chuỗi 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 thông báo huy động vốn của OpenRouter nhấn mạnh rằng AI đang chuyển từ thử nghiệm sang các ứng dụng sản xuất quan trọng và kịch bản tác nhân.

Sự tăng trưởng của nó, về bản chất, đến từ sự gia tăng khối lượng gọi AI.

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ó nằm giữa các 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ị, vừa dễ bị chèn ép.

Rủi ro đầu tiên là các công ty lớn có thể tự xây dựng.

Đối với các nhóm nhỏ, OpenRouter rất tiện lợi.

Nhưng đối với các doanh nghiệp lớn, việc đị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.

Đặc biệt là khách hàng tài chính, y tế, chính phủ, có thể quan tâm hơn đến việc 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 sắc 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à các nhà cung cấp đám mây cũng sẽ xây dựng cổng mô hình.

AWS, Google Cloud, Azure, những nền tảng đám mây này 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ể tích hợp 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.

Lợi thế của OpenRouter là mở và trung lập, phạm vi mô hình rộng hơn, kết nối nhanh hơn.

Nhưng lợi thế của nhà cung cấp đám mây là mối 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 dài hạn.

Rủi ro thứ ba là mối quan hệ với nhà cung cấp mô hình.

OpenRouter mang lưu lượng đến cho các công ty mô hình, nhưng cũng khiến các công ty mô hình xa hơn với nhà phát triển cuối cùng.

Khi nền tảng ngày càng lớn, nó sẽ nắm giữ nhiều mối quan hệ người dùng và dữ liệu sử dụng mô hình hơn.

Các nhà cung cấp mô hình vừa hy vọng có được phân phối, vừa lo ngại quyền thương lượng bị suy yếu.

Loại nền tảng trung gian này, ban đầu thường được bên cung cấp chào đón; khi quy mô lớn hơn, mối quan hệ sẽ trở nên tinh tế hơn.

Rủi ro thứ tư là phí nền tảng có thể bị ép xuống.

OpenRouter thu phí nền tảng 5,5%, hiện tại có vẻ không cao.

Nhưng nếu ngày càng nhiều dịch vụ tương tự xuất hiện, nhà phát triển sẽ so sánh giá cả, độ ổn định, phạm vi mô hình và tính năng doanh nghiệp.

Nếu một số đối thủ cạnh tranh sẵn sàng giảm phí, hoặc nhà cung cấp đám mây đóng gói khả năng này vào dịch vụ hiện có, OpenRouter cần chứng minh rằng nó 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ạm vi 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.