Kiểm tra sức khỏe của chúng tôi đã khởi động lại một máy chủ mô hình đang hoạt động bình thường tám lần trong một ngày
Vận hành
Vào ngày 22 tháng 7, một bộ giám sát đã khởi động lại máy chủ mô hình cục bộ của chúng tôi tám lần. Không có lần khởi động lại nào trong số đó do sự cố sập. Chính bước kiểm tra được thiết kế để giữ cho mô hình hoạt động lại là nguyên nhân khiến nó bị tắt.
Chuyện gì đã xảy ra
Máy chủ mô hình chạy vLLM trên một máy NVIDIA GB10 và tạo ra khoảng 8 token mỗi giây cho một yêu cầu duy nhất. Cứ năm phút một lần, bộ giám sát gửi cho máy chủ một yêu cầu trò chuyện thực tế và chờ tối đa 45 giây để nhận câu trả lời. Năm lần kiểm tra thất bại liên tiếp đồng nghĩa với việc máy chủ bị treo, và bộ giám sát sẽ khởi động lại nó. Một lần khởi động lại khiến mô hình bị gián đoạn trong vài phút trong khi khoảng 19 GB trọng số được nạp lại.
Hôm đó, một công việc hàng loạt đã giữ hai đến bốn yêu cầu bận trên máy chủ trong nhiều phút mỗi lần. Yêu cầu của bộ giám sát phải xếp hàng phía sau chúng, hết thời gian chờ và bị tính là thất bại. Sau năm lần kiểm tra như vậy, một máy chủ đang hoạt động bình thường đã bị khởi động lại. Chúng tôi có một tệp cờ "bận" mà bộ giám sát tôn trọng, nhưng công việc hàng loạt không bao giờ đặt cờ này.
Cách một lần khởi động lại sai dẫn đến lần tiếp theo
Mỗi lần khởi động lại đều làm thất bại các yêu cầu đang xử lý với lỗi 500 ("không thể lên lịch các tương lai mới sau khi tắt"). Một bộ giám sát thứ hai đếm các lỗi 500 và khởi động lại máy chủ khi có quá nhiều lỗi, và càng thấy nhiều lỗi thì nó càng hành động sớm hơn. Vì vậy, mỗi lần khởi động lại sai đều khiến lần tiếp theo xảy ra sớm hơn. Tổng cộng, bốn bộ giám sát riêng biệt có thể khởi động lại máy chủ đó, theo các bộ hẹn giờ 5, 10, 15 và 30 phút.
Quy tắc chúng tôi rút ra từ đó
Một bước kiểm tra sức khỏe không được sử dụng chính tài nguyên mà nó bảo vệ. Tài nguyên khan hiếm của máy chủ mô hình là các chỗ trống cho các yêu cầu đang xử lý. Một bước kiểm tra chiếm một trong các chỗ trống đó, hoặc chờ một chỗ trống, sẽ trở thành một phần của tải mà nó cần đánh giá. Hãy kiểm tra một cách tiết kiệm, và chỉ khởi động lại khi bạn có thể chứng minh rằng máy chủ bị kẹt.
Bước kiểm tra thay thế
vLLM công bố các bộ đếm riêng của nó tại /metrics. Bước kiểm tra mới đọc các bộ đếm này trước tiên:
- Các yêu cầu đang chạy và động cơ đang tiến triển: bình thường và bận. Không gửi yêu cầu thử nghiệm.
- Các yêu cầu đang chạy nhưng không có tiến triển giữa hai lần đọc: bị kẹt. Đây là trường hợp vẫn dẫn đến khởi động lại.
- Không có gì đang chạy: nhàn rỗi. Chỉ khi đó bước kiểm tra mới yêu cầu một câu trả lời ngắn, mà một động cơ nhàn rỗi sẽ cung cấp ngay lập tức.
Phiên bản đầu tiên đếm số token được tạo ra như là tiến triển. Nó đã vượt qua tám bài kiểm tra, và trong lần chạy thực tế đầu tiên, nó phát hiện máy chủ đang bận và bình thường: 2 yêu cầu đang chạy, 107 token mới giữa hai lần đọc.
Những gì chúng tôi đã thay đổi kể từ đó
- Đếm số bước chạy, không đếm token đầu ra. Trong khi vLLM đọc một prompt dài, nó không tạo ra token đầu ra trong một khoảng thời gian nhưng vẫn thực hiện các bước. Việc đếm số bước (số lượng của vllm:iteration_tokens_total) giúp một prompt dài không bị nhầm lẫn với một máy chủ bị treo.
- Hai lần chờ trước khi báo "treo", để một khoảng tạm dừng ngắn không bị tính là lỗi.
- Một lần khởi động lại giữa hai lần đọc được phát hiện nhờ thời gian khởi động tiến trình trong cùng các số liệu đo lường; khi đó, bước kiểm tra sẽ yêu cầu một phản hồi thay vì so sánh các bộ đếm từ hai tiến trình khác nhau.
- Một proxy chỉ được kiểm tra qua /models. Phía sau một proxy cân bằng tải theo số kết nối ít nhất, mỗi lần đọc /metrics có thể đến từ một backend khác nhau, như chúng tôi đã phát hiện khi chạy một bản sao của mô hình trên mỗi máy trong hai máy. Các backend được kiểm tra trực tiếp.
Sự khác biệt rất dễ thấy. Khi chúng tôi viết ghi chú này, cả hai máy chủ mô hình của chúng tôi đều đang chạy 12 yêu cầu mỗi máy, đạt mức giới hạn. Một yêu cầu thử nghiệm sẽ phải chờ trong hàng đợi. Bước kiểm tra mới báo cáo cả hai máy chủ đều bận và hoạt động bình thường, với tốc độ 126 và 101 token mỗi giây, mà không cần gửi thêm yêu cầu nào.
Factory Floor 1.0.2 cung cấp bước kiểm tra này trong models/llm-health.py, kèm theo các bài kiểm tra cho máy chủ nhàn rỗi, bận, treo và đã khởi động lại, một máy chủ không có số liệu đo lường, một proxy và một backend bị chết.