Thanawat Wongchai

Posted on Jul 22 • Originally published at apidog.com

เปรียบเทียบ Gemini 3.6 Flash กับ 3.5 Flash: ต่างกันอย่างไร และควรอัปเกรดไหม

Google อัปเดต Flash tier เมื่อวันที่ 21 กรกฎาคม 2026 โดยโมเดลหลักเปลี่ยนเป็น Gemini 3.6 Flash หากคุณใช้ 3.5 Flash ใน production ให้เตรียมอัปเกรด: 3.6 Flash อยู่ในตระกูลเดียวกัน ใช้ context window 1 ล้านโทเค็นและราคาอินพุตเท่าเดิม แต่ราคาเอาต์พุตต่ำลง ใช้โทเค็นเอาต์พุตน้อยลง และทำคะแนนด้านการใช้งานคอมพิวเตอร์ได้ดีกว่า ดูรายละเอียดของโมเดลได้ที่ Gemini 3.6 Flash คืออะไร

ลองใช้ Apidog วันนี้

คำตอบสั้นๆ

อัปเกรดเป็น gemini-3.6-flash หากคุณสามารถรันการประเมินและ regression test ได้

ราคาอินพุตยังคงอยู่ที่ $1.50 ต่อ 1 ล้านโทเค็น
ราคาเอาต์พุตลดจาก $9.00 เป็น $7.50 ต่อ 1 ล้านโทเค็น
ใช้โทเค็นเอาต์พุตน้อยกว่า 3.5 Flash ประมาณ 17% สำหรับงานเดียวกัน
คะแนน OSWorld-Verified เพิ่มจาก 78.4 เป็น 83.0
เวิร์กโฟลว์หลายขั้นตอนอาจใช้ reasoning step และ tool call น้อยลง

เหตุผลหลักที่ควรรอคือ คุณได้ตรึง gemini-3.5-flash และตรวจสอบผลลัพธ์ใน production แล้ว แต่ยังไม่มีเวลารันการประเมินซ้ำ

Gemini 3.6 Flash เทียบกับ 3.5 Flash

ตัวเลขต่อไปนี้อ้างอิงจากข้อมูลเปิดตัวของ Google ดูรายละเอียดเพิ่มเติมได้จาก บล็อกโพสต์ของ Google และ หน้าโมเดล DeepMind Flash

คุณสมบัติ	Gemini 3.6 Flash	Gemini 3.5 Flash
รหัสโมเดล	`gemini-3.6-flash`	`gemini-3.5-flash`
ราคาอินพุต (ต่อ 1 ล้านโทเค็น)	$1.50	$1.50
ราคาเอาต์พุต (ต่อ 1 ล้านโทเค็น)	$7.50	$9.00
ประสิทธิภาพโทเค็นเอาต์พุต	โทเค็นเอาต์พุตน้อยลง ~17%	ค่าพื้นฐาน
การใช้งานคอมพิวเตอร์ (OSWorld-Verified)	83.0	78.4
Context window	1 ล้านโทเค็นอินพุต	1 ล้านโทเค็นอินพุต

สิ่งที่ไม่เปลี่ยนคือราคาอินพุตและ context window ส่วนที่เปลี่ยนคือค่าใช้จ่ายฝั่งเอาต์พุตและประสิทธิภาพในการสร้างคำตอบ

สิ่งที่ปรับปรุงจริง

1. ใช้โทเค็นเอาต์พุตน้อยลง

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

ผลกระทบคือค่าใช้จ่ายลดลงโดยตรง เพราะคุณจ่ายตามจำนวนโทเค็นเอาต์พุตจริง

2. ราคาเอาต์พุตลดลง

ราคาเอาต์พุตลดจาก $9.00 เหลือ $7.50 ต่อ 1 ล้านโทเค็น หรือประมาณ 17% ต่อโทเค็น นี่เป็นส่วนลดเพิ่มเติมจากการที่โมเดลใช้โทเค็นเอาต์พุตน้อยลงอยู่แล้ว

3. การใช้งานคอมพิวเตอร์ดีขึ้น

ใน OSWorld-Verified ซึ่งเป็น benchmark สำหรับการควบคุม UI บนคอมพิวเตอร์จริง:

Gemini 3.6 Flash: 83.0
Gemini 3.5 Flash: 78.4

หากคุณสร้าง agent ที่ต้องคลิก UI กรอกฟอร์ม หรือเรียกใช้เครื่องมือ คะแนนที่ดีขึ้นอาจหมายถึงขั้นตอนล้มเหลวน้อยลง

4. ใช้ reasoning step และ tool call น้อยลง

ใน agent workflow แบบหลายขั้นตอน Gemini 3.6 Flash สามารถทำงานให้เสร็จโดยใช้ reasoning step และ tool call น้อยลง

ทุก tool call ที่ลดได้ช่วยลดทั้ง:

เวลา round trip
โทเค็นสะสมในแต่ละรอบ
ค่าใช้จ่ายรวมของ workflow

ความแม่นยำด้านโค้ดก็ดีขึ้น ซึ่งสำคัญสำหรับงานสร้าง diff แก้ไขไฟล์ หรือสร้างโค้ดที่โทเค็นผิดเพียงตัวเดียวอาจทำให้ build ล้มเหลวได้

รูปแบบ API ไม่ได้เปลี่ยน: request format, authentication, endpoint, input modality เช่น ข้อความ รูปภาพ วิดีโอ เสียง และ PDF ยังคงเหมือนเดิม

คำนวณผลกระทบด้านค่าใช้จ่าย

ส่วนลดสองส่วนนี้คูณกัน:

ราคาเอาต์พุตต่อโทเค็นต่ำลง
จำนวนโทเค็นเอาต์พุตที่สร้างต่ำลง

ตัวอย่าง: สมมติ workload หนึ่งสร้างเอาต์พุต 10 ล้านโทเค็นต่อวันบน Gemini 3.5 Flash

Gemini 3.5 Flash

10 ล้านโทเค็น × $9.00 ต่อ 1 ล้านโทเค็น = $90.00 ต่อวัน
Gemini 3.6 Flash

ใช้โทเค็นน้อยลง 17% เหลือประมาณ 8.3 ล้านโทเค็น

8.3 ล้านโทเค็น × $7.50 ต่อ 1 ล้านโทเค็น = $62.25 ต่อวัน

สำหรับส่วนเอาต์พุตของ workload นี้ ค่าใช้จ่ายลดลงประมาณ 31% โดยไม่ต้องเปลี่ยน prompt

ค่าอินพุตยังคงเท่าเดิม เพราะราคาอินพุตอยู่ที่ $1.50 ต่อ 1 ล้านโทเค็นสำหรับทั้งสองโมเดล

ผลประหยัดจริงขึ้นอยู่กับอัตราส่วน input/output ของคุณ:

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

ดูรายละเอียดเพิ่มเติมได้ที่ ราคา Gemini 3.6 Flash และ เอกสารราคา Gemini API

มีเหตุผลใดที่จะยังใช้ 3.5 Flash หรือไม่?

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

คุณควรตรึง gemini-3.5-flash ชั่วคราวหาก:

คุณมี evaluation suite ที่ผูกกับการอนุมัติด้าน compliance
parser หรือบริการปลายทางพึ่งพารูปแบบเอาต์พุตเดิมอย่างเข้มงวด
regression test ยังไม่พร้อมใน sprint ปัจจุบัน
คุณไม่สามารถตรวจสอบคุณภาพและผลกระทบของเวอร์ชันใหม่ได้ก่อน deploy

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

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

วิธีการย้าย

การแก้โค้ดมีเพียงหนึ่งบรรทัด:

- gemini-3.5-flash
+ gemini-3.6-flash

ตัวอย่างแนวคิดใน request body:

{
  "model": "gemini-3.6-flash",
  "contents": [
    {
      "parts": [
        {
          "text": "สรุปเอกสารนี้เป็น bullet points"
        }
      ]
    }
  ]
}

request body, auth และ endpoint ยังคงเหมือนเดิม ดูตัวอย่างการเรียกใช้แบบละเอียดได้ที่ วิธีใช้ Gemini 3.6 Flash API และ เอกสาร Gemini API

งานสำคัญคือการตรวจสอบก่อน deploy:

รัน evaluation suite เดิมกับ 3.6 Flash แล้วเปรียบเทียบกับ baseline ของ 3.5 Flash
รัน regression test เพราะถ้อยคำและรูปแบบเอาต์พุตอาจเปลี่ยนระหว่างเวอร์ชัน
ตรวจสอบทุกจุดที่ parse เอาต์พุตแบบตายตัว เช่น JSON key, regex และ schema validation
วัด latency และจำนวนโทเค็นจากตัวอย่าง traffic จริง
เปิดใช้ผ่าน feature flag ก่อน แล้วค่อย rollout เต็มรูปแบบ

หากเอาต์พุตของโมเดลส่งต่อไปยังบริการอื่น ให้ปฏิบัติต่อการเปลี่ยนนี้เหมือนการอัปเกรด dependency: เปลี่ยนแบบควบคุมได้ เปรียบเทียบผล แล้วจึงเผยแพร่

ทดสอบ regression ใน Apidog

Apidog ใช้เป็น API client และแพลตฟอร์มทดสอบสำหรับเปรียบเทียบสองโมเดลได้ มันไม่ได้รันโมเดลเอง แต่ช่วยส่ง request ตรวจสอบ response และรัน assertions ก่อนที่คุณจะ deploy

ทำ A/B test ระหว่าง Gemini 3.5 Flash และ 3.6 Flash ตามขั้นตอนนี้:

บันทึก request Gemini เดิม

สร้าง POST request ไปยัง Gemini API ใน Apidog เก็บ API key ใน environment variable เพื่อไม่ให้คีย์อยู่ใน request body
ทำซ้ำ request

สร้าง request ชุดที่สอง แล้วเปลี่ยนเฉพาะ model ID:

   - gemini-3.5-flash
   + gemini-3.6-flash

อย่าเปลี่ยน prompt, parameter หรือ request body ส่วนอื่น เพื่อให้เปรียบเทียบได้ตรงกัน

เพิ่ม assertions ที่แอปอ่านจริง ตรวจสอบ status code และ JSON field ที่ระบบปลายทางต้องใช้ เช่น:

   pm.test("สถานะต้องเป็น 200", () => {
     pm.response.to.have.status(200);
   });

   const body = pm.response.json();

   pm.test("response ต้องมี candidates", () => {
     pm.expect(body).to.have.property("candidates");
   });

เปรียบเทียบ response, latency และ token usage

รัน request ทั้งสองตัวกับ input ชุดเดียวกัน ตรวจสอบว่า 3.6 Flash ผ่าน assertions เดิมทั้งหมด และบันทึกเวลาตอบกลับกับการใช้โทเค็น
บันทึกเป็น regression scenario

เก็บทั้งสอง request พร้อม assertions แล้วกำหนดเวลาให้เป็นการทดสอบ regression เพื่อจับความเปลี่ยนแปลงจากการแก้ prompt หรือการอัปเดตโมเดลในอนาคต

เวิร์กโฟลว์คือ: ทำซ้ำ request เปลี่ยนเฉพาะ model ID แล้วใช้ assertions เป็นตัวตัดสินว่าการย้ายปลอดภัยหรือไม่ ดาวน์โหลด Apidog หากต้องการทดสอบกับ Gemini request ของคุณเอง

คำถามที่พบบ่อย

Gemini 3.6 Flash ใช้แทน 3.5 Flash ได้ทันทีหรือไม่?

ในเชิง API ได้ เพียงเปลี่ยนจาก gemini-3.5-flash เป็น gemini-3.6-flash ส่วนอื่นของ request ยังคงเหมือนเดิม อย่างไรก็ตาม ควรรัน evaluation และ regression test ก่อนใช้ใน production เพราะถ้อยคำและโครงสร้างเอาต์พุตอาจเปลี่ยนได้

ราคาอินพุตเปลี่ยนหรือไม่?

ไม่ ราคาอินพุตยังคง $1.50 ต่อ 1 ล้านโทเค็นทั้งสองโมเดล ราคาเอาต์พุตเท่านั้นที่ลดจาก $9.00 เป็น $7.50 ต่อ 1 ล้านโทเค็น

ทำไม Flash เป็น 3.6 แต่ Lite และ Cyber เป็น 3.5?

ในการอัปเดตนี้ Google ปรับปรุงเฉพาะ Flash รุ่นหลักเป็น 3.6 ส่วน Flash-Lite และ Flash Cyber เปิดตัวในเวอร์ชัน 3.5 หมายเลขเวอร์ชันไม่ได้เรียงเหมือนกันทุก tier ดังนั้นให้ตรวจสอบ model ID ที่ใช้จริง

ค่าใช้จ่ายจะลดลง 31% เสมอหรือไม่?

ไม่ ตัวเลข 31% เป็นตัวอย่างสำหรับ workload ที่มีเอาต์พุตสูง การประหยัดจริงขึ้นอยู่กับอัตราส่วน input/output ของคุณ งานที่สร้างเอาต์พุตจำนวนมากจะเห็นผลมากกว่า งานที่เน้นอ่านข้อมูลจะเห็นผลน้อยกว่า

Gemini 3.5 Flash ยังใช้งานได้หรือไม่?

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

สำหรับรุ่นก่อนหน้า ดู Gemini 3.5 คืออะไร

สำหรับทีมส่วนใหญ่ ขั้นตอนที่เหมาะสมคือเปลี่ยน model ID เป็น gemini-3.6-flash รัน evaluation และ regression test ใน Apidog จากนั้น rollout อย่างควบคุมได้ เก็บ 3.5 Flash ไว้เฉพาะเมื่อข้อจำกัดด้านการตรวจสอบยังไม่อนุญาตให้ย้ายเท่านั้น

DEV Community