Level 3 · ใช้ขั้นโปรscheduleอ่าน 17 นาที

Token optimization จัด context ให้คุ้ม ไม่ใช่แค่ให้สั้น

starsTL;DR

token คือหน่วยที่ทำให้ context กลายเป็นต้นทุนจริง บทนี้แกะว่า token หายไปตรงไหน prompt caching ช่วยอะไร ทำไมภาษาไทยแพงกว่า และควรเลือก subscription หรือ API แบบไหนให้ไม่จ่ายเกินจำเป็น

Token optimization จัด context ให้คุ้ม ไม่ใช่แค่ให้สั้น

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

คำถามที่ตามมาคือ token หายไปไหน

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

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

Token ไม่ได้อยู่แค่ในข้อความที่คุณพิมพ์

เวลาเห็นกล่องแชท คุณอาจรู้สึกว่าคุณใช้ token ตามความยาวข้อความของตัวเอง พิมพ์สั้นก็ควรถูก พิมพ์ยาวก็ควรแพง นั่นถูกแค่เสี้ยวเดียว

ในงาน AI จริง token มาจากทุกอย่างที่ถูกส่งให้ model เห็น ไม่ใช่แค่ประโยคใหม่ของคุณ

ลองแตกกอง context ออกเป็นชิ้น ๆ

  • system prompt คำสั่งตั้งต้นที่คุณไม่เห็น แต่ถูกโหลดก่อนเสมอ
  • tool definitions รายการเครื่องมือที่ model เรียกใช้ได้
  • project instructions เช่น CLAUDE.md, AGENTS.md, rules, memory หรือ skill descriptions
  • conversation history ประวัติแชททั้งหมดที่ยังอยู่ใน context
  • files ไฟล์ที่แนบ ไฟล์ที่ AI อ่าน หรือเอกสารที่คุณ paste เข้าไป
  • tool outputs ผลลัพธ์จากการค้นเว็บ รันคำสั่ง อ่าน log หรือ test output
  • your message ข้อความล่าสุดของคุณ
  • model output คำตอบที่ model สร้างออกมา ซึ่งจะกลับเข้า context ในรอบถัดไป

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

💡 ใจความสำคัญ: ค่า token ของหนึ่งรอบไม่ได้เท่ากับความยาวข้อความล่าสุดของคุณ แต่เท่ากับทุกอย่างที่ model ต้องเห็นเพื่อให้ตอบข้อความล่าสุดนั้นได้

ใน Claude Code มีคำสั่ง /context ไว้ดูว่าอะไรใช้พื้นที่ context อยู่ และเอกสาร Claude Code ระบุชัดว่า token cost เพิ่มตามขนาด context ยิ่ง Claude ต้องประมวลผล context มาก ยิ่งใช้ token มาก ส่วนคำสั่ง /usage (หรือชื่อเก่า /cost ที่ยังใช้ได้) จะแสดงการใช้งานของ session นั้น ถ้าเป็นสมาชิกรายเดือนจะเห็นเป็นแถบโควตาของแผน ถ้า login ด้วย API key จะเห็นเป็นตัวเลขค่าใช้จ่ายโดยประมาณ

ต้นทุนมีสองฝั่ง: input กับ output

เวลาคิดต้นทุน AI อย่ามองแค่สิ่งที่คุณส่งเข้าไป ต้องมองสองฝั่ง

input token คือ token ที่คุณส่งเข้าไปให้ model อ่าน ทั้งคำสั่งระบบ ประวัติแชท ไฟล์ และ prompt ล่าสุด

output token คือ token ที่ model สร้างกลับมาเป็นคำตอบ

สองฝั่งนี้คิดราคาไม่เท่ากันเสมอ และบ่อยครั้ง output แพงกว่า input เพราะการสร้างคำตอบใหม่ทีละ token ใช้ทรัพยากรมากกว่าการอ่าน token ที่มีอยู่แล้ว ตัวอย่าง ณ วันที่ 9 กรกฎาคม 2026 หน้า pricing ของ Claude ระบุ Sonnet 5 ที่ $3 ต่อ 1 ล้าน input token และ $15 ต่อ 1 ล้าน output token (ช่วงเปิดตัวถึงสิ้นเดือนสิงหาคม 2026 ลดเหลือ $2 กับ $10) ส่วน Haiku 4.5 อยู่ที่ $1 input และ $5 output ต่อ 1 ล้าน token สังเกตว่า output แพงกว่า input ราวห้าเท่าทั้งคู่ หน้า pricing ของ OpenAI ก็ใช้โครงสร้างคล้ายกัน คือแยก input, cached input, output ต่อ 1 ล้าน token

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

ลองดูสองงานนี้

งานแรก คุณให้ AI อ่าน brief ยาว 20 หน้า แล้วตอบสรุป 5 bullet งานนี้ input หนัก output เบา

งานที่สอง คุณให้ AI เขียนบทความ 10 แบบ จาก brief สั้น ๆ งานนี้ input เบา output หนัก

ทั้งสองงานใช้ AI เหมือนกัน แต่ต้นทุนคนละหน้าตา วิธี optimize จึงไม่เหมือนกัน งานแรกต้องลดของที่ส่งเข้า งานที่สองต้องคุมความยาวและจำนวนเวอร์ชันที่ให้มันสร้าง

ลองทำดู: แยก input-heavy กับ output-heavy

เปิดงานที่คุณทำกับ AI บ่อย ๆ แล้วลองตอบเองว่า งานนี้หนักฝั่งไหน

งานนี้ input-heavy หรือ output-heavy
1. สิ่งที่ฉันให้ AI อ่านยาวแค่ไหน
2. สิ่งที่ฉันให้ AI เขียนกลับยาวแค่ไหน
3. ถ้าจะลด token ควรลดของที่ให้มันอ่าน หรือคุมของที่ให้มันเขียน

แค่แยกสองฝั่งนี้ได้ คุณจะเลิก optimize แบบมั่ว ๆ เพราะงานคนละชนิดต้องประหยัดคนละจุด

Prompt caching: ส่งซ้ำเหมือนเดิม แต่ถูกลง

ตอนนี้มาถึงเรื่องที่คนสับสนง่ายที่สุด คือ prompt caching

จากบท 2.1.3 คุณรู้แล้วว่า model ไม่มีความจำ และ harness ต้องส่ง context กลับเข้าไปใหม่ทุก turn คำถามคือ ถ้าส่งซ้ำทุกครั้ง แปลว่าต้องจ่ายเต็มทุกครั้งหรือเปล่า

คำตอบคือ ไม่เสมอไป

prompt caching คือกลไกที่ฝั่ง API จำได้ว่า "ส่วนต้นของกองนี้เคยประมวลผลไปแล้ว" เช่น system prompt, tool definitions, CLAUDE.md, memory หรือประวัติช่วงต้นที่ยังเหมือนเดิม ถ้ารอบใหม่ส่งกองที่มีส่วนต้นเหมือนเดิม ระบบไม่ต้องประมวลผลส่วนนั้นเต็มราคาอีกครั้ง แต่ดึงจาก cache แทน

จุดสำคัญคือ caching ไม่ได้แปลว่าไม่ส่งซ้ำ เนื้อหายังอยู่ใน context เหมือนเดิม model ยังต้องเห็นกองครบเพื่อทำงานต่อได้ สิ่งที่เปลี่ยนคือฝั่งผู้ให้บริการไม่ต้องคิดงานประมวลผลซ้ำเต็ม ๆ กับส่วนที่เหมือนเดิม และจึงคิดราคาถูกลง

เอกสาร Claude API ระบุว่า cache read คิดที่ 10% ของ input price ปกติ ส่วน cache write มีต้นทุนตอนเก็บเข้า cache ครั้งแรก เช่น 5-minute cache write คิด 1.25 เท่าของ input ปกติ และ 1-hour cache write คิด 2 เท่า เอกสารหน้าเดียวกันสรุปจุดคุ้มทุนไว้ชัดว่า cache แบบ 5 นาทีคุ้มตั้งแต่ถูกอ่านซ้ำครั้งแรก ส่วนแบบ 1 ชั่วโมงคุ้มตั้งแต่ถูกอ่านซ้ำครั้งที่สอง

ถ้าเปรียบเทียบกับร้านถ่ายเอกสาร รอบแรกคุณเอาเอกสาร 100 หน้าไปให้ร้านถ่ายแม่แบบไว้ แพงกว่าปกตินิดหน่อย แต่รอบต่อ ๆ ไป ถ้า 90 หน้าแรกเหมือนเดิม ร้านไม่ต้องจัดหน้าใหม่ทั้งหมด แค่หยิบแม่แบบเดิมมาใช้แล้วเพิ่มหน้าท้ายใหม่ ค่าทำงานเลยถูกลง

จุดที่เปรียบเทียบนี้ใช้ไม่ได้คือ cache ไม่ใช่ความจำของ model และไม่ใช่การเก็บความลับไว้ในหัว AI มันเป็นกลไกลดงานซ้ำของระบบประมวลผลเท่านั้น ถ้า context เปลี่ยนตรงต้นกองมากเกินไป cache อาจพลาด ถ้า compact แล้วประวัติถูกสรุปใหม่ conversation layer ก็ไม่ใช่ prefix เดิมอีกต่อไป

💡 ใจความสำคัญ: prompt caching ทำให้การส่ง context เดิมซ้ำถูกลงและเร็วขึ้น แต่มันไม่ได้ยกเลิกการส่งซ้ำ และไม่ได้ทำให้ model มีความจำ

เมนู optimize: ลดของรก ไม่ใช่ลดของจำเป็น

การลด token ที่ดีไม่ใช่การทำให้ prompt สั้นที่สุดแบบตัดมั่ว ๆ เพราะถ้าคุณตัด context สำคัญออก คำตอบจะถูกลงแต่แย่ลง ประหยัดแบบนั้นไม่คุ้ม

เป้าหมายที่ถูกคือ ตัดของที่ไม่เกี่ยวออก และทำให้ของสำคัญอยู่ชัดที่สุด

เมนูที่ใช้ได้จริงมีหลายแบบ

เริ่มใหม่เมื่อเปลี่ยนงาน ถ้างานใหม่ไม่เกี่ยวกับงานเดิม เปิดแชทใหม่หรือใช้ /clear อย่าพกประวัติแชทเก่าที่ไม่เกี่ยวไปทุก turn

ใช้ handoff แทนประวัติยาว ถ้างานเดิมยาวมาก ให้สรุปเป้าหมาย decision ข้อห้าม และ next step แล้วเริ่ม session ใหม่ด้วย handoff ที่สะอาด

ใช้ compact เมื่อยังทำงานเดิมต่อ ถ้าไม่อยากเริ่มใหม่เพราะยังต้องเก็บเส้นเรื่องเดิม ใช้ compact ในจังหวะพักงาน ไม่ใช่รอให้ auto-compaction เกิดกลางงาน

ใช้ sub-agent กับงานย่อยที่ข้อมูลดิบเยอะ ให้ผู้ช่วยแยกไปอ่านเว็บ ไล่ log หรือเปิดไฟล์จำนวนมาก แล้วส่งกลับมาเฉพาะ summary ไม่ลากข้อมูลดิบทั้งหมดเข้ากองหลัก

ตัดไฟล์ก่อนโยนเข้า AI อย่า paste เอกสารทั้งเล่มถ้าต้องการแค่หน้าเดียว อย่าแนบทั้งโฟลเดอร์ถ้าถามเรื่องไฟล์เดียว เลือกชิ้นที่เกี่ยวจริง ๆ

เลือก model ให้ถูก step ไม่ใช่ทุกงานต้องใช้ model แพงสุด งานจัดรูปแบบ แปลงข้อมูล แยกหมวด หรือร่างหยาบ อาจใช้ model เล็กกว่าได้ แล้วค่อยใช้ model ใหญ่กับขั้นที่ต้องใช้ judgment สูง

คุม output ถ้าคุณต้องการ 5 แบบ อย่าสั่ง "ทำมาเยอะ ๆ" ให้บอกจำนวนและความยาว ถ้าต้องการ outline อย่าให้เขียนบทเต็มก่อน

ใช้ retrieval แทนการโยนเอกสารทั้งก้อน ถ้ามีเอกสารจำนวนมาก วิธีที่ดีกว่าคือค้นเฉพาะส่วนที่เกี่ยวมาใส่ context ไม่ใช่ยัดทุกหน้าเข้าไปเสมอ ในวงการเรียกแนวคิดนี้ว่า retrieval หรือ RAG แต่ผู้ใช้ทั่วไปจำแค่ว่า ค้นชิ้นที่เกี่ยว ดีกว่าหอบตู้เอกสารทั้งตู้มาวางบนโต๊ะ

ลองทำดู: ขอ AI ทำ token diet ให้แชทของคุณ

ในแชทยาวที่กำลังทำงานอยู่ ลองพิมพ์ว่า

ช่วยทำ token diet ให้บทสนทนานี้หน่อย
1. อะไรใน context ตอนนี้ยังจำเป็น
2. อะไรน่าจะไม่เกี่ยวแล้ว
3. ถ้าจะเปิดแชทใหม่ ควรย้ายอะไรไปเป็น handoff
4. ควรตัดไฟล์หรือข้อมูลส่วนไหนออก

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

ทำไมภาษาไทยทำให้เรื่องนี้สำคัญกว่าเดิม

สำหรับคนไทย token optimization ไม่ใช่เรื่องหรู มันเป็นเรื่องประหยัดจริง

ภาษาไทยไม่มีช่องว่างระหว่างคำแบบภาษาอังกฤษ และ tokenizer ของ model ส่วนใหญ่ถูกฝึกจากข้อมูลภาษาอังกฤษมากกว่า ผลคือประโยคภาษาไทยที่ความหมายเท่ากับภาษาอังกฤษมักถูกหั่นเป็น token มากกว่า บทกลไก LLMวางกรอบไว้ที่ประมาณ 3 ถึง 5 เท่า แล้วแต่ข้อความและ model ตัวเลขนี้คือกรณีแย่สุด tokenizer รุ่นใหม่ที่ฝึกกับหลายภาษาช่วยให้ช่องว่างนี้แคบลงเรื่อย ๆ

แปลเป็นภาษาบัญชีคือ ถ้าคนอังกฤษส่ง brief หนึ่งหน้าแล้วใช้ 1,000 token คนไทยอาจส่ง brief ความหมายเท่ากันแล้วใช้ 3,000 ถึง 5,000 token ในบางกรณี พอใช้ API ความต่างนี้โผล่เป็นเงินทันที พอใช้ subscription ความต่างนี้โผล่เป็นโควตาที่หมดเร็วขึ้นหรือ session ที่หนักขึ้น

มุมที่เจ็บคือคนไทยมักเจอ "จ่ายสองต่อ"

ต่อแรก ภาษาไทยกิน token มากกว่า จึงใช้ทรัพยากรมากกว่า

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

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

💡 ใจความสำคัญ: สำหรับงานภาษาไทย การจัด context ให้คมสำคัญกว่าปกติ เพราะ token บานเร็วกว่า และถ้าใช้ API บิลจะสะท้อนความบานนั้นตรง ๆ

ดู token usage ยังไง

วิธีดู token ขึ้นกับเครื่องมือที่คุณใช้

ถ้าใช้ Claude Code ให้เริ่มจาก /context เพื่อดูว่า context ถูกใช้อะไรอยู่ แล้วใช้ /usage ดูการใช้งานของ session ปัจจุบัน สมาชิกรายเดือนจะเห็นแถบโควตาของแผน ส่วนคน login ด้วย API key จะเห็นค่าใช้จ่ายโดยประมาณ (/cost เป็นชื่อเก่าของคำสั่งเดียวกัน ยังพิมพ์ได้) ส่วน /model ใช้ดูและเปลี่ยน model ที่บัญชีคุณใช้ได้

ถ้าใช้ Claude Code ผ่าน subscription หรือ enterprise seat คุณอาจไม่เห็นบิลต่อ token แต่ usage ยังถูก metered เป็นโควตาหรือ pool ของ plan อยู่ดี เอกสาร help ของ Claude Code ระบุว่าการ sign in แบบ subscription หรือ enterprise จะเจอรูปแบบ limit/reset ส่วนการใช้ API key เป็น pay-as-you-go คิดตาม token กับบัญชี API

ถ้าใช้ API โดยตรง ให้ดู usage dashboard ของผู้ให้บริการ และดู response usage fields เช่น input tokens, output tokens, cache creation tokens, cache read tokens ขึ้นกับ API ที่ใช้ ตัวเลขพวกนี้สำคัญเพราะบิลจริงไม่ได้มีแค่ input กับ output ปกติ แต่ยังมี cached input และ batch discount ได้ด้วย

ถ้าใช้แอปแชททั่วไปอย่าง ChatGPT หรือ Claude บนเว็บ คุณมักไม่เห็น token breakdown ราย turn แบบละเอียด สิ่งที่ดูได้คือพฤติกรรมของแชท เช่น เริ่มช้า เริ่มหลุด เริ่มเตือน limit หรือใช้โควตาเร็วผิดปกติ วิธีรับมือยังเหมือนเดิม คือเริ่มใหม่เมื่อเปลี่ยนงานและไม่ลาก context ที่ไม่เกี่ยว

Subscription vs API: ไม่ได้ถูกกว่าแพงกว่าเสมอไป

คำถามยอดฮิตคือ ควรจ่ายรายเดือนหรือใช้ API ดีกว่า

คำตอบคือขึ้นกับรูปแบบงาน ไม่ใช่ขึ้นกับว่าอันไหน "เก่งกว่า"

Subscription เช่น Pro, Max, Team เหมาะกับคนที่นั่งใช้ AI เองทุกวัน เปิดแชท คิดงาน เขียนงาน ทำ research ใช้ Claude Code หรือ ChatGPT ในฐานะผู้ช่วยส่วนตัว คุณจ่ายราคาคงที่ ได้โควตาตาม plan และไม่ต้องคิดเงินทุก turn เหมือนบุฟเฟต์ที่มีเพดาน

API เหมาะกับงานที่โปรแกรมเรียก AI เอง เช่น automation, batch processing, ฝัง AI ใน product, ระบบหลังบ้าน, workflow ที่ต้องรันตามเวลา หรือการวัดต้นทุนละเอียดระดับ request API คิดตาม token ใช้เท่าไหร่จ่ายเท่านั้น ไม่ใช้ก็ไม่จ่าย แต่ถ้าออกแบบ context แย่ บิลก็พองเร็วมาก

ณ วันที่ 9 กรกฎาคม 2026 หน้า pricing ของ Claude แสดงราคาสมาชิกแยกจากราคา API และหน้า API pricing คิดต่อ 1 ล้าน token ตาม model เช่น Haiku 4.5, Sonnet 5, Opus 4.8 ส่วน OpenAI pricing ก็คิดแยก input, cached input, output และบางหมวดมีราคา batch หรือ priority ต่างกัน ตัวเลขเหล่านี้เปลี่ยนได้ จึงควรตรวจหน้า pricing สดก่อนตัดสินใจจริง

กฎภาษาคนคือ

  • ถ้าคุณเป็นคนใช้เองทุกวัน เลือก subscription ก่อน
  • ถ้าคุณต้องให้ระบบเรียก AI เอง เลือก API
  • ถ้างานเป็น batch จำนวนมากและไม่รีบ API อาจถูกมากเมื่อใช้ batch หรือ caching ถูกวิธี
  • ถ้างานเป็นแชทยาว ๆ ภาษาไทยโดยคนหนึ่งคน subscription มักสบายใจกว่า API
  • ถ้าต้องคุมต้นทุนองค์กร ให้ตั้ง spend limit, dashboard, และ policy ตั้งแต่วันแรก

อย่าเอาค่า subscription ไปเทียบกับ API แบบ "ทำไมฉันจ่ายรายเดือนแล้วยังต้องจ่าย API" เพราะมันคนละบริการ Subscription คือที่นั่งคนใช้แอป API คือวัตถุดิบให้โปรแกรมเรียก model ถ้าคุณไม่ได้สร้าง automation หรือ product คุณอาจไม่ต้องแตะ API เลย

Monitoring: กันบิลบานก่อน ไม่ใช่หลัง

เรื่องต้นทุน AI พังง่ายที่สุดตอนคนคิดว่า "ลองแป๊บเดียวคงไม่เท่าไหร่"

งานเล็กที่วนซ้ำอัตโนมัติได้ สามารถกลายเป็นบิลใหญ่ได้เร็ว เพราะมันไม่ได้เหนื่อย ไม่ได้ง่วง และไม่รู้จักหยุดถ้าคุณไม่ตั้งขอบเขต เช่น agent ที่รัน loop ตรวจไฟล์ซ้ำ ๆ หรือ workflow ที่ส่งเอกสารทั้งก้อนเข้า model ทุกครั้งที่มี trigger ใหม่

ก่อนใช้งานจริง ควรมีอย่างน้อย 5 อย่าง

  • ตั้ง monthly budget หรือ spend limit ใน dashboard ถ้าผู้ให้บริการมี
  • แยก API key ตามโปรเจกต์หรือ environment เพื่อรู้ว่าอะไรใช้เงิน
  • log input token, output token, cache read, cache write ต่อ request
  • ตั้ง alert เมื่อใช้งานผิดปกติ เช่น token พุ่งเกินค่าเฉลี่ย
  • ทดสอบด้วยข้อมูลชุดเล็ก แล้วคูณขึ้นเป็นปริมาณจริงก่อนปล่อยรันยาว

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

ลองทำดู: คำนวณต้นทุนต่อชิ้นแบบหยาบ

เลือกงานหนึ่งอย่าง เช่น สรุป feedback ลูกค้า 1 รายการ แล้วให้ AI ช่วยคำนวณแบบหยาบ

ช่วยทำ cost estimate แบบหยาบสำหรับงานนี้
สมมติ input ประมาณ ___ token ต่อรายการ
output ประมาณ ___ token ต่อรายการ
ทำทั้งหมด ___ รายการต่อเดือน
ให้แยก input, output, cached input ถ้ามี และแปลงเป็นเงินบาทด้วยอัตรา ___ บาทต่อดอลลาร์

ตัวเลขไม่ต้องเป๊ะตั้งแต่แรก เป้าหมายคือเปลี่ยนความรู้สึกว่า "ไม่น่าแพง" ให้กลายเป็นสมมติฐานที่ตรวจได้

สรุป: ประหยัด token คือประหยัดความสนใจของ AI

Token optimization ไม่ใช่เทคนิคขี้เหนียว มันคือการจัดความสนใจของ AI ให้ถูกที่

ทุก token ที่ไม่เกี่ยวแย่งพื้นที่จาก token ที่เกี่ยว ทุกไฟล์ที่โยนเข้าไปทั้งก้อนทำให้ model ต้องแบกของมากขึ้น ทุกคำตอบยาวที่ไม่จำเป็นเพิ่ม output cost และกลับมากิน context ในรอบถัดไป ส่วนภาษาไทยทำให้บทเรียนนี้คมขึ้น เพราะความหมายเท่าเดิมมักกิน token มากกว่า

วิธีที่ดีจึงไม่ใช่ทำ prompt ให้สั้นที่สุด แต่คือทำ context ให้คมที่สุด ใส่ของที่จำเป็น ตัดของที่ไม่เกี่ยว ใช้ handoff เมื่อ session เริ่มรก ใช้ sub-agent เมื่อข้อมูลดิบเยอะ ใช้ compact เมื่อยังต้องเดินงานเดิมต่อ ใช้ model ให้เหมาะกับ step และตั้ง monitoring ก่อนปล่อยงานอัตโนมัติ

พอคุณเข้าใจ token คุณจะเริ่มเห็น AI เป็นระบบต้นทุน ไม่ใช่กล่องวิเศษ คุณจะรู้ว่าเมื่อไหร่ควรเปิดแชทใหม่ เมื่อไหร่ควรสรุป เมื่อไหร่ควรใช้ API เมื่อไหร่ subscription พอแล้ว และทำไมคนไทยต้องระวัง context บวมมากกว่าคนที่ทำงานภาษาอังกฤษ

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

อ่านต่อ: Skills, commands และ hooks ส่วนเสริมของ harness

แหล่งอ้างอิง