Khi gọi API mô hình ngôn ngữ, bạn phải tách lỗi làm hai loại: lỗi tạm thời như hết hạn mức (mã 429), máy chủ quá tải hay lỗi 5xx, quá thời gian chờ thì thử lại có lùi dần; lỗi do yêu cầu như sai khoá, sai tham số, đầu vào quá dài thì không thử lại mà sửa hoặc báo lỗi. Thêm vào đó là thời hạn chờ hợp lý, giới hạn số yêu cầu chạy đồng thời và một phương án dự phòng khi nhà cung cấp gặp sự cố.
Bài này dành cho lập trình viên đã có tính năng AI chạy được ở môi trường thử, chuẩn bị mở cho người dùng thật. Ở môi trường thử, lỗi hiếm gặp; khi có hàng trăm người dùng cùng lúc, hạn mức và sự cố của nhà cung cấp trở thành chuyện hằng tuần. Mã mẫu viết bằng Python ở dạng chung; mã lỗi và tên tiêu đề cụ thể bạn đối chiếu với tài liệu chính thức của hãng đang dùng.
Phân loại lỗi: thử lại hay không
Bảng dưới gom các nhóm lỗi hay gặp theo mã trạng thái HTTP phổ biến. Mỗi hãng có thể thêm mã riêng hoặc trả lỗi trong nội dung phản hồi; đọc mục lỗi trong tài liệu của hãng để bổ sung.
| Nhóm | Dấu hiệu thường gặp | Thử lại? | Nên làm gì |
|---|---|---|---|
| Yêu cầu sai | Mã 400, thông báo tham số không hợp lệ | Không | Ghi nhật ký đầy đủ, sửa mã; đây là lỗi của bạn |
| Xác thực | Mã 401, 403 | Không | Kiểm khoá trong biến môi trường, khoá có bị thu hồi hay hết hạn; báo động cho người trực |
| Đầu vào quá dài | Lỗi vượt độ dài ngữ cảnh | Không, với cùng đầu vào | Cắt lịch sử, giảm tài liệu đính kèm rồi mới gọi lại |
| Hết hạn mức | Mã 429 | Có, sau thời gian chờ | Đọc tiêu đề Retry-After nếu có, lùi dần, giảm tốc độ gửi |
| Máy chủ hãng lỗi hoặc quá tải | Mã 500, 502, 503 hoặc mã quá tải riêng của hãng | Có, vài lần | Lùi dần; kéo dài thì chuyển sang phương án dự phòng |
| Quá thời gian chờ, mất kết nối | Ngoại lệ timeout hoặc kết nối bị đóng | Có, thận trọng | Thử lại một hai lần; nếu là thao tác có tác dụng phụ thì kiểm trước |
| Bị bộ lọc an toàn chặn | Phản hồi bình thường nhưng lý do dừng hoặc trường riêng báo bị chặn | Không | Hiện thông báo phù hợp cho người dùng, ghi nhật ký để rà |
Hàng cuối hay bị bỏ sót vì nó không phải lỗi HTTP: phản hồi trả mã 200 nhưng nội dung rỗng hoặc bị cắt do bộ lọc. Nếu mã của bạn chỉ kiểm mã trạng thái, người dùng sẽ thấy một ô trả lời trống. Luôn kiểm lý do dừng trong phản hồi bên cạnh mã trạng thái.
Thử lại có lùi dần và độ nhiễu
Thử lại ngay lập tức sau lỗi 429 là cách chắc chắn nhất để nhận thêm lỗi 429. Cách đúng là chờ, và chờ lâu dần sau mỗi lần thất bại: một giây, hai giây, bốn giây, tám giây, tới một mức trần. Thêm một khoảng ngẫu nhiên nhỏ vào mỗi lần chờ, gọi là độ nhiễu, để hàng trăm yêu cầu bị từ chối cùng lúc không cùng thử lại vào đúng một thời điểm rồi lại bị từ chối cùng lúc.
Trong Python, phần tính thời gian chờ có thể viết: cho = min(30, 2 ** lan_thu) + random.uniform(0, 1) rồi time.sleep(cho). Nếu phản hồi có tiêu đề Retry-After, ưu tiên giá trị đó: sau = r.headers.get("Retry-After"), có thì chuyển sang số giây và chờ đúng chừng đó. Lưu ý Retry-After theo chuẩn HTTP có thể là số giây hoặc một mốc thời gian, nên mã chuyển đổi cần xử lý cả hai hoặc ít nhất bỏ qua khi không đọc được.
Đặt số lần thử tối đa nhỏ, khoảng ba đến năm lần, và một trần tổng thời gian cho cả chuỗi thử lại. Người dùng đang chờ trên giao diện không nên phải ngồi một phút chỉ vì máy chủ cố thử lại. Nhiều bộ thư viện chính thức của các hãng đã có sẵn cơ chế thử lại với lùi dần, cấu hình được số lần; nếu dùng chúng, kiểm mặc định là bao nhiêu và đừng bọc thêm một vòng thử lại của riêng bạn bên ngoài, kẻo số lần nhân lên.
Đặt thời hạn chờ cho đúng
Tách thời hạn kết nối và thời hạn đọc. Với thư viện requests, tham số timeout nhận một cặp giá trị: timeout=(5, 60) nghĩa là tối đa năm giây để kết nối và sáu mươi giây chờ dữ liệu giữa các lần nhận. Kết nối lâu thường là dấu hiệu mạng có vấn đề; đọc lâu có thể chỉ là câu trả lời dài.
Thời hạn theo tính năng. Gợi ý trong ô nhập cần thời hạn vài giây, quá thì bỏ qua lặng lẽ. Báo cáo chạy nền chấp nhận vài phút. Dùng chung một thời hạn cho mọi tính năng là hoặc quá chặt cho việc dài, hoặc quá lỏng cho việc cần nhanh.
Thời hạn ở mọi tầng phải khớp nhau. Nếu proxy phía trước máy chủ của bạn cắt kết nối sau ba mươi giây mà lời gọi API được phép chờ sáu mươi giây, người dùng nhận lỗi từ proxy trong khi máy chủ vẫn đang chờ và vẫn bị tính phí. Kiểm thời hạn của máy chủ web, proxy, nền tảng triển khai.
Trả về dần giúp tránh thời hạn đọc. Khi dùng streaming, dữ liệu về liên tục nên thời hạn đọc giữa các mẩu ít khi bị chạm, kể cả với câu trả lời dài.
Giới hạn số yêu cầu đồng thời trước khi bị nhà cung cấp giới hạn
Hạn mức của nhà cung cấp thường tính theo số yêu cầu mỗi phút và số token mỗi phút, có khi thêm số yêu cầu đồng thời. Mức cụ thể tuỳ gói và lịch sử sử dụng của tài khoản, xem trong bảng điều khiển của hãng. Thay vì gửi bừa rồi xử lý lỗi 429, bạn nên tự giới hạn ở phía mình, thấp hơn mức của hãng một khoảng.
Với mã bất đồng bộ trong Python, cách đơn giản là dùng một semaphore: gioi_han = asyncio.Semaphore(8) ở cấp mô-đun, và mỗi lời gọi bọc trong async with gioi_han:. Nhiều nhất tám lời gọi chạy cùng lúc, phần còn lại xếp hàng chờ. Với việc chạy nền như xử lý một nghìn bản ghi, dùng hàng đợi công việc với số tiến trình xử lý cố định và đếm token đã gửi trong phút hiện tại.
Nếu sản phẩm có cả việc người dùng đang chờ lẫn việc chạy nền, tách hạn mức cho hai loại, hoặc dùng hai khoá thuộc hai dự án riêng nếu hãng cho phép. Đừng để một lô xử lý đêm ăn hết hạn mức khiến người dùng đăng nhập sớm buổi sáng nhận toàn lỗi.
Phương án dự phòng khi nhà cung cấp gặp sự cố
Nhà cung cấp nào cũng có lúc chậm hay ngừng. Mức dự phòng cần có tuỳ tính năng quan trọng tới đâu:
- Mô hình phụ cùng hãng: mô hình lớn quá tải thì chuyển sang mô hình nhỏ hơn, chất lượng giảm chút nhưng vẫn phục vụ được.
- Hãng thứ hai: chỉ đáng làm khi tính năng thật sự quan trọng, vì phải duy trì và kiểm câu lệnh trên hai mô hình. Nhờ đã gói lời gọi vào một hàm, việc chuyển chỉ ở một chỗ.
- Kết quả lưu đệm: với câu hỏi đã có câu trả lời gần đây, trả bản lưu kèm ghi chú.
- Tắt mềm tính năng: một cờ cấu hình để ẩn nút AI và hiện thông báo tạm ngừng, bật lại không cần triển khai mã mới.
- Luồng thay thế không có AI: ô nhập tay vẫn hoạt động khi nút “gợi ý bằng AI” tạm ngừng. Tính năng AI tốt là tính năng mà khi nó hỏng, phần còn lại của sản phẩm vẫn chạy.
Dùng một bộ ngắt mạch đơn giản: nếu tỉ lệ lỗi trong năm phút vượt một ngưỡng, tự chuyển sang dự phòng trong một khoảng thời gian rồi thử lại đường chính. Cách này tránh việc mọi yêu cầu đều phải chờ hết chuỗi thử lại mới biết là hỏng.
Báo lỗi cho người dùng và giám sát cho người trực
Lỗi xảy ra là chuyện bình thường; điều khác biệt là người dùng thấy gì và nhóm biết khi nào. Trình tự gọn:
- Viết sẵn thông báo bằng chữ cho từng nhóm lỗi người dùng có thể gặp: đang quá tải xin thử lại sau ít phút, nội dung quá dài xin rút gọn, đã hết lượt dùng hôm nay.
- Không bao giờ hiện nguyên văn thông báo lỗi của nhà cung cấp lên giao diện; nó có thể chứa chi tiết kỹ thuật hay một phần cấu hình.
- Giữ lại dữ liệu người dùng đã nhập khi lỗi xảy ra, để họ bấm thử lại không phải gõ lại.
- Ghi nhật ký mỗi lỗi với mã trạng thái, nhóm lỗi, số lần đã thử, thời gian chờ, tính năng nào.
- Đặt cảnh báo cho người trực theo tỉ lệ lỗi và theo lỗi xác thực; lỗi xác thực chỉ một lần cũng đáng báo ngay.
- Sau mỗi sự cố lớn, đọc lại nhật ký, xem dự phòng có tự bật không, thông báo cho người dùng có rõ không, rồi sửa.
Trước khi mở cho người dùng, giả lập lỗi để xem hệ thống phản ứng: đặt khoá sai, đặt thời hạn chờ một giây, chặn mạng ra ngoài. Mỗi tình huống phải cho ra thông báo đúng và nhật ký đúng.
Thử lại thao tác có tác dụng phụ mà không làm hai lần
Với lời gọi chỉ sinh văn bản, thử lại nhiều nhất là tốn thêm tiền. Nhưng khi tính năng AI nằm trong một chuỗi có ghi dữ liệu, ví dụ mô hình soạn thư rồi hệ thống gửi thư, hay trợ lý gọi công cụ tạo phiếu yêu cầu, thử lại cả chuỗi sau lỗi giữa chừng có thể gửi hai thư hay tạo hai phiếu. Lỗi quá thời gian chờ là trường hợp khó nhất, vì bạn không biết phía bên kia đã làm xong hay chưa.
Cách xử lý quen thuộc trong lập trình hệ thống vẫn dùng được ở đây. Tách chuỗi thành các bước có trạng thái lưu lại: bước gọi mô hình xong thì lưu kết quả, bước gửi thư chỉ chạy khi chưa có dấu đã gửi. Mỗi thao tác ghi mang một khoá duy nhất do bạn sinh trước, như mã yêu cầu, và hàm ghi kiểm khoá đó đã tồn tại chưa trước khi làm. Thử lại khi đó chỉ chạy lại phần chưa xong.
Với lời gọi tới chính nhà cung cấp mô hình, một số hãng hỗ trợ khoá chống trùng trong tiêu đề yêu cầu cho một số loại thao tác; kiểm tài liệu xem hãng bạn có không và áp dụng cho điểm cuối nào. Còn lời gọi sinh văn bản thông thường thì thử lại chỉ đơn giản là sinh lại, và bạn dùng kết quả của lần thành công cuối.
Câu hỏi thường gặp
Thử lại có làm tốn tiền gấp đôi không?
Yêu cầu bị từ chối ngay vì hết hạn mức hay lỗi xác thực thường không bị tính phí. Nhưng yêu cầu đã được xử lý một phần rồi mới mất kết nối có thể đã bị tính. Vì vậy giới hạn số lần thử và theo dõi chi phí cùng với tỉ lệ lỗi.
Có nên thử lại khi người dùng đang chờ trên giao diện không?
Có, nhưng với trần tổng thời gian ngắn, vài chục giây là nhiều. Hết trần thì báo người dùng và cho nút thử lại. Với việc chạy nền, có thể thử lại lâu hơn và đưa vào hàng đợi xử lý sau.
Lỗi vượt độ dài ngữ cảnh nên xử lý tự động thế nào?
Đếm token trước khi gửi nếu hãng có công cụ đếm, và cắt từ phần ít quan trọng nhất: lịch sử cũ, rồi tài liệu đính kèm ít liên quan. Không bao giờ cắt câu lệnh hệ thống hay câu hỏi hiện tại. Ghi nhật ký mỗi lần phải cắt.
Làm sao kiểm thử mã xử lý lỗi mà không chờ hãng gặp sự cố thật?
Thay hàm gọi API bằng hàm giả trong kiểm thử, cho nó trả về lần lượt mã 429, 503, ngoại lệ timeout, rồi thành công. Kiểm số lần thử, thời gian chờ được tính đúng, và kết quả cuối cùng. Có thể giả lập thời gian để kiểm thử không phải chờ thật.
Có nên dùng nhiều khoá API để vượt hạn mức không?
Không nên lách hạn mức theo cách trái điều khoản của nhà cung cấp. Nếu cần hạn mức cao hơn, làm theo quy trình nâng hạn mức chính thức của hãng. Dùng các dự án riêng cho các môi trường hay tính năng khác nhau để quản lý thì khác, đó là cách tổ chức hợp lệ.
Lỗi nào cần báo động cho người trực ngay?
Lỗi xác thực, vì nó thường có nghĩa khoá bị thu hồi hoặc lộ; tỉ lệ lỗi tăng đột ngột trên mọi tính năng; chi phí theo giờ vượt mức thường lệ nhiều lần. Lỗi 429 lẻ tẻ thì chỉ cần theo dõi xu hướng.