<!-- Canonical URL: https://ask.atlascloud.ai/vi/migrate-openrouter-requests-to-openai-compatible-api -->

# Điều gì thay đổi khi chuyển yêu cầu OpenRouter sang một API khác tương thích OpenAI?

> Đổi base URL và API key chỉ là bước đầu khi rời OpenRouter. Các trường chat chuẩn thường chuyển được, nhưng ID mô hình, header và phần mở rộng định tuyến của OpenRouter, fallback, streaming, hạch toán mức dùng, đầu vào đa phương thức, lỗi và giới hạn tốc độ phải được kiểm thử sau adapter nhà cung cấp.

<!-- Canonical URL: https://ask.atlascloud.ai/migrate-openrouter-requests-to-openai-compatible-api -->

# Điều gì thay đổi khi chuyển yêu cầu OpenRouter sang một API khác tương thích OpenAI?

Với chat completion cơ bản, việc chuyển đổi có thể bắt đầu bằng base URL, API key và ID mô hình mới. Nhưng hành vi production rộng hơn hình dạng yêu cầu. Định tuyến, header, slug mô hình, fallback, metadata và lựa chọn nhà cung cấp riêng của OpenRouter cần được thay thế có chủ đích; streaming và tool call cần kiểm thử hợp đồng.

Hãy coi tương thích OpenAI là một phương ngữ truyền tải chung, không phải lời hứa rằng danh mục, phần mở rộng, thanh toán hay vận hành giống nhau.

## Kiểm kê hợp đồng bạn thực sự dùng

Tìm trong mã, cấu hình và log mọi trường gửi đến OpenRouter. Thiết lập OpenAI SDK được tài liệu hóa dùng `https://openrouter.ai/api/v1`, xác thực bearer và header ghi nhận tùy chọn. Ứng dụng cũng có thể dùng phần mở rộng định tuyến và fallback.

Tạo bảng kiểm kê trước khi đổi:

| Bề mặt | Thường chuyển được | Thường cần xem xét |
|---|---|---|
| Yêu cầu chat | `messages`, temperature, giới hạn đầu ra | Tham số không hỗ trợ và giá trị mặc định |
| Mô hình | Ý định ứng dụng | Slug riêng của nhà cung cấp |
| Công cụ | Tên hàm và JSON schema | Gọi song song, strictness, streaming đối số |
| Định tuyến | Không | Ưu tiên nhà cung cấp, fallback, transforms |
| Header | Mẫu xác thực | Header ghi nhận và metadata OpenRouter |
| Mức dùng | Số token | Trường chi phí, cache, tra cứu yêu cầu |
| Vận hành | Nhóm mã trạng thái HTTP | Rate limit, retry, timeout, nội dung lỗi |

## Trước tiên hãy thêm adapter nhà cung cấp

Đừng rải URL và slug mô hình mới khắp codebase. Đặt khác biệt nhà cung cấp sau một adapter và cung cấp alias ở cấp ứng dụng.

```python
from openai import OpenAI

def make_client(base_url: str, api_key: str) -> OpenAI:
    return OpenAI(base_url=base_url, api_key=api_key)

MODEL_MAP = {
    "coding_default": {
        "openrouter": "provider/model-slug",
        "target": "target-model-id",
    }
}
```

Adapter cũng nên dịch trường tùy chọn, chuẩn hóa lỗi và phát ra schema sự kiện chung.

## Thay thế ngữ nghĩa mô hình và định tuyến

Tương thích OpenAI không chuẩn hóa ID mô hình. Ánh xạ mỗi alias ứng dụng sang mô hình đích và kiểm tra độ dài ngữ cảnh, hỗ trợ công cụ, đầu ra có cấu trúc, phương thức và giá theo danh mục hiện tại.

OpenRouter hỗ trợ định tuyến và fallback mà gateway khác có thể biểu đạt khác hoặc không có. Quyết định tái tạo trong lớp điều phối, dùng router của đích hay chủ động bỏ. Thay đổi fallback âm thầm có thể đổi chi phí và chất lượng.

## Xóa hoặc chuyển đổi phần mở rộng OpenRouter

Xem lại header và trường body riêng của OpenRouter. Header ghi nhận tùy chọn thường có thể bỏ khi rời OpenRouter. Ưu tiên nhà cung cấp, mảng fallback, plugins, transforms và điều khiển metadata cần ánh xạ rõ.

Trong kiểm thử, từ chối phần mở rộng không biết. Âm thầm bỏ trường làm yêu cầu có vẻ thành công nhưng thay đổi hành vi.

## Kiểm thử hợp đồng công cụ và streaming

Tool calling là nơi API tưởng như tương thích thường khác nhau. Hãy kiểm thử:

* chấp nhận tên hàm và JSON schema;
* chế độ tool choice và gọi song song;
* sự kiện đối số công cụ tăng dần;
* finish reason và trường refusal;
* đối số sai và lần thử lại.

Với streaming, so sánh chuỗi sự kiện đã parse thay vì chunk thô. Bao gồm hủy, lỗi giữa stream, mức dùng cuối, delta rỗng và retry kết nối.

## Xây lại hạch toán mức dùng và chi phí

OpenRouter tài liệu hóa metadata lần sinh gồm mô hình, nhà cung cấp, mức dùng token và tổng chi phí. Gateway khác có thể trả mức dùng trong completion, qua endpoint tra cứu riêng hoặc yêu cầu định giá phía client.

Chuẩn hóa vào sổ cái riêng:

```json
{
  "request_id": "internal_123",
  "provider_request_id": "external_456",
  "gateway": "target",
  "model": "resolved-model-id",
  "input_tokens": 1200,
  "output_tokens": 340,
  "cost_usd": 0.0123
}
```

Tách ước tính khỏi phí đã đối soát. Kiểm tra lại việc thực thi ngân sách trước khi chuyển tác nhân production.

## Xác minh hình dạng yêu cầu đa phương thức

Hỗ trợ hình ảnh, âm thanh và video phụ thuộc mô hình và endpoint. Hai gateway có thể cùng hỗ trợ một phương thức nhưng khác schema content part, upload, truy cập URL, job bất đồng bộ hoặc đối tượng đầu ra.

Tạo fixture cho mỗi phương thức đang dùng. Đừng suy ra tương thích media từ một yêu cầu văn bản thành công.

## Kiểm thử hành vi vận hành

Đo header rate limit, mã trạng thái có thể retry, timeout, xếp hàng, kiểm soát khu vực, idempotency, logging và quy trình hỗ trợ. Dùng tài liệu hiện tại của nhà cung cấp.

Một rollout thực tế có bốn cổng:

1. Phát lại offline một bộ yêu cầu chuẩn.
2. Shadow lưu lượng an toàn mà không tạo hiệu ứng cho người dùng.
3. Canary một tỷ lệ nhỏ rủi ro thấp.
4. Chỉ mở rộng khi lỗi, độ trễ, chi phí và điều kiện đầu ra còn trong ngưỡng.

Giữ rollback một công tắc cho đến khi đường mới chịu được tải đại diện.

## Quyết định việc hợp nhất có đáng giá không

OpenRouter vẫn phù hợp khi danh mục LLM rộng và điều khiển định tuyến khớp sản phẩm. Gateway đầy đủ phương thức như Atlas Cloud có thể hấp dẫn khi một quan hệ tương thích OpenAI cho văn bản, hình ảnh và video giúp đơn giản hóa stack. Cả hai vẫn cần kiểm thử mô hình và tính năng.

Hãy chọn theo yêu cầu workload đã đo, không theo diff mã nhỏ nhất.

## Kết luận

Khi chuyển lưu lượng OpenRouter, hãy đổi cấu hình client rồi kiểm tra mọi giả định không chuẩn về mô hình, định tuyến, công cụ, streaming, mức dùng và vận hành. Adapter nhà cung cấp cùng bộ kiểm thử chuẩn giữ quá trình có thể đảo ngược và ngăn hồi quy ngữ nghĩa bị che giấu.

## FAQ

### Tôi có thể rời OpenRouter chỉ bằng cách đổi base_url và api_key không?

Đôi khi với yêu cầu chat đơn giản, nhưng tích hợp production thường còn phụ thuộc slug mô hình, tùy chọn định tuyến, header, hành vi streaming, trường sử dụng hoặc ngữ nghĩa fallback.

### Trường OpenRouter nào có khả năng không chuyển được?

Ưu tiên định tuyến nhà cung cấp, mảng fallback, header ghi nhận OpenRouter, transforms, plugins và metadata riêng là các điểm chuyển đổi phổ biến. Hãy giữ chúng ngoài mô hình yêu cầu lõi.

### Các API tương thích OpenAI có dùng cùng tên mô hình không?

Không. Tương thích thường chỉ bao phủ hình dạng yêu cầu, không phải danh mục. Hãy ánh xạ rõ alias mô hình của ứng dụng sang ID hiện tại của từng gateway.

### Nên kiểm thử streaming sau khi chuyển thế nào?

Ghi chuỗi sự kiện cho delta văn bản, đối số tool call, finish reason, mức dùng, hủy và lỗi. So sánh sự kiện đã parse thay vì byte thô vì cách đóng khung có thể khác.

### Cách triển khai chuyển đổi an toàn nhất là gì?

Dùng adapter, phát lại bộ yêu cầu chuẩn, shadow một mẫu nhỏ không ảnh hưởng người dùng, rồi canary lưu lượng rủi ro thấp với ngưỡng rollback cho lỗi, độ trễ, chi phí và điều kiện đầu ra.

### Khi nào nhóm nên tiếp tục dùng OpenRouter?

Tiếp tục khi danh mục LLM rộng, kiểm soát định tuyến và công cụ vận hành hiện có có giá trị hơn việc hợp nhất nơi khác. Quyết định theo yêu cầu đã đo, không chỉ theo tuyên bố tương thích.
