GPT-6 Sol กับ Luna: ราคาต่อ token ถูกลง แต่ต้องวัดราคาต่องาน

OpenAI เปิด GPT-6 Sol และ GPT-6 Luna ผ่าน API เมื่อ 22 กันยายน 2026 โดยวาง Sol เป็นตัวสมดุลสำหรับงาน coding กับ agent ที่ซับซ้อน ส่วน Luna เป็นรุ่นประหยัดสำหรับงานปริมาณมากครับ ข่าวนี้ดูเหมือนเรื่อง “รุ่นไหนเก่งกว่า” แต่คำถามที่ทีมวิศวกรรมควรถามคือ งานหนึ่งชิ้นจบด้วยกี่ request ใช้ output กี่ token ต้อง retry หรือเรียก tool กี่ครั้ง และเมื่อพลาดแล้วต้นทุนแก้ไขเป็นเท่าไร

เกิดอะไรขึ้น: สรุป 30 วินาที

ตาม API changelog ของ OpenAI ทั้งสองรุ่นรับ text และ image เป็น input และคืน text ผ่าน Responses API กับ Chat Completions ราคา Standard สำหรับ prompt ไม่เกิน 272K input tokens คือ Sol ที่ 2 ดอลลาร์ต่อหนึ่งล้าน input tokens, 0.20 ดอลลาร์สำหรับ cached input และ 10 ดอลลาร์สำหรับ output; Luna อยู่ที่ 0.10, 0.01 และ 0.50 ดอลลาร์ตามลำดับ ตัวเลขของ Luna จึงต่ำกว่า Sol ยี่สิบเท่าในตารางพื้นฐาน

แต่ model catalog ให้ทั้งคู่มี context 1.05 ล้าน tokens และ max output 128K พร้อม reasoning effort ตั้งแต่ none ถึง max ความเหมือนบนกระดาษไม่ได้แปลว่าคุณภาพ, latency หรือจำนวนรอบแก้เท่ากัน OpenAI แนะนำ Sol สำหรับ complex coding/agentic workflows และ Luna สำหรับ focused high-volume tasks ขณะที่ รายงาน TechCrunch สรุป framing เรื่องต้นทุนต่ำลงกับความผิดพลาดน้อยลง แต่ benchmark ของ vendor ยังต้องแปลกลับมาเป็น workload ของเรา

ทำไมเรื่องนี้เกี่ยวกับคุณ

ทีมที่มี model router มักเริ่มจากกฎง่าย เช่น “งานสั้นใช้รุ่นถูก งานยาวใช้รุ่นแพง” ปัญหาคือความยาว prompt ไม่เท่ากับความยาก งานสั้นอย่างแก้ race condition อาจต้อง reasoning ลึก ส่วนการสรุป log หลายหมื่นบรรทัดอาจเป็น pattern extraction ที่ Luna ทำได้ดี การ route ด้วยจำนวน token อย่างเดียวจึงเหมือนเลือกช่างจากน้ำหนักกล่องเครื่องมือ ไม่ได้ดูชนิดงาน

ราคาต่อ token ก็เป็นเพียงราคาวัตถุดิบ ถ้า Luna ต้องลองห้ารอบ ใช้ output ยาว และเรียก search/tool ซ้ำ แต่ Sol จบในรอบเดียว ต้นทุนรวมอาจกลับด้าน ในทางกลับกัน ถ้าโยน classification, schema extraction หรือข้อความตอบมาตรฐานทั้งหมดไป Sol เราจ่ายค่า capability ที่ไม่ถูกใช้ โดยเฉพาะระบบที่มี traffic สูง ตัวคูณเพียงเล็กน้อยต่อ request รวมเป็นงบรายเดือนได้มาก

อีกจุดคือ long-context pricing เอกสารราคา OpenAI ระบุว่าเมื่อ input เกิน 272K tokens อัตรา input และ cache เพิ่มเป็นสองเท่า ส่วน output เพิ่ม 1.5 เท่าสำหรับ request นั้นทั้งก้อน ถ้า agent สะสม transcript, tool output และไฟล์โดยไม่ compact การเพิ่ม context เล็กน้อยอาจข้ามขั้นราคา ไม่ใช่เพิ่มแบบเส้นตรง ทีมต้องวัด distribution ของ request ไม่ใช่ดูค่าเฉลี่ย เพราะ tail ที่ใหญ่เพียงไม่กี่เปอร์เซ็นต์อาจกินงบส่วนใหญ่

ทำงานยังไง: จากราคา token สู่ราคาต่องาน

เริ่มจากนิยาม “งานสำเร็จ” ให้ตรวจได้ เช่น test ผ่าน, JSON ตรง schema, reviewer รับ patch หรือคำตอบอ้างหลักฐานครบ จากนั้นทำ evaluation set ที่เป็นตัวแทนทั้งงานง่าย งานขอบ และงานที่แพงเมื่อผิด รัน Sol/Luna ที่ reasoning effort หลายระดับโดยคุม prompt, tools และ retry policy ให้เหมือนกัน เก็บอย่างน้อย success rate, input/cached/output tokens, latency, tool calls, retry count และ human correction time

คิดต้นทุนเป็น model cost + tool cost + retry cost + review cost + failure cost ไม่จำเป็นต้องแปลงทุกอย่างเป็นเงินแม่นยำในวันแรก แต่ต้องมองเห็นว่าโมเดลถูกที่ทำให้คนแก้เพิ่มสิบห้านาทีไม่ใช่ทางเลือกถูกสำหรับ flow สำคัญ อุปมาเหมือนบริษัทขนส่ง: ค่ารถต่อกิโลเมตรต่ำไม่ช่วยถ้าส่งผิดบ้านแล้วต้องขับย้อนกลับ

สำหรับ cache ให้แยก prefix คงที่ เช่น policy, schema และคู่มือ ออกจากข้อมูลที่เปลี่ยนทุก request เพื่อเพิ่ม cache hit แต่ต้องตรวจว่าการ cache ไม่ทำให้ข้อมูลคนละ tenant ปะปน อย่าดัน context เก่าทั้งหมดเพียงหวังใช้ cached rate เพราะ long-context multiplier และคุณภาพจาก context ที่รกอาจหักล้างกำไร การ compact ควรเก็บ decision, evidence และ open state มากกว่าบทสนทนาทุกคำ

การ route ที่เริ่มง่ายและตรวจสอบได้มีสามชั้น ชั้นแรก Luna สำหรับงาน reversible ที่มี validator แข็ง เช่นจัดหมวดหมู่หรือแปลง schema ชั้นสอง Sol สำหรับงานหลายขั้น, code change, ambiguity สูง หรือ failure แพง ชั้นสาม fallback เมื่อ validator ล้มเหลว: เพิ่ม context ที่จำเป็นหรือเลื่อนรุ่นเพียงครั้งเดียว ไม่วนอัตโนมัติไม่จำกัด บันทึกเหตุผลการ route เพื่อดูภายหลังว่ากฎใดสร้าง retry มากที่สุด

อย่าลืม processing tier หน้าราคา OpenAI ระบุ Batch/Flex ที่ครึ่งราคา Standard และ Fast ที่สองเท่าของ tier ที่ใช้ Regional processing เพิ่ม 10% ในพื้นที่ที่รองรับ การเลือก tier จึงต้องผูก SLA: offline enrichment อาจใช้ Batch, interactive assistant ใช้ Standard, ส่วน incident response ที่ latency มีมูลค่าสูงอาจยอม Fast ไม่ควรตั้ง Fast เป็นค่าเริ่มต้นเพราะ “เผื่อไว้”

เรื่องเงินและผลกระทบต่อสถาปัตยกรรม

ตัวอย่างเชิงวิธีคิด: สมมติงานหนึ่งมี input 100K และ output 10K โดยไม่คิด tool Sol Standard คิดราว 0.30 ดอลลาร์ ส่วน Luna ราว 0.015 ดอลลาร์ ความต่างยี่สิบเท่าดูชัด แต่ถ้า Luna สำเร็จเพียงครึ่งและแต่ละครั้งที่พลาดต้อง retry สองรอบกับ review เพิ่ม ต้นทุนต่องานสำเร็จจะสูงกว่าการคูณราคาตรง ๆ มาก หากงานนั้นแก้ production config ค่าเสียหายจากความผิดพลาดอาจใหญ่กว่าค่า token หลายลำดับ

จึงควรตั้ง budget guard สองระดับ: per-request จำกัด input/output/tool calls และ per-task จำกัด retry กับ wall time เมื่อชนเพดานให้หยุดขอคน ไม่เลื่อน reasoning ไป max อัตโนมัติทุกครั้ง Dashboard ควรแสดง cost ต่อ successful task แยก route, tenant และชนิดงาน พร้อมเปอร์เซ็นไทล์สูง ไม่ใช่เพียงค่าใช้จ่ายรวมรายวัน

ทีม procurement และ security ต้องดู data residency ด้วย เอกสารรุ่นระบุว่า EU data residency สำหรับ Sol/Luna มีเฉพาะ Standard processing ขณะตรวจ การย้าย tier เพื่อประหยัดอาจเปลี่ยนข้อกำหนด processing location หรือ feature availability ต้องทดสอบและทบทวนสัญญา ไม่ควรเดาจากชื่อโมเดลว่าการจัดการข้อมูลเหมือนกันทุก endpoint

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เอกสารทางการให้ positioning, ราคา และขีดจำกัด แต่ไม่ได้บอกว่า workload ของบริษัทคุณจะได้ success rate เท่าไร คำว่า “complex” กับ “focused” ไม่มีเส้นแบ่งสากล และผลขึ้นกับ prompt, tool quality, reasoning effort, context noise และ validator TechCrunch รายงานคำกล่าวเรื่อง fewer mistakes จากการเปิดตัว แต่ยังไม่แทน independent evaluation บนภาษาไทย, codebase เฉพาะ หรือ domain ที่มีกฎเข้ม

Latency จริงตามภูมิภาคและ usage tier ยังเปลี่ยนตาม load Rate limits ต่างตามบัญชี และ model snapshot/behavior อาจอัปเดตโดย provider หากระบบต้อง reproducible ควรตรวจว่ามี snapshot ID ใดให้ pin และบันทึก model ID, date, tier, effort กับ prompt version ทุก evaluation ตัวเลขราคาก็เปลี่ยนได้ บทความนี้ยืนยัน ณ 27 กันยายน 2026 เท่านั้น

ยังไม่ควรสรุปว่า Luna แทน Sol ได้เพราะ context window เท่ากัน Context capacity คือปริมาณที่รับได้ ไม่ใช่ความสามารถใช้หลักฐานยาวอย่างสม่ำเสมอ และไม่ควรสรุปว่า Sol ถูกกว่าจาก “จบในครั้งเดียว” จนกว่าจะวัด failure/retry จริง ทั้งสองข้อเป็นสมมติฐานที่ต้อง falsify ด้วย evaluation ของทีม

แล้วเราควรทำอะไร

สัปดาห์แรกอย่าเปลี่ยน production router ทันที ให้ดึงงานย้อนหลังที่ลบข้อมูลส่วนตัวแล้ว 50–200 ตัวอย่าง แบ่งตาม risk และความยาก สร้าง expected outcome/validator รันแบบ shadow ด้วย Sol กับ Luna ที่ effort เดียวกัน แล้ว review ตัวอย่างที่ผลไม่ตรงกัน บันทึกต้นทุนรวมต่องานและเวลาคนแก้

จากนั้นตั้ง policy เริ่มต้นแบบ fail closed: Luna รับงาน reversible + validator แข็ง, Sol รับงาน code/agent หลายขั้นและงานที่ failure แพง ถ้า Luna ไม่ผ่าน validator ให้ส่งเฉพาะ evidence ที่จำเป็นไป Sol หนึ่งครั้ง ไม่ส่ง transcript ที่มีคำสั่งจากแหล่งภายนอกโดยไม่ทำ trust labeling และไม่ให้ model router เปลี่ยน permission/tool scope เพื่อพยายามทำงานให้ผ่าน

หลัง rollout 10% ให้ติดตาม success rate, fallback rate, cost/task, latency p95 และ incident จาก output ทุกสัปดาห์ กฎ route ที่ fallback บ่อยต้องแก้หรือย้ายขึ้น Sol กฎที่ Sol ผ่านสบายและ Luna ให้ผลเท่ากันจึงค่อยลดลง Luna การลดต้นทุนที่ดีคือย้ายอย่างมีหลักฐาน ไม่ใช่ลดรุ่นทั้งระบบในคืนเดียว

Recap

ใช้ราคาต่อ successful task แทนราคาต่อ token อย่างเดียว
วัด Sol/Luna บน evaluation set ของทีมและ reasoning effort เดียวกัน
เฝ้า threshold 272K กับ long-context multiplier
แยก Batch/Flex/Standard/Fast ตาม SLA และ data residency
route Luna ไปงาน reversible ที่มี validator แข็ง
ให้ Sol รับงานหลายขั้นหรือ failure cost สูง
จำกัด retry, tool calls และ budget ต่อ task
บันทึก model/tier/effort/prompt version เพื่อ audit