· openrouter / llm / api

OpenRouter vs direct API: khi nào gateway là đúng?

OpenRouter thắng cho đa model và automatic failover. Direct API thắng khi single-provider, lưu lượng lớn hoặc workload cần compliance. Đây là cách chọn đúng.

Bởi

2.346 từ · 12 phút đọc

Chọn OpenRouter nếu bạn đang chạy nhiều hơn một model family, cần automatic failover mà không muốn tự viết retry logic, hoặc đang chi dưới $5,000/tháng — lúc đó phí platform còn rẻ hơn vài giờ công của lập trình viên. Chọn direct API nếu bạn chỉ dùng một provider với lưu lượng lớn, có yêu cầu compliance ràng buộc vào endpoint của nhà cung cấp cụ thể, hoặc cần tính năng riêng của provider mà một lớp gateway không thể expose. Phần còn lại của bài này đưa ra bằng chứng để bạn đưa ra quyết định đó.

Bài này dành cho ai

Các developer đang thực sự chi tiền cho LLM API và đang cân nhắc xem có nên thêm một lớp gateway không. Nếu bạn còn đang trong giai đoạn thử nghiệm với $20 credit miễn phí, bookmark bài này và quay lại khi bạn có workload thực — các đánh đổi này chỉ thực sự quan trọng ở quy mô lớn.

Những gì chúng tôi đánh giá

Giá token của OpenRouter tính đến tháng 5 năm 2026, đối chiếu với giá trực tiếp của Anthropic và OpenAI. Latency từ benchmark của opper.ai công bố tháng 4 năm 2026: 200 lần gọi GPT-4.1, so sánh OpenRouter và OpenAI direct từ cùng một origin. Uptime từ status.openrouter.ai, cả thời điểm hiện tại lẫn lịch sử năm 2025. Phân tích chi phí đối chiếu với tokenmix.ai. Catalog model, tùy chọn routing, và tài liệu bảo mật của OpenRouter từ openrouter.ai.

Giá — “không markup” phần lớn là đúng, nhưng đọc kỹ phần nhỏ

OpenRouter truyền thẳng giá token của provider xuống cho bạn, không tính thêm phí per-token. Tính đến tháng 5 năm 2026, giá khớp với giá trực tiếp từ provider: Claude Opus 4.7 ở mức $5 input / $25 output mỗi triệu token, Sonnet 4.6 là $3/$15, Haiku 4.5 là $1/$5. Giá của OpenAI và Google cũng được pass-through tương tự.

Chi phí thực tế là phí platform 5.5% trên mỗi lần nạp credit bằng thẻ tín dụng. Không có phí theo từng API call. Phí được tính khi bạn nạp credit — không phải khi bạn gửi request.

Có đáng hay không phụ thuộc hoàn toàn vào mức chi của bạn:

Chi tiêu LLM mỗi thángPhí OpenRouterTương đương thời gian lập trình viên
$500~$28~14 phút
$1,000~$55~30 phút
$5,000~$275~2.3 giờ
$10,000~$550~4.6 giờ

Ở mức $1,000/tháng, phí này không đáng kể so với tổng chi phí hạ tầng. Ở mức $10,000/tháng, bạn đang trả $550/tháng cho một bộ tính năng có thể tự xây — nhưng chỉ khi bạn thực sự xây, duy trì và vận hành nó. Công sức engineering để tái tạo smart routing và automatic failover không hề miễn phí. Với hầu hết các team, $550 đổi lại nhiều hơn số giờ công tương đương.

Câu hỏi về điểm hòa vốn không phải là về lượng token. Mà là về việc bạn có muốn sở hữu và duy trì hạ tầng routing đa provider hay không. Nếu có, đi thẳng và tự xây sẽ tiết kiệm được phí. Nếu không, hãy trả phí đó.

Phân tích theo từng loại task — khi nào dùng model rẻ hơn tiết kiệm chi phí hơn là chọn gateway — có trong LLM cost routing: khi nào Haiku thắng Opus và khi nào không.

Latency — OpenRouter có thể nhanh hơn, không phải chậm hơn

Điều này đi ngược trực giác. Giả định mặc định là bất kỳ gateway nào cũng thêm latency. Trong thực tế, điều ngược lại có thể đo được.

Benchmark của opper.ai (tháng 4 năm 2026, 200 lần gọi, GPT-4.1) cho thấy OpenRouter gửi first token nhanh hơn 70ms so với OpenAI direct từ cùng một origin. Throughput lại là câu chuyện khác: 73.2 tok/s trên OpenRouter so với 81.8 tok/s direct — giảm 10% tốc độ generation liên tục. Bạn đánh đổi một phần throughput để lấy time-to-first-byte nhanh hơn.

Cơ chế ở đây là smart routing của OpenRouter. Thay vì luôn gửi request đến một endpoint cố định của provider, nó định tuyến động đến replica có latency thấp nhất tại thời điểm đó, tránh các instance đang tắc nghẽn thay vì xếp hàng chờ. Kết quả là p95 latency thấp hơn đáng kể so với việc ghim vào một provider duy nhất — dù mức độ cụ thể phụ thuộc vào model, tải của provider, và vị trí địa lý của origin.

Tuy nhiên, kết quả của opper.ai chỉ là một workload trên một origin với một model. Các phép đo khác cho thấy OpenRouter thêm 50–70ms overhead trong điều kiện ổn định, đúng như kỳ vọng từ một network hop bổ sung. Việc smart routing có bù đắp được điều đó hay không phụ thuộc vào tải provider tại thời điểm gọi, vị trí địa lý của bạn, và model bạn đang nhắm tới.

Nếu ứng dụng của bạn nhạy cảm về latency — streaming chat, giọng nói, bất cứ thứ gì mà time-to-first-byte ảnh hưởng đến người dùng — đừng giả định chiều nào. Hãy chạy workload thực của bạn qua cả hai path và đo. Kết quả sẽ khác nhau tùy model, region, và thời điểm trong ngày.

Failover — tự động, nhưng hãy kiểm tra fallback

Lý do chính khiến các team thêm gateway là automatic failover. Với OpenRouter, bạn truyền một mảng models trong request:

response = client.chat.completions.create(
    model="openai/gpt-4.1",
    extra_body={
        "models": [
            "openai/gpt-4.1",
            "anthropic/claude-sonnet-4-6",
            "google/gemini-2.0-flash"
        ]
    },
    messages=[{"role": "user", "content": prompt}]
)

Nếu model đầu tiên chạm rate limit, trả về 5xx, hoặc từ chối content do kiểm duyệt, OpenRouter tự động chuyển sang model tiếp theo trong danh sách. Fallback được tính giá theo model thực sự xử lý request. Bạn không cần viết retry logic, circuit breaker, hay health-check poller.

Bạn cũng có thể điều chỉnh hành vi routing giữa các provider: sắp xếp theo giá, throughput, hoặc latency, và chỉ định rõ provider nào được phép hoặc bị bỏ qua trong một model family. Mức độ chi tiết này sẽ tốn khá nhiều công engineering nếu tự xây.

Điểm cần lưu ý: các fallback model cho kết quả khác nhau. Nếu bạn đã tinh chỉnh prompt cho GPT-4.1, Claude Sonnet sẽ diễn giải cùng prompt đó với độ nhấn mạnh, độ dài, và cách format khác nhau. API response có cùng cấu trúc, nhưng nội dung sẽ không giống nhau. Nếu code phía sau phân tích structured output hoặc phụ thuộc vào một kiểu response cụ thể, bạn cần kiểm tra prompt của mình hoạt động chấp nhận được trên tất cả các model trong fallback chain trước khi đưa vào production.

Độ tin cậy — track record tốt, nhưng không có SLA

OpenRouter hiện báo cáo uptime 100% trên chat API và 99.97% trên data API (status.openrouter.ai). Với một nền tảng còn khá mới, đó là thành tích đáng kể.

Không có SLA được công bố.

Câu đó quan trọng hơn các con số uptime. Nếu bạn có cam kết uptime theo hợp đồng với khách hàng, bạn không thể chuyển giao nó cho một vendor không có bảo đảm uptime. “Chúng tôi đã hoạt động ổn” không phải là SLA. Direct API từ Anthropic và OpenAI cũng không có SLA rõ ràng cho hầu hết các gói, nhưng ít nhất bạn đang giảm số điểm lỗi trong chuỗi: sự sẵn sàng của một provider thay vì hai.

Với các workload đòi hỏi SLA, đi thẳng là lựa chọn an toàn hơn — không phải vì direct đáng tin cậy hơn, mà vì gateway của OpenRouter là một dependency bổ sung không có cam kết uptime công khai. Một thiết lập dual-provider với routing logic của riêng bạn mang lại khả năng phục hồi tương đương với ít dependency black-box hơn.

Bảo mật và quản lý key

OpenRouter mặc định không log nội dung request vào lịch sử tài khoản của bạn. Nền tảng đạt chuẩn SOC-2 và GDPR. Bạn có thể dùng key của chính mình (BYOK) nếu muốn tránh việc routing credentials qua key vault của OpenRouter.

GitHub phát hiện OpenRouter API key bị commit và cảnh báo bạn trước khi bạn thấy vi phạm trong log (OpenRouter được liệt kê trong các pattern push-protection và user-alert của GitHub).

Chi tiết mà hầu hết các team bỏ qua: compliance routing đến Bedrock hoặc Vertex AI. Khi bạn route request Claude qua provider Bedrock hoặc Vertex AI trên OpenRouter, chúng không đi đến Anthropic.com — mà route đến hạ tầng của AWS hoặc Google. Điều này có ý nghĩa theo hai hướng:

Nếu yêu cầu compliance của bạn là “Claude inference không được đụng đến hạ tầng consumer của Anthropic,” routing này xử lý được mà không cần bạn tự thiết lập tích hợp Bedrock hoặc Vertex. Với các team muốn năng lực của Claude nhưng cần data boundary theo cloud cụ thể, đây là một shortcut engineering đáng kể.

Nếu yêu cầu compliance của bạn là “tất cả traffic phải đi đến [endpoint vendor cụ thể]” với audit trail đến endpoint đó, traffic vẫn route qua OpenRouter. Điều này có thể hoặc không thỏa mãn cách hiểu của team compliance — hãy xác nhận bằng văn bản trước khi cam kết với kiến trúc này.

Độ phủ model — hơn 400 model, một API format duy nhất

OpenRouter cho bạn truy cập hơn 400 model từ hơn 60 provider qua một giao diện tương thích OpenAI. Bạn viết một tích hợp duy nhất — chat/completions — và có quyền truy cập Anthropic, Google, Meta, Mistral, Cohere, cùng hàng chục provider nhỏ hơn mà không cần học SDK hay cơ chế xác thực riêng của từng vendor.

Open-source model là điểm mạnh đặc biệt. Dòng Llama của Meta và các model của Mistral chạy qua community provider với giá thấp hơn nhiều so với các model proprietary tương đương. Với các workload mà chất lượng output từ open-source model là chấp nhận được, chênh lệch chi phí per-token khá lớn.

Khoảng trống: một số model enterprise và preview vẫn chỉ có trực tiếp. Khi provider ra mắt model mới, thường có một khoảng lag trước khi OpenRouter route đến được. Nếu bạn cần truy cập ngay khi model vừa ra mắt, hoặc model đó chỉ có trong hợp đồng enterprise đòi hỏi provisioning trực tiếp, bạn vẫn phải đi thẳng dù sao đi nữa.

Chi phí chuyển đổi

Nếu bạn đang dùng bất kỳ OpenAI-compatible SDK nào, việc chuyển sang OpenRouter chỉ cần thay đổi một dòng — đổi base_url thành https://openrouter.ai/api/v1 và cập nhật API key. Giao diện không thay đổi.

Chiều ngược lại — từ OpenRouter về direct — cũng tương tự dễ dàng. Mảng models, cấu hình routing, và chọn provider là những thứ riêng của OpenRouter, nhưng cấu trúc core của chat completions là chuẩn. Không có format proprietary nào khóa chặt bạn ở cả hai phía.

Chi phí chuyển đổi thực sự không phải là việc thay đổi API. Mà là kiểm tra các phụ thuộc giữa prompt và model, và kiểm tra fallback behavior — điều bạn nên làm dù chọn path nào.

Kết luận

Dùng OpenRouter nếu:

  • Bạn đang chạy nhiều hơn hai model family, hoặc đánh giá model mới đủ thường xuyên để một giao diện thống nhất tiết kiệm thực sự thời gian tích hợp
  • Bạn cần automatic failover mà không muốn tự xây và duy trì routing logic
  • Bạn chi dưới $5,000/tháng — ở mức đó, phí platform rẻ hơn số giờ công để tự thay thế những gì nó làm
  • Bạn muốn Bedrock hoặc Vertex routing cho Claude mà không cần tự thiết lập cloud infrastructure
  • Team bạn đủ nhỏ để việc quản lý nhiều provider key và dashboard là gánh nặng thực sự

Đi thẳng nếu:

  • Bạn chỉ dùng một provider với lưu lượng lớn — phí cộng dồn mà không thêm giá trị khi bạn không dùng multi-model routing hay failover
  • Bạn có workload đòi hỏi SLA và thái độ không-SLA của OpenRouter là vấn đề cứng
  • Yêu cầu compliance của bạn chỉ định rõ endpoint vendor theo cách mà proxy gateway không thể đáp ứng
  • Bạn cần tính năng riêng của provider mà giao diện chuẩn của OpenRouter không expose — batch processing, fine-tuned model endpoint, các parameter riêng của provider
  • Bạn đã ở quy mô mà investment engineering là chi phí nhỏ hơn phí platform hàng tháng

Nếu bạn đang đánh giá cả các lựa chọn self-hosted như LiteLLM và Portkey, LLM router tốt nhất 2026: OpenRouter, LiteLLM, Portkey có so sánh đầy đủ.

Lưu ý

Các con số latency trong bài này đến từ một benchmark bên thứ ba duy nhất (opper.ai, tháng 4 năm 2026, chỉ với GPT-4.1). Hành vi smart routing của OpenRouter thay đổi theo model, tải provider, và vị trí địa lý của origin. Nếu latency là tiêu chí quyết định chính của bạn, hãy đo workload cụ thể của bạn qua cả hai path.

Các con số giá trong bài là từ tháng 5 năm 2026. Giá token do provider ấn định và có thể thay đổi. Phí platform 5.5% do OpenRouter ấn định và cũng có thể thay đổi. Kiểm tra giá hiện tại trước khi xây dựng dự toán tài chính dựa trên các con số này.

Không có quan hệ affiliate với OpenRouter, Anthropic, hay OpenAI. Không có hoa hồng nào ảnh hưởng đến kết luận này.

Tài liệu tham khảo