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í
Đừng để nó đọc lại những thứ cũ.
Tiêu đề gốc: Tại sao phiên OpenClaw của tôi đốt 21,5 triệu mã thông báo trong một ngày (Và điều gì thực sự đã sửa nó)
Tác giả gốc: MOSHIII
Bản tổng hợp gốc: Peggy, BlockBeats
Lưu ý của biên tập viên: Với sự phổ biến nhanh chóng của các ứng dụng Đại lý, nhiều nhóm đã phát hiện ra một hiện tượng có vẻ bất thường: hệ thống đang chạy bình thường nhưng chi phí của mã thông báo vẫn vô tình tiếp tục tăng. Thông qua việc loại bỏ khối lượng công việc OpenClaw thực sự, bài viết này nhận thấy nguyên nhân gây ra sự bùng nổ chi phí thường không đến từ đầu vào của người dùng hoặc đầu ra mô hình mà do việc phát lại bộ đệm bối cảnh bị bỏ qua (phát lại tiền tố được lưu trong bộ nhớ đệm). Mô hình liên tục đọc bối cảnh lịch sử khổng lồ trong mỗi vòng gọi, dẫn đến việc tiêu thụ một lượng lớn mã thông báo.
Bài viết kết hợp dữ liệu phiên cụ thể để cho thấy các sản phẩm trung gian lớn như đầu ra công cụ, ảnh chụp nhanh của trình duyệt và nhật ký JSON được ghi liên tục vào bối cảnh lịch sử và đọc lặp lại trong vòng lặp tác nhân như thế nào.
Qua trường hợp này, tác giả đưa ra một tập hợp ý tưở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ế nén. Đối với các nhà phát triển đang xây dựng hệ thống Đại lý, đây không chỉ là bản ghi xử lý sự cố kỹ thuật mà còn là hướng dẫn tiết kiệm tiền thực sự.
Sau đây là văn bản gốc:
Tôi đã phân tích khối lượng công việc OpenClaw thực tế và phát hiện ra một mẫu mà tôi nghĩ nhiều người dùng Đại lý sẽ nhận ra:
Việc sử dụng mã thông báo có vẻ "hoạt động"
Các phản hồi cũng có vẻ bình thường
Nhưng mức tiêu thụ mã thông báo đột nhiên bùng nổ
Sau đây là bản phân tích cấu trúc của phân tích này, nguyên nhân cốt lõi và lộ trình sửa chữa thực tế.
TL;DR
Nguyên nhân gây ra chi phí lớn nhất không phải là tin nhắn của người dùng quá dài. Thay vào đó, một lượng lớn tiền tố được lưu trong bộ nhớ đệm sẽ được phát lại nhiều lần.
Từ dữ liệu phiên:
Tổng số mã thông báo: 21.543.714
cacheRead: 17.105.970 (79,40%)
đầu vào: 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 không thực sự xử lý ý định của người dùng mới mà liên tục đọc bối cảnh lịch sử to lớn.
Câu hỏi "Đợi đã, sao chuyện này có thể xảy ra được?" khoảnh khắc
Ban đầu tôi nghĩ mức sử dụng mã thông báo cao là do: lời nhắc của người dùng rất dài, tạo ra sản lượng lớn hoặc các lệnh gọi công cụ đắt tiền.
Nhưng mô hình thực sự nổi trội là:
Đầu vào: hàng trăm đến hàng nghìn mã thông báo
cacheRead: 170.000 đến 180.000 mã thông báo cho mỗi cuộc gọi
Nói cách khác, mô hình liên tục đọc 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 hai cấp độ dữ liệu:
1. Nhật ký thời gian chạy
2. Bản ghi phiên
Cần lưu ý rằng:
Nhật ký thời gian chạy chủ yếu được sử dụng để quan sát các tín hiệu hành vi (chẳng hạn như khởi động lại, lỗi, sự cố cấu hình)
Số liệu thống kê mã thông báo chính xác đến từ việc sử dụng trong trường JSONL phiên
Tập lệnh được sử dụng:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Được tạo tệp phân tích:
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 Mức tiêu thụ thực tế ở đâu?
1) Tập trung phiên
Có một phiên tiêu thụ nhiều hơn các phiên khác:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19.204.645 token
Sau đó, có một vách đá rõ ràng thả:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1.505.038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649.584
2) Tập trung hành vi
mã thông báo Chủ yếu from:
toolUse: 16,372,294
stop: 5,171,420
Điều đó có nghĩa là vấn đề chủ yếu nằm ở vòng lặp chuỗi lệnh gọi công cụ chứ không phải trò chuyện thông thường.
3) Sự tập trung thời gian
Đỉnh của token không phải ngẫu nhiên mà tập trung trong vài 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
Có gì trong tiền tố bộ đệm khổng lồ?
Đây không phải là nội dung của cuộc trò chuyện mà chủ yếu là các sản phẩm trung gian lớn:
Khối dữ liệu kết quả công cụ khổng lồ
Dấu vết lý luận / suy nghĩ rất dài
Ảnh chụp nhanh JSON lớn
Danh sách tệp
Dữ liệu thu thập thông tin của trình duyệt
Bản ghi cuộc hội thoại của các Đại lý phụ
Trong phiên lớn nhất, số lượng ký tự xấp xỉ:
toolResult:text: 366.469 ký tự
assistant:thinking: 331.494 ký tự
assistant:toolCall: 53.039 ký tự
Khi những nội dung này được giữ lại trong bối cảnh lịch sử, mỗi lệnh gọi tiếp theo có thể đọc lại chúng thông qua tiền tố bộ đệm.
Ví dụ cụ thể (từ tệp phiên)
Một khối ngữ cảnh lớn xuất hiện lặp đi lặp lại trong:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Nhật ký JSON cổng lớn (khoảng 3,7 Swastika)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Ảnh chụp nhanh của trình duyệt + bao bì an toàn (khoảng 2,9 swastika)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Đầu ra danh sách tệp rất lớn (khoảng 4.1 Swastika ký tự)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
ảnh chụp nhanh trạng thái phiên/trạng thái + cấu trúc lời nhắc lớn (khoảng 30.000 ký tự)
"Lãng phí nội dung trùng lặp" so với "gánh nặng phát lại bộ đệm"
Tôi cũng đã đo lường tỷ lệ nội dung trùng lặp trong một nội dung call:
Tỷ lệ trùng lặp xấp xỉ: 1,72%
Có tồn tại nhưng không phải là vấn đề chính.
Vấn đề thực sự là: kích thước 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ồ, đọc lại mỗi vòng lệnh gọi và chỉ một lượng nhỏ dữ liệu đầu vào mới được thêm vào nó
Vì vậy, trọng tâm của việc 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 Tác nhân đặc biệt dễ gặp phải vấn đề này?
Ba cơ chế chồng chéo lên nhau:
1. Một số lượng lớn các kết quả đầu ra của công cụ được viết theo bối cảnh lịch sử
2. Chu trình công cụ sẽ tạo ra một số lượng lớn các lệnh gọi trong khoảng thời gian ngắn
3. Tiền tố thay đổi rất ít → bộ đệm sẽ được đọc lại mỗi lần
Nếu tính năng nén ngữ cảnh không được kích hoạt ổn định, vấn đề sẽ nhanh chóng được khuếch đại.
Các chiến lược khắc phục quan trọng nhất (được sắp xếp theo tác động)
P0—Không nhồi nhét đầu ra công cụ lớn vào bối cảnh dài hạn
Đối với đầu ra công cụ rất lớn:
- Giữ bản tóm tắt + đường dẫn/ID tham chiếu
- Tạo tác tệp văn bản tải trọng gốc
- Không giữ toàn bộ văn bản gốc trong lịch sử trò chuyện
Ưu tiên hạn chế những điều này danh mục:
- JSON lớn
- Danh sách thư mục dài
- Ảnh chụp nhanh toàn bộ trình duyệt
- Bản ghi đầy đủ của tác nhân phụ
P1—Đảm bảo rằng cơ chế nén thực sự có hiệu lực
Trong dữ liệu này, các vấn đề tương thích về cấu hình xuất hiện nhiều lần: khóa nén không hợp lệ
Điều này sẽ lặng lẽ tắt cơ chế tối ưu hóa.
Phương pháp đúng: Chỉ sử dụng các cấu hình tương thích với 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 quá trình nén đã được chấp nhận.
P1—Giảm tính tồn tại của văn bản lý luận
Tránh phát lại văn bản lý luận dài
Trong môi trường sản xuất: lưu các bản tóm tắt ngắn thay vì lý luận đầy đủ
P3—Cải thiện thiết kế bộ nhớ đệm nhanh chóng
Mục tiêu không phải là tối đa hóa cacheRead. Mục tiêu là sử dụng bộ đệm trên các tiền tố nhỏ gọn, ổn định, có giá trị cao.
Gợi ý:
- Đưa các quy tắc ổn định vào lời nhắc hệ thống
- Không đặt dữ liệu không ổn định vào tiền tố ổn định
- Tránh đưa một lượng lớn dữ liệu gỡ lỗi vào mỗi vòng
Kế hoạch dừng lỗ thực tế (nếu tôi phải xử lý nó vào ngày mai)
1. Tìm phiên có tỷ lệ đọc bộ đệm cao nhất
2. Thực hiện phiên chạy /compact
3. Thêm phần cắt bớt + tạo tác vào đầu ra của công cụ
4. Chạy lại số liệu thống kê về mã thông báo sau mỗi lần sửa đổi
Tập trung theo dõi bốn KPI:
cacheRead / TotalTokens
toolSử dụng avgTotal/call
>=Số lệnh gọi tới 100 nghìn mã thông báo
Tỷ lệ phiên tối đa
Dấu 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ệnh gọi mã thông báo hơn 100 nghìn là giảm đáng kể
tỷ lệ cacheRead giảm
trọng lượng cuộc gọi sử dụng công cụ giảm
Sự thống trị của một phiên duy nhất giảm
Nếu các chỉ báo này không thay đổi, điều đó có nghĩa là chính sách ngữ cảnh của bạn vẫn còn quá lỏng lẻo.
Tạo lại lệnh thử nghiệm
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 'session' \
--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 Tác nhân của bạn Mọi thứ dường như hoạt động tốt trong hệ thống nhưng chi phí vẫn tiếp tục tăng. Đây là câu hỏi cần kiểm tra trước: Bạn đang trả tiền cho suy luận mới hay bạn đang trả tiền để bối cảnh cũ được phát lại trên quy mô lớn?
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 sẽ rất rõ ràng: kiểm soát chặt chẽ dữ liệu được đưa vào bối cảnh dài hạn.
