Vào 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ố giảm hiệu suất API.
Sự cố đầu tiên 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à Chế độ Chuyên gia. 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ố đã được giải quyết. OpenCode cũng báo cáo rằng DeepSeek Flash đang gặp vấn đề về công suất do nhu cầu 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 hiệu suất giảm và không công bố nguyên nhân gốc rễ.
Tóm tắt
- Trang trạng thái chính thức của DeepSeek đã ghi nhận hai sự cố giảm hiệu suất ả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 nhà cung cấp tạo ra một điểm thất bại duy nhất, ngay cả khi cùng một mô hình có sẵn ở 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 đường phía trên trả về lỗi có thể thử lại.
- Nếu tất cả các kênh nhà cung cấp cho mô hình chính đều thất bại, việc chuyển đổi mô hình ở cấp độ khóa 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 nhiều nhà cung cấp giảm sự phụ thuộc vào một điểm cuối, nhưng không thể loại bỏ các lỗi tương quan hoặc rủi ro ở cấp độ cổng.
Các sự cố như thế này làm nổi bật một nguyên tắc cơ sở hạ tầng quan trọng:
Một mô hình đáng tin cậy không đủ nếu nó được truy cập thông qua một điểm cuối nhà cung cấp duy nhất.
Một mô hình không nhất thiết phải có nghĩa là 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, điểm cuối đó trở thành một điểm thất bại duy nhất.
Nếu nhà cung cấp gặp sự cố, đạt giới hạn tỷ lệ, hoặc bị tăng độ trễ, ứng dụng sẽ không có nơi nào khác để gửi yêu cầu. Người dùng sẽ thấy thời gian chờ và lỗi ngay cả khi cùng một mô hình vẫn có sẵn thông qua các nhà cung cấp hạ tầng khác.
AIHubMix tách mô hình ra khỏi nhà cung cấp phục vụ nó.
Ví dụ, DeepSeek V4 Flash có sẵn thông qua nhiều nhà cung cấp trên AIHubMix, bao gồm DeepSeek, Baidu, DeepInfra và Alibaba Cloud. Các ứng dụng tiếp tục sử dụng một điểm cuối API tương thích với OpenAI trong khi AIHubMix quản lý các tuyến đường phía trên có sẵn.
Điều này tạo ra hai lớp độ tin cậy khác nhau.
Lớp 1: Chuyển đổi nhà cung cấp
Chuyển đổi nhà cung cấp giữ nguyên mô hình yêu cầu trong khi chuyển đổi nhà cung cấp hạ tầng phía sau nó.
Khi một yêu cầu cho DeepSeek V4 Flash đến AIHubMix, cổng 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ác có sẵn cho cùng một mô hình.
Đường dẫn yêu cầu có thể trông như sau:
- Thử DeepSeek V4 Flash qua Nhà cung cấp A.
- Nhà cung cấp A trả về một thời gian chờ, lỗi 5xx, hoặc lỗi công suất có thể thử lại.
- Thử cùng một mô hình DeepSeek V4 Flash qua Nhà cung cấp B.
- Tiếp tục cho đến khi yêu cầu thành công hoặc tất cả các kênh đủ điều kiện đều đã được sử dụng.
Khách hàng không cần tích hợp nhiều SDK nhà cung cấp, quản lý các khóa API riêng biệt, hoặc triển khai logic thử lại của riêng mình.
Đây là chuyển đổi ở cấp độ nhà cung cấp: nhà cung cấp thay đổi, nhưng mô hình yêu cầu vẫn giữ nguyên.
Lớp 2: Chuyển đổi mô hình
Một chuyển đổi nhà cung cấp không thể giúp nếu mọi nhà cung cấp có sẵn cho mô hình chính đều không khả dụng.
Vì vậy, AIHubMix hỗ trợ một lớp độ tin cậy thứ hai: chuyển đổi 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 mỗi khóa API. Sau khi mọi kênh đủ điều kiện cho mô hình chính đã trả về một 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ụ:
- Chính:
deepseek-v4-flash - Dự phòng đầu tiên:
gpt-5.4 - Dự phòng thứ hai:
gemini-3.1-pro-preview
Việc chuyển đổi được thực hiện bên trong cổng AIHubMix. Các ứng dụng hiện có không cần gửi thêm các tham số định tuyến hoặc thay đổi mã khách hàng của chúng.
Việc thanh toán dựa trên mô hình cuối cùng trả về phản hồi thành công. Các nhà phát triển có thể xác minh hành vi chuyển đổi thông qua các tiêu đề phản hồi:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
Cấu hình hoàn chỉnh và các quy tắc kích hoạt được tài liệu hóa trong AIHubMix Model Mapping and Fallback.
Những gì chuyển đổi tự động có thể xử lý
Chuyển đổi nhà cung cấp được thiết kế để phục hồi từ các vấn đề hạ tầng phía trên như:
- Thời gian chờ của nhà cung cấp
- Sự cố kết nối
- Các phản hồi 5xx có thể thử lại
- Giới hạn tỷ lệ và lỗi công suất của nhà cung cấp
- Thời gian không khả dụng tạm thời của một kênh phía trên
Khi những lỗi này xảy ra trước khi phản hồi bắt đầu, AIHubMix có thể thử một tuyến đường khác một cách minh bạch.
Những gì chuyển đổi không thể giải quyết
Định tuyến nhiều nhà cung cấp cải thiện khả năng sẵn có, nhưng nó không làm cho một cổng trở nên không thể sai lầm.
Chuyển đổi không được kích hoạt khi:
- Khóa API AIHubMix của người dùng không hợp lệ, hết hạn, hoặc vượt quá hạn mức
- Yêu cầu tự nó không hợp lệ
- Khách hàng ngắt kết nối hoặc đạt thời gian chờ của riêng mình
- Một phản hồi phát trực tiếp đã bắt đầu
- Một kênh nhà cung cấp cụ thể đã được chọn rõ ràng
- Sự cố ảnh hưởng đến mọi nhà cung cấp hoặc chính cổng
Các sự cố của nhà cung cấp cũng có thể tương quan. Nhiều nhà cung cấp có thể phụ thuộc vào cùng một hạ tầng cơ sở, phát hành mô hình, hoặc mạng khu vực. Vì lý do này, khả năng sẵn có của nhiều nhà cung cấp nên được đo bằng lưu lượng thực tế thay vì chỉ dựa vào số lượng nhà cung cấp.
Tại sao một bộ tổng hợp có thể đáng tin cậy hơn một điểm cuối trực tiếp
Gọi một API chính thức trực tiếp cung cấp cho một ứng dụng một tuyến đường đến mô hình.
Một cổng nhiều nhà cung cấp cung cấp cho nó nhiều tuyến đường.
Nếu những tuyến đường của nhà cung cấp đó thất bại độc lập, cổng có thể định tuyến xung quanh một điểm cuối bị giảm mà không phơi bày sự cố cho ứng dụng. Điều này giảm sự phụ thuộc vào bất kỳ nhà cung cấp nào và có thể cung cấp khả năng sẵn có cao hơn so với một tích hợp nhà cung cấp đơn lẻ trực tiếp.
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 thất bại
- AIHubMix: một mô hình, nhiều nhà cung cấp, chuyển đổi tự động
- AIHubMix với chuyển đổi 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ẽ thất bại tiếp theo. Mục tiêu là biến một sự cố phía trên thành một sự kiện định tuyến nội bộ thay vì một sự cố đối mặt với khách hàng.
Xây dựng cho sự cố nhà cung cấp tiếp theo
DeepSeek V4 Flash đã phục hồi, nhưng các hạn chế về công suất tạm thời, giới hạn tỷ lệ, và các sự cố phía trên là những phần bình thường của hạ tầng AI sản xuất.
Các ứ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, các nhà phát triển có thể truy cập nhiều nhà cung cấp thông qua một API, tự động thử lại cùng một mô hình qua các kênh có sẵn, và cấu hình các mô hình dự phòng cho một lớp bảo vệ bổ sung.
Khám phá các mô hình và nhà cung cấp có sẵn tại aihubmix.com/models.
Câu hỏi thường gặp
Chuyển đổi giữa nhiều nhà cung cấp là gì?
Nó tự động thử lại cùng một mô hình thông qua một nhà cung cấp đủ điều kiện khác khi tuyến đường hiện tại trả về một lỗi có thể thử lại.
Chuyển đổi mô hình khác như thế nào?
Chuyển đổi nhà cung cấp giữ nguyên mô hình. Chuyển đổi mô hình chỉ chuyển sang một mô hình dự phòng đã được cấu hình sau khi tất cả các kênh đủ điều kiện cho 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?
Các kích hoạt điển hình bao gồm thời gian chờ, sự cố kết nối, các phản hồi 5xx có thể thử lại, giới hạn tỷ lệ, và lỗi công suất tạm thời trước khi phản hồi bắt đầu.
Chuyển đổi có đảm bảo không có thời gian chết không?
Không. Các sự cố nhà cung cấp tương quan, sự cố ở cấp độ cổng, lỗi không thể thử lại, và các sự cố sau khi phát trực tiếp bắt đầu vẫn có thể đến với khách hàng.
Tôi có cần thay đổi mã ứng dụng của mình không?
Không cần logic định tuyến bổ sung. Các ứng dụng tiếp tục sử dụng điểm cuối tương thích với OpenAI của AIHubMix, trong khi các mô hình dự phòng có thể được cấu hình ở cấp độ khóa API.