OpenClaw เผาโทเค็น 21.5 ล้านตัวในหนึ่งวัน? 3 กลยุทธ์การปรับให้เหมาะสมทำให้ต้นทุนลดลงอย่างรวดเร็ว

ชื่อต้นฉบับ: Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)

ผู้เขียนต้นฉบับ: MOSHIII

ผู้แปล: Peggy, BlockBeats

หมายเหตุบรรณาธิการ: ในช่วงเวลาที่แอปพลิเคชัน Agent กำลังแพร่หลายอย่างรวดเร็ว หลายทีมพบปรากฏการณ์ที่ดูเหมือนขัดแย้ง: ระบบทำงานปกติทุกอย่าง แต่ต้นทุน token กลับเพิ่มสูงขึ้นอย่างต่อเนื่องโดยไม่รู้ตัว บทความนี้ผ่านการวิเคราะห์ภาระงาน OpenClaw จริงพบว่า สาเหตุของการระเบิดต้นทุนมักไม่ได้มาจากอินพุตของผู้ใช้หรือเอาต์พุตของโมเดล แต่มาจากการเล่นซ้ำแคชบริบท (cached prefix replay) ที่ถูกละเลย โมเดลอ่านบริบทประวัติขนาดใหญ่อย่างซ้ำซากในการเรียกใช้แต่ละรอบ ส่งผลให้เกิดการบริโภค token จำนวนมหาศาล

บทความนี้ใช้ข้อมูลเซสชันเฉพาะเจาะจง แสดงให้เห็นว่าผลลัพธ์ขนาดใหญ่จากเครื่องมือ สแนปช็อตเบราว์เซอร์ บันทึก JSON และอื่นๆ ถูกเขียนลงในบริบทประวัติอย่างต่อเนื่องอย่างไร และถูกอ่านซ้ำในวงจรของ agent

ผ่านกรณีศึกษานี้ ผู้เขียนได้เสนอแนวทางการปรับปรุงที่ชัดเจน: ตั้งแต่การออกแบบโครงสร้างบริบท การจัดการผลลัพธ์เครื่องมือ ไปจนถึงการกำหนดค่ากลไกการบีบอัด (compaction) สำหรับนักพัฒนาที่กำลังสร้างระบบ Agent นี่ไม่เพียงเป็นบันทึกการตรวจสอบทางเทคนิค แต่ยังเป็นคู่มือประหยัดเงินจริงๆ

ต่อไปนี้คือต้นฉบับ:

ฉันวิเคราะห์ภาระงาน OpenClaw จริงและพบรูปแบบที่ฉันคิดว่าผู้ใช้ Agent หลายคนน่าจะคุ้นเคย:

ปริมาณการใช้ token ดู "กระฉับกระเฉง"

การตอบกลับก็ดูปกติ

แต่การใช้ token กลับเพิ่มขึ้นแบบระเบิด

ต่อไปนี้คือการแยกโครงสร้าง สาเหตุรากเหง้า และเส้นทางการแก้ไขที่ปฏิบัติได้จริงจากการวิเคราะห์ครั้งนี้

TL;DR

ปัจจัยขับเคลื่อนต้นทุนที่ใหญ่ที่สุด ไม่ใช่ข้อความผู้ใช้ที่ยาวเกินไป แต่เป็นการเล่นซ้ำแคชคำนำหน้า (cached prefix) จำนวนมหาศาล

จากข้อมูลเซสชัน:

token ทั้งหมด: 21,543,714

cacheRead: 17,105,970 (79.40%)

input: 4,345,264 (20.17%)

output: 92,480 (0.43%)

พูดอีกอย่างคือ: ต้นทุนของการเรียกใช้ส่วนใหญ่ ไม่ได้มาจากการประมวลผลความตั้งใจใหม่ของผู้ใช้ แต่มาจากการอ่านบริบทประวัติขนาดใหญ่อย่างซ้ำซาก

ช่วงเวลา "เดี๋ยวนะ... มันเกิดขึ้นได้ยังไง?"

ฉันเคยคิดว่าการใช้ token สูงมาจาก: พรอมต์ผู้ใช้ที่ยาวมาก การสร้างเอาต์พุตจำนวนมาก หรือการเรียกใช้เครื่องมือที่มีราคาแพง

แต่รูปแบบที่ครอบงำจริงๆ คือ:

input: หลายร้อยถึงหลายพัน token

cacheRead: 170,000 ถึง 180,000 token ต่อการเรียกใช้แต่ละครั้ง

นั่นหมายความว่า โมเดลกำลังอ่านคำนำหน้าที่ใหญ่และคงที่เดียวกันซ้ำๆ ในทุกๆ รอบ

ขอบเขตข้อมูล

ฉันวิเคราะห์ข้อมูลในสองระดับ:

1. บันทึกเวลาทำงาน (runtime logs)

2. บันทึกการสนทนา (session transcripts)

สิ่งที่ต้องชี้แจง:

บันทึกเวลาทำงานใช้หลักเพื่อสังเกตสัญญาณพฤติกรรม (เช่น การรีสตาร์ท ข้อผิดพลาด ปัญหาการกำหนดค่า)

สถิติ token ที่แม่นยำมาจากฟิลด์ usage ใน session JSONL

สคริปต์ที่ใช้:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

ไฟล์วิเคราะห์ที่สร้าง:

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 ถูกใช้ไปที่ไหนจริงๆ?

1) การรวมตัวของเซสชัน

มีหนึ่งเซสชันที่ใช้ token สูงกว่าอื่นๆ อย่างมาก:

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

จากนั้นลดลงอย่างรวดเร็ว:

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

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

2) การรวมตัวของพฤติกรรม

token ส่วนใหญ่มาจาก:

toolUse: 16,372,294

stop: 5,171,420

แสดงว่าปัญหาหลักอยู่ที่วงจรการเรียกใช้เครื่องมือ (tool call chain loop) ไม่ใช่การแชทปกติ

3) การรวมตัวของเวลา

จุดสูงสุดของ token ไม่ได้เกิดขึ้นแบบสุ่ม แต่รวมตัวอยู่ในช่วงเวลาไม่กี่ชั่วโมง:

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

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

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

ในแคชคำนำหน้าขนาดใหญ่นั้นมีอะไรบ้าง?

ไม่ใช่เนื้อหาการสนทนา แต่ส่วนใหญ่เป็นผลลัพธ์ขั้นกลางขนาดใหญ่:

บล็อกข้อมูล toolResult ขนาดใหญ่

ร่องรอยการให้เหตุผล / การคิด (reasoning / thinking traces) ที่ยาว

สแนปช็อต JSON ขนาดใหญ่

รายการไฟล์

ข้อมูลที่ดึงมาจากเบราว์เซอร์

บันทึกการสนทนาของ Agent ย่อย

ในเซสชันที่ใหญ่ที่สุด ปริมาณอักขระประมาณ:

toolResult:text: 366,469 อักขระ

assistant:thinking: 331,494 อักขระ

assistant:toolCall: 53,039 อักขระ

เมื่อเนื้อหาเหล่านี้ถูกเก็บรักษาไว้ในบริบทประวัติ การเรียกใช้ครั้งต่อๆ ไปแต่ละครั้งอาจอ่านซ้ำผ่านแคชคำนำหน้า

ตัวอย่างเฉพาะเจาะจง (จากไฟล์เซสชัน)

บล็อกบริบทขนาดใหญ่ปรากฏซ้ำๆ ในตำแหน่งต่อไปนี้:

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

บันทึก JSON เกตเวย์ขนาดใหญ่ (ประมาณ 37,000 อักขระ)

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

สแนปช็อตเบราว์เซอร์ + การห่อหุ้มความปลอดภัย (ประมาณ 29,000 อักขระ)

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

ผลลัพธ์รายการไฟล์ขนาดใหญ่ (ประมาณ 41,000 อักขระ)

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

สแนปช็อตสถานะ session/status + โครงสร้างพรอมต์ขนาดใหญ่ (ประมาณ 30,000 อักขระ)

"การสูญเสียจากเนื้อหาซ้ำซ้อน" เทียบกับ "ภาระการเล่นซ้ำแคช"

ฉันยังวัดสัดส่วนของเนื้อหาซ้ำซ้อนภายในหนึ่งการเรียกใช้:

สัดส่วนการซ้ำซ้อนประมาณ: 1.72%

มีอยู่จริง แต่ไม่ใช่ปัญหาหลัก

ปัญหาจริงคือ: ขนาดสัมบูรณ์ของแคชคำนำหน้าใหญ่เกินไป

โครงสร้างคือ: บริบทประวัติขนาดใหญ่, การอ่านซ้ำทุกรอบการเรียกใช้, โดยมีอินพุตใหม่เพียงเล็กน้อยซ้อนทับบนนั้น

ดังนั้นจุดเน้นการปรับปรุงไม่ใช่การกำจัดซ้ำซ้อน แต่เป็นการออกแบบโครงสร้างบริบท

ทำไมวงจร Agent ถึงมีแนวโน้มเกิดปัญหานี้เป็นพิเศษ?

กลไกสามอย่างเสริมกัน:

1. ผลลัพธ์เครื่องมือจำนวนมากถูกเขียนลงในบริบทประวัติ

2. วงจรเครื่องมือสร้างการเรียกใช้จำนวนมากที่มีช่วงเวลาสั้น

3. คำนำหน้าเปลี่ยนแปลงน้อย → แคชจะอ่านซ้ำทุกครั้ง

หาก context compaction ไม่ถูกกระตุ้นอย่างสม่ำเสมอ ปัญหาจะขยายตัวอย่างรวดเร็ว

กลยุทธ์การแก้ไขที่สำคัญที่สุด (เรียงตามผลกระทบ)

P0—อย่าใส่ผลลัพธ์เครื่องมือขนาดใหญ่ลงในบริบทระยะยาว

สำหรับผลลัพธ์เครื่องมือขนาดใหญ่เกินไป:

• เก็บสรุป + เส้นทางอ้างอิง / ID
• เขียน payload ดั้งเดิมลงในไฟล์ artifact
• อย่าเก็บข้อความเต็มไว้ในประวัติการแชท

จำกัดประเภทเหล่านี้เป็นลำดับแรก:

• JSON ขนาดใหญ่
• รายการไดเรกทอรียาว
• สแนปช็อตเบราว์เซอร์เต็มรูปแบบ
• บันทึกการสนทนาเต็มรูปแบบของ Agent ย่อย

P1—ตรวจสอบให้แน่ใจว่ากลไก compaction ทำงานจริง

ในข้อมูลชุดนี้ ปัญหาความเข้ากันได้ของการกำหนดค่าเกิดขึ้นหลายครั้ง: คีย์ compaction ไม่ถูกต้อง

สิ่งนี้จะปิดกลไกการปรับปรุงอย่างเงียบๆ

วิธีที่ถูกต้อง: ใช้เฉพาะการกำหนดค่าที่เข้ากันได้กับเวอร์ชัน

จากนั้นตรวจสอบ:

openclaw doctor --fix

และตรวจสอบบันทึกการเริ่มระบบเพื่อยืนยันว่า compaction ถูกยอมรับ

P1—ลดการคงอยู่ของข้อความการให้เหตุผล (reasoning)

หลีกเลี่ยงการเล่นซ้ำข้อความการให้เหตุผลยาวๆ

ในสภาพแวดล้อมการผลิต: บันทึกสรุปสั้นๆ แทนการให้เหตุผลแบบเต็ม

P3—ปรับปรุงการออกแบบแคชพรอมต์

เป้าหมาย ไม่ใช่การเพิ่ม cacheRead ให้มากที่สุด เป้าหมายคือการใช้แคชบนคำนำหน้าที่กะทัดรัด คงที่ และมีมูลค่าสูง

คำแนะนำ:

• ใส่กฎที่คงที่ลงใน system prompt
• อย่าใส่ข้อมูลที่ไม่คงที่ลงในคำนำหน้าที่คงที่
• หลีกเลี่ยงการฉีดข้อมูลดีบักจำนวนมากในทุกรอบ

แผนปฏิบัติการหยุดการสูญเสีย (หากฉันต้องจัดการพรุ่งนี้)

1. หาเซสชันที่มีสัดส่วน cacheRead สูงที่สุด

2. ดำเนินการ /compact กับเซสชันที่ควบคุมไม่ได้ (runaway session)

3. เพิ่มการตัดทอน + การแปลงเป็น artifact ให้กับผลลัพธ์เครื่องมือ

4. รันสถิติ token ใหม่หลังการแก้ไขแต่ละครั้ง

ติดตาม KPI สี่ประการเป็นพิเศษ:

cacheRead / totalTokens

toolUse avgTotal/call

จำนวนการเรียกใช้ที่มี token >=100k

สัดส่วนของเซสชันที่ใหญ่ที่สุด

สัญญาณแห่งความสำเร็จ

หากการปรับปรุงมีผล คุณควรเห็น:

การเรียกใช้ 100k+ token ลดลงอย่างเห็นได้ชัด

สัดส่วน cacheRead ลดลง

น้ำหนักการเรียกใช้ toolUse ลดลง

อิทธิพลของเซสชันเดียวลดลง

หากตัวชี้วัดเหล่านี้ไม่เปลี่ยนแปลง นั่นหมายความว่ากลยุทธ์บริบทของคุณยังคงหละหลวมเกินไป

คำสั่งสำหรับการทดลองซ้ำ

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

บทสรุป

หากระบบ Agent ของคุณดูเหมือนทำงานปกติทุกอย่าง แต่ต้นทุนกลับเพิ่มขึ้นอย่างต่อเนื่อง คุณสามารถตรวจสอบปัญหาหนึ่งก่อน: คุณกำลังจ่ายเงินสำหรับการอนุมานใหม่ หรือสำหรับการเล่นซ้ำบริบทเก่าขนาดใหญ่?

ในกรณีของฉัน ต้นทุนส่วนใหญ่มาจากการเล่นซ้ำบริบท

เมื่อคุณตระหนักถึงสิ่งนี้ ทางออกก็ชัดเจน: ควบคุมข้อมูลที่เข้าสู่บริบทระยะยาวอย่างเคร่งครัด

ลิงก์ต้นฉบับ