Độ trễ và giới hạn tốc độ: yếu tố ít ai tính khi chọn model

Tính năng trả lời tự động trên website chạy mượt lúc bạn demo cho sếp xem, nhưng đến giờ cao điểm buổi tối, khách hàng thật lại thấy vòng xoay chờ kéo dài nhiều giây rồi bỏ đi giữa chừng trước khi kịp đọc câu trả lời. Vấn đề không nằm ở chất lượng model mà nằm ở hai yếu tố ít ai để ý khi chọn model: độ trễ thật đo từ vị trí người dùng của bạn, và giới hạn số lượt gọi mà nhà cung cấp cho phép mỗi phút. Bài này giúp bạn đo đúng, hiểu đúng và có cách xử lý thực tế cho cả hai vấn đề này.

Độ trễ thật gồm những phần nào

Khi nói "model chậm", thực tế có ba khoảng thời gian cộng lại mà ít người tách riêng ra để hiểu rõ. Thứ nhất là thời gian dữ liệu đi từ máy người dùng đến máy chủ của nhà cung cấp model và ngược lại, phụ thuộc vào khoảng cách địa lý và chất lượng đường truyền. Thứ hai là thời gian tới token đầu tiên, tức là khoảng chờ từ lúc gửi yêu cầu đến lúc nhận được ký tự phản hồi đầu tiên — đây thường là phần chiếm nhiều thời gian nhất và bị ảnh hưởng bởi độ dài yêu cầu đầu vào cùng mức độ bận rộn của model lúc đó. Thứ ba là tốc độ sinh chữ sau khi đã bắt đầu trả lời, quyết định câu trả lời dài sẽ hiện ra nhanh hay chậm.

Tuy ba phần này cộng lại tạo nên trải nghiệm chờ đợi mà người dùng cảm nhận được, nhưng phần bạn có thể cải thiện dễ nhất lại là cách hiển thị, chứ không phải bản thân tốc độ model. Một câu trả lời hiện dần từng chữ theo kiểu streaming luôn cảm thấy nhanh hơn nhiều so với việc bắt người dùng chờ toàn bộ câu trả lời xong xuôi rồi mới hiện lên cùng lúc, dù tổng thời gian xử lý thực tế của cả hai cách gần như bằng nhau.

Cách đo độ trễ thật từ Việt Nam

Đừng tin vào con số độ trễ được quảng cáo chung chung, vì con số đó thường đo từ trung tâm dữ liệu đặt gần nhà cung cấp nhất, không phản ánh đúng trải nghiệm người dùng thật của bạn tại Việt Nam. Cách đáng tin cậy nhất là tự gửi hàng chục lượt gọi thử từ đúng vị trí máy chủ ứng dụng của bạn đang đặt, vào cả giờ thấp điểm lẫn giờ cao điểm, rồi ghi lại thời gian tới token đầu tiên của từng lượt để lấy trung bình và điểm cao nhất (thường gọi là mức p95 hoặc p99), vì chính những lượt chậm nhất mới là thứ khiến khách hàng khó chịu và bỏ đi, không phải mức trung bình.

Hiểu hạn mức gọi theo phút và cách nó tăng dần theo tài khoản

Ngoài độ trễ, mỗi nhà cung cấp còn giới hạn số lượt gọi và số token bạn có thể gửi trong một phút, thường gọi là hạn mức theo số yêu cầu mỗi phút và số token mỗi phút. Hạn mức này không cố định mãi mãi mà thường tăng dần một cách tự động theo lịch sử sử dụng và uy tín thanh toán của tài khoản — tài khoản mới thường bắt đầu ở mức thấp, rồi được nâng lên khi hệ thống ghi nhận bạn sử dụng ổn định trong một khoảng thời gian.

Đây chính là lý do vì sao một tính năng chạy êm trong giai đoạn thử nghiệm với vài chục lượt gọi mỗi ngày có thể đột ngột báo lỗi "vượt hạn mức" khi ra mắt chính thức với lượng người dùng tăng vọt. Nếu bạn biết trước ngày ra mắt sẽ có lượng truy cập lớn, hãy chủ động liên hệ nhà cung cấp để xin nâng hạn mức trước, thay vì để đến sát ngày mới phát hiện ra tài khoản chưa đủ điều kiện phục vụ lưu lượng dự kiến. Quy trình xin nâng hạn mức ở hầu hết nhà cung cấp thường mất từ vài ngày đến khoảng một tuần để được xét duyệt, nên nếu bạn có kế hoạch ra mắt hoặc chạy chiến dịch quảng bá lớn, hãy chuẩn bị việc này sớm thay vì để sát ngày mới nhớ ra.

Cách tính số lượt gọi tối đa hệ thống chịu được mỗi phút

Công thức đơn giản để ước lượng: lấy hạn mức token mỗi phút của tài khoản, chia cho số token trung bình một lượt gọi tiêu tốn (bao gồm cả token đầu vào và đầu ra), sẽ ra số lượt gọi tối đa hệ thống xử lý được trong một phút trước khi bị từ chối. Ví dụ nếu hạn mức là vài trăm nghìn token mỗi phút và mỗi lượt gọi tiêu tốn trung bình một nghìn token, hệ thống chỉ chịu được vài trăm lượt gọi đồng thời mỗi phút, con số này có thể thấp hơn nhiều so với lượng truy cập thực tế vào giờ cao điểm nếu sản phẩm của bạn phát triển nhanh.

• Thêm hàng đợi để xếp các yêu cầu vượt hạn mức chờ xử lý thay vì bị từ chối thẳng, giúp trải nghiệm mượt hơn khi có đợt tăng đột biến ngắn hạn.
• Có model dự phòng từ nhà cung cấp khác để chuyển tạm sang khi hạn mức chính bị chạm ngưỡng, tránh gián đoạn hoàn toàn dịch vụ.
• Theo dõi sát tỷ lệ lỗi vượt hạn mức hằng ngày để phát hiện sớm xu hướng tăng trưởng vượt quá khả năng phục vụ hiện tại, chủ động xin nâng hạn mức trước khi bị động.

Kỹ thuật giảm cảm giác chờ cho người dùng

Không phải lúc nào cũng có thể làm model trả lời nhanh hơn, nhưng luôn có cách làm người dùng cảm thấy đỡ phải chờ hơn. Hiển thị câu trả lời theo kiểu chảy dần từng chữ (streaming) là kỹ thuật hiệu quả nhất và tương đối dễ triển khai, vì nó cho người dùng thấy hệ thống đang "làm việc" ngay lập tức thay vì một màn hình trống trơn kèm vòng xoay chờ vô định.

Bên cạnh đó, với những câu hỏi thường gặp và lặp lại nhiều, bạn có thể lưu sẵn câu trả lời đã tính toán trước (cache) để trả về gần như tức thì mà không cần gọi model lại từ đầu. Với các tác vụ không cần phản hồi ngay lập tức, ví dụ tóm tắt tài liệu dài hay phân tích báo cáo, hãy xử lý ở chế độ nền và thông báo cho người dùng khi xong, thay vì bắt họ ngồi chờ trực tiếp trên màn hình — cách tiếp cận này giúp bạn thoải mái chọn model mạnh hơn mà không lo ảnh hưởng đến cảm nhận tốc độ của người dùng.

Checklist trước khi ra mắt tính năng cần phản hồi nhanh

Độ trễ và hạn mức gọi là hai yếu tố dễ bị bỏ qua khi so sánh model chỉ dựa trên bảng giá và điểm benchmark, nhưng lại là thứ quyết định trực tiếp trải nghiệm thật của khách hàng vào đúng lúc hệ thống của bạn bận rộn nhất. Nếu bạn đang cân nhắc giữa việc gọi thẳng nhà cung cấp hay đi qua một lớp trung gian để có thêm phương án dự phòng, bài Cổng API trung gian hay gọi thẳng nhà cung cấp model sẽ giúp bạn cân đối thêm giữa độ trễ và khả năng chống chịu sự cố. Và nếu hệ thống của bạn còn xử lý nhiều tác vụ nền phía sau tính năng phản hồi nhanh này, đừng bỏ qua bài Hạ tầng chạy AI Agent: hàng đợi, retry và xử lý lỗi để dựng đúng cơ chế hàng đợi ngay từ đầu.