OpenRouter: Làm thế nào để trở thành công ty trị giá 1 tỷ đô la chỉ bằng “trạm trung chuyển mô hình”?
Tuyển chọn TechFlowTuyển chọn TechFlow
OpenRouter: Làm thế nào để trở thành công ty trị giá 1 tỷ đô la chỉ bằng “trạm trung chuyển mô hình”?
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.
Chuyên sâu báo cáo Web3Tác giả: Trương Ái Lạp
Hôm nay chúng ta sẽ cùng bàn về các trạm trung chuyển (gateway).
Nói một cách đơn giản, trạm trung chuyển mô hình là việc kết nối nhiều mô hình khác nhau như OpenAI, Claude, Gemini và DeepSeek vào cùng một cổng đầu vào, giúp nhà phát triển gọi đa mô hình thông qua một giao diện API duy nhất, một tài khoản và hệ thống quản lý hóa đơn thống nhất, đồng thời lựa chọn, chuyển đổi và thiết lập mô hình dự phòng giữa các mô hình hoặc nhà cung cấp khác nhau.
Dĩ 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 truy cập các mô hình nước ngoài và tiết kiệm chi phí hơn.
Điều này ai cũng hiểu rõ, nên chúng ta sẽ không đi sâu vào các trạm trung chuyển nội địa. Hôm nay, bài viết chủ yếu giới thiệu về OpenRouter.
Tính đến năm 2026, OpenRouter đã huy động thành công 113 triệu USD trong vòng tài trợ Series B, định giá đạt gần 1,3 tỷ USD.
Nói cách khác, OpenRouter hiện đã trở thành một kỳ lân (unicorn).
Chúng ta hãy cùng phân tích xem vì sao một trạm trung chuyển mô hình “không tự xây dựng mô hình” lại có thể đạt giá trị cao đến vậy?
OpenRouter thực chất làm gì?
Định vị chính thức của OpenRouter là: Giao diện thống nhất cho các mô hình ngôn ngữ lớn (LLM).
Hiện tại OpenRouter 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òn tiết lộ rằng nền tảng đã xử lý 100 nghìn tỷ token mỗi tháng và có hơn 10 triệu người dùng toàn cầu.
Theo thông báo về vòng tài trợ Series B vào tháng 5/2026, 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, đồng thời 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 chỉ là một công cụ dành riêng cho nhóm nhỏ nhà phát triển, mà đã trở thành một cổng truy cập AI quy mô lớn.
Cách nhà phát triển sử dụng OpenRouter cũng rất đơn giản.
Trước đây, bạn phải kết nối riêng lẻ từng mô hình như OpenAI, Anthropic, Google, DeepSeek, Mistral và xAI.
Mỗi lần kết nối đều đòi hỏi đọc tài liệu kỹ lưỡng, đăng ký khóa API, liên kết phương thức thanh toán, xử lý sự khác biệt giữa các giao diện, tuân thủ quy tắc giới hạn tốc độ (rate limiting) và xử lý ngoại lệ.
Khi sử dụng OpenRouter, nhà phát triển có thể gọi nhiều mô hình khác nhau thông qua cùng một giao diện API.
Trong nhiều trường hợp, chỉ cần thay đổi URL gốc (base URL), đổi khóa API và chỉ định tên mô hình, mã nguồn vốn được viết để gọi API OpenAI có thể ngay lập tức gọi các mô hình khác thông qua OpenRouter.
Đây cũng là một trong những nguyên nhân khiến OpenRouter tăng trưởng mạnh mẽ trong giai đoạn đầu: chi phí chuyển đổi thấp.
Vì sao nhà phát triển không kết nối trực tiếp với các công ty cung cấp mô hình?
Trông thì có vẻ nhà phát triển hoàn toàn có thể bỏ qua OpenRouter và đăng ký API trực tiếp trên trang web chính thức của các công ty cung cấp mô hình.
Nhưng trong thực tế phát triển phần mềm, việc này không hề đơn giản.
Nếu sản phẩm AI chỉ nhằm mục đích demo, thì chỉ cần một mô hình là đủ. Nhưng một khi bước vào vận hành thực tế, rất khó để phụ thuộc duy nhất vào một mô hình.
Ví dụ, một công cụ viết nội dung AI có thể bao gồm nhiều loại tác vụ khác nhau:
- Tạo tiêu đề — chỉ cần mô hình giá rẻ là đủ;
- Viết bài dài — yêu cầu khả năng xử lý văn bản mạnh hơn;
- Phân tích tài liệu — cần mô hình hỗ trợ ngữ cảnh dài;
- Kiểm duyệt nội dung — yêu cầu khả năng phân loại ổn định và chi phí thấp;
- Khách hàng doanh nghiệp yêu cầu dữ liệu không được lưu trữ — buộc phải lựa chọn nhà cung cấp tuân thủ chính sách bảo mật dữ liệu;
- Trong giờ cao điểm, mô hình bị giới hạn tốc độ — hệ thống phải tự động chuyển sang mô hình dự phòng.
Lúc này, vấn đề không còn chỉ đơn thuần là “kết nối một API” nữa.
Đội ngũ phát triển phải duy trì một hệ thống gọi mô hình hoàn chỉnh, bao gồm:
Mô hình nào chịu trách nhiệm cho tác vụ nào, mô hình nào rẻ hơn, nhà cung cấp nào có tốc độ nhanh hơn, nhà cung cấp nào có tỷ lệ lỗi thấp hơn, xử lý chuyển đổi khi gặp sự cố ra sao, phân bổ hóa đơn thế nào, cách cô lập dữ liệu khách hàng doanh nghiệp ra sao.
Rắc rối hơn nữa là thị trường mô hình thay đổi quá nhanh.
Ngày hôm nay Claude phù hợp để viết mã; ngày mai Gemini nổi bật nhờ khả năng xử lý ngữ cảnh dài; ngày kia DeepSeek hoặc một mô hình mã nguồn mở nào đó hạ giá mạnh.
Khả năng mô hình, giá cả, độ dài ngữ cảnh và chính sách nhà cung cấp luôn biến động.
Chính ở đây thể hiện giá trị thực sự của OpenRouter.
Nó không thay thế nhà phát triển trong việc xây dựng ứng dụng AI, mà thay nhà phát triển quản lý toàn bộ quy trình: “dùng mô hình nào, gọi ra sao, xử lý sự cố thế nào và kiểm soát chi phí ra sao”.
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 như một “siêu thị mô hình”, bạn sẽ đánh giá thấp vai trò thực sự của nó.
Siêu thị mô hình giải quyết vấn đề “ở đây có rất nhiều mô hình, bạn có thể lựa chọn”.
Nhưng khả năng quan trọng nhất của OpenRouter nằm ở việc đ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 nhiều nhà cung cấp khác nhau cung cấp dịch vụ suy luận (inference).
Ví dụ, một mô hình mã nguồn mở có thể được lưu trữ và triển khai bởi nhiều nhà cung cấp điện toán đám mây hoặc dịch vụ suy luận khác nhau. Giá cả, tốc độ và độ ổn định của từng nhà cung cấp đều khác nhau.
Trong tài liệu của OpenRouter có một tính năng mang tên “provider routing” (định tuyến nhà cung cấp).
Nhà phát triển có thể thiết lập các điều kiện như giá cả, độ trễ, thông lượng và thứ tự ưu tiên nhà cung cấp để hệ thống tự động phân phối yêu cầu tới các nhà cung cấp tương ứng.
OpenRouter cũng hỗ trợ cơ chế “fallback” (chuyển đổi dự phòng): khi một mô hình hoặc nhà cung cấp gặp sự cố, 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 rời hoàn toàn chức năng “lựa chọn mô hình” và “xử lý sự cố” khỏi mã nghiệp vụ, chuyển giao cho một nền tảng chuyên biệt đảm nhận.
Vì sao doanh nghiệp lại cần lớp trung gian này?
Khi triển khai AI trong doanh nghiệp, vấn đề ban đầu thường là “có dùng được hay không”, nhưng nhanh chóng chuyển thành “làm sao quản lý”.
Một công ty có thể có nhiều đội nhóm khác nhau đều đang sử dụng AI.
Đội marketing dùng để viết nội dung; đội chăm sóc khách hàng dùng để trả lời người dùng; đội R&D dùng để viết mã; đội vận hành dùng để phân tích dữ liệu; đội pháp lý dùng để xử lý hợp đồng.
Nếu mỗi đội đều tự kết nối riêng với các mô hình, các vấn đề sẽ ngày càng gia tăng:
- Hóa đơn không rõ ràng; lựa chọn mô hình thiếu thống nhất;
- Chính sách dữ liệu không minh bạch; nhiều đội trùng lặp trong việc kết nối;
- Khi xảy ra sự cố, không xác định được yêu cầu nào gây ra;
- Khi nhà cung cấp mô hình thay đổi, hệ thống rất khó điều chỉnh tập trung.
OpenRouter cung cấp các tính năng như không gian làm việc (workspace), kiểm soát ngân sách, nhật ký gọi API, chiến lược nhà cung cấp và định tuyến “không lưu trữ dữ liệu”, tất cả đều nhằm giải quyết những vấn đề này.
Ví dụ như tính năng “không lưu trữ dữ liệu” (zero data retention).
Đối với nhiều doanh nghiệp, không phải mọi yêu cầu đều có thể gửi tùy ý tới 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ế hay dữ liệu tài chính đều có thể chịu các quy định nghiêm ngặt.
Tài liệu OpenRouter hỗ trợ tính năng Zero Data Retention — nghĩa 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 tới các nhà cung cấp cam kết không lưu trữ dữ liệu. Chính sách này có thể áp dụng ở cấp độ toàn cục, theo nhóm mô hình, theo quy tắc bảo mật hoặc cho từng yêu cầu riêng lẻ.
Một ví dụ khác là tính năng “cache prompt” (tức lưu trữ tạm thời prompt).
Nhiều ứng dụng AI thường xuyên sử dụng các prompt hệ thống dài, nội dung cơ sở tri thức hoặc ngữ cảnh phức tạp. Nếu mỗi lần đều phải tính toán lại, chi phí sẽ rất cao.
OpenRouter hỗ trợ tăng tỷ lệ hit cache bằng cách định tuyến dựa trên “độ bám dính nhà cung cấp”, nhằm tối đa hóa khả năng các yêu cầu kế tiếp được gửi tới cùng một điểm cuối (endpoint) của nhà cung cấp, từ đó giảm chi phí xử lý ngữ cảnh lặp lại.
Các tính năng kiểu này nghe có vẻ không “ấn tượng”, nhưng lại cực kỳ thiết thực, và quy mô ứng dụng AI càng lớn thì mức tiết kiệm chi phí 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 dựa trên mức độ sử dụng.
Nhà phát triển trước tiên mua hạn mức sử dụng trên nền tảng, sau đó trả phí theo mô hình và số token thực tế được gọi.
OpenRouter công khai minh bạch:
Nền tảng thu phí 5,5% khi mua hạn mức, mức tối thiểu là 0,8 USD; giá gốc từ nhà cung cấp mô hình được chuyển nguyên giá tới người dùng, không cộng thêm bất kỳ khoản phí nào trên giá suy luận mô hình.
Đây là một mô hình kinh doanh điển hình kiểu “phí trung chuyển lưu lượng”.
Ưu điểm của mô hình này là doanh thu gắn chặt với mức độ sử dụng.
Nhà phát triển gọi càng nhiều, nền tảng thu nhập càng cao; ứng dụng AI càng phổ biến, lượng token tiêu thụ càng lớn, thì quy mô kinh doanh của OpenRouter càng mở rộng.
Tuy nhiên, mô hình này cũng có một đặc điểm: mức hoa hồng trên mỗi giao dịch không cao, nên bắt buộc phải dựa vào quy mô.
Đây cũng là lý do vì sao khối lượng token xử lý lại 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à số lượng token được xử lý hàng tuần, hàng tháng qua nền tả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 khối lượng xử lý hàng năm khoảng 1,5 triệu tỷ token.
Đây chính là logic nền tảng của mô hình 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ẽ tiếp tục thu phí dịch vụ từ mỗi lần gọi.
Vì sao gần đây tăng trưởng lại nhanh đến vậy?
Tăng trưởng của OpenRouter nói chung bắt nguồn từ ba xu hướng thay đổi.
Thứ nhất là số lượng mô hình ngày càng tăng.
Trước đây, khi xây dựng ứng dụng AI, nhiều đội nhóm mặc định chọn OpenAI làm ưu tiên hàng đầu. Giờ đây điều đó đã thay đổi.
Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, cùng vô số mô hình mã nguồn mở và mô hình có trọng số mở (open-weight) đều thể hiện ưu thế riêng trong các tình huống khác nhau.
Đây không phải một thị trường “mô hình này hoàn toàn thay thế mô hình kia”.
Một số mô hình giỏi viết mã, một số khác rẻ hơn, một số khác mạnh về xử lý văn bản dài, một số có tốc độ nhanh hơn, một số phù hợp với đóng vai (role-playing), một số thích hợp với tài liệu doanh nghiệp, một số phù hợp với đa phương thức (multimodal).
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, giá trị của lớp trung gian càng lớn.
Thứ hai là ứng dụng AI ngày càng quan tâm đến chi phí.
Nhiều sản phẩm trong giai đoạn đầu sử dụng mô hình mạnh nhất, vì mục tiêu trước mắt là đạt hiệu quả tốt nhất.
Nhưng một khi sản phẩm đã có người dùng, chi phí mô hình nhanh chóng trở thành vấn đề nan giải.
Một chatbot hỗ trợ khách hàng, một sản phẩm tìm kiếm AI, một trợ lý viết mã hay một công cụ tạo nội dung — nếu mọi yêu cầu đều chạy trên mô hình đắt nhất, biên lợi nhuận dễ dàng bị “ăn mòn”.
Giải pháp chín chắn hơn là phân chia tác vụ:
- Tác vụ đơn giản dùng mô hình rẻ;
- Tác vụ phức tạp dùng mô hình mạnh;
- Tác vụ có tần suất cao ưu tiên mô hình có độ trễ thấp;
- Khi thất bại, tự động chuyển sang mô hình dự phòng;
- Khi liên quan đến dữ liệu nhạy cảm, chỉ gửi yêu cầu tới nhà cung cấp tuân thủ chính sách bảo mật dữ liệu.
Đây chính xác là bối cảnh sử dụng điển hình của OpenRouter.
Nó không nhất thiết giúp bạn tìm ra “mô hình mạnh nhất”, nhưng chắc chắn giúp bạn cân bằng giữa hiệu quả, giá cả, tốc độ và độ ổn định.
Thứ ba là ứng dụng AI đang chuyển từ giao diện chat đơn thuần sang các tác tử thông minh (intelligent agent).
Các tác tử thông minh có khả năng gọi công cụ, đọc tệp, tìm kiếm trên web và thực hiện tác vụ, đồng thời có thể gọi mô hình nhiều vòng liên tiếp.
So với giao diện chat thông thường, các tác tử thông minh tiêu thụ nhiều token hơn và phụ thuộc cao hơn vào độ ổn định.
Điều này mang lại lợi ích cho OpenRouter.
Bởi vì số lần gọi càng nhiều, chuỗi xử lý càng dài, nhà phát triển càng cần đến khả năng định tuyến, dự phòng, ghi nhật ký, kiểm soát chi phí và quản lý nhà cung cấp.
Đây cũng là lý do vì sao thông báo tài trợ của OpenRouter nhấn mạnh rằng AI đang chuyển từ giai đoạn thử nghiệm sang các ứng dụng sản xuất then chốt và các kịch bản tác tử thông minh.
Sự tăng trưởng của nó về bản chất bắt nguồn từ việc khối lượng gọi AI ngày càng gia tăng.
Mô hình kinh doanh này cũng tiềm ẩn rủi ro
Vị trí của OpenRouter rất thuận lợi, nhưng không phải là an toàn tuyệt đối.
Nó nằm giữa các công ty cung cấp mô hình, nhà cung cấp điện toán đám mây và nhà phát triển ứng dụng — vị trí này vừa tạo ra giá trị, vừa dễ bị “nén ép”.
Rủi ro đầu tiên là các công ty lớn có thể tự xây dựng hệ thống tương tự.
Đối với các nhóm nhỏ, OpenRouter rất tiện lợi.
Nhưng với doanh nghiệp lớn, việc định tuyến mô hình, quản lý quyền hạn, ghi nhật ký và kiểm soát chi phí hoàn toàn có thể tự thực hiện hoặc giao cho nhà cung cấp điện toán đám mây đảm nhiệm.
Đặc biệt là khách hàng trong lĩnh vực tài chính, y tế và chính phủ — những đối tượng rất coi trọng khả năng kiểm soát dữ liệu và triển khai nội bộ (on-premise).
Để tiếp cận các khách hàng này, OpenRouter không thể chỉ dựa vào “số lượng mô hình”. Nó phải xây dựng sâu sắc các khả năng về quản lý 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 điện toán đám mây cũng sẽ phát triển cổng kết nối mô hình (model gateway).
AWS, Google Cloud và Azure vốn đã có sẵn cơ sở khách hàng doanh nghiệp, hệ thống hóa đơn, hệ thống quản lý quyền và năng lực tuân thủ.
Họ hoàn toàn có thể tích hợp khả năng gọi đa mô hình, định tuyến, giám sát và kiểm soát chi phí vào dịch vụ đám mây của mình.
Ưu thế của OpenRouter nằm ở tính mở và trung lập, phạm vi mô hình rộng hơn và tốc độ tích hợp nhanh hơn.
Nhưng ưu thế của các nhà cung cấp đám mây lại nằm ở 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 các nhà cung cấp mô hình.
OpenRouter mang lại lưu lượng truy cập cho các công ty cung cấp mô hình, nhưng đồng thời cũng làm “xa cách” họ hơn với nhà phát triển cuối cùng.
Khi nền tảng ngày càng mở rộng, nó sẽ nắm giữ nhiều hơn về mối quan hệ người dùng và dữ liệu sử dụng mô hình.
Các nhà cung cấp mô hình vừa mong muốn được phân phối, vừa lo ngại về việc mất dần quyền thương lượng.
Loại nền tảng trung gian này thường được các bên cung cấp chào đón trong giai đoạn đầu; nhưng khi quy mô mở rộng, mối quan hệ sẽ trở nên tinh tế và phức tạp hơn.
Rủi ro thứ tư là phí nền tảng có thể bị ép xuống thấp.
OpenRouter thu phí nền tảng 5,5%, mức này hiện vẫn được coi là hợp lý.
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 về 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ủ sẵn sàng đưa ra mức phí thấp hơn, hoặc các nhà cung cấp đám mây tích hợp khả năng này vào dịch vụ hiện có, OpenRouter sẽ phải chứng minh mình không chỉ là một “bộ định tuyến yêu cầu”.
Nó phải liên tục cung cấp khả năng định tuyến tốt hơn, phạm vi mô hình rộng hơn, giá cả minh bạch hơn, dịch vụ ổn định hơn và kiểm soát doanh nghiệp toàn diện hơn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
