OpenClaw đốt 21,5 triệu token trong một ngày? Ba chiến lược tối ưu hóa giảm chi phí đột ngột

Tiêu đề gốc: Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)

Tác giả gốc: MOSHIII

Biên dịch gốc: Peggy, BlockBeats

Lời tựa của biên tập viên: Trong bối cảnh ứng dụng Agent đang phổ biến nhanh chóng, nhiều nhóm phát hiện ra một hiện tượng có vẻ nghịch lý: hệ thống hoạt động bình thường, nhưng chi phí token lại tăng lên liên tục một cách vô hình. Thông qua việc phân tích một khối lượng công việc OpenClaw thực tế, bài viết này phát hiện ra rằng nguyên nhân của việc bùng nổ chi phí thường không đến từ đầu vào của người dùng hoặc đầu ra của mô hình, mà là từ việc phát lại bộ nhớ đệm ngữ cảnh (cached prefix replay) bị bỏ qua. Mô hình liên tục đọc lại ngữ cảnh lịch sử khổng lồ trong mỗi lần gọi, từ đó tạo ra lượng tiêu thụ token khổng lồ.

Bài viết kết hợp với dữ liệu session cụ thể, cho thấy cách các sản phẩm trung gian lớn như đầu ra công cụ, ảnh chụp nhanh trình duyệt, nhật ký JSON,... liên tục được ghi vào ngữ cảnh lịch sử và được đọc lại trong vòng lặp agent.

Thông qua trường hợp này, tác giả đề xuất một hướng tối ưu hóa rõ ràng: từ thiết kế cấu trúc ngữ cảnh, quản lý đầu ra công cụ đến cấu hình cơ chế compaction. Đối với các nhà phát triển đang xây dựng hệ thống Agent, đây không chỉ là một bản ghi chép kiểm tra kỹ thuật mà còn là một hướng dẫn tiết kiệm chi phí thực sự.

Dưới đây là bài viết gốc:

Tôi đã phân tích một khối lượng công việc OpenClaw thực tế và phát hiện ra một mô hình mà tôi nghĩ nhiều người dùng Agent sẽ nhận ra:

Lượng sử dụng token trông có vẻ 'sống động'

Phản hồi cũng có vẻ bình thường

Nhưng lượng tiêu thụ token lại đột ngột tăng vọt

Dưới đây là cấu trúc phân tích, nguyên nhân gốc rễ và con đường khắc phục khả thi thực tế.

TL;DR

Yếu tố chi phí lớn nhất KHÔNG phải là tin nhắn người dùng quá dài. Mà là việc phát lại khối lượng lớn tiền tố bộ nhớ đệm (cached prefix).

Từ dữ liệu session:

Tổng tokens: 21,543,714

cacheRead: 17,105,970 (79.40%)

input: 4,345,264 (20.17%)

output: 92,480 (0.43%)

Nói cách khác: Chi phí của hầu hết các lần gọi thực chất không phải để xử lý ý định mới của người dùng, mà là để liên tục đọc lại ngữ cảnh lịch sử khổng lồ.

Khoảnh khắc "Chờ đã, sao lại thế?"

Tôi ban đầu nghĩ rằng lượng sử dụng token cao đến từ: prompt người dùng rất dài, tạo ra nhiều đầu ra, hoặc các lệnh gọi công cụ đắt đỏ.

Nhưng mô hình thực sự chi phối là:

input: vài trăm đến vài nghìn token

cacheRead: 170k đến 180k token mỗi lần gọi

Điều này có nghĩa là, mô hình đang liên tục đọc lại cùng một tiền tố ổn định khổng lồ trong mỗi vòng.

Phạm vi dữ liệu

Tôi đã phân tích dữ liệu ở hai cấp độ:

1. Nhật ký thời gian chạy (runtime logs)

2. Bản ghi phiên (session transcripts)

Cần lưu ý rằng:

Nhật ký chạy chủ yếu dùng để quan sát tín hiệu hành vi (như khởi động lại, lỗi, vấn đề cấu hình)

Thống kê token chính xác đến từ trường usage trong session JSONL

Các tập lệnh được sử dụng:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

Các tệp phân tích được tạo:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

Token thực sự được tiêu thụ ở đâu?

1) Tập trung Session

Có một session tiêu thụ cao hơn nhiều so với các session khác:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens

Sau đó giảm mạnh rõ rệt:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584

2) Tập trung Hành vi

Token chủ yếu đến từ:

toolUse: 16,372,294

stop: 5,171,420

Điều này cho thấy vấn đề chủ yếu nằm ở chuỗi vòng lặp lệnh gọi công cụ, không phải trò chuyện thông thường.

3) Tập trung Thời gian

Đỉnh điểm token không phải ngẫu nhiên, mà tập trung trong vài khung giờ:

2026-03-08 16:00: 4,105,105

2026-03-08 09:00: 4,036,070

2026-03-08 07:00: 2,793,648

Tiền tố bộ nhớ đệm khổng lồ thực sự chứa gì?

Không phải nội dung trò chuyện, mà chủ yếu là các sản phẩm trung gian lớn:

Khối dữ liệu toolResult khổng lồ

Các vết suy luận / suy nghĩ dài

Ảnh chụp nhanh JSON lớn

Danh sách tệp

Dữ liệu thu thập trình duyệt

Bản ghi trò chuyện của Agent con

Trong session lớn nhất, số lượng ký tự xấp xỉ là:

toolResult:text: 366,469 ký tự

assistant:thinking: 331,494 ký tự

assistant:toolCall: 53,039 ký tự

Một khi nội dung này được giữ lại trong ngữ cảnh lịch sử, mỗi lần gọi tiếp theo đều có thể đọc lại chúng thông qua tiền tố cache.

Ví dụ cụ thể (từ tệp session)

Các khối ngữ cảnh khổng lồ lặp đi lặp lại ở các vị trí sau:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

Nhật ký JSON gateway lớn (khoảng 37k ký tự)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

Ảnh chụp nhanh trình duyệt + đóng gói an toàn (khoảng 29k ký tự)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

Đầu ra danh sách tệp khổng lồ (khoảng 41k ký tự)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

Ảnh chụp nhanh trạng thái session/status + cấu trúc prompt lớn (khoảng 30k ký tự)

"Lãng phí nội dung trùng lặp" vs "Gánh nặng phát lại bộ nhớ đệm"

Tôi cũng đo lường tỷ lệ nội dung trùng lặp bên trong một lần gọi:

Tỷ lệ trùng lặp xấp xỉ: 1.72%

Thực sự tồn tại, nhưng không phải vấn đề chính.

Vấn đề thực sự là: Khối lượng tuyệt đối của tiền tố bộ nhớ đệm quá lớn

Cấu trúc là: Ngữ cảnh lịch sử khổng lồ, được đọc lại mỗi lần gọi, chỉ thêm một lượng nhỏ đầu vào mới lên trên

Do đó, trọng tâm tối ưu hóa không phải là loại bỏ trùng lặp, mà là thiết kế cấu trúc ngữ cảnh.

Tại sao vòng lặp Agent đặc biệt dễ gặp vấn đề này?

Ba cơ chế chồng chéo lên nhau:

1. Nhiều đầu ra công cụ được ghi vào ngữ cảnh lịch sử

2. Vòng lặp công cụ tạo ra nhiều lệnh gọi khoảng cách ngắn

3. Tiền tố thay đổi rất ít → cache sẽ đọc lại mỗi lần

Nếu cơ chế compaction ngữ cảnh không được kích hoạt ổn định, vấn đề sẽ nhanh chóng phóng đại.

Chiến lược khắc phục quan trọng nhất (theo thứ tự ảnh hưởng)

P0—Đừng nhồi nhét đầu ra công cụ khổng lồ vào ngữ cảnh dài hạn

Đối với đầu ra công cụ siêu lớn:

• Giữ bản tóm tắt + đường dẫn tham chiếu / ID
• Ghi payload gốc vào artifact tệp
• Đừng giữ toàn văn gốc trong lịch sử trò chuyện

Ưu tiên hạn chế các loại sau:

• JSON lớn
• Danh sách thư mục dài
• Ảnh chụp nhanh trình duyệt đầy đủ
• Bản ghi đầy đủ của Agent con

P1—Đảm bảo cơ chế compaction thực sự hoạt động

Trong dữ liệu này, vấn đề tương thích cấu hình xuất hiện nhiều lần: compaction key không hợp lệ

Điều này sẽ âm thầm tắt cơ chế tối ưu hóa.

Cách làm đúng: Chỉ sử dụng cấu hình tương thích phiên bản

Sau đó xác minh:

openclaw doctor --fix

Và kiểm tra nhật ký khởi động để xác nhận compaction được chấp nhận.

P1—Giảm tính bền vững của văn bản suy luận

Tránh việc văn bản suy luận dài bị replay liên tục

Trong môi trường sản xuất: Lưu bản tóm tắt ngắn gọn, thay vì suy luận đầy đủ

P3—Cải thiện thiết kế bộ nhớ đệm prompt

Mục tiêu KHÔNG phải là tối đa hóa cacheRead. Mục tiêu là sử dụng cache trên một tiền tố ổn định, có giá trị cao và gọn gàng.

Đề xuất:

• Đặt các quy tắc ổn định vào system prompt
• Đừng đặt dữ liệu không ổn định vào tiền tố ổn định
• Tránh tiêm nhiều dữ liệu debug vào mỗi vòng

Phương án thực tế để ngăn chặn tổn thất (nếu tôi phải xử lý ngày mai)

1. Tìm session có tỷ lệ cacheRead cao nhất

2. Thực thi /compact trên session chạy trốn (runaway session)

3. Thêm cắt ngắn + artifact hóa vào đầu ra công cụ

4. Chạy lại thống kê token sau mỗi lần sửa đổi

Tập trung theo dõi bốn KPI:

cacheRead / totalTokens

toolUse avgTotal/call

Số lần gọi có >=100k token

Tỷ lệ chiếm ưu thế của session lớn nhất

Tín hiệu thành công

Nếu tối ưu hóa có hiệu lực, bạn sẽ thấy:

Các lần gọi 100k+ token giảm rõ rệt

Tỷ lệ cacheRead giảm

Trọng lượng lệnh gọi toolUse giảm

Mức độ chi phối của một session đơn lẻ giảm

Nếu các chỉ số này không thay đổi, chiến lược ngữ cảnh của bạn vẫn còn quá lỏng lẻo.

Lệnh thử nghiệm tái tạo

python3 scripts/session_token_breakdown.py 'sessions' \

--include-deleted \

--top 20 \

--outlier-threshold 120000 \

--json-out tmp/session_token_stats_v2.json \

> tmp/session_token_stats_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \

--include-deleted \

--top 20 \

--png-out tmp/session_duplicate_waste.png \

--json-out tmp/session_duplicate_waste.json \

> tmp/session_duplicate_waste.txt

Kết luận

Nếu