เราไม่ได้ปรับการใช้โทเคนเพียงเพื่อลดค่าใช้จ่าย แต่เพราะโทเคนคือวัตถุดิบของผลิตภัณฑ์ และความสูญเปล่าคือข้อบกพร่องของผลิตภัณฑ์

00 · ทำไม ActelosAI จึงเขียนเรื่องโทเคน

แก่นของ Generative Engine Optimization คือความเชื่อในคุณค่าของการสนทนากับโมเดลแนวหน้า เอเจนต์ของเราเรียกโมเดลเพื่อวัดว่าแบรนด์ปรากฏอย่างไรในคำตอบ AI และมีบทบาทในการปรับปรุงการปรากฏนั้นเพิ่มขึ้น ทุกคำถาม ทุกขั้นการให้เหตุผล ทุกหน้าที่ค้นคืน ล้วนเป็นโทเคน บริษัทที่ขาย “การเพิ่มประสิทธิภาพเอนจินสร้างคำตอบ” ต้องเริ่มจากใช้เอนจินเหล่านั้นเองอย่างมีประสิทธิภาพ

เราไม่ควรสอนลูกค้าเรื่อง Generative Engine Optimization ขณะที่บิลโทเคนของเราเองรั่วไหล ต้องใช้วินัยเดียวกันกับงานของเรา

01 · โทเคนเป็นโจทย์ผลิตภัณฑ์ ไม่ใช่แค่โจทย์ค่าใช้จ่าย

สัญชาตญาณทั่วไปคือมองค่าโทเคนเป็นรายการโครงสร้างพื้นฐานที่ต้องต่อรองราคา แต่มุมนี้ไม่เพียงพอ สำหรับบริษัท AI Native โทเคนคือเศรษฐศาสตร์ต่อหน่วย เป็นฐานต้นทุนของทุกสิ่งที่ส่งมอบ และสะสมผ่านทุกเอเจนต์ ลูกค้า และการลองใหม่

ปัญหาลึกกว่าบิล ความเป็นอิสระของเอเจนต์มีสิทธิ์สองประเภทที่แทบไม่เคยถูกแยก:

สิทธิ์ ความหมาย วิธีที่เราใช้
การลงมือทำ สิทธิ์ใช้เครื่องมือ เขียนไฟล์ รันโค้ด ให้ภายในขอบเขตชัดเจน
การใช้ทรัพยากร สิทธิ์ใช้จ่าย เรียก LLM และสร้างเอเจนต์ย่อย ให้อย่างจำกัดและแสดงให้เห็น

เหตุการณ์ภายในที่ผู้เขียนรายงานแสดงสิ่งที่เกิดได้เมื่อมองข้ามสิทธิ์ที่สอง งานเดียวขยายเป็น 12 เอเจนต์ย่อย → 265 คำขอ LLM → ประมาณ 19.8M โทเคน → ≈ ¥1000 ในเวลาไม่ถึงห้านาที ตัวเลขนี้เป็นรายงานภายในของผู้เขียน ไม่ใช่เกณฑ์ทดสอบควบคุมหรือผลลูกค้า รายละเอียด:

ตัวชี้วัด ค่า สิ่งที่บ่งชี้
โทเคนขาเข้า ~19.64M บริบทเป็นภาระหลัก
โทเคนขาออก ~0.13M โมเดลสร้างผลลัพธ์เพียงเล็กน้อย
การอ่านจากแคช 0 ทุกรอบ ไม่พบบันทึกการอ่านแคช ต้องตรวจสาเหตุระดับคำขอ

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

02 · โครงสร้างของบิลโทเคน

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

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

จึงเห็นว่าคำแนะนำ “เขียนพรอมป์ต์ให้สั้น” มักไม่ครบ ต้นทุนอยู่ในสิ่งที่แบกไป ไม่ใช่แค่สิ่งที่พิมพ์ การปรับปรุงต้องเริ่มที่สภาพแวดล้อม ได้แก่ คำสั่งระบบ นิยามเครื่องมือ และการจัดระเบียบสนทนา

03 · กรวยห้าชั้น

กรวยห้าชั้นต่อไปนี้เป็นลำดับเชิงปฏิบัติสำหรับทบทวนประสิทธิภาพโทเคน เริ่มจากด้านบน แล้ววัดว่าชั้นใดให้ผลมากที่สุดกับงานจริง

# ชั้น คำถาม ตัวอย่าง
1 ไม่ใช้ LLM ขั้นนี้ต้องใช้ความฉลาดหรือไม่ โค้ดที่ให้ผลแน่นอน แคช กฎ
2 ใช้โมเดลราคาต่ำลง ต้องใช้โมเดลแนวหน้าหรือไม่ ส่งงานประจำให้โมเดลเล็ก
3 ส่งโทเคนน้อยลง กำลังแบกสิ่งไม่จำเป็นหรือไม่ ย่อบริบท เอาประวัติเก่าออก
4 ลดราคาโทเคน จ่ายซ้ำเพื่อเนื้อหานี้หรือไม่ แคชพรอมป์ต์
5 ไม่จ่ายซ้ำ ใช้ผลคำขอนี้ซ้ำได้หรือไม่ ใช้ผลที่ตรวจสอบแล้วซ้ำ และ memoization

อย่าหยุดที่พรอมป์ต์สั้นลง ถามก่อนว่าจำเป็นต้องเรียกหรือไม่ และใช้บริบทซ้ำได้หรือไม่

04 · แคช: จุดเริ่มต้นที่ให้ผลมาก

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

ผู้ให้บริการ กลไก ข้อควรพิจารณา
Anthropic Prompt caching การเขียนแบบ 5 นาทีมักคิด 1.25× ของอินพุตพื้นฐาน แบบ 1 ชั่วโมง 2× อัตราอ่านขึ้นกับโมเดล
OpenAI Prompt caching ส่วนต้นที่เข้าเกณฑ์ ราคาเขียน และระยะเก็บต่างกันตามโมเดล prompt_cache_key ช่วยจัดเส้นทางได้แต่ไม่รับประกัน cache hit
Google Context caching Gemini 2.5 และใหม่กว่ารองรับ implicit caching ความยาวขั้นต่ำและราคาขึ้นกับโมเดล

อ้างอิงทางเทคนิค: Anthropic prompt caching, OpenAI prompt caching และ Google context caching ตรวจสอบเมื่อ 8 กันยายน 2026

วินัยสามข้อที่ทำให้แคชใช้งานได้จริง:

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

02 · อย่าทำให้สายต่อเนื่องขาด การแก้ช่วงต้นของสนทนาทำให้แคชหลังจุดนั้นเริ่มใหม่ ปฏิบัติต่อส่วนต้นร่วมเสมือนแก้ไม่ได้ ใช้การต่อท้ายแทนแทรกกลาง

03 · ตรวจว่าแคชทำงานจริง ในเหตุการณ์ที่รายงาน cacheReadTokens = 0 เป็นสัญญาณให้สอบสวน ไม่ใช่คำวินิจฉัยครบถ้วน ตรวจฟิลด์การใช้งานของผู้ให้บริการ ความยาวส่วนต้นที่เข้าเกณฑ์ การตั้งค่า อายุแคช และการเปลี่ยนคำขอ การขาดส่วนหัวสนทนาไม่ใช่คำอธิบายสากลของ cache miss ตัวชี้วัดแคชต้องเป็นส่วนหลักของระบบติดตาม มิฉะนั้นอาจกำลัง “ปรับปรุง” สิ่งที่ไม่ได้เชื่อมทำงาน

05 · จัดการบริบท: นำไปเฉพาะสิ่งที่งานต้องใช้

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

  • ย่อแต่เนิ่น ๆ และสม่ำเสมอ สนทนายาวสะสมรอบเก่าที่โมเดลต้องอ่านซ้ำ สรุปงานที่จบแล้วโดยยังเก็บการตัดสินใจและหลักฐานจำเป็น วัดผลประหยัดเทียบกับการเสียโอกาสใช้แคช
  • ปรับสภาพแวดล้อมให้พอดี ทบทวนว่า Memory, Rules, Skills และ MCP โหลดอะไรเข้าบริบทจริง โหลดเนื้อหาที่มีประโยชน์เมื่อถึงเวลาต้องใช้
  • ค้นคืนแทนสะสม การค้นหาเล็กและตรงเป้าดีกว่าหน้าต่างที่ยัดเต็ม ทั้งต้นทุนและคุณภาพคำตอบ

วินัยของบริบทคือการลด ไม่ใช่การเพิ่ม ทุกโทเคนที่ไม่มีจุดหมายเป็นภาระต่อทุกคำขอถัดไป

06 · เลือกโมเดลและใช้ผลลัพธ์มีโครงสร้าง

ไม่ใช่ทุกขั้นต้องใช้โมเดลแนวหน้า และไม่ใช่ทุกคำตอบต้องเป็นร้อยแก้ว

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

ปรับระดับการคิด คู่ reasoning.effort / text.verbosity ของ OpenAI ควบคุมแยกกันในโมเดลที่รองรับ ว่า คิดลึกแค่ไหน และ พูดมากแค่ไหน ลดสำหรับงานประจำ เพิ่มเมื่อความลึกคุ้มค่า

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

07 · สถาปัตยกรรมเอเจนต์: จำนวนโทเคนรวมไม่เท่ากับต้นทุน

ข้อแตกต่างสำคัญคือ จำนวนโทเคนรวมเพียงอย่างเดียวกำหนดค่าใช้จ่ายไม่ได้ ในการเปรียบเทียบภายในที่ผู้เขียนรายงาน Claude Code Internal ใช้คำขอเล็ก 22 ครั้ง ค่าใช้จ่าย ¥9.05 ขณะที่ CodeBuddy IDE ใช้คำขอใหญ่ 2 ครั้ง ค่าใช้จ่าย ¥18.34 สูงราวสองเท่าทั้งที่ใช้โทเคนน้อยกว่ามาก ต้องเทียบโมเดล สัดส่วนอินพุต/เอาต์พุต การใช้แคช และเงื่อนไขคิดเงินก่อนสรุปว่าเป็นผลจากสถาปัตยกรรม ตัวเลขอธิบายการรันที่บันทึกไว้ ไม่ใช่การจัดอันดับผลิตภัณฑ์ภายใต้เงื่อนไขเท่าเทียมกัน

หลักสถาปัตยกรรมสามข้อ:

  • จำกัดต้นไม้เอเจนต์ย่อย ความลึกและจำนวนกิ่งทำให้คำขอเพิ่มแบบทวีคูณ จำกัดทั้งคู่และกำหนดให้มีเหตุผลในการสร้าง
  • เลือกคำขอที่มีขอบเขตพอดี แบ่งงานเมื่อช่วยลดต้นทุนรวมโดยไม่เสียบริบทหรือคุณภาพจำเป็น จำนวนคำขอมากขึ้นไม่ได้ถูกลงเสมอ
  • แสดงค่าใช้จ่ายเป็นส่วนหลักของผลิตภัณฑ์ เอเจนต์ควรแสดงต้นทุนสะสม อัตรา cache hit และเพดานใช้จ่าย ไม่ซ่อนไว้ในบิลสิ้นเดือน

08 · ตัวเลขที่ควรติดตาม

สิ่งที่ไม่วัดก็จัดการไม่ได้ ตัวชี้วัดเจ็ดข้อเมื่อดูร่วมกันจะบอกว่ายุทธศาสตร์โทเคนได้ผลหรือไม่:

ตัวชี้วัด สิ่งที่เปิดเผย
ต้นทุนต่องาน เศรษฐศาสตร์ต่อการรันเอเจนต์
อัตรา cache hit กลไกประหยัดหลักทำงานหรือไม่
อัตราส่วนอินพุต/เอาต์พุต บริบทบวมเกินไปหรือไม่
โทเคนต่อผลลัพธ์ ประสิทธิภาพต่อหน่วยคุณค่าที่ส่งมอบ
ความหน่วง P50 / P90 / P99 สุขภาพของการเลือกเส้นทางโมเดลและแคช
อัตราลองใหม่ จุดที่แยกข้อมูลหรือให้ผลแน่นอนล้มเหลว
ต้นทุนต่อแบรนด์/ลูกค้า มุม GEO: ส่วนต่างกำไรต่องาน

ต้นทุนต่องานที่เสร็จสำเร็จคือเข็มทิศทางเศรษฐศาสตร์ โดยมีคุณภาพ การควบคุม และความหน่วงเป็นข้อจำกัด

09 · ความหมายสำหรับ ActelosAI

สำหรับ ActelosAI ประสิทธิภาพโทเคนอยู่ในงานออกแบบความสามารถ Actelos Delta ถามว่าผลใดคุ้มที่จะมุ่งไป และหลักฐานใดแสดงการเปลี่ยนแปลงที่มีประโยชน์ Actelos Forge นำการตัดสินใจนั้นสู่งานวิศวกรรม ทั้งเลือกโมเดล บริบท สิทธิ์ การประเมิน และทรัพย์สินสำหรับใช้งานต่อ

GEO ใน Growth Marketing เป็นบริบทที่นำวินัยนี้มาใช้ได้ชัด:

  • ออนโทโลยีร่วมที่แคชได้ เก็บนิยามหมวด ข้อเท็จจริงแบรนด์ และคลังคำถามที่ได้รับอนุญาตไว้ในส่วนต้นคงที่และใช้ซ้ำได้ เมื่อผู้ให้บริการรองรับ
  • งบรายวันต่อแบรนด์ กำหนดเพดานใช้ทรัพยากรที่ตกลง เมื่อถึงเพดานให้ทบทวน ไม่ใช่รอเจอบิลที่ไม่คาดคิด
  • เลือกโมเดลตามชนิดคำถาม ใช้การตรวจแบบแน่นอนหรือโมเดลเล็กเมื่อเพียงพอ เก็บการใช้วิจารณญาณลึกไว้ให้คำถามที่จำเป็นและพิสูจน์ด้วยการประเมิน
  • ติดตามก่อนปรับปรุง เราไม่ “เพิ่มประสิทธิภาพ” สิ่งที่มองไม่เห็น

10 · ทิศทาง: จากคิดราคาตามโทเคนสู่คิดตามผลลัพธ์

ราคาโทเคนเป็นความตรงไปตรงมาในช่วงเปลี่ยนผ่าน เป็นสิ่งที่มี ไม่ใช่สิ่งที่ต้องการ ลูกค้าไม่ได้ซื้อ “โทเคนน้อยลง” แต่ซื้อการที่แบรนด์ปรากฏ ถูกอ้างอิง และน่าเชื่อถือในคำตอบ AI เมื่อโมเดลใช้เหตุผลและแคชพัฒนาขึ้น เราคาดว่าโมเดลการค้าจะเชื่อมค่าบริการกับผลงานและผลลัพธ์ที่มีประโยชน์มากขึ้น แทนปริมาณอินพุตอย่างเดียว

แต่การเปลี่ยนผ่านนี้ไม่ใช่เหตุให้ลดวินัย ระหว่างที่ราคายังไม่ตามคุณค่า บริษัทที่ปฏิบัติต่อโทเคนเหมือนวัตถุดิบ โดยวัด แคช เลือกเส้นทาง และกำหนดขอบเขต จะทำงานได้ดีกว่าบริษัทที่มองเพียงเป็นบิล วินัยต้นทุนไม่ขัดกับความทะเยอทะยาน แต่ทำให้ส่งมอบความทะเยอทะยานนั้นได้

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