**Báo cáo hậu sự cố về ba vấn đề gần đây**
Từ tháng 8 đến đầu tháng 9, ba lỗi cơ sở hạ tầng đã làm giảm chất lượng phản hồi của Claude một cách gián đoạn. Chúng tôi đã khắc phục những vấn đề này và muốn giải thích những gì đã xảy ra.
Vào đầu tháng 8, một số người dùng bắt đầu báo cáo phản hồi kém chất lượng từ Claude. Những báo cáo ban đầu này khó phân biệt với sự biến động thông thường trong phản hồi của người dùng. Đến cuối tháng 8, tần suất và tính liên tục ngày càng tăng của các báo cáo này đã thúc đẩy chúng tôi mở một cuộc điều tra, dẫn đến việc phát hiện ra ba lỗi cơ sở hạ tầng riêng biệt.
Nói một cách rõ ràng: Chúng tôi không bao giờ giảm chất lượng mô hình do nhu cầu, thời gian trong ngày hoặc tải máy chủ. Các vấn đề mà người dùng báo cáo chỉ do lỗi cơ sở hạ tầng.
Chúng tôi nhận ra rằng người dùng mong đợi chất lượng nhất quán từ Claude, và chúng tôi duy trì một tiêu chuẩn cực kỳ cao để đảm bảo các thay đổi cơ sở hạ tầng không ảnh hưởng đến đầu ra của mô hình. Trong các sự cố gần đây, chúng tôi đã không đáp ứng được tiêu chuẩn đó. Bài phân tích sau sự cố này giải thích những gì đã sai, tại sao việc phát hiện và khắc phục mất nhiều thời gian hơn mong muốn, và những gì chúng tôi đang thay đổi để ngăn chặn các sự cố tương tự trong tương lai.
Chúng tôi thường không chia sẻ chi tiết kỹ thuật ở mức độ này về cơ sở hạ tầng của mình, nhưng phạm vi và độ phức tạp của những vấn đề này đã biện minh cho một lời giải thích toàn diện hơn.
Chúng tôi cung cấp Claude cho hàng triệu người dùng thông qua API nội bộ, Amazon Bedrock và Google Cloud's Vertex AI. Chúng tôi triển khai Claude trên nhiều nền tảng phần cứng, cụ thể là AWS Trainium, GPU NVIDIA và Google TPU. Cách tiếp cận này cung cấp dung lượng và phân bố địa lý cần thiết để phục vụ người dùng trên toàn thế giới.
Mỗi nền tảng phần cứng có các đặc điểm khác nhau và yêu cầu tối ưu hóa cụ thể. Bất chấp những biến thể này, chúng tôi có các tiêu chuẩn tương đương nghiêm ngặt cho việc triển khai mô hình. Mục tiêu của chúng tôi là người dùng sẽ nhận được phản hồi chất lượng như nhau bất kể nền tảng nào phục vụ yêu cầu của họ. Sự phức tạp này có nghĩa là bất kỳ thay đổi cơ sở hạ tầng nào cũng yêu cầu xác nhận cẩn thận trên tất cả các nền tảng và cấu hình.
Bản chất chồng chéo của những lỗi này khiến việc chẩn đoán trở nên đặc biệt khó khăn. Lỗi đầu tiên được giới thiệu vào ngày 5 tháng 8, ảnh hưởng đến khoảng 0,8% yêu cầu gửi đến Sonnet 4. Hai lỗi nữa phát sinh từ các bản triển khai vào ngày 25 và 26 tháng 8.
Mặc dù tác động ban đầu có hạn, một thay đổi cân bằng tải vào ngày 29 tháng 8 bắt đầu làm tăng lưu lượng bị ảnh hưởng. Điều này khiến nhiều người dùng gặp vấn đề hơn trong khi những người khác vẫn thấy hiệu suất bình thường, tạo ra các báo cáo gây nhầm lẫn và mâu thuẫn.
Dưới đây, chúng tôi mô tả ba lỗi đã gây ra sự suy giảm, thời điểm chúng xảy ra và cách chúng tôi khắc phục:
Vào ngày 5 tháng 8, một số yêu cầu Sonnet 4 đã bị định tuyến sai đến các máy chủ được cấu hình cho cửa sổ ngữ cảnh 1M token sắp tới. Lỗi này ban đầu ảnh hưởng đến 0,8% yêu cầu. Vào ngày 29 tháng 8, một thay đổi cân bằng tải thông thường đã vô tình làm tăng số lượng yêu cầu ngữ cảnh ngắn được định tuyến đến các máy chủ ngữ cảnh 1M. Vào giờ bị ảnh hưởng nặng nhất ngày 31 tháng 8, 16% yêu cầu Sonnet 4 đã bị ảnh hưởng.
Khoảng 30% của Claude
Người dùng Claude đã gửi yêu cầu trong giai đoạn này có ít nhất một tin nhắn bị định tuyến sai loại máy chủ, dẫn đến phản hồi bị suy giảm chất lượng. Trên Amazon Bedrock, lưu lượng bị định tuyến sai đạt đỉnh 0,18% tổng số yêu cầu Sonnet 4 từ ngày 12 tháng 8. Việc định tuyến sai ảnh hưởng đến dưới 0,0004% yêu cầu trên Vertex AI của Google Cloud trong khoảng thời gian từ 27 tháng 8 đến 16 tháng 9.
Tuy nhiên, một số người dùng bị ảnh hưởng nghiêm trọng hơn vì cơ chế định tuyến của chúng tôi là "cố định". Điều này có nghĩa là khi một yêu cầu được phục vụ bởi máy chủ sai, các yêu cầu tiếp theo có khả năng cao cũng được phục vụ bởi cùng máy chủ sai đó.
Giải pháp: Chúng tôi đã sửa logic định tuyến để đảm bảo các yêu cầu ngữ cảnh ngắn và dài được chuyển đến đúng cụm máy chủ. Chúng tôi triển khai bản sửa lỗi vào ngày 4 tháng 9. Việc triển khai lên nền tảng độc quyền và Vertex AI của Google Cloud hoàn tất vào ngày 16 tháng 9, và lên AWS Bedrock vào ngày 18 tháng 9.
Vào ngày 25 tháng 8, chúng tôi đã triển khai một cấu hình sai lên máy chủ TPU của Claude API gây ra lỗi trong quá trình tạo token. Một vấn đề phát sinh từ tối ưu hóa hiệu suất thời gian chạy đôi khi gán xác suất cao cho các token hiếm khi được tạo ra dựa trên ngữ cảnh, ví dụ như tạo ra ký tự Thái Lan hoặc Trung Quốc để đáp lại các câu hỏi tiếng Anh, hoặc tạo ra lỗi cú pháp rõ ràng trong mã. Một nhóm nhỏ người dùng đặt câu hỏi bằng tiếng Anh có thể thấy "สวัสดี" ở giữa phản hồi.
Lỗi này ảnh hưởng đến các yêu cầu gửi đến Opus 4.1 và Opus 4 từ ngày 25-28 tháng 8, và các yêu cầu gửi đến Sonnet 4 từ ngày 25 tháng 8 đến 2 tháng 9. Các nền tảng bên thứ ba không bị ảnh hưởng bởi vấn đề này.
Giải pháp: Chúng tôi đã xác định vấn đề và hoàn nguyên thay đổi vào ngày 2 tháng 9. Chúng tôi đã thêm các bài kiểm tra phát hiện đầu ra ký tự bất thường vào quy trình triển khai của mình.
Vào ngày 25 tháng 8, chúng tôi đã triển khai mã để cải thiện cách Claude chọn token trong quá trình tạo văn bản. Thay đổi này vô tình kích hoạt một lỗi tiềm ẩn trong trình biên dịch XLA:TPU, được xác nhận đã ảnh hưởng đến các yêu cầu gửi đến Claude Haiku 3.5.
Chúng tôi cũng tin rằng điều này có thể đã ảnh hưởng đến một phần nhỏ Sonnet 4 và Opus 3 trên Claude API. Các nền tảng bên thứ ba không bị ảnh hưởng bởi vấn đề này.
Giải pháp: Chúng tôi lần đầu tiên quan sát thấy lỗi ảnh hưởng đến Haiku 3.5 và hoàn nguyên nó vào ngày 4 tháng 9. Sau đó, chúng tôi nhận thấy báo cáo từ người dùng về vấn đề với Opus 3 tương thích với lỗi này và hoàn nguyên nó vào ngày 12 tháng 9. Sau khi điều tra sâu rộng, chúng tôi không thể tái tạo lỗi này trên Sonnet 4 nhưng quyết định hoàn nguyên nó vì lý do thận trọng.
Đồng thời, chúng tôi đã (a) làm việc với nhóm XLA:TPU để sửa lỗi trình biên dịch và (b) triển khai bản sửa lỗi sử dụng top-k chính xác với độ chính xác cao hơn. Để biết chi tiết, hãy xem phần phân tích chuyên sâu bên dưới.
Để minh họa độ phức tạp của các vấn đề này, đây là cách lỗi trình biên dịch XLA biểu hiện và tại sao nó đặc biệt khó chẩn đoán.
Khi Claude tạo văn bản, nó tính toán xác suất cho mỗi từ tiếp theo có thể, sau đó chọn ngẫu nhiên một mẫu từ phân phối xác suất này. Chúng tôi
Sử dụng "top-p sampling" để tránh các đầu ra vô nghĩa—chỉ xem xét những từ có xác suất tích lũy đạt đến một ngưỡng (thường là 0,99 hoặc 0,999). Trên TPU, các mô hình của chúng tôi chạy trên nhiều chip, với các phép tính xác suất diễn ra ở những vị trí khác nhau. Để sắp xếp các xác suất này, chúng tôi cần phối hợp dữ liệu giữa các chip, điều này rất phức tạp.[2]
Vào tháng 12 năm 2024, chúng tôi phát hiện ra rằng triển khai TPU của mình đôi khi bỏ qua token có xác suất cao nhất khi nhiệt độ bằng 0. Chúng tôi đã triển khai một giải pháp tạm thời để khắc phục trường hợp này.
Nguyên nhân gốc rễ liên quan đến số học chính xác hỗn hợp. Các mô hình của chúng tôi tính toán xác suất token tiếp theo ở định dạng bf16 (dấu phẩy động 16-bit). Tuy nhiên, bộ xử lý vector là fp32-native, vì vậy trình biên dịch TPU (XLA) có thể tối ưu hóa thời gian chạy bằng cách chuyển đổi một số phép toán sang fp32 (32-bit). Quá trình tối ưu hóa này được bảo vệ bởi cờ xla_allow_excess_precision, mặc định là true.
Điều này gây ra sự không khớp: các phép toán lẽ ra phải thống nhất về token có xác suất cao nhất lại chạy ở các mức độ chính xác khác nhau. Sự không khớp về độ chính xác có nghĩa là chúng không thống nhất được token nào có xác suất cao nhất. Điều này khiến token có xác suất cao nhất đôi khi biến mất hoàn toàn khỏi quá trình xem xét.
Vào ngày 26 tháng 8, chúng tôi đã triển khai một bản viết lại mã lấy mẫu để khắc phục các vấn đề về độ chính xác và cải thiện cách xử lý xác suất ở ngưỡng đạt đến top-p. Nhưng khi sửa các vấn đề này, chúng tôi lại phát hiện ra một vấn đề phức tạp hơn.
Bản sửa lỗi của chúng tôi đã loại bỏ giải pháp tạm thời từ tháng 12 vì chúng tôi tin rằng đã giải quyết được nguyên nhân gốc rễ. Điều này dẫn đến một lỗi sâu hơn trong phép toán approximate top-k—một tối ưu hóa hiệu suất giúp nhanh chóng tìm ra các token có xác suất cao nhất.[3] Phép xấp xỉ này đôi khi trả về kết quả hoàn toàn sai, nhưng chỉ xảy ra với một số kích thước batch và cấu hình mô hình nhất định. Giải pháp tạm thời từ tháng 12 đã vô tình che giấu vấn đề này.
Hành vi của lỗi này không nhất quán một cách khó chịu. Nó thay đổi tùy thuộc vào các yếu tố không liên quan như các phép toán chạy trước hoặc sau nó, một
