Chiến lược Multi-LLM: Khớp Mô hình với Tác vụ

Câu hỏi phổ biến nhất khi xây dựng AI product: "Nên dùng model nào?". Câu trả lời không đơn giản — mỗi model có điểm mạnh riêng, và việc dùng một model cho mọi tác vụ vừa tốn kém vừa không tối ưu. Bài viết này chia sẻ cách chúng tôi xây dựng chiến lược multi-LLM trong Assistant Core.

Tại sao không dùng một model duy nhất?

Câu trả lời ngắn: cost và quality không thể tối ưu cùng lúc với một model.

• GPT-4o mạnh nhưng đắt — $15/1M input tokens không hợp lý cho FAQ đơn giản
• Gemini 1.5 Flash rẻ và nhanh nhưng yếu hơn với code phức tạp
• Claude 3.5 Sonnet xuất sắc cho analysis dài nhưng context window = chi phí
• Dữ liệu nhạy cảm cần model nội bộ (on-premise), không gửi ra ngoài

Phân tích điểm mạnh từng model

Routing logic trong Assistant Core

Mỗi assistant có thể cấu hình model stack riêng. Bên cạnh đó, chúng tôi có routing logic tự động dựa trên loại tác vụ được detect:

def select_model(
    task_type: str,
    content_length: int,
    has_image: bool,
    is_voice: bool,
    assistant_default: str
) -> str:
    # Voice request → realtime model
    if is_voice:
        return assistant.voice_model or "openai-realtime"

    # Image analysis → multimodal model
    if has_image:
        return "gpt-4o"

    # Code generation → Claude
    if task_type == "code":
        return "claude-3-5-sonnet-20241022"

    # Long document → model với large context
    if content_length > 50_000:
        return "claude-3-5-sonnet-20241022"  # 200K context

    # Default: fast + cheap
    return assistant_default or "gemini-1.5-flash"

Model per assistant — multi-tenancy

Mỗi assistant trong platform có thể chọn model stack riêng. Điều này rất quan trọng vì:

• Khách hàng enterprise cần Claude hoặc GPT-4o cho độ chính xác cao
• Internal FAQ bot chỉ cần Gemini Flash để tiết kiệm chi phí
• Tổ chức tài chính cần model on-premise (không gửi dữ liệu ra cloud)
• Voice assistant cần model realtime khác với text assistant

Cost optimization trong thực tế

Sau khi áp dụng routing logic, phân bổ request thực tế của một khách hàng điển hình:

• 68% requests → Gemini 1.5 Flash (simple Q&A, FAQ)
• 22% requests → Claude 3.5 Sonnet (code, phân tích tài liệu)
• 8% requests → GPT-4o (image, complex reasoning)
• 2% requests → GPT-4o Realtime / Soniox (voice)

Kết quả: giảm 62% chi phí API so với dùng GPT-4o cho mọi request, trong khi quality score (đo bằng user feedback) chỉ giảm 3%.

Switching model không cần restart

Trong Assistant Core, model configuration được lưu trong database và hot-reload — admin có thể đổi model từ GPT-4o sang Claude ngay trên dashboard mà không cần deploy lại. LLMManager trong backend tạo LangChain chain dynamically dựa trên config hiện tại của assistant.

# LLMManager: dynamic model selection
class LLMManager:
    def get_llm(self, provider: str, model: str):
        match provider:
            case "openai":
                return ChatOpenAI(model=model)
            case "anthropic":
                return ChatAnthropic(model=model)
            case "google":
                return ChatGoogleGenerativeAI(model=model)
            case "xai":
                return ChatOpenAI(
                    model=model,
                    base_url="https://api.x.ai/v1"
                )
            case "deepseek":
                return ChatOpenAI(
                    model=model,
                    base_url="https://api.deepseek.com"
                )

Lời khuyên cho team mới bắt đầu

Nếu đang build AI product và chưa biết dùng model nào, đây là heuristic đơn giản:

1. Bắt đầu với Gemini 1.5 Flash cho tất cả — rẻ, nhanh, đủ tốt cho prototype
2. Upgrade lên Claude 3.5 Sonnet khi cần code generation hoặc document analysis
3. Thêm GPT-4o chỉ khi có tác vụ multimodal hoặc complex reasoning thực sự cần thiết
4. Đo cost/quality tradeoff sau mỗi tháng và điều chỉnh routing