Có hai kiểu chậm khi dùng Claude Code, và phần lớn thời gian người ta mất là vì chữa nhầm kiểu. Một kiểu sinh ra từ chính phiên làm việc của bạn: ngữ cảnh càng dồn nhiều, mỗi câu trả lời càng lâu. Kiểu còn lại nằm ở đường truyền — công cụ này liên tục đọc tệp, chạy lệnh rồi đọc kết quả, mỗi vòng như vậy đều phải đi tới máy chủ và quay về. Nếu mỗi vòng cõng thêm vài trăm mili giây, một tác vụ hai mươi bước sẽ lê lết thấy rõ.
Vấn đề là những lời khuyên hay gặp nhất — nén ngữ cảnh, hạ xuống mô hình nhẹ hơn — chỉ chạm vào kiểu thứ nhất. Đường truyền tệ thì bạn có nén cả ngày agent vẫn ì, vì thuế độ trễ bị thu trên từng lượt gọi công cụ, không liên quan gì tới số token.
Bạn thuộc nhóm nào
Nhóm thứ nhất là người ngồi phiên dài. Buổi sáng mọi thứ trơn tru, đến chiều cùng một câu lệnh lại chậm hẳn. Đây là dấu hiệu kinh điển của ngữ cảnh tích tụ: thời gian phản hồi tăng theo lượng dữ liệu phiên đang gánh. Một cuộc trò chuyện khởi đầu ở mười lăm nghìn token cư xử rất khác khi đã chạm sáu mươi nghìn.
Nhóm thứ hai thì khác hẳn — chậm ngay từ lệnh đầu tiên, phiên dài hay ngắn cũng vậy. Thường là người ở xa về địa lý so với máy chủ, nên mỗi yêu cầu phải đi một chặng dài và hay nghẽn trước khi tới đích rồi mới quay lại. Khi agent nối hàng chục lượt đọc và sửa tệp, mỗi lượt đều ngồi chờ đúng cái vòng khứ hồi đó.
Năm phút để biết mình ở đâu
Mở một phiên trắng và thử lại
Đây là phép thử nhanh nhất. Lấy đúng câu lệnh vừa thấy chậm, mở một phiên mới tinh và gửi lại. Phiên mới chạy nhanh, phiên cũ chậm — vấn đề là ngữ cảnh, không phải mạng. Cách xử lý đơn giản: nén sớm khi đầu vào vượt quãng một trăm nghìn token, tách phiên riêng cho việc không liên quan, và đừng kéo nguyên cả thư mục lớn hay tệp sinh tự động vào ngữ cảnh. Mô hình phải đọc qua từng byte bạn nạp trước khi kịp nghĩ.
Bấm giờ một vòng khứ hồi
Nếu phiên trắng vẫn chậm, thủ phạm gần như chắc chắn là đường truyền. Ping thử máy chủ API và ghi lại con số. Trên 200 mili giây liên tục là mỗi lượt gọi công cụ kế tiếp đều phải gánh thêm chừng ấy. Mà Claude Code vốn nặng tính agent — đọc tệp, chạy lệnh, đọc lại, rồi sửa — một tác vụ thường gói hơn hai mươi vòng. Một tuyến 250 mili giây cộng dồn lại thành nhiều giây chờ trắng trước khi mô hình bắt đầu suy nghĩ. Đây mới là lý do hay bị bỏ sót nhất, vì người ta cứ chăm chăm cắt ngữ cảnh.
Soi độ rung, đừng chỉ nhìn trung bình
Con số độ trễ trung bình có thể trông rất đẹp trong khi trải nghiệm thực tế lại tệ. Một tuyến không ổn định dao động mạnh và thỉnh thoảng làm rớt gói, buộc phải gửi lại. Chạy mtr vài chục giây rồi nhìn cột mất gói theo từng chặng. Gói gửi lại gần như vô hình trong một lần ping ngẫu nhiên, nhưng nó tàn phá kiểu lập trình tương tác — mỗi lần gói kẹt là con trỏ đông cứng một nhịp.
Đừng dùng dao mổ trâu giết gà
Không phải bước nào cũng cần mô hình mạnh nhất. Một gợi ý cú pháp hay câu giải thích ngắn thì mô hình nhẹ trả về gần như tức thì; để dành mô hình nặng cho việc suy luận thật sự khó. Khớp mô hình với độ khó của tác vụ giúp bạn bỏ đi phần chậm tự chuốc lấy. Nhưng nói thẳng: việc này chỉ bổ trợ cho một đường truyền khỏe, nó không cứu nổi một tuyến vốn đã tệ.
Bốn nguyên nhân, sửa ở đâu
| Nguyên nhân | Triệu chứng | Gốc nằm ở | Hướng xử lý |
|---|---|---|---|
| Ngữ cảnh tích tụ | Càng về cuối phiên càng chậm | Thói quen dùng phiên | Nén sớm, mở phiên mới cho việc khác |
| Độ trễ mỗi lượt gọi | Chậm ngay lệnh đầu, đều khắp | Tuyến mạng tới API | Đi qua một tuyến độ trễ thấp |
| Độ rung và mất gói | Đông cứng ngẫu nhiên giữa chừng | Chất lượng tuyến mạng | Chọn tuyến ổn định, ít rớt gói |
| Chọn nhầm mô hình | Mô hình nặng làm việc vặt | Cấu hình của bạn | Khớp mô hình với độ khó tác vụ |
Để ý hai dòng giữa: cả hai đều nằm ở đường truyền. Đó cũng là nửa vấn đề mà bản thân bạn khó tự xử lý, vì nó phụ thuộc vào quãng đường gói tin phải đi.
Mấy câu hay được hỏi
Máy mình mạnh mà sao Claude Code vẫn chậm?
Vì phần lớn thời gian chờ là mạng và suy luận, không phải sức tính của máy. CPU nhanh giúp công cụ chạy nhanh hơn một chút, nhưng không rút ngắn được vòng khứ hồi tới API, cũng không làm mô hình nghĩ nhanh hơn trên một ngữ cảnh đồ sộ.
Nén ngữ cảnh có thật sự nhanh hơn không?
Có, nhưng chỉ với kiểu chậm theo độ dài phiên. Ít token thì mỗi câu trả lời nhẹ việc hơn. Còn với một tuyến mạng kém thì nén bao nhiêu cũng vô ích — đây chính là lý do nhiều người nén xong chẳng thấy khác gì.
Cắm dây mạng có hơn Wi-Fi không?
Đa số trường hợp là có. Đường có dây thường ít rung và ít rớt gói hơn so với Wi-Fi đông thiết bị, mà lập trình tương tác lại nhạy đúng với những đỉnh nhiễu kiểu đó. Nếu bạn hay bị đông cứng giữa chừng, thử cắm dây trước khi nghĩ tới chuyện khác.
Một tuyến tốt thay đổi được bao nhiêu?
Nó cắt phần độ trễ thu trên mỗi lượt gọi và làm phẳng độ rung. Từng vòng trong số hàng chục vòng của một phiên agent về nhanh hơn và đều hơn. Trên một tác vụ nhiều bước, phần tiết kiệm cộng dồn lại đáng kể.
Cách thoát khỏi tình trạng này không phải đoán mò mà là chia đôi vấn đề. Xác nhận xem độ chậm tăng dần theo phiên hay bám bạn ngay từ phím đầu tiên. Nửa thuộc về ngữ cảnh, bạn chỉnh bằng thói quen dùng phiên. Nửa thuộc về mạng thì cần một tuyến dựng riêng cho loại lưu lượng độ trễ thấp, liên tục — và đó là phần NasaCode lo, với các node tinh chỉnh để giữ mỗi vòng khứ hồi ngắn và ổn định cho người viết code. Nếu phép thử phiên trắng ở trên cho thấy bạn rơi vào nhóm mạng, đó là lúc đáng thử một tuyến tối ưu.
