Chiến lược failover cho LLM API khi nhà cung cấp gặp sự cố

Failover API LLM là thực tiễn định tuyến các yêu cầu AI tạo sinh sang nhà cung cấp thay thế khi nguồn chính trả lỗi, hết thời gian chờ hoặc ngừng sinh token giữa luồng. Chiến lược cấp production không đơn thuần là “thử lại cho đến khi được”; nó phân biệt lỗi nào có thể thử lại an toàn và lỗi nào nên thất bại nhanh, đồng thời xử lý khác nhau giữa lỗi ở đầu luồng và lỗi xảy ra sau khi đã gửi một phần đầu ra cho người dùng.

Tại sao failover khó hơn vẻ ngoài

Hầu hết các API gateway được xây dựng xung quanh ngữ nghĩa yêu cầu/phản hồi HTTP. Mã 5xx thường có nghĩa là “thử lại ở nơi khác.” Nhưng khối lượng công việc LLM thêm hai phức tạp phá vỡ giả định đó.

Thứ nhất, nhiều yêu cầu được stream. Mã trạng thái HTTP có thể là 200, nhưng nhà cung cấp vẫn có thể phát ra một chunk lỗi sau khi trợ lý đã bắt đầu nói. Một khi token đã đến client, việc thử lại một cách ngây thơ sẽ lặp lại câu trả lời dở, làm người dùng bối rối và tính phí gấp đôi cho các token đã tiêu thụ.

Thứ hai, cùng một triệu chứng có thể có nguyên nhân trái ngược. 429 Too Many Requests thường hết trong vài giây, trong khi 401 Unauthorized hoặc 403 Forbidden sẽ tồn tại cho đến khi xoay vòng thông tin xác thực. Thử lại trường hợp sau lãng phí cả ngân sách chi phí lẫn ngân sách độ trễ.

Đó là lý do tại sao OWASP Top 10 for LLM Applications 2025 xem excessive agency và retry không kiểm soát là rủi ro kiến trúc: một vòng lặp tự động có thể khuếch đại chi phí, làm rò rỉ dữ liệu sang nhà cung cấp dự phòng hoặc vi phạm quy định lưu trữ dữ liệu.

Phân loại lỗi trước khi thử lại

Cách đáng tin cậy nhất để giữ failover an toàn là phân loại lỗi trước. Hãy dùng mã trạng thái HTTP của nhà cung cấp, vị trí trong luồng và cấu trúc thân lỗi.

Lỗi đầu luồng

Những lỗi này xảy ra trước khi bất kỳ token có ý nghĩa nào được sinh ra. Gateway chưa cam kết đầu ra với bên gọi, nên thử lại hoặc chuyển nhà cung cấp thường là an toàn.

Ví dụ phổ biến:

• 408 Request Timeout trước token đầu tiên
• 429 Too Many Requests từ giới hạn tốc độ
• 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout
• Lỗi bắt tay TLS hoặc reset kết nối trước khi header hoàn tất

Với những lỗi này, hãy thử lại với exponential backoff, sau đó failover sang mô hình được cấu hình tiếp theo. Giữ tổng độ trễ trong ngưỡng chịu đựng của ứng dụng; một vòng lặp thử lại 30 giây sẽ phá hỏng mục đích của giao diện trò chuyện phản hồi nhanh.

Lỗi giữa luồng

Những lỗi này xảy ra sau khi ít nhất một chunk nội dung đã được gửi. Người dùng có thể đã thấy một phần câu trả lời, nên gateway không thể trong suốt thử lại cùng một yêu cầu mà không rủi ro tạo ra đầu ra trùng lặp hoặc mâu thuẫn.

Cách xử lý đề xuất:

1. Dừng luồng sạch sẽ với client.
2. Ghi lại lỗi trong nhật ký sử dụng kèm số token đã tiêu thụ một phần.
3. Hiển thị lỗi cho bên gọi hoặc UI thay vì âm thầm chuyển mô hình.
4. Cho phép người dùng tái tạo một cách rõ ràng; UI sau đó có thể định tuyến yêu cầu tiếp theo sang nhà cung cấp dự phòng.

Một số nhóm triển khai “tiếp tục từ điểm cắt” bằng cách gửi lại phần tin nhắn của trợ lý như ngữ cảnh và yêu cầu nhà cung cấp dự phòng hoàn thành nó. Điều này chỉ hiệu quả nếu hai mô hình chia sẻ cùng hành vi tokenizer và ứng dụng chấp nhận thay đổi về giọng điệu hoặc định dạng. Đây không phải hành vi an toàn mặc định.

Các mã trạng thái thường không nên thử lại

Mã	Ý nghĩa điển hình	Thử lại?
400 Bad Request	Payload sai định dạng, tham số không hợp lệ hoặc kích hoạt bộ lọc an toàn	Không — sửa yêu cầu
401 Unauthorized	Khóa API không hợp lệ hoặc hết hạn	Không — xoay vòng thông tin xác thực trước
403 Forbidden	Tài khoản bị đình chỉ, chặn khu vực hoặc vi phạm chính sách	Không — điều tra tài khoản
404 Not Found	Mô hình hoặc endpoint không tồn tại	Không — cập nhật ánh xạ mô hình
422 Unprocessable Entity	Lỗi ngữ nghĩa trong thân yêu cầu	Không — sửa payload
429 Too Many Requests	Giới hạn tốc độ hoặc hết hạn ngạch	Có, backoff, sau đó failover
5xx	Lỗi phía nhà cung cấp	Có, thử lại giới hạn, sau đó failover

Bảng này là điểm khởi đầu, không phải đảm bảo. Các nhà cung cấp đôi khi tái sử dụng mã trạng thái cho các chế độ lỗi khác nhau, nên hãy phân tích thân lỗi khi có sẵn.

Cách đọc lỗi thân tạm thời

Mã trạng thái là chưa đủ. Một luồng kiểu OpenAI có thể phát ra chunk error với trường code như rate_limit_exceeded, server_error hoặc content_filter. Anthropic và Gemini trả về các đối tượng lỗi có cấu trúc với chuỗi lý do. Những mã này nên điều khiển chính sách thử lại nhiều hơn là chỉ dựa vào mã HTTP.

Ví dụ:

• rate_limit_exceeded → thử lại với backoff, sau đó failover.
• server_error → failover nhanh; nhà cung cấp đã thừa nhận có sự cố phía họ.
• content_filter hoặc content_policy_violation → không thử lại với nhà cung cấp khác trừ khi chính sách quản trị của bạn cho phép rõ ràng, vì cùng một prompt có thể kích hoạt cùng một bộ lọc ở nơi khác và tạo rủi ro tuân thủ.
• insufficient_quota hoặc billing_hard_limit_reached → failover ngay lập tức; tài khoản không thể phục vụ yêu cầu này.

Khi lỗi thân xuất hiện giữa luồng, hãy xử lý như lỗi giữa luồng ngay cả khi mã trạng thái là 200. Chính sách an toàn nhất là dừng luồng, ghi log sự kiện và để người dùng quyết định có tái tạo hay không.

Ngân sách thử lại và luân chuyển nhà cung cấp

Chính sách thử lại cần có giới hạn. Không có giới hạn, một sự cố lan rộng ở một nhà cung cấp có thể làm cạn kiệt giới hạn tốc độ của nhà cung cấp tiếp theo. Xác định những điều sau theo từng yêu cầu hoặc phiên:

• Số lần thử tối đa trên mỗi nhà cung cấp: thường là 1–2 lần thử lại trước khi chuyển tiếp.
• Số nhà cung cấp tối đa được thử: thường là 2–3, bao gồm cả nhà cung cấp chính.
• Giới hạn backoff: giới hạn exponential backoff để failover xảy ra trước khi người dùng bỏ cuộc. Giới hạn phổ biến cho giao diện trò chuyện là 2–4 giây.
• Tổng thời gian chờ: bao gồm thời gian kết nối, thời gian đến token đầu tiên và độ trễ giữa các token.

Luân chuyển nhà cung cấp cũng có nghĩa là luân chuyển cấu trúc chi phí. Fallback từ GPT-4o sang Claude 3.5 Sonnet hoặc Gemini 1.5 Pro có thể thay đổi cả giá và chất lượng. Các nhóm sử dụng khả năng hiển thị giá mô hình như một phần quản trị có thể đặt rào chi phí để failover không âm thầm làm tăng gấp ba hóa đơn suy luận.

Ghi log và khả năng quan sát

Mỗi sự kiện failover nên để lại một dấu vết kiểm toán. Tối thiểu hãy ghi lại:

• Nhà cung cấp ban đầu và nhà cung cấp dự phòng
• Mã trạng thái và mã lỗi từ thân phản hồi
• Lỗi xảy ra ở đầu luồng hay giữa luồng
• Số token đã tiêu thụ, nếu có
• Độ trễ mỗi lần thử và tổng độ trễ
• Thuộc tính người dùng hoặc dự án

Dữ liệu này nằm trong nhật ký sử dụng và là đầu vào cho cảnh báo dashboard. Nếu một nhà cung cấp bắt đầu trả về tỷ lệ 5xx cao hơn, nhóm vận hành nên nhận thấy trước khi người dùng mở ticket.

Ghi log cũng bảo vệ chống lại tranh chấp thanh toán. Khi nhà cung cấp tính phí cho các token đã phát ra trước khi lỗi giữa luồng xảy ra, bạn cần bản ghi chính xác về thời điểm luồng bị gián đoạn và bao nhiêu token liên quan.

Khi không nên failover

Có những lý do chính đáng để để yêu cầu thất bại thay vì định tuyến nó đi nơi khác.

Lưu trữ dữ liệu và tuân thủ. Nếu prompt chứa dữ liệu cá nhân hoặc chịu sự điều chỉnh của một khu vực pháp lý cụ thể, failover sang nhà cung cấp ở khu vực khác có thể vi phạm chính sách. Hãy định tuyến các prompt này qua danh sách kênh bị hạn chế.

Kiểm soát chi phí. Một prompt phức tạp cao gửi đến mô hình cao cấp có thể không có fallback tương đương về chi phí. Failover sang mô hình rẻ hơn có thể cho kết quả kém hơn và vẫn tốn hơn dự kiến nếu cửa sổ ngữ cảnh lớn.

An toàn nội dung. Một prompt bị bộ lọc an toàn của nhà cung cấp A từ chối không nên tự động được thử lại ở nhà cung cấp B để vượt qua bộ lọc. Mô hình đó có thể tạo ra trách nhiệm pháp lý và vi phạm hầu hết các chính sách sử dụng có thể chấp nhận.

Khối lượng công việc mang tính xác định. Sinh mã, soạn thảo pháp lý hoặc quy trình hỗ trợ y tế có thể yêu cầu một phiên bản mô hình cụ thể. Failover thay đổi phân phối đầu ra và có thể làm mất hiệu lực xác thực phía sau.

Mô hình vận hành: một runbook đơn giản

Sử dụng danh sách kiểm tra sau khi thiết kế hoặc xem xét chiến lược failover API LLM của bạn:

• Ánh xạ mỗi mô hình được hỗ trợ sang một hoặc nhiều mô hình dự phòng có cửa sổ ngữ cảnh và định dạng đầu ra tương thích.
• Cấu hình số lần thử lại, backoff và tổng thời gian chờ cho mỗi nhà cung cấp.
• Phân biệt thử lại đầu luồng với lỗi giữa luồng trong cả code và log.
• Phân tích mã lỗi cụ thể của nhà cung cấp và ghi đè quy tắc dựa trên mã HTTP khi cần.
• Đặt ngân sách chi phí và giới hạn tốc độ cho từng dự án hoặc khóa API.
• Hạn chế các tuyến failover cho các khu vực pháp lý nhạy cảm về dữ liệu.
• Cảnh báo khi tỷ lệ failover tăng đột biến qua dashboard vận hành.
• Tài liệu hóa lỗi nào kích hoạt thử lại tự động, lỗi nào kích hoạt failover, và lỗi nào cần xem xét thủ công.

Kết hợp lại

Một chiến lược failover được thiết kế tốt coi gateway như một control plane, không chỉ là proxy. Nó biết phân biệt giữa sự cố thoáng qua và lỗi nghiêm trọng, tôn trọng quyền của người dùng được thấy đầu ra nhất quán, và giữ chi phí có thể dự đoán. Bằng cách kết hợp quy tắc mã trạng thái, phân tích lỗi thân, ngân sách thử lại và ghi log rõ ràng, các nhóm có thể duy trì tính khả dụng của tính năng AI mà không biến sự cố nhà cung cấp thành hóa đơn mất kiểm soát.

Nếu bạn đang hợp nhất nhiều nhà cung cấp sau một giao diện thống nhất, bối cảnh rộng hơn cũng quan trọng. Failover chỉ là một phần của lớp truy cập AI có khả năng phục hồi, còn bao gồm một API cho nhiều mô hình AI, quản trị khóa API cho các nhóm AI và khả năng hiển thị giá mô hình. Mỗi khả năng củng cố các khả năng khác: quản trị xác định ai có thể định tuyến đâu, hiển thị giá ngăn chi phí bất ngờ, và failover giữ cho hệ thống đứng vững khi một nhà cung cấp duy nhất vấp ngã.

Kiểm tra lần cuối: 2026-06-22

AveMujica API giúp ở đâu

Khi workflow AI đi vào lưu lượng thật, câu hỏi không còn là “gọi được mô hình không” mà là ai được dùng, tốn bao nhiêu và xử lý lỗi thế nào. AveMujica API gom quyền truy cập mô hình, bối cảnh giá, ví và lịch sử sử dụng vào một console.

• Bắt đầu bằng một workflow thật.
• So sánh quyền truy cập mô hình, chi phí và log mà không phải ghép nhiều dashboard nhà cung cấp.
• Mở rộng khi độ trễ, chi phí và chủ sở hữu đã rõ.

Gateway nên giảm việc vận hành lặp lại: key, hóa đơn, giới hạn nhà cung cấp và sự cố không nên nằm rải rác ở nhiều nơi.

Tài liệu tham khảo

Các nguồn chính thức này giúp kiểm tra hành vi nhà cung cấp, giá và khung rủi ro được nhắc tới trong bài.

• IETF HTTP Semantics RFC 9110
• OpenTelemetry documentation
• Amazon Bedrock model invocation logging

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

Đội ngũ nên quyết định gì trước với Chiến lược failover cho LLM API khi nhà cung cấp gặp sự cố?

Bắt đầu từ quyền sở hữu và ranh giới chính sách: group hoặc key nào sở hữu workflow, mô hình nào được phép dùng và tín hiệu nào chứng minh chính sách đang hoạt động.

Sau khi triển khai nên theo dõi chỉ số nào?

Theo dõi chỉ số gần tác động người dùng nhất: chi phí trên tác vụ thành công, tỷ lệ fallback, p95 latency, request bị chặn hoặc biến động quota. Sau đó nối chỉ số đó với usage logs.

Bao lâu nên xem lại?

Các thông tin về giá và mô hình thay đổi nhanh. Hãy xem lại hàng tháng, và xem lại ngay sau sự cố, lần ra mắt mới hoặc thay đổi giá.

Nên so sánh gì

Phạm vi	Câu hỏi	Kiểm tra ở đâu
Ownership	Who owns this workflow?	usage logs and scoped API keys
Cost	Which unit can grow fastest?	pricing, model catalog, and wallet
Reliability	What failure pattern matters?	dashboard overview and channel history
Governance	What should be reviewed next month?	groups, quotas, key scope, and request history

Bắt đầu từ một workflow

Chọn một workflow thật và kiểm tra trong AveMujica API rằng quyền truy cập mô hình, bối cảnh giá, log sử dụng và ngân sách khớp với nhau trước khi mở rộng lưu lượng.