Failover tự động trong LLM gateway hoạt động thế nào

Gọi API nhà cung cấp trực tiếp là một cược: endpoint họ còn lên, bạn còn dưới rate limit, và phía họ không suy giữa request. Phần lớn lúc cược thắng. Khi không, failure là việc của bạn — logic retry, SDK thứ hai, key thứ hai, code chỉ được tập khi sự cố.

Gateway tồn tại để cược đó không cần. Chuỗi provider/model như z-ai/glm-5.2 hoặc openai/gpt-4o-mini resolve thành danh sách ứng viên upstream, không phải một đích cố định, và router chọn giữa chúng mỗi request dựa trên health sống.

Mọi request đi cùng chuỗi chọn trước khi một byte tới upstream:

1. Chọn ứng viên chính qua chiến lược routing
2. Load mọi upstream đã cấu hình cho mô hình đó
3. Áp preference nhà cung cấp cấp request, đủ điều kiện BYOK, và chính sách tuân thủ nhà cung cấp
4. Gỡ backend đang cooldown
5. Trả danh sách có thứ tự — chính, rồi fallback 1, fallback 2, ...
6. Nếu mọi ứng viên đều cooldown, vẫn trả full list — dịch vụ suy còn hơn không

Chiến lược routing tạo ứng viên chính cấu hình được theo request:

Nếu request của ứng viên chính fail, executor không đẩy lỗi ra — nó chuyển ứng viên kế trong list và thử lại, trong suốt với caller.

Retry endpoint chết trên mọi request phí thời gian và có thể làm sự cố tệ hơn. Mỗi backend upstream có circuit breaker riêng với ngưỡng cố định:

Backend trip breaker thì bị bỏ hẳn — không round trip phí, không cộng latency cho caller — đến khi recovery timeout qua và breaker cho một số nhỏ call probe half-open đi.

Circuit breaker là theo backend và sống ngắn. Bên dưới, store cooldown trên KV theo dõi mẫu failure trên cửa sổ rolling — 3 failure trong cửa sổ quan sát 60s trip cooldown — và mỗi lần tái phạm nhân đôi phạt, bắt đầu từ base 60s, trần 10 phút:

Backend cooldown bị lọc khỏi list ứng viên trước khi routing chạy, nên upstream flap không nhận nhỏ giọt traffic production lúc hồi. Dạng đơn giản, vòng dispatch như sau:

const candidates = await getFallbackChain(modelId, requestOptions)
  // primary + fallbacks, cooled-down backends already removed

for (const backend of candidates) {
  if (circuitBreaker.isOpen(backend)) continue

  try {
    const response = await dispatch(backend, requestBody)
    circuitBreaker.recordSuccess(backend)
    return response
  } catch (err) {
    circuitBreaker.recordFailure(backend)
    cooldownStore.recordFailure(backend) // may trigger escalating cooldown
    // fall through to the next candidate
  }
}
throw new AllUpstreamsFailedError(modelId)

Câu trả lời thẳng ở đây không phải số benchmark — mà là hình dạng hai thao tác đang so. Chọn ứng viên là quyết định routing cộng đọc cache; generate response là mô hình inference suốt thời gian tạo output, từng token. Dù overhead routing là gì, nó xảy ra một lần mỗi request, trong khi generate token diễn ra suốt thời gian response.

Nó cũng không bị trả hai lần. Gateway không buffer response upstream trước khi trả — chat completions, Anthropic messages, và stream Responses API đều được pipe qua như server-sent events, dịch dialect-to-dialect từng chunk, không gom vào memory rồi phát lại. Time-to-first-token do mô hình upstream chi phối, không phải lớp routing phía trước.

• Id mô hình vẫn chạy khi nhà cung cấp outage — request tự chuyển sang upstream đã cấu hình kế
• Upstream đang vật lộn ngừng nhận traffic trong một cửa sổ failure, không phải sau khi người nhận ra
• Hồi phục từ từ — call probe half-open, không đổ full traffic ngay lúc backend trông khỏe lại
• Không cái nào đòi logic retry trong client — cùng request, cùng key, cùng hình response dù thế nào