X · Production operations

Giữ dịch vụ ổn định khi tải tăng hoặc worker lỗi

Các cơ chế chống sập dây chuyền, giảm tải chủ động (load shedding) và phục hồi khi lưu lượng tăng đột biến hoặc worker gặp sự cố.

LESSON ID reliability GROUP Kiến trúc Inference

1Định nghĩa

Reliability engineering trong hệ thống suy luận là thiết kế các cơ chế giữ cho dịch vụ hoạt động ổn định khi lưu lượng tăng vọt hoặc khi một số worker GPU gặp lỗi phần cứng, tràn bộ nhớ hay đứt kết nối. Thách thức riêng của LLM là mỗi request đang chạy đều giữ trạng thái KV cache lớn và có thể đã stream một nửa câu trả lời về phía người dùng.

Hệ thống tự bảo vệ qua nhiều lớp: tạo áp lực ngược (backpressure) và cắt tải sớm (load shedding) ở gateway khi hàng đợi đầy để tránh sập toàn cụm; tự động cô lập replica lỗi ở router; rút tải êm (graceful drain) ở control plane khi thu hồi máy; và quy định rõ chính sách thử lại (retry) để không làm lặp chữ hay nhân đôi tải lên các máy còn sống.

Ví dụ đời thường: Kỹ thuật giữ độ tin cậy (reliability) giống như hệ thống cầu chì tự ngắt và điều tiết giao thông ở cửa hầm đường bộ. Khi lượng xe đổ về quá đông hoặc một làn xe trong hầm gặp sự cố, đèn tín hiệu ngoài cửa hầm sẽ điều tiết nhịp xe vào chậm lại và chuyển làn tự động để các xe đã vào trong hầm vẫn chạy thoát ra an toàn, tránh kẹt cứng toàn bộ đường hầm.

2Luồng

Sơ đồ luồng (4 bước)

Phát hiện lỗi hoặc quá tải
Health và deadline/counters báo trạng thái.
Hạn chế công việc mới
Admission và router phản ứng.
Xử lý request đang chạy
Dọn state hoặc quyết định retry rõ ràng.
Phục hồi capacity
Restart/warmup và chỉ nhận traffic khi ready.

Mã Mermaid

flowchart TD
  step1["Phát hiện lỗi hoặc quá tải"]
  step2["Hạn chế công việc mới"]
  step3["Xử lý request đang chạy"]
  step4["Phục hồi capacity"]
  step1 --> step2
  step2 --> step3
  step3 --> step4

3Giải pháp

Dùng readiness, bounded queue, cancellation và canary. Giữ reserve capacity nếu yêu cầu dịch vụ cần chịu lỗi một worker.

Sau khi đã stream, retry có thể tạo phần text khác hoặc lặp. Giao thức client cần xác định request ID, tình trạng đã trả và cách thông báo lỗi.

4Profiling

Recovery time và affected requests
Tắt thử worker trong test; đo timeouts, work bị lặp và thời gian đạt capacity lại.
Error budget
Theo dõi mức lỗi so với mục tiêu dịch vụ, phân loại nguyên nhân.

Mẹo đo lường: ghim số liệu trên workload thật, ghi cả p50/p95/p99 thay vì chỉ trung bình, và luôn ghi lại điều kiện chạy (batch, cache, đồng thời, phần cứng) trước và sau khi tối ưu. Số đo thiếu điều kiện chạy thì không so sánh được.

5Ví dụ

Worker hết memory

Ngừng chuyển traffic, dọn/restart và warmup thay vì tiếp tục nhận request vào máy chưa phục hồi.

Burst traffic

Từ chối sớm một phần yêu cầu có thể giữ latency và khả năng phục vụ của những request đang chạy.

6Thuật ngữ

Graceful drain: Ngừng nhận mới và hoàn tất hoặc hủy có kiểm soát công việc đang chạy.
Retry budget: Giới hạn số và tổng thời gian thử lại để không nhân tải khi hệ thống lỗi.

Glossary (4)

Latency: Thời gian chờ để nhận một kết quả hoặc một bước kết quả.
Warmup: Chạy chuẩn bị để hoàn tất khởi tạo, compilation/capture hoặc ổn định execution trước đo.
Worker: Tiến trình hoặc máy thực hiện một phần công việc của hệ thống.
Context: Chuỗi token trước vị trí hiện tại mà model được phép sử dụng.

7Bài liên quan

Quản lý vòng đời các bản sao mô hình Cổng tiếp nhận và kiểm soát yêu cầu Theo dõi và tìm nguyên nhân request chậm

8Nguồn

TensorRT-LLM: tích hợp engine với dịch vụ