OpenRouter hay gọi trực tiếp: Chọn cách bạn gọi LLM

Các cách triển khai lệnh gọi LLM

1) API trực tiếp của nhà cung cấp

Bạn tích hợp với điểm cuối của một nhà cung cấp và tự chịu trách nhiệm cho phần còn lại: thử lại, phương án dự phòng, theo dõi mức sử dụng, luân chuyển khóa và chuyển đổi dự phòng.

Đây là phương án đơn giản nhất khi:

• bạn đã biết mình muốn dùng mô hình nào,
• độ trễ là yếu tố quan trọng,
• yêu cầu tuân thủ đòi hỏi chuỗi nhà cung cấp gọn hơn,
• và lưu lượng của bạn đủ ổn định để bạn có thể lập kế hoạch dựa trên các giới hạn của một nhà cung cấp.

2) Cổng trung gian / bộ tổng hợp / bộ chuyển tiếp

Bạn gửi yêu cầu đến một lớp trung gian để chuyển tiếp tới một trong nhiều nhà cung cấp. OpenRouter là ví dụ nổi tiếng nhất, nhưng mô hình này không chỉ giới hạn ở một công ty.

Phương án này hấp dẫn khi:

• bạn muốn có nhiều lựa chọn mô hình thông qua một tích hợp duy nhất,
• bạn cần định tuyến dự phòng,
• bạn thường xuyên thử nghiệm các mô hình,
• hoặc bạn không muốn quản lý nhiều SDK và tài khoản thanh toán của các nhà cung cấp.

3) Tự lưu trữ

Bạn chạy một mô hình mở trên hạ tầng của mình, thường thông qua bộ định tuyến riêng.

Phương án này có lợi thế khi:

• quyền kiểm soát dữ liệu là yêu cầu không thể thỏa hiệp,
• khối lượng sử dụng đủ lớn để phần cứng luôn có việc xử lý,
• hoặc bạn cần chi phí trên mỗi token có thể dự đoán được và có thể đảm nhận gánh nặng vận hành.

Những khác biệt trong thực tế

Đây là điều mọi người thường bỏ qua: lựa chọn tốt nhất thường không chỉ phụ thuộc vào giá token thuần túy. Nó còn phụ thuộc vào toàn bộ chuỗi sự cố.

Bảng này che khuất một sự thật quan trọng: gateway hiếm khi giúp tiết kiệm tiền một cách thần kỳ. Nó giúp tiết kiệm tiền khi tránh được việc thiết kế quá mức cần thiết, giảm thời gian ngừng hoạt động hoặc cho phép bạn tự động định tuyến tác vụ đến mô hình rẻ nhất đáp ứng yêu cầu.

Chi phí thực sự thay đổi ở đâu

Nếu bạn dùng một mô hình duy nhất cho mọi việc, gọi trực tiếp thường là cách đơn giản nhất và rẻ nhất. Nhưng hầu hết hệ thống thực tế đều phức tạp hơn:

• tính năng trò chuyện trong sản phẩm dùng mô hình cao cấp,
• bản nháp trả lời hỗ trợ dùng mô hình rẻ hơn,
• tác vụ tóm tắt dùng mô hình nhỏ và nhanh,
• và lưu lượng tăng đột biến cần năng lực xử lý bổ sung.

Đó là lúc một dịch vụ chuyển tiếp có thể giúp ích. Không phải vì giá niêm yết thấp hơn, mà vì nó cho phép bạn đưa ra quyết định định tuyến một cách tập trung.

Một chính sách đơn giản có thể như sau:

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

Cấu hình đó không dành riêng cho nhà cung cấp nào; đó là cấu trúc của một bộ định tuyến hợp lý. Trên thực tế, khoản tiết kiệm đến từ việc tránh lãng phí:

• đừng gửi mọi tác vụ trích xuất đến mô hình đắt nhất của bạn,
• đừng thử lại mãi với một nhà cung cấp hoạt động thiếu ổn định,
• đừng duy trì một tích hợp thứ hai chỉ để phục vụ 2% lưu lượng tăng vọt vào thứ Sáu.

Một vấn đề dễ gặp: nếu ứng dụng của bạn có lệnh gọi công cụ hoặc tác động phụ, việc thử lại có thể lặp lại các hành động. Nếu gateway thử lại một yêu cầu sau khi hết thời gian chờ, mô hình có thể phát lại cùng một lệnh gọi hàm. Nếu không có khóa bảo đảm tính lũy đẳng và thiết kế công cụ cẩn thận, “phương án dự phòng hữu ích” sẽ trở thành “tạo phiếu hỗ trợ trùng lặp” hoặc “thu tiền hai lần”.

Khi nào gateway thực sự hữu ích

Tôi sẽ chọn một dịch vụ tổng hợp hoặc chuyển tiếp khi có ít nhất một trong các điều sau:

• Bạn vẫn đang tìm hiểu khối lượng công việc. Ở giai đoạn đầu, bạn chưa biết liệu GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3 hay một mô hình mở sẽ phù hợp nhất với tác vụ của mình.
• Bạn muốn định tuyến theo tác vụ, không phải theo nhà cung cấp. Một bộ phân loại có thể gửi các prompt ngắn đến mô hình rẻ và nhanh, còn công việc có ngữ cảnh dài đến một mô hình như Fable 5 khi đó thực sự là lựa chọn phù hợp hơn.
• Bạn cần một phương án chuyển sang dự phòng nhanh chóng. Nếu một nhà cung cấp bắt đầu áp dụng giới hạn tốc độ, dịch vụ chuyển tiếp có thể chuyển lưu lượng trước khi người dùng nhận ra.
• Bạn không muốn có năm hệ thống thanh toán. Một hóa đơn và một tích hợp dễ quản lý hơn việc xoay xở với nhiều khóa, hạn ngạch và bảng theo dõi chi tiêu.
• Bạn cần một lớp trừu tượng cho các sản phẩm đa khách thuê. Gateway cho phép bạn thay đổi nhà cung cấp ở tầng bên dưới mà không phải viết lại ứng dụng.

Điều này đặc biệt hữu ích nếu đội ngũ của bạn nhỏ. Tôi từng thấy các đội ngũ startup dành nhiều thời gian để xây dựng logic thử lại riêng cho từng nhà cung cấp hơn là tạo ra giá trị cho sản phẩm. Một dịch vụ chuyển tiếp có thể gom công việc đó về một nơi.

Khi nào gọi trực tiếp là lựa chọn tốt hơn

API trực tiếp của nhà cung cấp thường chiếm ưu thế khi bạn quan tâm đến bất kỳ điều nào sau đây:

• Độ trễ thấp nhất. Giảm một chặng truyền có ý nghĩa khi ngân sách độ trễ của sản phẩm eo hẹp. Nếu bạn muốn một tương tác 300 ms tạo cảm giác “tức thì”, phần chi phí thời gian bổ sung cho mạng và định tuyến có thể chiếm một phần đáng kể trong ngân sách đó.
• Ranh giới tuân thủ nghiêm ngặt. Mỗi bên xử lý bổ sung đồng nghĩa với thêm một mối quan hệ, thêm một bộ quy tắc lưu giữ dữ liệu và thêm một lần rà soát hợp đồng.
• Các tính năng riêng của nhà cung cấp. Một số nhà cung cấp cung cấp những khả năng mà các dịch vụ tổng hợp hoặc làm mất đi khi chuẩn hóa, hoặc chậm hỗ trợ.
• Lưu lượng lớn, có thể dự đoán. Khi mức sử dụng đã ổn định, định tuyến tùy chỉnh có thể rẻ hơn việc trả tiền cho một lớp trung gian.
• Quy trình hỗ trợ rõ ràng hơn. Khi có sự cố, việc đổ lỗi qua lại ít hơn.

Lợi ích ít thấy là sự rõ ràng trong vận hành. Nếu đường đi của lệnh gọi là trực tiếp, bạn sẽ dễ khoanh vùng nguyên nhân gốc rễ của lỗi hơn. Nếu lệnh gọi thất bại, nguyên nhân thường nằm ở mã của bạn hoặc nhà cung cấp. Với gateway, bạn còn phải xác định liệu dịch vụ chuyển tiếp, lớp định tuyến của dịch vụ đó hay nhà cung cấp ở phía trên gây ra lỗi.

Tự lưu trữ là một bài toán khác

Tự lưu trữ các mô hình mở không chỉ là “API rẻ hơn, nhưng chạy trên máy chủ của tôi”. Đó là một bài toán hệ thống.

Bạn cần cân nhắc:

• quy mô và mức sử dụng GPU,
• xử lý theo lô,
• lượng tử hóa,
• áp lực lên bộ nhớ đệm KV,
• tự động điều chỉnh quy mô,
• khởi động từ trạng thái đã sẵn sàng,
• bộ lọc an toàn,
• cập nhật mô hình,
• và quy trình khôi phục về phiên bản trước.

Ưu điểm là khả năng kiểm soát. Nếu khối lượng công việc của bạn ổn định và đủ lớn, tự lưu trữ có thể hấp dẫn về mặt kinh tế. Nhưng bài toán chi phí chỉ hợp lý khi bạn duy trì được mức sử dụng phần cứng. GPU nhàn rỗi rất tốn kém. Thời gian kỹ thuật để hệ thống phục vụ mô hình hoạt động ổn định dưới áp lực cũng vậy.

Một vấn đề dễ gặp khác là chất lượng thay đổi theo thời gian. Một mô hình mở hôm nay có thể đủ tốt để tóm tắt, nhưng kết quả đánh giá của bạn có thể xuống dốc khi độ dài prompt, yêu cầu về phong cách hoặc cách sử dụng công cụ thay đổi. Đừng cho rằng “mở” tự động có nghĩa là “đủ rẻ để thay thế một API được quản lý”.

Một mô hình kết hợp thực tế

Trong các hệ thống thực tế, kiến trúc tốt nhất thường là sự kết hợp:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

Và bên trong ứng dụng:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

Mô hình đó giữ cho luồng xử lý trọng yếu đơn giản, đồng thời vẫn mang lại sự linh hoạt trong định tuyến. Tôi nhận thấy đây thường là hướng mà các đội ngũ lựa chọn sau tháng đầu tiên vận hành thực tế: gọi trực tiếp cho trải nghiệm người dùng cốt lõi, dùng gateway để thử nghiệm và xử lý lưu lượng vượt khả năng, chỉ tự lưu trữ khi lợi ích kinh tế hoặc quyền riêng tư thực sự rõ ràng.

Quyền riêng tư, độ trễ và sự tin cậy

Đây là lúc kỹ thuật trở thành vấn đề chính sách.

Quyền riêng tư

Gateway thay đổi ranh giới tin cậy của bạn. Ngay cả khi prompt được chuyển tiếp đến nhà cung cấp ở phía trên, bạn vẫn cần trả lời:

• Dịch vụ chuyển tiếp có ghi nhật ký prompt không?
• Chúng được lưu giữ trong bao lâu?
• Những bên xử lý phụ nào có thể xem chúng?
• Bạn có thể giữ một số khách thuê trên một tuyến xử lý hạn chế không?
• Có hỗ trợ cố định khu vực xử lý không?

Với khối lượng công việc chịu sự quản lý theo quy định, “nhà cung cấp đã hứa sẽ làm đúng” là chưa đủ. Bạn cần hồ sơ tài liệu và một thiết kế phù hợp với hồ sơ đó.

Độ trễ

Một dịch vụ chuyển tiếp thêm một chặng truyền. Điều đó không tự động khiến ứng dụng chậm đi, nhưng có làm tăng sự bất định. Nếu ứng dụng của bạn thực hiện nhiều lần trao đổi và việc truyền token theo luồng là quan trọng, mỗi lớp bổ sung có thể khiến thời gian đến token đầu tiên khó dự đoán hơn.

Giới hạn tốc độ

Các tích hợp trực tiếp chịu nguyên các giới hạn của nhà cung cấp. Gateway có thể giảm bớt tác động bằng cách phân tán lưu lượng giữa các nhà cung cấp, nhưng cũng có thể áp dụng giới hạn riêng. Nói cách khác: bạn có thể đổi giới hạn này lấy giới hạn khác. Lợi ích là khả năng co giãn, chứ không phải thoát khỏi mọi giới hạn.

Quy tắc ra quyết định tôi sử dụng

Nếu phải cô đọng lựa chọn trong một câu: hãy gọi trực tiếp khi bạn biết cần dùng mô hình nào và quan tâm đến đường đi của lệnh gọi; dùng gateway khi bạn quan tâm đến khả năng lựa chọn và khả năng chống chịu sự cố; tự lưu trữ khi khả năng kiểm soát và mức sử dụng ổn định đủ để bù đắp chi phí vận hành.

Một vài quy tắc thực tiễn cụ thể:

• Bắt đầu bằng cách gọi trực tiếp nếu bạn đang đưa tính năng đầu tiên vào môi trường vận hành thực tế và chỉ cần một mô hình.
• Thêm gateway khi bạn có ít nhất hai loại mô hình khác nhau, hoặc khi vấn đề chuyển đổi dự phòng bắt đầu xuất hiện trong các cuộc rà soát sự cố.
• Chỉ tự lưu trữ sau khi bạn có số liệu sử dụng thực tế và lý do rõ ràng để tự quản lý toàn bộ hệ thống.
• Dùng gateway để thử nghiệm định tuyến, nhưng bảo đảm luồng xử lý trọng yếu có tính lũy đẳng.
• Đo chi phí từ đầu đến cuối, không chỉ giá token.

Những điểm thực tiễn cần ghi nhớ

• Ưu tiên API trực tiếp để có độ trễ tối ưu, gỡ lỗi đơn giản nhất và hỗ trợ tốt nhất cho các tính năng riêng của nhà cung cấp.
• Ưu tiên một gateway/dịch vụ tổng hợp khi bạn cần định tuyến đa mô hình, khả năng dự phòng hoặc một tích hợp dùng cho nhiều nhà cung cấp.
• Ưu tiên tự lưu trữ chỉ khi bạn có thể duy trì mức sử dụng phần cứng và chấp nhận sự phức tạp trong vận hành.
• Xây dựng tính lũy đẳng và quy tắc thử lại chặt chẽ trước khi thêm các phương án dự phòng tự động.
• So sánh tổng chi phí: token, phụ phí, các lần thử lại, thời gian kỹ thuật và khôi phục sau sự cố.
• Lưu quyền riêng tư và việc lưu giữ dữ liệu trong quyết định ngay từ ngày đầu, không phải đợi đến khi bộ phận mua sắm hỏi.
• Sử dụng một kiến trúc kết hợp nếu khối lượng công việc của bạn có cả các luồng xử lý cao cấp lẫn phổ thông.

Nếu bạn muốn, tôi có thể chuyển nội dung này thành một phiên bản thể hiện quan điểm rõ hơn cho một nhóm đối tượng cụ thể, chẳng hạn như những người xây dựng startup, các nhóm nền tảng hoặc các nhóm doanh nghiệp có yêu cầu tuân thủ cao.