A postmortem of three recent issues

Anthropic · 2025 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Postmortem của hạ tầng phục vụ LLM. Phần sampling và độ chính xác số học chỉ tóm tắt ngắn; trọng tâm wiki là ba lỗi chồng lên nhau, thay đổi định tuyến khuếch đại lỗi, và vì sao phát hiện chậm.

Bối cảnh

• Anthropic phục vụ Claude qua API của mình, Amazon Bedrock và Google Vertex AI, trên ba loại phần cứng (AWS Trainium, GPU NVIDIA, TPU Google). Mỗi nền tảng cần tối ưu riêng nhưng phải cho kết quả tương đương, nên mọi thay đổi hạ tầng phải kiểm trên mọi nền tảng và cấu hình.
• Từ đầu 8/2025, người dùng báo chất lượng câu trả lời giảm; ban đầu khó phân biệt với dao động phản hồi bình thường. Cuối 8/2025 báo cáo dày hơn mới mở điều tra, tìm ra ba lỗi hạ tầng độc lập. Theo Anthropic, họ không bao giờ hạ chất lượng model theo tải hay giờ trong ngày.

Thay đổi chính (ba lỗi)

1. Định tuyến sai cửa sổ ngữ cảnh (từ 5/8): một phần request Sonnet 4 bị gửi tới pool server cấu hình cho context 1M token. Ban đầu khoảng 0,8% request. Ngày 29/8, một thay đổi load balancing thường lệ vô tình tăng lượng request ngắn đi vào pool đó; giờ tệ nhất (31/8) là 16% request Sonnet 4. Định tuyến sticky nên người đã dính một lần thì các lượt sau thường dính tiếp; khoảng 30% người dùng Claude Code có ít nhất một message bị định tuyến sai. Sửa ngày 4/9, rollout xong trên các nền tảng tới 16–18/9.
2. Cấu hình sai trên server TPU (25/8): một tối ưu runtime đôi khi gán xác suất cao cho token hiếm (ví dụ chèn ký tự Thái hay Trung vào câu trả lời tiếng Anh). Rollback ngày 2/9; thêm test phát hiện ký tự bất thường vào quy trình deploy.
3. Lỗi tiềm ẩn trong compiler XLA:TPU (25–26/8): bản viết lại code sampling đã sửa một lỗi độ chính xác (bf16 lẫn fp32 làm token xác suất cao nhất đôi khi biến mất), và vì tin đã sửa gốc nên gỡ workaround từ 12/2024. Workaround đó hoá ra đang che một lỗi khác của phép approximate top-k, chỉ hiện với vài batch size và cấu hình, thay đổi theo cả việc có bật công cụ debug hay không. Rollback theo từng model (4/9, 12/9), chuyển sang exact top-k và chuẩn hoá thêm phép tính về fp32, chấp nhận tốn hiệu năng hơn một chút.

Vì sao phát hiện và xử lý chậm (theo Anthropic)

• Quy trình kiểm tra thường dùng benchmark, safety eval, metric hiệu năng, spot check và canary; nhưng eval không bắt được suy giảm người dùng thấy, một phần vì model thường tự gỡ được lỗi lẻ.
• Ba lỗi cho triệu chứng khác nhau trên nền tảng khác nhau với tỉ lệ khác nhau, nên báo cáo trông như suy giảm ngẫu nhiên, không trỏ về một nguyên nhân.
• Kiểm soát quyền riêng tư giới hạn việc engineer xem tương tác của người dùng (trừ khi được gửi làm phản hồi), nên khó tái hiện.
• Khi báo cáo tăng vọt ngày 29/8, không ai nối ngay với thay đổi load balancing cùng ngày.

Hành động khắc phục

• Eval nhạy hơn, phân biệt được bản đúng và bản hỏng; chạy eval chất lượng liên tục trên hệ production thật, không chỉ trước khi deploy.
• Công cụ debug nhanh hơn cho phản hồi từ cộng đồng mà vẫn giữ quyền riêng tư.
• Coi phản hồi người dùng (/bug, nút thumbs down) là một tín hiệu giám sát chính thức.

Bài học cho SWE

• Một thay đổi định tuyến "thường lệ" có thể khuếch đại một lỗi nhỏ có sẵn từ 0,8% lên 16%; khi metric xấu đi, đối chiếu với mọi thay đổi gần đó, kể cả thay đổi không đụng tới code (Deploy và release an toàn).
• Routing sticky làm tác động dồn lên một nhóm người dùng: tỉ lệ request bị lỗi thấp nhưng tỉ lệ người dùng bị ảnh hưởng cao.
• Gỡ workaround khi "đã sửa gốc" là một thay đổi rủi ro: workaround có thể đang che lỗi khác (Sự cố và postmortem).
• Với hệ mà lỗi biểu hiện là chất lượng đầu ra giảm chứ không phải lỗi 5xx, metric hạ tầng thông thường không đủ; cần kiểm tra chất lượng chạy liên tục trên production (Observability và monitoring).
• Nhiều lỗi chồng nhau thì triệu chứng mâu thuẫn; tách theo nền tảng và theo thời điểm thay đổi giúp khoanh vùng.

Liên quan

• Hạ tầng phục vụ LLM inference
• Sự cố và postmortem · Deploy và release an toàn · Observability và monitoring