Ngày 4 tháng 8 năm 2026, trang trạng thái chính thức của DeepSeek ghi nhận hai sự cố API suy giảm hiệu năng.
Sự cố thứ nhất kéo dài 1 giờ 18 phút, từ 02:02 đến 03:20 UTC, và ảnh hưởng đến DeepSeek V4 Flash, V4 Pro và Expert Mode. Sự cố thứ hai kéo dài 36 phút, từ 03:43 đến 04:20 UTC, và ảnh hưởng đến API DeepSeek V4 Flash.
Cả hai sự cố hiện đã được khắc phục. OpenCode cũng báo cáo rằng DeepSeek Flash gặp vấn đề về năng lực xử lý do nhu cầu tăng đột biến chưa từng có. Tuy nhiên, trang trạng thái chính thức của DeepSeek chỉ xác nhận tình trạng suy giảm hiệu năng và không công bố nguyên nhân gốc rễ.
TL;DR
- Trang trạng thái chính thức của DeepSeek ghi nhận hai sự cố suy giảm hiệu năng ảnh hưởng đến V4 Flash vào ngày 4 tháng 8 năm 2026.
- Việc tích hợp trực tiếp với một nhà cung cấp tạo ra một điểm lỗi đơn lẻ, ngay cả khi cùng mô hình đó vẫn khả dụng ở nơi khác.
- AIHubMix có thể thử lại cùng một mô hình qua nhiều kênh nhà cung cấp khi một tuyến upstream trả về lỗi có thể thử lại.
- Nếu tất cả kênh nhà cung cấp của mô hình chính đều thất bại, Key-level model fallback có thể chuyển yêu cầu sang các mô hình dự phòng đã được cấu hình.
- Định tuyến đa nhà cung cấp giúp giảm sự phụ thuộc vào một endpoint duy nhất, nhưng nó không thể loại bỏ hoàn toàn các lỗi tương quan hoặc rủi ro ở tầng gateway.
Những sự cố như thế này làm nổi bật một nguyên tắc hạ tầng quan trọng:
Một mô hình đáng tin cậy là chưa đủ nếu nó chỉ được truy cập qua một endpoint nhà cung cấp duy nhất.
Một mô hình không nhất thiết phải gắn với một nhà cung cấp
Khi một ứng dụng kết nối trực tiếp với một nhà cung cấp, endpoint đó trở thành một điểm lỗi đơn lẻ.
Nếu nhà cung cấp gặp sự cố ngừng hoạt động, đạt giới hạn tốc độ, hoặc tăng đột biến độ trễ, ứng dụng không còn nơi nào khác để gửi yêu cầu. Người dùng sẽ thấy lỗi hết thời gian chờ, dù cùng mô hình đó vẫn khả dụng qua các hạ tầng nhà cung cấp khác.
AIHubMix tách biệt mô hình khỏi nhà cung cấp đang phục vụ nó.
Ví dụ, DeepSeek V4 Flash có sẵn qua nhiều nhà cung cấp trên AIHubMix, bao gồm DeepSeek, Baidu, DeepInfra và Alibaba Cloud. Ứng dụng tiếp tục sử dụng một endpoint API tương thích OpenAI duy nhất, trong khi AIHubMix quản lý các tuyến upstream khả dụng.
Điều này tạo ra hai lớp độ tin cậy riêng biệt.
Lớp 1: Chuyển đổi dự phòng nhà cung cấp
Provider failover giữ nguyên mô hình được yêu cầu trong khi chuyển sang nhà cung cấp hạ tầng khác phía sau nó.
Khi một yêu cầu cho DeepSeek V4 Flash đến AIHubMix, gateway sẽ chọn một kênh nhà cung cấp đủ điều kiện. Nếu kênh đó trả về lỗi có thể thử lại trước khi phản hồi bắt đầu, AIHubMix có thể thử một kênh khả dụng khác cho cùng mô hình.
Luồng xử lý yêu cầu có thể như sau:
- Thử DeepSeek V4 Flash qua Provider A.
- Provider A trả về lỗi timeout, lỗi 5xx, hoặc lỗi năng lực xử lý có thể thử lại.
- Thử cùng mô hình DeepSeek V4 Flash qua Provider B.
- Tiếp tục cho đến khi yêu cầu thành công hoặc tất cả kênh đủ điều kiện đã được thử hết.
Client không cần tích hợp nhiều SDK của nhà cung cấp, quản lý nhiều API key riêng biệt, hay tự triển khai logic thử lại.
Đây là chuyển đổi dự phòng ở cấp nhà cung cấp: nhà cung cấp thay đổi, nhưng mô hình được yêu cầu vẫn giữ nguyên.
Lớp 2: Chuyển đổi dự phòng mô hình
Chuyển đổi dự phòng nhà cung cấp không thể giúp ích nếu mọi nhà cung cấp khả dụng cho mô hình chính đều không hoạt động.
Vì vậy, AIHubMix hỗ trợ thêm một lớp độ tin cậy thứ hai: chuyển đổi dự phòng mô hình.
Người dùng có thể cấu hình một danh sách có thứ tự các mô hình dự phòng cho từng API key. Sau khi mọi kênh đủ điều kiện của mô hình chính đều trả về lỗi có thể thử lại, AIHubMix sẽ chuyển sang mô hình tiếp theo trong danh sách dự phòng.
Ví dụ:
- Mô hình chính:
deepseek-v4-flash - Dự phòng thứ nhất:
gpt-5.4 - Dự phòng thứ hai:
gemini-3.1-pro-preview
Việc chuyển đổi dự phòng được thực hiện bên trong gateway của AIHubMix. Các ứng dụng hiện có không cần gửi thêm tham số định tuyến hay thay đổi mã client.
Việc tính phí dựa trên mô hình trả về phản hồi thành công cuối cùng. Nhà phát triển có thể kiểm tra hành vi chuyển đổi dự phòng qua các response header:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
Toàn bộ cấu hình và quy tắc kích hoạt được ghi tại AIHubMix Model Mapping and Fallback.
Những gì chuyển đổi dự phòng tự động có thể xử lý
Chuyển đổi dự phòng nhà cung cấp được thiết kế để khôi phục sau các sự cố hạ tầng upstream, chẳng hạn như:
- Nhà cung cấp hết thời gian chờ
- Lỗi kết nối
- Phản hồi 5xx có thể thử lại
- Giới hạn tốc độ của nhà cung cấp và lỗi năng lực xử lý
- Kênh upstream tạm thời không khả dụng
Khi những lỗi này xảy ra trước khi phản hồi bắt đầu, AIHubMix có thể âm thầm thử một tuyến khác.
Những gì chuyển đổi dự phòng không thể giải quyết
Định tuyến đa nhà cung cấp giúp cải thiện tính sẵn sàng, nhưng nó không làm cho gateway trở nên bất khả xâm phạm.
Chuyển đổi dự phòng sẽ không được kích hoạt khi:
- API key AIHubMix của người dùng không hợp lệ, đã hết hạn, hoặc đã hết hạn mức
- Chính yêu cầu không hợp lệ
- Client ngắt kết nối hoặc vượt quá thời gian chờ của chính nó
- Phản hồi streaming đã bắt đầu
- Một kênh nhà cung cấp cụ thể đã được chỉ định rõ ràng
- Lỗi ảnh hưởng đến mọi nhà cung cấp hoặc chính gateway
Các lỗi của nhà cung cấp cũng có thể mang tính tương quan. Nhiều nhà cung cấp có thể phụ thuộc vào cùng một hạ tầng nền, cùng một bản phát hành mô hình, hoặc cùng một mạng khu vực. Vì lý do này, tính sẵn sàng đa nhà cung cấp nên được đo lường bằng lưu lượng thực tế, thay vì giả định chỉ dựa vào số lượng nhà cung cấp.
Vì sao một aggregator có thể đáng tin cậy hơn endpoint trực tiếp
Gọi trực tiếp một API chính thức chỉ cho ứng dụng một tuyến duy nhất đến mô hình.
Một gateway đa nhà cung cấp cung cấp cho ứng dụng nhiều tuyến.
Nếu các tuyến nhà cung cấp đó hoạt động độc lập với nhau, gateway có thể định tuyến quanh một endpoint đang suy giảm mà không để lỗi lộ ra ứng dụng. Điều này giảm sự phụ thuộc vào bất kỳ nhà cung cấp đơn lẻ nào và có thể mang lại tính sẵn sàng cao hơn so với tích hợp trực tiếp với một nhà cung cấp duy nhất.
Sự khác biệt nằm ở kiến trúc:
- API trực tiếp: một mô hình, một nhà cung cấp, một miền lỗi
- AIHubMix: một mô hình, nhiều nhà cung cấp, chuyển đổi dự phòng tự động
- AIHubMix với chuyển đổi dự phòng mô hình: nhiều nhà cung cấp cộng với các mô hình dự phòng
Mục tiêu không phải là dự đoán nhà cung cấp nào sẽ gặp sự cố tiếp theo. Mà là biến một sự cố upstream thành một sự kiện định tuyến nội bộ, thay vì một gián đoạn ảnh hưởng đến khách hàng.
Chuẩn bị cho sự cố nhà cung cấp tiếp theo
DeepSeek V4 Flash đã phục hồi, nhưng các giới hạn năng lực xử lý tạm thời, giới hạn tốc độ và sự cố upstream là chuyện bình thường trong hạ tầng AI vận hành thực tế.
Ứng dụng không nên phải thay đổi mã mỗi khi một nhà cung cấp trở nên không ổn định.
Với AIHubMix, nhà phát triển có thể truy cập nhiều nhà cung cấp qua một API, tự động thử lại cùng một mô hình trên các kênh khả dụng, và cấu hình mô hình dự phòng để có thêm một lớp bảo vệ.
Khám phá các mô hình và nhà cung cấp khả dụng tại aihubmix.com/models.
Câu hỏi thường gặp
Chuyển đổi dự phòng đa nhà cung cấp là gì?
Đây là cơ chế tự động thử lại cùng một mô hình qua một nhà cung cấp đủ điều kiện khác khi tuyến hiện tại trả về lỗi có thể thử lại.
Chuyển đổi dự phòng mô hình khác gì?
Chuyển đổi dự phòng nhà cung cấp giữ nguyên mô hình. Chuyển đổi dự phòng mô hình chỉ chuyển sang một mô hình dự phòng đã cấu hình sau khi mọi kênh đủ điều kiện của mô hình chính đều thất bại.
Những lỗi nào có thể kích hoạt chuyển đổi dự phòng?
Các trường hợp điển hình bao gồm hết thời gian chờ, lỗi kết nối, phản hồi 5xx có thể thử lại, giới hạn tốc độ, và lỗi năng lực xử lý tạm thời trước khi phản hồi bắt đầu.
Chuyển đổi dự phòng có đảm bảo không có thời gian ngừng hoạt động không?
Không. Các lỗi tương quan của nhà cung cấp, sự cố ở tầng gateway, lỗi không thể thử lại, và lỗi xảy ra sau khi streaming đã bắt đầu vẫn có thể ảnh hưởng đến client.
Tôi có cần thay đổi mã ứng dụng không?
Không cần thêm logic định tuyến nào. Ứng dụng tiếp tục sử dụng endpoint tương thích OpenAI của AIHubMix, trong khi các mô hình dự phòng có thể được cấu hình ở cấp API key.
