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

Tại sao các phiên OpenClaw của tôi đã đốt cháy 21,5 triệu token trong một ngày (và điều gì thực sự đã khắc phục được vấn đề này)

Tác giả gốc: MOSHIII

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

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

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

Qua trường hợp này, tác giả đưa ra một hướng tối ưu 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à bản ghi gỡ lỗi kỹ thuật, mà còn là một kế hoạch tiết kiệm chi phí thực tế.

Dưới đây là bản gốc:

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

Lượng sử dụng token trông rất « sôi động »

Phản hồi cũng trông rất bình thường

Nhưng mức tiêu thụ token lại tăng đột biến

Dưới đây là phân tích cấu trúc, nguyên nhân cốt lõi và lộ trình khắc phục thực tế cho lần phân tích này.

Yếu tố thúc đẩy chi phí lớn nhất không phải là tin nhắn người dùng quá dài, mà là lượng lớn tiền tố được lưu trong bộ nhớ đệm (cached prefix) bị phát lại lặp đi lặp lại.

Dựa trên dữ liệu phiên:

Tổng số token: 21.543.714

cacheRead: 17.105.970 (79,40%)

4.345.264 (20,17%)

đầu ra: 92.480 (0,43%)

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

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

Nhưng mô hình thống trị thực sự là:

Hàng trăm đến hàng nghìn token

cacheRead: Mỗi lần gọi từ 170.000 đến 180.000 token

Nói cách khác, mô hình lặp lại đọc cùng một tiền tố ổn định lớn trong mỗi vòng.

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:

Log hoạt động chủ yếu được sử dụng để theo dõi các tín hiệu hành vi (như khởi động lại, lỗi, vấn đề cấu hình)

Số liệu token chính xác đến từ trường usage trong file JSONL của phiên

Script được sử dụng:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

Tệp phân tích được tạo ra:

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

1) Tập trung phiên

Một phiên có mức tiêu thụ cao hơn đáng kể so với các phiên khác:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19.204.645 token

Sau đó là sự sụt giảm 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

dừng: 5.171.420

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

3) Thời gian tập trung

Đỉnh điểm của token không phải là ngẫu nhiên, mà tập trung vào một 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

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

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

Các chuỗi lập luận / suy nghĩ dài

Bản sao JSON lớn

Danh sách tệp

Trình duyệt thu thập dữ liệu

Hồ sơ hội thoại của Sub-Agent

Trong phiên lớn nhất, số ký tự khoảng:

366.469 ký tự

assistant:thinking：331,494 ký tự

assistant:toolCall：53,039 ký tự

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

Các khối ngữ cảnh khổng lồ đã xuất hiện lặp lại tại vị trí sau:

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

Bản ghi JSON của cổng lớn (khoảng 37.000 ký tự)

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

Bản sao trình duyệt + đóng gói bảo mật (khoảng 29.000 ký tự)

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

Danh sách tệp tin lớn (khoảng 41.000 ký tự)

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

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

Tôi cũng đã đo tỷ lệ nội dung lặp lại trong mỗi lần gọi:

Tỷ lệ lặp lại khoảng: 1.72%

Có thật, nhưng không phải là 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à: bối cảnh lịch sử khổng lồ, mỗi lần gọi lại đọc lại toàn bộ, 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.

Ba cơ chế chồng lấn lẫn nhau:

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

2. Việc lặp lại công cụ sẽ tạo ra nhiều cuộc gọi với khoảng thời gian ngắn.

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

Nếu việc nén context không được kích hoạt ổn định, vấn đề sẽ nhanh chóng trở nên nghiêm trọng hơn.

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

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

• Giữ tóm tắt + đường dẫn/trích dẫn ID
• Ghi payload gốc vào tệp artifact
• Đừng giữ nguyên văn bản đầy đủ trong lịch sử chat

Ưu tiên giới hạn các danh mục này:

• JSON lớn
• Danh sách danh mục dài
• Full browser snapshot
• Bản ghi đầy đủ của Sub Agent

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

Trong dữ liệu này, các 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ẽ tắt cơ chế tối ưu hóa một cách lặng lẽ.

Đúng cách: 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 rằng compaction đã được chấp nhận.

P1—Giảm lưu trữ văn bản reasoning

Tránh để văn bản suy luận dài bị phát lại liên tục

Trong môi trường sản xuất: lưu tóm tắt ngắn gọn, thay vì toàn bộ lý luận

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 các tiền tố chặt chẽ, ổn định và có giá trị cao.

Khuyến nghị:

• Đưa quy tắc ổn định vào system prompt
• Đừng đưa dữ liệu không ổn định vào tiền tố ổn định
• Tránh tiêm lượng lớn dữ liệu gỡ lỗi trong mỗi vòng

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

2. Thực hiện /compact cho phiên runaway session

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

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

Theo dõi bốn KPI chính:

cacheRead / tổngSốToken

toolUse avgTotal/call

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

Tỷ lệ phiên tối đa

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

Số lần gọi token giảm rõ rệt hơn 100k+

Tỷ lệ cacheRead giảm

Giảm trọng số gọi công cụ

Mức độ chi phối của từng phiên giảm xuống

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

python3 scripts/session_token_breakdown.py 'sessions' \

--include-deleted \

--20 cặp hàng đầu \

--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 \

--20 cặp hàng đầu \

--png-out tmp/session_duplicate_waste.png \

--json-out tmp/session_duplicate_waste.json \

> tmp/session_duplicate_waste.txt

Nếu hệ thống Agent của bạn trông có vẻ hoạt động bình thường nhưng chi phí liên tục tăng, hãy kiểm tra trước một vấn đề: bạn đang trả tiền cho các lần suy luận mới, hay đang phát lại lớn các ngữ cảnh cũ?

Trong trường hợp của tôi, phần lớn chi phí thực sự đến từ việc phát lại ngữ cảnh.

Khi bạn nhận ra điều này, giải pháp trở nên rõ ràng: kiểm soát chặt chẽ dữ liệu được đưa vào ngữ cảnh dài hạn.

Liên kết gốc