Giới Thiệu

Trong thế giới phát triển phần mềm, rất nhiều lập trình viên đã dựa vào OpenAI Chat Completions API. Nhưng nếu nền tảng của bạn cần độc lập nhà cung cấp và tối ưu chi phí bằng cách chạy suy diễn trên AWS Bedrock (hoặc GCP Vertex AI) — trong khi vẫn cung cấp cho lập trình viên một API tương thích với OpenAI? Đây là thách thức mà tôi đã gặp phải khi xây dựng OnglX Deploy.

Bối Cảnh & Quyết Định Kiến Trúc

Tôi muốn lập trình viên có thể áp dụng OnglX Deploy mà không cần thay đổi mã nguồn. Điều này có nghĩa là:

• Hỗ trợ định dạng OpenAI API như hiện tại.
• Chạy suy diễn trên Bedrock, không phải OpenAI.
• Giữ mọi thứ mở rộng cho môi trường đa đám mây (AWS + GCP).
• Bảo mật bằng API keys và các thực hành tốt nhất về IAM không máy chủ.

Sự lựa chọn kiến trúc: một tầng dịch giao thức chấp nhận các yêu cầu theo phong cách OpenAI và chuyển đổi chúng sang định dạng cụ thể của nhà cung cấp — và ngược lại.

Thách Thức Cụ Thể

Mô hình của Bedrock (và các nhà cung cấp khác) không nói cùng một “ngôn ngữ.”

• Claude yêu cầu xử lý riêng biệt các hệ thống nhắc nhở.
• Llama mong đợi một nhắc nhở theo kiểu tiếp tục.
• Titan chỉ hỗ trợ inputText.

Báo cáo sử dụng token và thông báo lỗi cũng khác nhau.

Vậy làm thế nào để bạn thống nhất tất cả điều đó trong khi vẫn trông và hoạt động như OpenAI?

Các Phương Án Giải Quyết Tôi Đã Xem Xét

1. Điểm Cuối Cung Cấp Cụ Thể
   • ✅ Sạch hơn cho từng họ mô hình
   • ❌ Phá vỡ khả năng tương thích
2. Tầng Dịch Thống Nhất (Lựa Chọn)
   • ✅ Hoạt động trực tiếp với khách hàng OpenAI
   • ✅ Có thể mở rộng cho đa đám mây
   • ❌ Cần nhiều logic và kiểm thử dịch hơn

Các Đánh Giá

• Khả năng tương thích vs Hiệu suất → Chúng tôi ưu tiên khả năng tương thích. Thời gian khởi động lạnh và chi phí dịch là chấp nhận được vì độ trễ suy diễn là yếu tố chi phối.
• Hỗ trợ đa đám mây vs Đơn giản → Thêm phức tạp, nhưng đảm bảo tính di động và tránh bị khóa.
• Không máy chủ vs Cơ sở hạ tầng chuyên dụng → Chọn không máy chủ vì hiệu quả chi phí và khả năng mở rộng, mặc dù có độ trễ khởi động lạnh hơi cao hơn một chút.

Chi Tiết Thực Hiện

Ví Dụ Dịch Yêu Cầu

Các tin nhắn hệ thống trong OpenAI có thể xuất hiện ở bất kỳ đâu, nhưng Claude cần chúng được tách biệt:

system_messages = [m for m in messages if m['role'] == 'system']
conversation_messages = [m for m in messages if m['role'] != 'system']

payload = {
    "messages": conversation_messages,
    "system": "\\n".join(m["content"] for m in system_messages)
}

Xử lý theo mô hình:

if self.model_id.startswith("anthropic."):
    # Định dạng Claude
elif self.model_id.startswith("meta.llama"):
    # Định dạng tiếp tục Llama
elif self.model_id.startswith("amazon.titan"):
    # Định dạng inputText Titan

Ví Dụ Dịch Phản Hồi

Thống nhất việc sử dụng token:

if self.model_id.startswith("anthropic."):
    usage = {
        "prompt_tokens": response["usage"]["input_tokens"],
        "completion_tokens": response["usage"]["output_tokens"],
        "total_tokens": response["usage"]["input_tokens"] + response["usage"]["output_tokens"]
    }

Bản đồ lỗi theo phong cách OpenAI:

except ClientError as e:
    if e.response["Error"]["Code"] == "ValidationException":
        raise ValueError("Yêu cầu hoặc mô hình không hợp lệ")

Thiết Lập Hạ Tầng

• API Gateway v2 (CORS + xác thực)
• DynamoDB (quản lý API key với TTL)
• AWS Lambda (Python 3.12, 512MB, 30s timeout)
• Amazon Bedrock (Cung cấp mô hình AI)
• IAM (quyền hạn tối thiểu cho Bedrock + DynamoDB)

Ví dụ Terraform:

resource "aws_lambda_function" "api" {
  runtime     = "python3.12"
  timeout     = 30
  memory_size = 512
}

Kết Quả & Bài Học Kinh Nghiệm

• Khởi động lạnh không phải là vấn đề lớn vì độ trễ suy diễn chi phối.
• Lambda 512MB là điểm ngọt — ít lỗi hơn, chi phí lãng phí cao hơn.
• Phát hiện tiền tố mô hình là cách sạch để xử lý các đặc điểm khác nhau của nhà cung cấp.
• Dịch lỗi rất quan trọng cho trải nghiệm người dùng: người dùng mong đợi các lỗi giống như OpenAI.

Điều quan trọng nhất là các lập trình viên có thể hướng khách hàng OpenAI của họ đến điểm cuối của chúng tôi mà không cần thay đổi mã nguồn.

Khi Nào Nên Áp Dụng Cách Tiếp Cận Này

• Bạn cần khả năng tương thích API OpenAI mà muốn sử dụng nhà cung cấp khác (AWS/GCP/tự lưu trữ).
• Bạn đang xây dựng hạ tầng AI đa đám mây và cần các API đồng nhất.
• Bạn ưu tiên sự áp dụng và khả năng tương thích của lập trình viên hơn là hiệu suất thô.

Kêu Gọi Hành Động

Nếu bạn đang xây dựng hạ tầng AI và muốn khả năng tương thích với OpenAI mà không bị ràng buộc nhà cung cấp, mô hình tầng dịch này đáng để xem xét.

👉 Khám phá tài liệu API tương thích với OpenAI của OnglX Deploy và thử triển khai API tương thích OpenAI của riêng bạn trên AWS chỉ trong vài phút.