Multi-Model ArchitectureLLM RoutingAPI Fallback

Cách dùng nhiều model AI trong một app: kiến trúc và code

Q: Mẫu đa model đơn giản nhất để bắt đầu?

Model chính + một fallback. Thêm vào code hôm nay: try: primary_model(); except: fallback_model(). Mười dòng. Ngăn nguyên nhân phổ biến nhất của downtime liên quan LLM. Nâng cấp lên định tuyến đầy đủ khi hóa đơn API hàng tháng chạm ba chữ số.

Q: Xử lý cửa sổ ngữ cảnh khác nhau của model thế nào?

Đặt max_tokens mỗi model trong cấu hình client. Khi fallback đến model có cửa sổ ngữ cảnh nhỏ hơn, cắt lịch sử hội thoại cho vừa. Log sự kiện cắt —chúng cho bạn biết khi nào cần nâng giới hạn ngữ cảnh model fallback.

27 thg 7, 20261 phút đọc

Chạy nhiều model AI trong một ứng dụng không phải xa xỉ —mà là điều kiện cơ bản năm 2026. Không model AI đơn lẻ nào dẫn đầu mọi khía cạnh. Claude Opus cho gỡ lỗi phức tạp. GPT-5.5 cho độ tin cậy agent. Gemini cho đa phương thức. DeepSeek cho chi phí. App một model đang bỏ phí khả năng —hoặc trả quá nhiều cho tác vụ mà model rẻ hơn xử lý giống hệt.

Nhưng việc nối nhiều model —với chuỗi fallback, logic định tuyến và giám sát thống nhất— là phần không ai dạy. Hướng dẫn chỉ cho bạn cách gọi một API. Sản xuất cần bốn. Bài viết này cho bạn thấy kiến trúc biến “tôi có thể gọi GPT-5.5” thành “app của tôi tự động dùng model tốt nhất cho mỗi request và rẻ hơn 70% so với toàn hàng đầu”.

Vì sao kiến trúc một model là gánh nặng

Sự cố nhà cung cấp xảy ra. OpenAI có ba sự cố lớn trong nửa đầu 2026. Người dùng API trực tiếp thấy lỗi. App đa model có fallback thấy request âm thầm định tuyến đến Claude hoặc DeepSeek. Người dùng không nhận ra. SLA của bạn sống sót qua sự cố nhà cung cấp chỉ khi bạn có nơi khác để gửi request. Ngoài sự cố, giới hạn tốc độ —đặc biệt lỗi 429 trong sản xuất— là rủi ro một nhà cung cấp khác mà định tuyến đa model loại bỏ bằng cách phân phối tải giữa các nhà cung cấp.

Ngừng hỗ trợ model theo quý. OpenAI ngừng hỗ trợ ba model trong năm qua. Anthropic một. Di chuyển mất vài tuần điều chỉnh prompt và xác thực đầu ra —trừ khi bạn đã có model fallback được tích hợp và thử nghiệm. Kiến trúc đa model nghĩa là ngừng hỗ trợ là thay đổi định tuyến, không phải dự án di chuyển.

Không mức giá đơn lẻ nào tối ưu cho mọi tác vụ. Phân loại và trích xuất không cần GPT-5.5 ở $30/M đầu ra. DeepSeek V4 Flash làm chúng tốt tương đương ở $0.28/M.

Khác biệt trên 100,000 request phân loại mỗi ngày: $900/ngày so với $8.40/ngày. Một bộ định tuyến đa model tự động bắt khoảng chênh này. App một model trả phụ phí trên mỗi request.

Sự cố thực không đáng xảy ra. Một đội thương mại điện tử tôi hợp tác Q1/2026 chạy phát hiện gian lận bằng AI trên một model không fallback. Chiều thứ Ba, bộ cân bằng tải nội bộ của nhà cung cấp hỏng và trả lỗi 503 trong 47 phút. Mọi giao dịch trong khoảng đó bị gắn cờ để xem xét thủ công: 312 đơn hàng, $47,000 doanh thu kẹt lơ lửng.

Ticket hỗ trợ tăng gấp ba. Đội kỹ thuật dành 47 phút đó triển khai hotfix khẩn cấp để đổi nhà cung cấp —một thay đổi chỉ là công tắc cấu hình nếu họ thiết kế đa model từ đầu. Họ phát hành chuỗi fallback trong sprint sau: 30 dòng Python và một buổi sáng thử nghiệm.

Tổng chi phí sự cố: khoảng $12,000 cho bồi hoàn, công xem xét thủ công và mất mua lại từ khách bỏ giỏ hàng.

Mẫu client thống nhất

Nền tảng của kiến trúc đa model là một giao diện duy nhất hoạt động với mọi nhà cung cấp. Code ứng dụng của bạn gọi client.chat(). Client xử lý định tuyến, dịch và fallback.

Python —lớp UnifiedClient:

from openai import OpenAI
import logging

class UnifiedLLMClient:
    def __init__(self, base_url: str, api_key: str):
        self.client = OpenAI(base_url=base_url, api_key=api_key)

    def chat(self, model: str, messages: list, **kwargs):
        """One method. Any model. Same parameters."""
        return self.client.chat.completions.create(
            model=model,
            messages=messages,
            **kwargs
        )

Tham số model là thứ duy nhất thay đổi giữa các nhà cung cấp. Mọi thứ khác —định dạng tin nhắn, streaming, temperature, max_tokens— giữ nguyên. Đây là lý do tiêu chuẩn tương thích OpenAI quan trọng: nó biến kiến trúc đa model thành vấn đề cấu hình, không phải tích hợp. Các công cụ như bộ định tuyến LiteLLM triển khai cả năm chiến lược trong bài viết này như tùy chọn cấu hình.

Nền tảng tổng hợp đưa điều này xa hơn: base_url trỏ đến một endpoint đã định tuyến tới mọi nhà cung cấp. Client thống nhất của bạn trở thành một lời gọi API với tham số model có thể là "gpt-5.5", "claude-opus-4-8", "gemini-3.1-pro" hoặc "deepseek-v4-pro" —không cần code riêng nhà cung cấp.

Chuỗi fallback: không bao giờ làm rơi request

Mẫu đa model đơn giản nhất —và cái ngăn chặn hầu hết sự cố.

import logging
from openai import OpenAI

client = OpenAI(
    base_url="https://api.tokspan.com/v1",
    api_key="ts-your-key-here"
)

FALLBACK_CHAIN = [
    "claude-opus-4-8",      # Primary
    "gpt-5.5",               # First fallback
    "deepseek-v4-pro"        # Last resort
]

def chat_with_fallback(messages, model_chain=FALLBACK_CHAIN, timeout=30):
    """Try models in order. First success wins. All fail = raise."""
    last_error = None

    for model in model_chain:
        try:
            response = client.chat.completions.create(
                model=model,
                messages=messages,
                timeout=timeout
            )
            return response.choices[0].message.content
        except Exception as e:
            last_error = e
            logging.warning(f"Model {model} failed: {type(e).__name__}. Trying next in chain.")
            continue

    raise RuntimeError(f"All {len(model_chain)} models failed. Last error: {last_error}")

Cân nhắc sản xuất. Ngắt mạch nhà cung cấp thất bại liên tục. Một nhà cung cấp trả 5xx trong 30 giây nên bị bỏ qua trong 60 giây tiếp theo —không retry mỗi request. Theo dõi cooldown mỗi nhà cung cấp bằng cờ theo thời gian đơn giản. Thăm dò nhà cung cấp bằng một request sau khi cooldown hết. Nếu thành công, gỡ cooldown. Nếu thất bại, đặt lại bộ đếm.

Điều này thực sự tiết kiệm gì. OpenAI trải qua ba sự cố lớn trong nửa đầu 2026. App một model trên GPT-5.5 sập 47 phút, 23 phút và 12 phút tương ứng —hơn 80 phút lỗi người dùng gặp phải. Đội chạy chuỗi fallback ba model trên thấy không downtime trong cả ba sự cố. Request của họ âm thầm định tuyến đến Claude và DeepSeek trong khi OpenAI phục hồi. Chi phí triển khai: chuỗi try/except mười dòng. Chi phí không triển khai: 80 phút downtime đáng giá bao nhiêu cho doanh nghiệp bạn.

5 chiến lược định tuyến: từ chi phí đến chất lượng

Chuỗi fallback xử lý thất bại. Chiến lược định tuyến xử lý 99.9% request còn lại —khi mọi thứ hoạt động và bạn muốn model tốt nhất cho mỗi tác vụ.

Chiến lược 1: Định tuyến theo chi phí. Gửi mỗi request đến model rẻ nhất có thể xử lý nó đầy đủ.

def cost_based_route(user_message: str) -> str:
    """Classify task complexity, route to cheapest capable model."""
    complexity = classify_complexity(user_message)  # Use a cheap model to classify
    if complexity == "simple":
        return "deepseek-v4-flash"     # $0.14/$0.28
    elif complexity == "medium":
        return "deepseek-v4-pro"       # $0.44/$0.87
    else:
        return "claude-sonnet-4-6"     # $3/$15

Tiết kiệm: 70–95% so với toàn hàng đầu. Bộ phân loại tốn ~$0.000004 mỗi request. Khoản tiết kiệm tính bằng đô la. Cho đào sâu hơn về chiến lược giảm chi phí ngoài định tuyến, xem hướng dẫn chiến lược giảm chi phí của chúng tôi.

Chiến lược 2: Định tuyến theo độ trễ. Định tuyến đến model nhanh nhất đáp ứng ngưỡng chất lượng tối thiểu. Đặt ngân sách độ trễ mỗi endpoint —ví dụ p95 500ms. Nếu model chính vượt nó, lưu lượng chuyển sang phương án nhanh hơn. Trong sản xuất, DeepSeek V4 Flash trung bình 180ms cho phản hồi ngắn so với 420ms của Claude Opus —khoảng cách 240ms người dùng nhận thấy trong giao diện chat. Đánh đổi: định tuyến theo độ trễ có thể âm thầm làm giảm chất lượng phản hồi nếu model nhanh của bạn thấp điểm hơn trên benchmark đánh giá nội bộ. Kết hợp với cổng chất lượng lấy mẫu 5% request được định tuyến và so sánh đầu ra với đường cơ sở.

Chiến lược 3: Định tuyến theo chất lượng. Phân loại độ phức tạp tác vụ (đơn giản/trung bình/phức tạp). Định tuyến đến tầng năng lực phù hợp. Đơn giản —DeepSeek Flash. Trung bình —Claude Sonnet. Phức tạp —Claude Opus.

Chiến lược 4: Round-robin với phân phối có trọng số. Phân phối tải giữa các nhà cung cấp để giữ dưới giới hạn tốc độ riêng. Ngoài quản lý giới hạn, phân phối có trọng số mở khóa pha trộn chi phí: trộn model hàng đầu và bình dân theo tỷ lệ cố định (60% GPT-5.5 / 40% DeepSeek V4 Pro) để đạt chi phí pha trộn dự đoán được mỗi request. Ở 100,000 request/ngày với phân chia 60/40, bạn trung bình $4.80/M token đầu ra thay vì $15/M với toàn hàng đầu —giảm 68% không đổi một dòng logic ứng dụng. Định tuyến có trọng số cũng làm phẳng các đỉnh độ trễ khu vực: nếu cụm us-east-1 của Nhà cung cấp B suy giảm, phân phối lại trọng số của nó cho Nhà cung cấp A và C cho đến khi xác nhận phục hồi.

Chiến lược 5: Thứ tự ưu tiên với fallback. Ưu tiên cố định: “luôn Claude Opus, fallback GPT-5.5, fallback DeepSeek”. Đơn giản nhất triển khai. Đủ tốt cho hầu hết đội.

So sánh chiến lược:

Chiến lược	Tốt nhất cho	Độ phức tạp	Tác động đến chi phí	Lợi ích độ tin cậy
Dựa trên chi phí	App khối lượng lớn, nhạy cảm chi phí	Trung bình	Tiết kiệm 70–95%	Thấp
Dựa trên độ trễ	Chat thời gian thực, giọng nói	Trung bình	Trung lập	Thấp
Dựa trên chất lượng	Khối lượng công việc hỗn hợp	Trung bình	Tiết kiệm 50–90%	Trung bình
Round-robin	Quản lý giới hạn tốc độ	Thấp	Trung lập	Cao
Thứ tự ưu tiên	Fallback đơn giản	Rất thấp	Trung lập	Cao

Với hầu hết đội, bắt đầu với Thứ tự ưu tiên (10 dòng, ngăn sự cố). Thêm định tuyến theo chi phí khi hóa đơn API vượt $500/tháng. Các chiến lược khác là tối ưu bạn thêm khi cần. Cho triển khai định tuyến đầy đủ với chuyển đổi dự phòng, caching và quy thuộc chi phí, xem tài liệu custom routing của chúng tôi.

Quan sát thống nhất

Nhiều model + nhiều nhà cung cấp = quan sát không phải tùy chọn.

Schema logging thống nhất: mỗi lời gọi API được log với cùng trường bất kể nhà cung cấp —quy ước ngữ nghĩa GenAI của OpenTelemetry cung cấp schema tiêu chuẩn được hầu hết nền tảng quan sát áp dụng.

import time, json

def log_request(model: str, messages: list, response, latency_ms: float):
    log_entry = {
        "timestamp": time.time(),
        "model": model,
        "provider": get_provider_for_model(model),
        "prompt_tokens": response.usage.prompt_tokens,
        "completion_tokens": response.usage.completion_tokens,
        "cost": calculate_cost(model, response.usage),
        "latency_ms": latency_ms,
        "status": "success"
    }
    # Write to your logging system —CloudWatch, Datadog, custom
    logging.info(json.dumps(log_entry))

Ba dashboard bạn thực sự cần. (1) Chi phí mỗi model mỗi ngày —bắt “bất ngờ $500” trước khi nó xảy ra. (2) Độ trễ p50/p95 mỗi nhà cung cấp —phát hiện suy giảm trước khi người dùng phàn nàn. (3) Tỷ lệ lỗi mỗi nhà cung cấp —tự động kích hoạt ngắt mạch và fallback.

Nền tảng tổng hợp cung cấp các dashboard này sẵn có. Nếu bạn tự xây hệ thống đa model, dự trù 2–3 ngày thiết lập quan sát —đó là khác biệt giữa “có gì đó sai” và “độ trễ p95 Claude Opus tăng 300ms trong giờ qua, đang định tuyến 30% lưu lượng sang GPT-5.5”.

Khi nào KHÔNG dùng nhiều model AI

Kiến trúc nhiều model AI có mức sàn chi phí. Với app dưới 1,000 request/ngày, độ phức tạp thêm hiếm khi xứng đáng.

Một model là lựa chọn đúng khi: (1) Hóa đơn API hàng tháng của bạn dưới $100 —khoản tiết kiệm định tuyến không bù nổi chi phí tích hợp quản lý chuỗi fallback và quan sát giữa các nhà cung cấp. (2) Bạn dùng một nhà cung cấp độc quyền và đã đàm phán giảm giá doanh nghiệp theo khối lượng khiến việc đổi không kinh tế —khóa $8/M token đầu ra trên GPT-5.5 tốt hơn chia khối lượng cho ba nhà cung cấp theo giá tiêu chuẩn. (3) Ứng dụng của bạn thực hiện một loại tác vụ hẹp duy nhất (ví dụ chỉ Q&A dựa trên RAG từ cơ sở tri thức cố định) nơi một lớp model luôn thể hiện tốt nhất và khác biệt chi phí giữa các nhà cung cấp không đáng kể. (4) Đội của bạn nhỏ —dưới ba kỹ sư— và băng thông nên dành cho tính năng sản phẩm hơn lớp trừu tượng hạ tầng.

Ngưỡng nơi đa model trở thành thắng lợi ròng: khoảng 10,000 request/tháng. Dưới đó, dành thời gian kỹ thuật cho tính năng, không phải hạ tầng. Trên đó, kiến trúc trong bài viết này tự trả phí trong tháng đầu chỉ nhờ tiết kiệm chi phí.

Cho đội vượt ngưỡng đó, bắt đầu với mẫu fallback Thứ tự ưu tiên —10 dòng code và ngăn chế độ lỗi lớn nhất mà không cần lớp định tuyến đầy đủ.

Câu hỏi thường gặp

Nên dùng bao nhiêu model trong sản xuất?

Bắt đầu với 3: một ngựa thồ rẻ (DeepSeek V4 Flash), một tầng trung (Claude Sonnet hoặc GPT-5.4 Mini), một hàng đầu (Claude Opus hoặc GPT-5.5). Thêm model chuyên biệt khi nhu cầu tăng. Hơn 5 model thường là tối ưu quá mức —độ phức tạp định tuyến vượt khoản tiết kiệm chi phí biên.

Định tuyến đa model có thêm độ trễ đáng kể không?

Bản thân logic định tuyến: dưới 10ms. Định tuyến theo chi phí và chất lượng thêm bước phân loại (~200ms dùng model rẻ). Chi phí phân loại ~$0.000004 mỗi request. Đáng khi nó tiết kiệm $0.01–0.05 mỗi request bằng cách gửi tác vụ đơn giản đến model rẻ hơn.

Mẫu đa model đơn giản nhất để bắt đầu?

Model chính + một fallback. Thêm vào code hôm nay: try: primary_model(); except: fallback_model(). Mười dòng. Ngăn nguyên nhân phổ biến nhất của downtime liên quan LLM. Nâng cấp lên định tuyến đầy đủ khi hóa đơn API hàng tháng chạm ba chữ số.

Xử lý cửa sổ ngữ cảnh khác nhau của model thế nào?

Đặt max_tokens mỗi model trong cấu hình client. Khi fallback đến model có cửa sổ ngữ cảnh nhỏ hơn, cắt lịch sử hội thoại cho vừa. Log sự kiện cắt —chúng cho bạn biết khi nào cần nâng giới hạn ngữ cảnh model fallback.

Tôi có thể làm điều này không cần nền tảng tổng hợp không?

Có. Bạn sẽ quản lý 3–5 SDK nhà cung cấp, 3–5 hệ thống thanh toán, 3–5 dashboard giới hạn tốc độ và tự xây lớp định tuyến, fallback và quan sát. Dự trù 1–2 tuần thiết lập ban đầu và 4–8 giờ/tháng bảo trì. Nền tảng tổng hợp gom tất cả vào một endpoint với định tuyến, fallback và giám sát tích hợp. Câu hỏi là thời gian đội của bạn đáng dùng để xây hạ tầng hay xây tính năng.

Kiến trúc đa model không phải phức tạp vì lợi ích của nó. Đó là sự thừa nhận rằng không nhà cung cấp nào tối ưu chi phí, chất lượng, độ trễ và năng lực đồng thời. Kiến trúc trong bài viết này thêm khoảng 50 dòng Python vào app một model —và đổi lại, loại bỏ sự cố nhà cung cấp khỏi chế độ lỗi và cắt hóa đơn API của bạn 70%.

Đến lượt bạn: mở tích hợp API hiện có. Thêm model fallback —một dòng trong try/except bắt lỗi từ model chính và định tuyến đến dự phòng. Đó là 10 dòng code. Mất 15 phút. Ngăn nguyên nhân phổ biến nhất của downtime liên quan LLM. Khi fallback vào chỗ, thêm bộ phân loại theo chi phí từ Chiến lược 1 và nhìn hóa đơn giảm. Bạn không cần xây lại app —cần thêm hai điểm quyết định.

Chuỗi fallback đầu bài viết là mười dòng Python. Bộ định tuyến theo chi phí thêm bốn mươi. Nếu bạn muốn dành giờ đó cho tính năng sản phẩm, nền tảng tổng hợp giao cả hai như hạ tầng —endpoint mà client OpenAI của bạn đã trỏ có thể định tuyến giữa các nhà cung cấp, xử lý chuyển đổi dự phòng và log chi phí mỗi model. Dù bạn tự xây lớp định tuyến hay dùng cái có sẵn, quyết định kiến trúc giống nhau: một model là gánh nặng. Hai là bảo hiểm. Ba là tiêu chuẩn sản xuất.