Anthropic chia sẻ cách tối ưu hóa giúp claude.ai và ứng dụng desktop nhanh gấp 3 lần

Tháng 8 vừa qua, chúng tôi đã tăng tốc trải nghiệm người dùng cốt lõi của claude.ai và ứng dụng Claude trên máy tính lên khoảng 3 lần chỉ trong một đợt chạy nước rút kéo dài hai tuần. Người dùng đã phản hồi rằng ứng dụng chạy chậm, và họ hoàn toàn đúng. Chúng tôi đã vận hành mọi thứ từ một kênh Slack duy nhất, với Claude tham gia vào mọi luồng thảo luận.

Chúng tôi tập trung vào bốn hành trình chiếm 95% hoạt động của người dùng. Ở phân vị thứ 75, thời gian để tải một trang có thể nhập liệu trên claude.ai từ trạng thái mới đã giảm từ 3,1 giây xuống 0,55 giây, thời gian bắt đầu phiên Claude Code mới giảm từ 0,8 giây xuống 0,3 giây, và thời gian tải phiên làm việc trên đám mây của Claude Cowork giảm từ 2,6 giây xuống 0,73 giây. Tổng cộng, chúng tôi ước tính điều này giúp tiết kiệm hàng chục nghìn giờ chờ đợi của người dùng mỗi ngày.

Chúng tôi đã sử dụng Claude Tag (bản beta), chạy một mô hình nghiên cứu nội bộ có hiệu năng tương đương với Opus 5.5. Claude đã tìm ra các điểm nghẽn, xây dựng các bài kiểm chuẩn (benchmark), triển khai các cải tiến và theo dõi mọi đợt phát hành. Chúng tôi điều hướng bằng cách đặt mục tiêu, đưa ra các đánh đổi và phê duyệt mọi thay đổi. Với cách tiếp cận đó, chúng tôi đã hợp nhất hơn ba nghìn thay đổi mà không gặp phải bất kỳ sự cố nào ảnh hưởng đến khách hàng hay cần phải hoàn tác. Bài viết này đề cập đến những gì chúng tôi đã triển khai, cách chúng tôi đo lường và vòng lặp mà chúng tôi đã xây dựng cùng Claude để thực hiện điều đó một cách an toàn.

TÓM TẮT

Trước đợt chạy nước rút, chúng tôi đã tạo một kênh Slack với các hướng dẫn thường trực sau:

@Claude Nhiệm vụ của bạn là hỗ trợ mọi vấn đề liên quan đến hiệu năng của trang web claude.ai và ứng dụng máy tính. Trách nhiệm của bạn bao gồm theo dõi các đợt triển khai để phát hiện sự suy giảm hiệu năng, đánh giá độ chính xác và tính toàn diện của hệ thống đo từ xa hiện có, duy trì các bảng điều khiển quan sát được quản lý tốt, chủ động triển khai các giải pháp cho các vấn đề đã quan sát được và các vấn đề dễ xử lý, đề xuất các cơ hội dự án hiệu năng, và giao tiếp với các đồng nghiệp là con người. […] Mục tiêu cuối cùng của kênh này là giúp bạn trở nên tự chủ nhất có thể, nhưng hiện tại chúng tôi biết điều đó vẫn chưa khả thi.

Chúng tôi đã yêu cầu Claude phân tích dữ liệu sử dụng thông qua máy chủ Datadog MCP. Nó đã xác định bốn hành trình người dùng có tác động lớn nhất: khởi chạy ứng dụng, bắt đầu cuộc trò chuyện, tải cuộc trò chuyện hiện có và gửi tin nhắn. Giữa phiên bản web và máy tính, cũng như trên các sản phẩm của chúng tôi, những hành trình đó tạo ra mười ba phép đo riêng biệt. Để thiết lập các chỉ số cơ sở, chúng tôi đã thêm công cụ đo lường cho đến khi chúng có thể so sánh trực tiếp: mỗi hành trình bắt đầu bằng một tương tác của người dùng, kết thúc khi kết quả được hiển thị, và phân tách rõ ràng công việc của máy khách (client) và máy chủ (server).

Chúng tôi bắt đầu đợt chạy nước rút với danh sách khoảng hai mươi dự án được chọn lọc kỹ lưỡng, mỗi dự án nhắm vào một hành trình cụ thể. Claude đã ước tính tác động của từng dự án theo mili giây, và chúng tôi tổng hợp các ước tính đó để đặt mục tiêu cho đợt chạy nước rút. Một số dự án khá lớn, nhưng chúng tôi nghĩ rằng mình có thể hoàn thành hầu hết trong vòng hai tuần.

Chúng tôi đã đạt được mười hai trên mười ba mục tiêu vào ngày thứ ba.

Các dự án theo kế hoạch đã hoàn thành sớm. Để khởi chạy nhanh hơn, chúng tôi đã tích hợp sẵn một trình soạn thảo tĩnh (static composer) vào HTML để người dùng có thể nhập liệu trong khi React đang khởi tạo, và biên dịch trước bộ nhớ đệm mã V8 để tiến trình chính của ứng dụng máy tính không phải biên dịch lại từ đầu. Để điều hướng nhanh hơn, chúng tôi giữ trình soạn thảo luôn được gắn (mounted) giữa các cuộc trò chuyện, tải trước các phiên khi người dùng di chuột qua và cắt giảm 90% việc hiển thị lại (re-render) thanh bên.

Chúng tôi cũng để dành không gian để Claude xác định các cơ hội và đề xuất các luồng công việc mới. Những luồng công việc đó nhanh chóng phát triển thành các dự án hoàn chỉnh, vượt xa các mục tiêu ban đầu của chúng tôi. Vì vậy, chúng tôi đặt ra các mục tiêu mới, sau đó tìm kiếm thêm những thứ để đo lường:

@Claude chúng ta đã tài trợ cho gần như mọi dự án trong danh sách ban đầu và hơn thế nữa. hãy làm mới lại […] chúng ta chưa khám phá những gì, chúng ta có thể tối ưu hóa (hill climb) ở đâu, đâu là cơ hội lớn nhất vào lúc này? […] tôi sẵn sàng đón nhận những ý tưởng ĐIÊN RỒ

MỌI THỨ ĐỀU CÓ THỂ TỐI ƯU HÓA (HILL CLIMB)

Ngay từ đầu, chúng tôi biết mình muốn lặp lại nhanh hơn nhịp độ triển khai. Claude có thể làm việc không đồng bộ trong nhiều giờ, thậm chí qua đêm, và chúng tôi muốn để nó xác thực các nguyên mẫu của mình mà không cần chờ đợi kết quả thực tế. Để đạt được điều đó, chúng tôi tìm kiếm các cách khác để đo lường hiệu năng trong phòng thí nghiệm.

Sam đã tìm thấy manh mối đầu tiên:

Mười một phút sau, năm luồng đã được chạy, mỗi luồng tập trung vào một phép đo khác nhau: số lượng lệnh (instruction counts), số lần gọi V8, các commit của React, tính toán lại kiểu dáng (style recalculations) và các thay đổi DOM.

Chúng tôi tiếp cận mọi bài kiểm chuẩn mới với sự hoài nghi. Mỗi bài kiểm chuẩn có hai nhiệm vụ: thứ nhất, một chỉ số mà Claude có thể cải thiện trong phòng thí nghiệm; thứ hai, một rào cản trong CI với một con số chỉ có thể giảm xuống. Nếu một bài kiểm chuẩn không ổn định, hoặc không thực sự tương quan với độ trễ của người dùng, chúng tôi sẽ loại bỏ nó thay vì để Claude tối ưu hóa sai hướng.

@Claude hãy chứng minh rằng việc tối ưu hóa (hill climbing) dựa trên từng chỉ số này có thể mang lại kết quả cải thiện hiệu năng thực tế. chúng tôi sẽ gỡ bỏ các bài kiểm chuẩn cho bất kỳ ứng cử viên nào không chứng minh được điều đó

Thời gian thực tế (wall-clock time) là những gì người dùng cảm nhận được, nhưng nó có nhiều nhiễu, và mili giây là quá không ổn định để dùng làm cổng kiểm soát CI. Số lượng lệnh rất hấp dẫn vì chúng mang tính xác định, nhưng chúng tôi vẫn cần Claude chứng minh rằng chúng theo dõi được thời gian thực tế.

Vì vậy, chúng tôi yêu cầu Claude giảm số lượng lệnh trên hai đường dẫn quan trọng: quy trình tập hợp cây tin nhắn của cuộc trò chuyện và trình quét các dòng trạng thái trong đầu ra của Claude Code. Claude đã lập hồ sơ cả hai bằng Valgrind và phát hiện ra rằng một phần tư số lệnh của đường dẫn đầu tiên là các tra cứu từ điển megamorphic, giải quyết cùng một ID tin nhắn ba lần riêng biệt.

Một giờ sau, nó đã cắt giảm số lượng lệnh trên cả hai đường dẫn lần lượt là 48% và 31%, và thời gian thực tế đã giảm 78% và 44%. Chúng tôi đã kiểm tra hai cơ chế kiểm soát mới. Kể từ đó, bất kỳ PR nào làm tăng số lượng lệnh của các đường dẫn đó đều thất bại trong CI, và một công việc hàng ngày sẽ hạ thấp ngưỡng giới hạn mỗi khi số lượng lệnh giảm xuống.

Điều đó dẫn chúng tôi đến bài học trung tâm của đợt chạy nước rút. Với Claude, việc đo lường bất cứ thứ gì đều làm cho nó trở nên khả thi.

Đo lường từng là bước số không: bạn thêm một chỉ số, chờ dữ liệu đổ về, và chỉ sau đó mới bắt đầu hiểu vấn đề. Với Claude, đó là bước một của quá trình tối ưu hóa. Ngay khi Claude có một con số để vượt qua, nó có thể bắt đầu tối ưu hóa. Điều này có nghĩa là việc có đòn bẩy cao nhất mà chúng tôi có thể làm là tìm thêm nhiều thứ để đo lường.

VÒNG LẶP, TỪNG LUỒNG MỘT

Tất cả những điều này diễn ra trong cùng một kênh Slack, với nhiều kỹ sư và Claude cùng tham gia vào mọi luồng thảo luận. Từ đó, đợt chạy nước rút đi vào một vòng lặp:

1. Ai đó sẽ mở một luồng thảo luận về một đoạn chậm của hành trình, thường kèm theo ảnh chụp màn hình hoặc bản ghi.
2. Claude sẽ truy vết luồng, sau đó tìm hoặc xây dựng một bài kiểm chuẩn chứng minh vấn đề.
3. Khi đã có kết quả khả quan trong phòng thí nghiệm, Claude sẽ quay lại với một PR — thường là vài PR, được chia nhỏ để quản lý rủi ro và đánh giá, với bất kỳ tính năng nào người dùng nhìn thấy được đặt sau một cờ (flag).
4. Sau khi triển khai, Claude theo dõi đợt phát hành và đọc dữ liệu thực tế.
5. Nếu hiệu năng cải thiện, Claude chốt kết quả bằng cách hạ thấp ngưỡng kiểm chuẩn; nếu không, nó tắt cờ và lặp lại quy trình.
6. Sau đó, nó tiếp tục tìm kiếm điểm chậm tiếp theo trong cùng hành trình đó.

Một ví dụ: ai đó đã chia sẻ bản ghi màn hình cho thấy các hàng trong thanh bên (sidebar) xuất hiện sau khi trang đã tải xong. Các hàng Chat và Cowork hiển thị vào những thời điểm khác nhau, khiến trang web có cảm giác bị giật lag. Không có công cụ giám sát nào hiện có của chúng tôi phát hiện ra điều này. Chỉ số gần nhất mà chúng tôi có là Cumulative Layout Shift, nhưng mỗi lần dịch chuyển chỉ đạt khoảng 0,008 — nằm trong ngưỡng tốt là 0,1.

Issac đã nảy ra ý tưởng tham chiếu trực tiếp đến Layout Instability API bên dưới. Claude đã tạo một sự kiện đo lường từ xa (telemetry event) ánh xạ các nguồn của mỗi mục dịch chuyển bố cục vào một vùng được đặt tên (ví dụ: sidebar, transcript) và giai đoạn (ví dụ: trước khi hiển thị lần đầu, sau khi có thể nhập liệu). Nó đã thêm một bài kiểm tra tích hợp mở trang với thanh bên đã được điền dữ liệu, giữ dữ liệu của thanh bên cho đến sau khi hiển thị lần đầu và báo lỗi nếu có bất kỳ sự dịch chuyển nào trong bất kỳ vùng nào được đặt tên. Claude đã sử dụng điều đó làm tiêu chuẩn để chứng minh bản sửa lỗi: bài kiểm tra thất bại 20/20 lần trên nhánh main và thành công 20/20 lần trên PR.

Sau khi sự kiện được triển khai, Claude đã đọc dữ liệu thực tế và phát hiện ra rằng 31% số lần tải trang web có sự dịch chuyển nội dung sau khi trang đã có thể sử dụng mà không cần bất kỳ tương tác nào từ người dùng. Từ đó, Claude xử lý các nguyên nhân theo tên: một hàng tiêu đề xuất hiện muộn, một con trỏ trượt sang ngang khi tên người dùng tải xong, một danh sách bị dịch chuyển khi thanh cuộn xuất hiện. Claude đã sửa các lỗi nghiêm trọng nhất theo từng đợt, và khi chúng được khắc phục, nó lại tìm ra đợt lỗi tiếp theo.

VIDEO: Giật lag thanh bên, trước và sau khi sửa

Đó chỉ là một luồng công việc. Trong suốt giai đoạn chạy nước rút (sprint), chúng tôi đã thực hiện hơn một trăm năm mươi luồng cùng một lúc.

MỞ RỘNG THEO CHIỀU NGANG

Khi vòng lặp hoạt động trên một luồng, việc chạy nó trên nhiều luồng hơn chỉ đơn giản là mở thêm các luồng đó. Thay vì đóng một luồng sau khi yêu cầu ban đầu đã được hoàn thành, Claude sẽ tiếp tục thực hiện. Một luồng riêng lẻ có thể tạo ra năm mươi, đôi khi là một trăm PR tối ưu hóa. Ngày càng nhiều, chính Claude chứ không phải chúng tôi là người mở các luồng mới để theo đuổi những cơ hội mà nó tự tìm thấy, như một phần của cuộc điều tra riêng biệt hoặc công việc chạy hàng đêm. Shelley, một trong những kỹ sư trong kênh, đã nhận xét: "[Mô hình này] là một con quỷ số liệu."

Mọi phép đo đều tìm ra thứ gì đó để cải thiện. Claude đã thực hiện kiểm kê các React hook và tìm thấy 6.900 hook cùng 900 lượt đăng ký store trong đường dẫn nhập liệu của trình soạn thảo, gây ra việc render lại sau mỗi lần nhấn phím. Claude đếm các lần tính toán lại kiểu dáng (style recalculations) và phát hiện một bộ chọn:root:has duy nhất làm tăng thêm 24 mili giây cho mỗi thay đổi DOM. Claude truy vết các đường dẫn mã sau khi hiển thị lần đầu và tìm thấy một lệnh location.reload thừa gây ra nửa triệu lượt tải lại ẩn mỗi ngày mà không có số liệu tải nào của chúng tôi phát hiện được. Claude đọc các mẫu profiler từ các tab không hoạt động và thấy các bản sao bộ nhớ đệm giống hệt nhau được nhân bản vào IndexedDB hai lần mỗi phút, tất cả đều trên luồng chính (main thread).

Chúng tôi hiếm khi biết một luồng sẽ dẫn đến đâu. Trong một đợt quét các điểm nghẽn CPU, Claude nhận thấy việc làm nổi bật một khối mã đã hoàn thành có thể làm treo trang trong khoảng một giây. Nó đào sâu vào phòng thí nghiệm và tìm ra thủ phạm: dấu gạch ngang dài (em dash). Nếu markdown của một phản hồi chứa bất kỳ ký tự nào không thuộc bảng Latin-1, như dấu gạch ngang dài hoặc dấu ngoặc kép cong, V8 sẽ lưu trữ toàn bộ chuỗi dưới dạng UTF-16, khiến mọi regex tô sáng cú pháp phải chạy trên đường dẫn hai byte chậm hơn. Claude đã sửa lỗi này bằng một thay đổi gồm hai mươi dòng để sao chép mỗi khối mã vào một chuỗi một byte trước khi tô sáng nó.

Đến tuần thứ hai, chúng tôi gần như không thể tóm tắt kết quả đầu ra thành các bản cập nhật hàng ngày. Vào những ngày bận rộn nhất, hơn hai trăm thay đổi đã được áp dụng. Claude liên tục đề xuất các tiêu chuẩn mới; khoảng một phần ba số PR bao gồm các công cụ đo lường từ xa hoặc các rào cản bảo vệ bổ sung, và mỗi công cụ mới lại tạo ra nhiều luồng hơn với nhiều cơ hội hơn.

Làm việc trong một kênh duy nhất có nghĩa là mọi thứ đều diễn ra công khai. Chúng tôi nhảy vào và ra khỏi các luồng của nhau để tranh luận về các quyết định và ăn mừng chiến thắng. Tin đồn lan xa: các nhóm khác bắt đầu đưa các thay đổi của họ vào kênh để được đánh giá về hiệu suất. Các dự án mới được viết với hiệu suất tốt hơn một cách tinh tế nhờ tất cả các rào cản bảo vệ và kỹ năng của Claude đã được giới thiệu.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗