DeepSeek API không hoạt động? Cách sửa lỗi xác thực, thanh toán và giới hạn tốc độ

Khi yêu cầu API DeepSeek báo lỗi, hãy bắt đầu từ dịch vụ đã nhận yêu cầu đó. Key DeepSeek chính thức, key của gateway và gói lập trình không thể dùng thay cho nhau. Cùng một mã trạng thái HTTP cũng có thể mang ý nghĩa khác nhau ở các dịch vụ khác nhau.

Cách chẩn đoán nhanh và hữu ích nhất là ghép bốn dữ kiện: hostname đích, mã định danh model, mã trạng thái HTTP và thông báo lỗi trong phản hồi. Hãy ghi lại những thông tin này trước khi thay đổi cấu hình. Hướng dẫn này nói về lỗi cấu hình và lỗi yêu cầu, dựa trên tài liệu đã kiểm tra ngày 26 tháng 10 năm 2026. Đây không phải báo cáo sự cố trực tiếp, cũng không phải khẳng định rằng một dịch vụ cụ thể đang không khả dụng.

Nếu lỗi là 402 hoặc nạp tiền không thành công, xem thanh toán API DeepSeek để biết cách nạp tiền, hoàn tiền và số dư hoạt động.

1. Xác nhận bạn đang gọi API nào

Hãy coi nhà cung cấp, nơi cấp key, định dạng endpoint và model ID là một cấu hình thống nhất. Trộn các phần từ những ví dụ khác nhau sẽ tạo ra lỗi trông như vấn đề của model.

Tuyến	Base URL định dạng OpenAI	Mã định danh model Flash
DeepSeek trực tiếp	https://api.deepseek.com	deepseek-flash
cheapaimodel	https://api.cheapaimodel.ai/v1	deepseek-v4-1-flash

Những mã định danh này lấy từ bắt đầu nhanh DeepSeek và trang model DeepSeek V4.1 Flash trên cheapaimodel. Chúng mô tả các tuyến truy cập khác nhau, không phải bằng chứng rằng hành vi backend là giống hệt nhau. DeepSeek cũng có tài liệu về endpoint định dạng Anthropic; đừng dán địa chỉ đó vào client đang mong đợi định dạng yêu cầu OpenAI.

Hãy kiểm tra cấu hình mà ứng dụng của bạn thực sự dùng, không chỉ tệp bạn vừa sửa. Một biến môi trường khi triển khai, một hồ sơ dự án khác hoặc một tiến trình cũ có thể ghi đè giá trị bạn muốn. Chỉ khởi động lại hoặc triển khai lại nếu phù hợp với ứng dụng của bạn, rồi kiểm tra nhà cung cấp và cài đặt model đang có hiệu lực mà không in ra key bí mật.

2. Đọc mã trạng thái và thông báo cùng nhau

Với API DeepSeek trực tiếp, tài liệu lỗi chính thức ghi các nhóm sau:

Mã trạng thái	Ý nghĩa trên API trực tiếp	Kiểm tra đầu tiên
400	Yêu cầu sai định dạng	Cấu trúc body và định dạng JSON
401	Xác thực không thành công	Key và đích gửi
402	Số dư không đủ	Số dư tài khoản trực tiếp
422	Tham số không hợp lệ	Tên, kiểu và giá trị được hỗ trợ
429	Giới hạn tốc độ hoặc số yêu cầu đồng thời	Nhịp gửi yêu cầu và các tác vụ đang chạy
500	Lỗi máy chủ	Thử lại có giới hạn, rồi kiểm tra xem lỗi có lặp lại không
503	Máy chủ quá tải	Chờ trước khi thử lại có giới hạn

Bảng này không phải từ điển lỗi chung cho mọi gateway. Ví dụ, câu hỏi thường gặp về thanh toán của cheapaimodel cho biết dịch vụ trả về 403 khi số dư trả trước đã hết. Hãy đọc phản hồi của gateway đó thay vì coi mọi 403 là sai mật khẩu hay mọi vấn đề số dư là lỗi 402 của DeepSeek.

3. Tách xác thực khỏi quyền truy cập tài khoản

Khi xác thực không thành công, hãy kiểm tra xem key có được cấp bởi nhà cung cấp của endpoint đó không và còn hoạt động không. Tìm các dấu cách thừa xung quanh, biến môi trường bị thiếu hoặc tên biến khác nhau giữa môi trường local và môi trường đã triển khai.

Đừng để lộ key trong ảnh chụp màn hình hay nhật ký chỉ để chứng minh key tồn tại. Thay vào đó, hãy ghi lại nhãn key không phải bí mật hoặc tên biến cấu hình. Nếu thông tin xác thực đã bị lộ, hãy làm theo quy trình thu hồi và thay thế của nhà cung cấp trước khi tiếp tục.

Với lỗi số dư hoặc quyền truy cập, hãy mở tài khoản thuộc route đang được gọi. Nạp tiền cho nhà cung cấp này không có nghĩa là nhà cung cấp khác cũng có tiền. Kiểm tra cả các giới hạn ở cấp key đang áp dụng lẫn số dư tài khoản. cheapaimodel có ghi rõ hạn mức chi tiêu theo từng key, ngày hết hạn, danh sách cho phép model và danh sách cho phép IP; một giới hạn như vậy cần được kiểm tra riêng thay vì tự động nạp thêm tiền.

Đừng nạp thêm tiền như hành động gỡ lỗi đầu tiên khi phản hồi cho thấy key không hợp lệ, tham số yêu cầu sai hoặc đích đến sai.

4. Rút gọn yêu cầu về trường hợp tối thiểu

Nếu xác thực thành công nhưng yêu cầu bị từ chối, hãy tạm bỏ bớt độ phức tạp của ứng dụng. Bắt đầu từ ví dụ hiện hành trong tài liệu của nhà cung cấp đã chọn, với một prompt văn bản ngắn, không nhạy cảm và một model được hỗ trợ. Bỏ qua tools, hình ảnh, định dạng phản hồi tùy chỉnh, cài đặt suy luận tùy chọn và lịch sử hội thoại dài cho đến khi đường đi cơ bản hoạt động.

Sau đó thêm từng tính năng một. Nếu yêu cầu đơn giản thành công mà yêu cầu có bật tools báo lỗi, thì khác biệt đó cho bạn nhiều thông tin hơn là gửi lại nguyên payload production nhiều lần.

Kiểm tra những nguyên nhân sai lệch phổ biến sau:

• Giá trị model là tên hiển thị tiếp thị chứ không phải mã định danh API.
• SDK tự thêm một đường dẫn vốn đã có trong URL bạn cấu hình.
• Một tham số bạn sao chép thuộc về nhà cung cấp khác hoặc định dạng endpoint khác.
• Một trường bị sai kiểu, ví dụ chuỗi trong khi cần số hoặc object.
• Ngữ cảnh hoặc đầu ra yêu cầu vượt quá giới hạn của model hoặc route đang áp dụng.

Dùng phản hồi lỗi và tài liệu hiện hành của nhà cung cấp để xác định trường hợp nào đang xảy ra. Bỏ hẳn mọi tùy chọn không phải là cách thay thế cho việc hiểu rõ tính năng bắt buộc nào không tương thích.

5. Chẩn đoán lỗi 429 trước khi thêm retry

Tài liệu về giới hạn tốc độ của DeepSeek định nghĩa số lượng xử lý đồng thời ở cấp tài khoản. Một yêu cầu vẫn đang hoạt động cho đến khi phản hồi xong, và dùng key khác trong cùng tài khoản không tạo ra hạn mức độc lập.

Nghĩa là một workload có thể bị giới hạn khi các yêu cầu mất nhiều thời gian hơn, dù số lượng yêu cầu bắt đầu mỗi giây không đổi. Hãy kiểm tra các yêu cầu đang hoạt động, kích thước hàng đợi, thời gian hoàn thành và liệu nhiều worker của ứng dụng có đang dùng chung một tài khoản không.

Giảm việc chạy song song, thêm độ trễ có giới hạn kèm jitter, và tuân theo độ trễ retry nếu dịch vụ có cung cấp. Giới hạn cả số lần thử lẫn tổng thời gian chờ. Đảm bảo chỉ một tầng đảm nhận retry: vòng retry của SDK nhân với vòng retry của ứng dụng có thể làm tình trạng quá tải nặng hơn.

Đừng retry liên tục với thông tin xác thực không hợp lệ hoặc yêu cầu sai định dạng. Những trường hợp đó cần đổi cấu hình, không phải thêm lưu lượng.

6. Coi hết thời gian chờ là một kết quả chưa chắc chắn

Client hết thời gian chờ không chứng minh rằng máy chủ chưa từng xử lý yêu cầu. Trước khi lặp lại công việc tốn kém, hãy kiểm tra bản ghi yêu cầu hoặc nhật ký mức sử dụng nếu có. Có thể phản hồi đã được tạo ra sau khi client của bạn ngừng chờ.

Lỗi streaming cũng cần xử lý tương tự. Ghi lại xem kết nối đã mở chưa, có sự kiện nào đến không, và client của bạn có thấy tín hiệu hoàn tất như mong đợi không. Một câu trả lời hiển thị một phần không tự động là một phản hồi hoàn chỉnh thành công.

Nếu mô hình thực hiện các hành động bên ngoài, hãy tách những hành động đó khỏi việc thử lại tạo sinh. Một ứng dụng không nên lặp lại thanh toán, thông báo hay tác động phụ khác chỉ vì đã mất phản hồi cuối cùng.

7. Báo lên cấp trên với bản tái hiện an toàn

Nếu vấn đề vẫn tiếp diễn, hãy chuẩn bị một báo cáo ngắn gọn cho nhà cung cấp: mốc thời gian UTC, hostname của endpoint, model ID, trạng thái, thông báo lỗi đã làm sạch, mã định danh yêu cầu nếu có, phiên bản SDK, và payload nhỏ nhất có thể tái hiện mà không chứa dữ liệu riêng tư.

Mô tả xem lỗi có xảy ra liên tục không, chỉ khi chạy đồng thời, hay chỉ với một tính năng. Ghi kèm những thay đổi trước khi lỗi xuất hiện. Tuyệt đối không đính kèm header xác thực thô hay prompt của khách hàng chỉ để báo cáo đầy đủ hơn.

Khi yêu cầu đã chạy được, hãy quay lại khối lượng công việc thực tế một cách từ từ và kiểm tra mức sử dụng bị tính phí. Hướng dẫn bảng giá DeepSeek của chúng tôi giải thích các nhóm chi phí; tài liệu cho nhà phát triển là điểm bắt đầu cho cấu hình riêng của gateway. Hãy sửa nguyên nhân đã chẩn đoán trước khi quyết định xem có cần mô hình hay nhà cung cấp khác không.