Claude.ai tăng tốc gấp 3 lần chỉ trong hai tuần nhờ chính AI

Đội ngũ Anthropic vừa công bố chi tiết cách họ dùng chính Claude để tăng tốc trải nghiệm cốt lõi của claude.ai và ứng dụng desktop lên gấp 3 lần trong một sprint kéo dài hai tuần. Toàn bộ quá trình diễn ra trong một kênh Slack duy nhất, với Claude hiện diện trong mọi luồng thảo luận. Hơn 3.000 thay đổi được hợp nhất mà không có bất kỳ sự cố hay lần rollback nào ảnh hưởng tới khách hàng.

Giao diện Claude trên web và ứng dụng desktop

Bốn hành trình người dùng chiếm 95% hoạt động

Trước khi bắt đầu, nhóm đã tạo một kênh Slack với chỉ dẫn thường trực giao cho Claude nhiệm vụ theo dõi hiệu năng, đánh giá độ chính xác của hệ thống đo lường, duy trì dashboard quan sát và chủ động đề xuất giải pháp cho các vấn đề phát hiện được.

Claude phân tích dữ liệu sử dụng qua máy chủ MCP của Datadog và xác định bốn hành trình 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 có sẵn và gửi tin nhắn. Trên cả web lẫn desktop, những hành trình này tương ứng với 13 phép đo riêng biệt. Nhóm bổ sung instrumentation cho tới khi các phép đo có thể so sánh trực tiếp: mỗi phép đo bắt đầu từ 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õ phần việc phía client với phía server.

Kết quả đạt được ở phân vị thứ 75 rất đáng chú ý:

• Thời gian tới trang có thể gõ được khi tải mới claude.ai: từ 3,1 giây xuống 0,55 giây
• Khởi tạo phiên Claude Code mới: từ 0,8 giây xuống 0,3 giây
• Tải phiên Claude Cowork trên cloud: từ 2,6 giây xuống 0,73 giây

Theo ước tính của nhóm, điều này tiết kiệm hàng chục nghìn giờ chờ đợi của người dùng mỗi ngày.

Đo lường trở thành bước đầu tiên, không còn là bước số 0

Sprint khởi động với khoảng 20 dự án được chọn thủ cô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 đơn vị mili-giây, và nhóm tổng hợp lại để đặt mục tiêu. Chỉ đến ngày thứ ba, 12 trong số 13 mục tiêu đã đạt được.

Một số tối ưu đáng chú ý ban đầu:

• Nhúng sẵn một composer tĩnh vào HTML để người dùng có thể gõ ngay trong lúc React khởi tạo
• Biên dịch trước V8 code cache để tiến trình chính của ứng dụng desktop không phải biên dịch lại từ đầu
• Giữ composer luôn được mount giữa các cuộc trò chuyện
• Prefetch phiên khi người dùng rê chuột qua
• Giảm 90% số lần re-render của sidebar

Nhưng bước ngoặt thực sự đến từ một thay đổi trong tư duy. Nhóm nhận ra rằng với Claude, hễ đo được thứ gì thì có thể tối ưu được thứ đó. Trước đây, đo lường là bước số 0 — bạn thêm chỉ số, chờ dữ liệu về, rồi mới hiểu vấn đề. Với Claude, đó là bước đầu tiên của quá trình leo dốc. Ngay khi Claude có một con số để vượt qua, nó có thể bắt tay vào tối ưu.

Nhóm bắt đầu tìm thêm nhiều thứ để đo:

"Chúng ta có thể làm gì thay vì đo thời gian thực tế? Ví dụ, đo số lượng lệnh JS được thực thi thì sao?"

Câu trả lời là có. Với các đường dẫn nóng thuần JavaScript, có thể đếm số lệnh thực thi theo nghĩa đen bằng cách chạy benchmark dưới Valgrind với node --predictable và so sánh với baseline. Với các đường dẫn trên trình duyệt, có cả một thang bậc các phép đếm xác định khác: số lần React commit mỗi tương tác, số lần gọi hàm từ công cụ đo độ phủ chính xác của V8, số lần tính lại layout và style, số lần thay đổi DOM.

Mười một phút sau, năm luồng công việc đã chạy song song, mỗi luồng tập trung vào một phép đo khác nhau.

Ratchet: giữ thành quả không bị tuột dốc

Mỗi benchmark mới đều được nhìn nhận một cách hoài nghi. Nó phải làm hai việc: thứ nhất, là một chỉ số mà Claude có thể cải thiện trong phòng lab; thứ hai, là một guardrail trong CI với con số chỉ có thể giảm xuống, không bao giờ tăng lên. Nếu một benchmark không ổn định, hoặc không thực sự tương quan với độ trễ mà người dùng cảm nhận, nó bị loại bỏ thay vì để Claude leo nhầm dốc.

Ví dụ cụ thể: Claude được yêu cầu giảm số lệnh thực thi trên hai đường dẫn nóng — hàm lắp ráp cây tin nhắn của cuộc trò chuyện, và bộ quét dòng trạng thái trong output của Claude Code. Claude dùng Valgrind để profile và phát hiện 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 cùng một message ID tới ba lần riêng biệt.

Một giờ sau, Claude đã giảm số lệnh trên hai đường dẫn lần lượt 48% và 31%, thời gian thực tế giảm 78% và 44%. Hai ratchet mới được đưa vào. Từ đó trở đi, bất kỳ PR nào làm tăng số lệnh trên các đường dẫn đó đều khiến CI thất bại, và một tác vụ chạy hàng ngày sẽ hạ trần xuống mỗi khi con số giảm.

Bảng điều khiển hiệu năng và các chỉ số đo lường

Một kênh Slack, hơn 150 luồng song song

Toàn bộ sprint vận hành trong cùng một kênh Slack, với nhiều kỹ sư và Claude cùng tham gia mọi luồng. Một ví dụ điển hình: ai đó chia sẻ bản ghi màn hình cho thấy các hàng sidebar xuất hiện nhấp nháy sau khi trang tải xong. Các chỉ số hiện có đều không phát hiện được vấn đề này — Cumulative Layout Shift gần nhất chỉ đạt khoảng 0,008, vẫn nằm trong ngưỡng tốt là 0,1.

Claude tạo một sự kiện telemetry ánh xạ nguồn gốc của từng mục dịch chuyển layout tới một vùng có tên (sidebar, transcript) và một pha (trước lần vẽ đầu tiên, sau khi trang gõ được). Nó thêm một bài kiểm tra tích hợp mở trang với sidebar đã có dữ liệu và thất bại nếu có bất kỳ dịch chuyển nào. Kết quả: đỏ 20/20 lần trên nhánh main, xanh 20/20 lần trên PR.

Sau khi sự kiện được triển khai, Claude đọc dữ liệu thực địa và phát hiện 31% lượt tải trang web có thứ gì đó dịch chuyển sau khi trang đã dùng được, mà không có tương tác nào của người dùng. Claude lần lượt xử lý từng nguyên nhân: một hàng header đến muộn, một con trỏ bị trượt ngang khi tên người dùng tải xong, một danh sách bị xê dịch khi thanh cuộn xuất hiện.

Đó chỉ là một luồng. Trong suốt sprint, nhóm chạy hơn 150 luồng cùng lúc. Thay vì đóng một luồng sau khi yêu cầu ban đầu đã hoàn thành, Claude tiếp tục đào sâu. Một luồng đơn lẻ có thể đưa ra 50, thậm chí 100 PR tối ưu. Ngày càng nhiều luồng mới do chính Claude mở ra để theo đuổi các cơ hội nó tự tìm thấy.

Một kỹ sư trong kênh nhận xét: "Mô hình này đúng là một con quỷ số."

Từ đếm hook React tới em dash

Mỗi phép đo đều tìm ra điều gì đó để cải thiện:

• Claude kiểm kê hook React và phát hiện 6.900 hook cùng 900 đăng ký store trong đường dẫn gõ phím của composer, khiến nó re-render sau mỗi lần gõ
• Đếm số lần tính lại style, Claude tìm ra một selector :root:has() duy nhất làm mỗi thay đổi DOM tốn thêm 24 mili-giây
• Truy vết các đường dẫn code sau lần vẽ đầu tiên, Claude phát hiện một lệnh location.reload() sót lại gây ra nửa triệu lượt tải lại ẩn mỗi ngày mà không chỉ số nào phát hiện được
• Đọc mẫu profiler từ các tab không hoạt động, Claude phát hiện các snapshot cache giống hệt nhau bị nhân bản vào IndexedDB hai lần mỗi phút, toàn bộ trên main thread

Một phát hiện thú vị đến từ quá trình quét các điểm nghẽn CPU: Claude nhận thấy việc tô sáng một khối code đã hoàn thành có thể làm đơ trang khoảng một giây. Thủ phạm hóa ra là dấu gạch ngang dài (em dash). Nếu markdown của câu trả lời chứa bất kỳ ký tự nào ngoài Latin-1, như dấu gạch ngang dài hay dấu ngoặc kép cong, V8 sẽ lưu toàn bộ chuỗi dưới dạng UTF-16, đẩy mọi biểu thức chính quy tô sáng cú pháp sang đường dẫn hai byte chậm hơn. Claude khắc phục bằng một thay đổi khoảng 20 dòng: sao chép mỗi khối code sang chuỗi một byte trước khi tô sáng.

Đến tuần thứ hai, nhóm gần như không thể tóm tắt khối lượng công việc thành bản cập nhật hàng ngày. Vào những ngày bận rộn nhất, hơn 200 thay đổi được hợp nhất. Khoảng một phần ba số PR bao gồm thêm telemetry hoặc guardrail, và mỗi công cụ đo mới lại sinh ra thêm nhiều luồng với nhiều cơ hội hơn.

Ba trụ cột để giữ Claude đi đúng hướng

Vòng lặp này hiệu quả nhưng không hề tự trị. Giữ nó nhanh, an toàn và đúng hướng là việc của con người, với ba phần:

Tham vọng. Mặc định Claude khá thận trọng về phạm vi — nó ghi nhận phát hiện thành ticket, dè dặt về tính khả thi và ước tính dư ra. Nhóm liên tục khuyến khích Claude táo bạo hơn. Khi bắt đầu chạm tới các mục tiêu đề ra, các luồng chậm lại, và một kỹ sư phải đi từng luồng với cùng một thông điệp: "Hãy tiếp tục đẩy nó xuống, mục tiêu không phải là điểm dừng. Tiếp theo là gì? Hãy tham vọng lên."

Gu thẩm mỹ. Mỗi luồng đều có một người chủ có tên, và Claude phải nêu bật mọi thay đổi mà người dùng có thể cảm nhận được kèm ảnh chụp hoặc bản ghi trước–sau để người đó quyết định. Bảng nên điền từng ô một hay đợi tới khi xong cả hàng? Khung xương tải nên hiện ngay hay chỉ sau nửa giây? Hiệu ứng mờ dần từng chữ trên văn bản streaming có đáng với một phần năm ngân sách khung hình mà nó tiêu tốn?

Định hướng. Mỗi luồng được giữ hẹp một cách có chủ đích, tập trung vào một benchmark hoặc một hành trình. Nhóm hình dung các luồng như 150 chiếc búa đang tìm đinh. Một PR dài 900 dòng nhận được phản hồi chỉ một dòng: "Chốt là 2 mili-giây mỗi lần gửi không đáng với độ phức tạp của việc duy trì plugin build này."

Sidequest: giữ 120 fps khi streaming

Một trong những "sidequest" cho thấy mọi thứ vận hành cùng nhau. Để minh họa một tối ưu hóa cho biểu thức chính quy dùng trong tô sáng cú pháp trực tiếp, Claude đính kèm bản ghi màn hình một câu trả lời dài đang streaming trong phòng lab, kèm chỉ số khung hình trên mỗi giây ở góc màn hình.

Nhóm nhận ra giàn thử chỉ chạy ở 60 Hz vì Chromium headless mặc định như vậy, và thách thức Claude đẩy lên 120 Hz. Claude xác nhận có thể điều khiển qua DevTools begin-frame control, đạt bước khung hình 120 Hz xác định — đúng 240 khung cho 240 begin-frame ở mức 8,33 mili-giây. Nhờ đó, câu hỏi "khung hình này có nằm trong ngân sách 120 Hz không" trở thành một phép đọc chính xác thay vì nhiễu.

Mỗi khung hình vẽ có ngân sách 8,33 mili-giây, nên Claude bước qua từng khung của một câu trả lời dài để tìm những chỗ chậm. Nó loại bỏ công việc tỷ lệ với độ dài tin nhắn bằng cách ghi nhớ các khối đã hoàn thành, chuyển logic token hóa cho các khối code đang phát triển sang một worker, và hiển thị bảng theo từng ô.

Trong riêng luồng đó, nhóm đã hợp nhất gần 60 PR. Câu trả lời dài chặn main thread tổng cộng khoảng 200 mili-giây, so với 750 mili-giây trước đây, chỉ dùng khoảng một phần ba CPU, và giữ 120 fps từ đầu tới cuối trên MacBook 120 Hz. Giàn thử 120 Hz trở thành một tác vụ chạy hàng đêm để Claude theo dõi thoái hóa hiệu năng.

Kết quả: các câu trả lời dài trên Claude ở web và desktop giờ streaming mượt hơn khoảng 4 lần.

Bài học và những gì còn ở phía trước

Hiện tại, claude.ai và ứng dụng desktop đã nhanh hơn khoảng 3 lần so với đầu tháng 8, và các ratchet được kỳ vọng sẽ giữ chúng ở mức đó. Nhưng nhóm khẳng định chưa dừng lại: phân vị thứ 95, các hành trình khác và những cuộc trò chuyện rất dài vẫn còn dư địa cải thiện.

Một bài học quan trọng khác là các chiến thắng về hiệu năng sẽ mai một trong một codebase chuyển động nhanh. Ví dụ, composer tĩnh vốn dễ vỡ theo thiết kế: nhóm hiển thị cho người dùng bản sao HTML của trang gần như ngay lập tức, rồi để React vẽ trực tiếp lên trên. Nếu bản render của React lệch dù chỉ một pixel, hiệu ứng sẽ mất. Vì vậy Claude đã xây dựng hàng chục guardrail để bảo vệ kỹ thuật này.

Ngay cả những lỗi nằm ngoài tầm kiểm soát cũng được xử lý. Bốn giờ sau khi phát hành composer tĩnh nội bộ, một đồng nghiệp chia sẻ bản ghi về hiện tượng dịch chuyển layout khi mở claude.ai trong tab mới. Claude truy vết và phát hiện đó là Chrome đang thay đổi kích thước trang, không phải lỗi từ khâu bàn giao composer. Cụ thể, Chrome prerender trang trong nền ở chiều cao của tab hiện tại, và trên trình duyệt do tổ chức quản lý, trang tab mới thấp hơn một chút do có footer. Claude đã ghim layout qua lần thay đổi kích thước đó và thêm bài kiểm tra mô phỏng luồng prerender.

Khi chia sẻ kết quả nội bộ, một thành viên trong nhóm đã đúc kết: "Sáu tháng trước bạn không thể nào thuyết phục được tôi rằng điều này là khả thi." Nhóm dự định tiếp tục làm việc theo cách này — từng luồng một, ở bất kỳ quy mô nào. Kênh Slack vẫn đang chạy.