Posted inAI

Xây dựng AI Gateway tại chỗ với LiteLLM: Hợp nhất OpenAI, Anthropic và Ollama

AI tutorial - IT technology blog
AI tutorial - IT technology blog

Tích hợp trực tiếp vs. AI Gateway: Nên chọn hướng đi nào?

Xây dựng một ứng dụng hỗ trợ AI thường bắt đầu với một API key OpenAI duy nhất. Bạn đưa nó vào biến môi trường và mọi thứ hoạt động trơn tru. Nhưng ngay khi bạn muốn thêm Claude để có khả năng lập luận tốt hơn hoặc một Llama 3 chạy cục bộ để bảo mật quyền riêng tư, mã nguồn của bạn sẽ trở thành một mớ hỗn độn với các SDK xung đột và xử lý lỗi chồng chéo.

Trong mô hình tích hợp trực tiếp, ứng dụng của bạn giao tiếp với từng nhà cung cấp riêng lẻ. Nếu OpenAI gặp lỗi rate limit vào lúc 2 giờ sáng, dịch vụ của bạn sẽ bị gián đoạn. Bạn buộc phải viết code thủ công cho các logic fallback sang Anthropic hoặc Gemini. Việc quản lý chi phí cũng trở thành một cơn ác mộng khi API key và dữ liệu sử dụng nằm rải rác trên nhiều nền tảng khác nhau.

Một AI Gateway sẽ đảo ngược kiến trúc này. Ứng dụng của bạn giao tiếp with một endpoint nội bộ duy nhất bằng định dạng chuẩn của OpenAI. Gateway nằm ở giữa, đảm nhận việc định tuyến (routing), thử lại (retries) và xác thực. Nó đóng vai trò như một bộ điều phối lưu lượng thông minh, chuyển đổi yêu cầu của bạn đến bất kỳ nhà cung cấp nào nhanh nhất hoặc rẻ nhất tại thời điểm đó.

Đánh giá thực tế về kiến trúc Proxy-First

Thêm một lớp khác vào tech stack là một quyết định lớn. Dưới đây là những ưu và nhược điểm thực tế trong môi trường production.

Ưu điểm

  • API thống nhất: Bạn chỉ cần viết code một lần bằng OpenAI SDK. Dù bạn gọi GPT-4o hay một mô hình local qua Ollama, cú pháp vẫn không thay đổi.
  • Virtual Keys: Ngừng chia sẻ key Anthropic chính. Thay vào đó, hãy tạo các “Virtual Keys” cho từng lập trình viên hoặc tính năng cụ thể với thời hạn hết hạn được thiết lập sẵn.
  • Tự động chuyển vùng lỗi (Failover): Nếu GPT-4o trả về lỗi 500, LiteLLM sẽ ngay lập tức định tuyến lại yêu cầu sang Claude 3.5 Sonnet. Người dùng của bạn thậm chí sẽ không nhận ra sự gián đoạn này.
  • Theo dõi chi tiết: Bạn có cái nhìn rõ ràng về lượng token tiêu thụ. Bạn có thể biết chính xác tính năng nào đang “đốt” ngân sách trong thời gian thực.

Nhược điểm

  • Chi phí vận hành: Gateway là một phần quan trọng của cơ sở hạ tầng. Nếu nó gặp sự cố, toàn bộ khả năng AI của bạn sẽ bị ngừng trệ. Điều này khiến việc triển khai tính sẵn sàng cao (high-availability) trở thành yêu cầu bắt buộc.
  • Độ trễ nhỏ: Định tuyến qua một proxy sẽ thêm khoảng 5–15ms độ trễ mạng. Tuy nhiên, xét việc một phản hồi LLM trung bình mất 1.000ms trở lên, độ trễ này thực tế là không thể nhận thấy đối với người dùng cuối.

Kiến trúc sẵn sàng cho Production

Để có một thiết lập ổn định, hãy chạy LiteLLM dưới dạng Docker container kết hợp với cơ sở dữ liệu PostgreSQL. Cơ sở dữ liệu đóng vai trò là “bộ não” của hệ thống, lưu trữ các virtual key, theo dõi giới hạn sử dụng và ghi log mọi yêu cầu để gỡ lỗi. Nếu không có nó, LiteLLM sẽ chạy ở chế độ stateless, phù hợp cho bản demo nhanh nhưng rủi ro cho một doanh nghiệp đang mở rộng.

Tôi đã thấy thiết lập này giúp các đội ngũ tiết kiệm được một khoản tiền đáng kể. Trong một dự án, chúng tôi đã cắt giảm 30% chi phí API hàng tháng bằng cách định tuyến các tác vụ phân loại đơn giản đến instance Llama 3 cục bộ, trong khi chỉ dành các mô hình đắt đỏ như GPT-4o cho các tác vụ lập luận phức tạp.

Hướng dẫn triển khai từng bước

Hãy cùng xây dựng một LiteLLM Proxy quản lý đồng thời OpenAI, Anthropic và một instance Ollama cục bộ.

1. Cấu hình định tuyến mô hình

Mọi thứ trong LiteLLM đều xoay quanh tệp config.yaml. Đây là nơi bạn ánh xạ tên mô hình nội bộ với các nhà cung cấp thực tế. Tạo một tệp có tên litellm_config.yaml:

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: "os.environ/OPENAI_API_KEY"

  - model_name: claude-3-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20240620
      api_key: "os.environ/ANTHROPIC_API_KEY"

  - model_name: local-llama
    litellm_params:
      model: ollama/llama3
      api_base: "http://host.docker.internal:11434"

router_settings:
  routing_strategy: simple-shuffle
  set_verbose: True

2. Khởi chạy với Docker Compose

Docker Compose đảm bảo gateway và cơ sở dữ liệu của bạn luôn đồng bộ. Tạo tệp docker-compose.yml để quản lý các dịch vụ:

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    environment:
      - OPENAI_API_KEY=sk-your-key
      - ANTHROPIC_API_KEY=sk-ant-key
      - DATABASE_URL=postgresql://user:pass@db:5432/litellm
    command: ["--config", "/app/config.yaml"]
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=litellm
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Chạy lệnh docker-compose up -d. Gateway của bạn hiện đang lắng nghe các yêu cầu tại http://localhost:4000.

3. Thiết lập Fallback thông minh

Bạn có thể nhóm nhiều nhà cung cấp dưới một bí danh (alias) duy nhất để đảm bảo tính sẵn sàng cao. Nếu một nhà cung cấp gặp lỗi, gateway sẽ tự động thử nhà cung cấp tiếp theo trong danh sách.

model_list:
  - model_name: high-reliability-model
    litellm_params:
      model: openai/gpt-4o
  - model_name: high-reliability-model
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20240620

router_settings:
  routing_strategy: latency-based-routing
  enable_fallbacks: True

Giờ đây, ứng dụng của bạn chỉ cần yêu cầu high-reliability-model. LiteLLM sẽ đảm nhận phần việc nặng nhọc là chọn nhà cung cấp có phản hồi tốt nhất.

4. Kết nối ứng dụng của bạn

Việc kiểm tra gateway rất đơn giản. Bạn có thể sử dụng lệnh cURL tiêu chuẩn để xác minh việc định tuyến có hoạt động chính xác hay không:

curl --request POST \
  --url http://localhost:4000/chat/completions \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Tại sao nên sử dụng gateway?"}]
  }'

Trong Python, bạn chỉ cần cập nhật base_url. Phần còn lại của mã nguồn tương thích với OpenAI vẫn giữ nguyên:

from openai import OpenAI

client = OpenAI(
    api_key="sk-anything", # Gateway sẽ xác thực key này
    base_url="http://localhost:4000"
)

response = client.chat.completions.create(
    model="claude-3-sonnet",
    messages=[{"role": "user", "content": "Giải thích về proxy pattern."}]
)

print(response.choices[0].message.content)

Thắt chặt ngân sách và giám sát

Khi lưu lượng truy cập đi qua gateway, bạn có thể truy cập giao diện người dùng tích hợp (thường ở đường dẫn /ui) để quản lý chi tiêu. Tôi khuyên bạn nên tạo các virtual key riêng biệt cho các môi trường Phát triển (Development), Thử nghiệm (Staging) và Triển khai (Production).

Quản lý ngân sách là nơi gateway thực sự tỏa sáng. Bạn có thể đặt max_budget là 50 USD cho một key Development. Nếu một lập trình viên vô tình kích hoạt vòng lặp vô tận gây spam API, gateway sẽ hoạt động như một bộ ngắt mạch (circuit breaker). Nó sẽ chặn tất cả các yêu cầu tiếp theo khi đạt đến hạn mức, ngăn chặn hóa đơn 1.000 USD bất ngờ trong kỳ sao kê thẻ tín dụng tiếp theo.

Chiến lược tập trung này giúp bạn không còn phải kiểm tra ba bảng điều khiển thanh toán khác nhau mỗi sáng. Thay vào đó, bạn có một trung tâm điều khiển duy nhất cho toàn bộ hạ tầng AI của mình. Điều này giúp việc mở rộng quy mô vận hành bớt căng thẳng hơn khi bạn biết chính xác từng đồng đang được chi tiêu vào đâu.

Share:
Tags: