GPT-6.1 Sol ลดราคา AI งานซับซ้อน แต่โหมดเครื่องมือย้ายไป Responses API

OpenAI เปิด GPT-6.1 Sol ใน API เมื่อ 29 กันยายน 2026 สำหรับงานเขียนโค้ดและงานวิชาชีพที่ซับซ้อนในราคาต่ำกว่า GPT-6 Astra ราคา Standard สำหรับคำขอที่มีโทเคนนำเข้าไม่เกิน 272,000 โทเคนอยู่ที่ 2 ดอลลาร์ต่อหนึ่งล้านโทเคนนำเข้าและ 10 ดอลลาร์ต่อหนึ่งล้านโทเคนส่งออก ขณะที่การเรียกเครื่องมือด้วยรุ่นนี้ต้องใช้ Responses API

การเปิดตัวเกิดขึ้นระหว่าง DevDay 2026 ที่ซานฟรานซิสโกในวันเดียวกัน โดย รายงานของ Axios จากงาน DevDay อธิบายว่า Sol นำความสามารถบางส่วนของโมเดลระดับสูงมาอยู่ในระดับราคาที่ต่ำลง สำหรับผู้พัฒนาไทย ผลที่ต้องพิจารณามีสองด้านพร้อมกัน คือค่าโทเคนของคำขอจริงและงานย้ายระบบที่ใช้เครื่องมืออยู่แล้ว คำอธิบายด้านความสามารถจากการเปิดตัวไม่ใช่ผลทดสอบของแอปพลิเคชันทุกประเภท

ราคา Standard เปลี่ยนเมื่อคำขอยาวเกินเกณฑ์

รายละเอียดรุ่น GPT-6.1 Sol กำหนดหน้าต่างบริบท 1,050,000 โทเคนและเอาต์พุตสูงสุด 128,000 โทเคน ราคา Standard ต่อหนึ่งล้านโทเคนอยู่ที่ 2 ดอลลาร์สำหรับอินพุตทั่วไป 0.10 ดอลลาร์สำหรับอินพุตที่อ่านจากแคช 2.50 ดอลลาร์สำหรับการเขียนแคช และ 10 ดอลลาร์สำหรับเอาต์พุต หากพรอมป์ต์มีอินพุตมากกว่า 272,000 โทเคน อัตราอินพุตและแคชเพิ่มเป็นสองเท่า ส่วนเอาต์พุตเพิ่มเป็น 1.5 เท่าสำหรับคำขอทั้งรายการ

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

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

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

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

สามคำขอสมมติให้เห็นผลของราคา

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

• คำขอทั่วไปมีอินพุตที่ไม่อ่านจากแคช 100,000 โทเคน และเอาต์พุต 10,000 โทเคน ค่าอินพุตคือ 0.20 ดอลลาร์ ค่าเอาต์พุตคือ 0.10 ดอลลาร์ รวม 0.30 ดอลลาร์ คำขอนี้อยู่ใต้เกณฑ์บริบทยาวจึงใช้อัตรา Standard ช่วงแรกทั้งสองด้าน
• คำขอที่มีอินพุต 100,000 โทเคนซึ่งถูกนับเป็นการอ่านแคชทั้งหมด และเอาต์พุต 10,000 โทเคน มีค่าอ่านแคช 0.01 ดอลลาร์กับค่าเอาต์พุต 0.10 ดอลลาร์ รวม 0.11 ดอลลาร์ กรณีนี้ตั้งสมมติฐานว่าแคชพร้อมให้อ่านแล้ว จึงยังไม่รวมค่าเขียนแคชที่อาจเกิดขึ้นก่อนหน้า
• คำขอยาวมีอินพุตทั่วไป 300,000 โทเคน และเอาต์พุต 10,000 โทเคน เมื่ออินพุตข้ามเกณฑ์ อัตราที่ใช้กับทั้งคำขอเป็น 4 ดอลลาร์ต่อหนึ่งล้านโทเคนนำเข้าและ 15 ดอลลาร์ต่อหนึ่งล้านโทเคนส่งออก ค่าอินพุตคือ 1.20 ดอลลาร์ ค่าเอาต์พุตคือ 0.15 ดอลลาร์ รวม 1.35 ดอลลาร์

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

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

บริบทใหญ่ไม่ได้หมายถึงคำตอบยาวเท่ากัน

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

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

การตั้งระดับการใช้เหตุผลก็เป็นส่วนหนึ่งของการย้ายรุ่น ค่าเริ่มต้นคือ medium และมีตัวเลือก low, high, xhigh และ max ส่วน none กับ minimal ใช้ไม่ได้กับ Sol หากแอปพลิเคชันเดิมส่งค่าที่ไม่รองรับ การเปลี่ยนเพียงชื่อโมเดลในคำขออาจทำให้เส้นทางนั้นทำงานไม่สำเร็จ ก่อนเทียบต้นทุนต่อชิ้นงานจึงควรใช้ระดับการใช้เหตุผลที่ระบบตั้งใจใช้งานจริงและดูโทเคนที่เกิดขึ้นจากผลลัพธ์จริง

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

การเรียกเครื่องมือทำให้การย้าย API เป็นงานจริง

Sol ใช้ได้ทั้ง Responses API และ Chat Completions สำหรับการรับคำตอบที่ไม่เรียกเครื่องมือ แต่เมื่อโมเดลต้องเรียกฟังก์ชันหรือเครื่องมือ เส้นทางที่รองรับคือ Responses API ข้อจำกัดนี้แบ่งระบบเดิมออกเป็นสองกลุ่มอย่างชัดเจน คำขอข้อความอย่างเดียวอาจทดลองเปลี่ยนรุ่นได้โดยไม่ต้องย้ายวงจรเครื่องมือ ส่วนคำขอที่มีเครื่องมือต้องปรับเส้นทางและวิธีรับส่งผลลัพธ์

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

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

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

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

1. แยกคำขอที่ส่งนิยามฟังก์ชันหรือเปิดใช้เครื่องมือออกจากคำขอข้อความทั่วไป แล้วเปลี่ยนเฉพาะเส้นทางที่ต้องใช้เครื่องมือไปยัง Responses API ตรวจชื่อรุ่นและค่าการใช้เหตุผลที่ส่งไปพร้อมคำขอด้วย
2. ปรับตัวอ่านผลตอบกลับให้แยกข้อความ คำสั่งเรียกฟังก์ชัน และรายการชนิดอื่นได้ ระบบไม่ควรถือว่าทุกรายการในผลลัพธ์เป็นข้อความพร้อมแสดงต่อผู้ใช้
3. ตรวจการส่งผลจากฟังก์ชันกลับไปให้ตรงกับคำสั่งเรียกที่เริ่มต้นไว้ รวมทั้งกรณีฟังก์ชันล้มเหลว คืนข้อมูลว่าง หรือมีคำสั่งเรียกหลายรายการในรอบเดียว
4. กำหนดวิธีรักษาบริบทระหว่างรอบให้ชัด ว่าแอปจะส่งรายการก่อนหน้ากลับเองหรืออ้างอิงคำตอบก่อนหน้า แล้วตรวจว่าคำสั่ง ผลเครื่องมือ และคำตอบสุดท้ายไม่หลุดจากงานเดียวกัน
5. ทบทวนการตั้งค่าที่ผูกกับรูปแบบคำขอเดิม เช่น รูปแบบผลลัพธ์ที่ต้องการและการรับผลแบบทยอยส่ง เพราะตัวอ่านข้อมูลที่อิงโครงสร้างเดิมอาจจัดการผลจาก Responses ได้ไม่ครบ
6. บันทึกโทเคนและค่าเครื่องมือของงานที่เสร็จสมบูรณ์ โดยแยกคำขอใต้เกณฑ์กับเหนือเกณฑ์ รวมถึงอินพุตทั่วไป การอ่านแคช การเขียนแคช และเอาต์พุต

ผลต่อผู้พัฒนาไทยอยู่ที่ต้นทุนทั้งงาน

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

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

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

หลังเปิดใช้รุ่นใหม่ ตัวเลขที่ชี้ผลได้ชัดที่สุดคือค่าใช้จ่ายต่อผลลัพธ์ที่ผ่านเกณฑ์ของระบบเดิม โดยรวมทุกคำขอ การอ่านหรือเขียนแคช และการเรียกเครื่องมือที่จำเป็น หากเส้นทางที่ใช้ Chat Completions ยังมี tool calling งานย้ายไป Responses API จะเกิดขึ้นก่อนที่จะวัดผลประหยัดของเส้นทางนั้นจากการใช้งานจริงได้

อ่านเพิ่มเติม:

• Gemini 3.8 Live สร้างอวตารสดได้ 97 ภาษา แต่ API ยังมีเงื่อนไข