ถ้าคุณใช้ coding agent ทุกวัน จะสังเกตได้ว่าบางสัปดาห์บิลแทบเรียบ แล้วมีหลุมลึกเป็นครั้งคราว — มักวันที่ใครสักคนเปิดแชทเก่าบนเครื่องอื่น “ถามแค่ข้อเดียว” นั่นไม่ใช่เวทมนตร์ แต่คือ อัตรา cache hit ของ prompt
บทความนี้เป็นบันทึกภาคสนามจากการใช้ agent แนว Grok กับงานจริง: มัลติไซต์ API และ ops เศรษฐศาสตร์เดียวกันใช้ได้กับผู้ช่วยใดที่คิดเงิน input token และมี path ของ prefix แบบ cache
คุณจ่ายอะไรจริง ๆ
- Prefix — system, tools, skills, กติกาโปรเจกต์ และเทิร์นก่อนหน้าที่ผู้ให้บริการถือเป็นบล็อกคงที่
- Suffix — ข้อความล่าสุด ผล tool ใหม่ การวางไฟล์ใหม่
ถ้าผู้ให้บริการเพิ่งเห็น prefix เดียวกัน ส่วนใหญ่คิดเป็น cache read ได้ ถ้า prefix เปลี่ยนหรือ cache เย็น คุณจ่ายทั้ง prompt ใหม่
ต้นทุนต่ำจึงไม่ใช่ “โมเดลฟรี” แต่คือ cache_read มากกว่า input ที่ไม่ cache ตั้งแต่เทิร์นสองเป็นต้นไป
หน่วยคือเซสชัน ไม่ใช่ป้ายชื่อ “API”
แคชไม่อ่านป้าย “งาน API” มันอ่าน ความต่อเนื่องที่ไบต์คงที่: เซสชันเดียวกัน โมเดลเดียวกัน โฟลเดอร์และกฎโปรเจกต์เดียวกัน ชุด tool เดียวกัน
อยู่เซสชันยาวชุดเดียว แก้ API บริการหนึ่งแล้วต่ออีกบริการ — ยังได้ประโยชน์ prefix อุ่น เริ่มเซสชันใหม่ทุก microservice เพราะ “เป็น API เหมือนกัน” — ทิ้งความอุ่นทุกครั้ง
ทำไมเซสชันเก่าบน workstation อื่นถึงเจ็บ
- เครื่องและ directory ต่างกัน → prefix ต่าง
- cache ฝั่งผู้ให้บริการเย็นหลังทิ้งช่วง
- ประวัติฟอสซิลยาว — แพงเมื่อ miss และรบกวน agent
ทางแก้จืดชืด: ตั้งชื่อเซสชันต่อ workstream เปิดต่อบนโฮสต์ที่งานอยู่ และเริ่มใหม่เมื่อเธรดเก่าไม่ใช่งานนั้นแล้ว
สิ่งที่รักษา prefix
- เซสชันยาวต่อ workstream
- resume ด้วย id หรือชื่อชัด
- โฮสต์และไดเรกทอรีโปรเจกต์เดิม
- โมเดลเดิมตลอดเธรด
- skills/MCP/กฎโปรเจกต์นิ่ง
- ติดตามสั้นในเธรดเดิม
สิ่งที่ทำลาย cache
- เซสชันใหม่ทุกคำถามเล็ก (โดยเฉพาะ headless ที่ไม่ resume)
- สลับโมเดลกลางคัน
- เปิดปิด MCP/skills บ่อย
- วางทั้งไฟล์ทุกเทิร์นทั้งที่อ้าง path ก็พอ
- subagent งานเล็ก — ลูกแต่ละตัวมักเป็น prefix เย็น
Compaction ไม่ใช่ศัตรู — การกระโดดเซสชันต่างหาก
เธรดยาวชนขีดจำกัดบริบท compaction ย่อประวัติ prefix เปลี่ยน cache ต้องอุ่นใหม่ แต่ยังมักถูกกว่าทิ้งงานไปเปิดแชทเก่าบนแล็ปท็อป หรือเริ่มใหม่โดยทิ้งการตัดสินใจที่จ่ายไปแล้ว
เพลย์บุ๊กทีม
- ตั้งชื่อเซสชัน
- ตรึงที่ทำงาน — โค้ด infra ที่ต้นทางความจริงอยู่
- automation ต้อง resume session id
- วัด uncached กับ cache read
- บรีฟแบบต่อเนื่อง ไม่ยัดดีไซน์ทั้งก้อนซ้ำ
เทียบราคา: Kimi K3 กับ Grok 4.5 เมื่อ cache hit-rate สูง
ราคาตามใบเสนอขายบอกแค่ครึ่งเดียว งาน coding แบบ agent ส่วนใหญ่ของเซสชันยาวคือ prefix ที่ซ้ำ — system prompt, tools, กติกาโปรเจกต์, เทิร์นก่อนหน้า ทั้งโฮสต์ Kimi K3 ของ Moonshot และ Grok 4.5 ของ xAI ขายการ reuse นี้ในราคา cache-read ตัวเลขที่สำคัญคือ ราคainput เฉลี่ย เมื่อ hit-rate สูง
ตัวเลขด้านล่างเป็น list rate สาธารณะกลางปี 2026 (USD ต่อ 1M token) ตรวจ console ล่าสุดเสมอ — โปรโมชันและ long-context เปลี่ยนได้ ใช้เรท short-context ของ Grok 4.5 (<200k prompt)
| โมเดล (hosted API) | Input miss | Cache hit | Output | Context |
|---|---|---|---|---|
| Kimi K3 (Moonshot) | $3.00 | $0.30 | $15.00 | ~1M |
| Grok 4.5 (xAI, short) | $2.00 | $0.30 | $6.00 | 500k (long-context แพงกว่า) |
Moonshot ระบุสาธารณะว่า cache hit-rate >90% บนงาน coding เมื่อ prefix นิ่ง — ตรงกับวินัยเซสชันยาวด้านบน ที่ 90% hit-rate ต้นทุน input ผสมต่อล้าน token คือ:
- Kimi K3: 0.9 × $0.30 + 0.1 × $3.00 = $0.57 / 1M input
- Grok 4.5: 0.9 × $0.30 + 0.1 × $2.00 = $0.48 / 1M input
ที่ hit-rate เท่ากัน Grok 4.5 ถูกกว่าเล็กน้อยฝั่ง input และ output ถูกกว่ามาก ($6 ต่อ $15 ต่อ 1M) agent ที่ยิง tool และข้อความยาว ๆ จ่าย output หนัก — ช่องว่างนั้นมักกินบิลมากกว่าเศษสตางค์บน input ผสม
ถ้า hit-rate พัง (เซสชันใหม่ทุกพรอมป์, แชทซอมบี้เย็น, สั่น prefix) ทั้งคู่กระโดดกลับใกล้ราคา miss เต็ม: K3 $3 และ Grok $2 บวก output เต็ม บทเรียนเหมือนกันทุกโฮสต์: ปกป้อง prefix วัด cache_read ตั้งเป้า 90% hit-rate — ไม่ใช่ของแถมจากตารางราคาอย่างเดียว
หน้าต่าง context ใหญ่ของ K3 ยังชนะงานเฉพาะ (repo ก้อนเดียวมหาศาล) ส่วน Grok 4.5 ที่ miss ถูกกว่า, cache hit ราคาเท่ากัน และ output ถูกกว่า อธิบายได้ว่าทำไมเซสชัน coding ยาวที่รันดีบน Grok ถึง “ถูกเป็นพิเศษ” — ถ้าคุณอยู่ในเซสชันอุ่นชุดเดียว
สรุป
หัวข้อเดียวกัน ช่วงงานยาว เซสชันมีชีวิตชุดเดียว ทำให้ต้นทุน AI coding เรียบ วินัยคือปกป้อง cache key: เซสชัน โมเดล ไดเรกทอรี และกฎ ใส่ของใหม่ในข้อความล่าสุด อย่าสั่น prefix
3DN ใช้ coding agent เป็นส่วนหนึ่งของการสร้างและเดินระบบซอฟต์แวร์ กลไกด้านบนเป็นภาพรวม — ชื่อผลิตภัณฑ์ต่างกันตามผู้ขาย เศรษฐศาสตร์ prefix cache เหมือนกัน
ใส่ความเห็น