ภาพวาดโทนเขียวเข้ม แถวสถานีเรียบง่ายหกจุดวางเรียงบนโต๊ะทำงาน ทุกจุดจมอยู่ในเงา ยกเว้นจุดเดียวที่มีหน้าปัดวัดขนาดใหญ่เกินตัวติดอยู่และมีไฟส่องสว่าง มีเส้นสีอำพันเส้นบางลากผ่านทุกจุดตั้งแต่ซ้ายสุดถึงขวาสุด
aiinferencehardwareperformanceenergy

Jalapeño ชิป Inference ของ OpenAI: ทำไม Latency กับไฟต้องวัดพร้อมกัน

พี่โชว์Engineering

เวลาบอกว่า AI “เร็วขึ้น” เราต้องถามต่อว่าเร็วแบบไหน: ผู้ใช้เห็นคำแรกไวขึ้น, คำถัดไปไหลลื่นขึ้น, รองรับคนพร้อมกันมากขึ้น หรือใช้ไฟเท่าเดิมแต่ทำงานได้มากขึ้น เพราะตัวเลขเดียวตอบสี่เรื่องนี้ไม่ได้ครับ

OpenAI เผยผลทดสอบ Jalapeño เมื่อ 25 สิงหาคม 2026 นี่คือชิป inference ที่ออกแบบเองรุ่นแรกของบริษัท โดย inference หมายถึงช่วงที่โมเดลนำสิ่งที่เรียนมาแล้วมาตอบคำขอ ไม่ใช่ช่วงฝึกโมเดลใหม่ บริษัทระบุว่าจะเริ่มนำชิปเข้าระบบภายในปลายปี ขณะนี้จึงเป็นผล qualification ก่อนใช้งานเต็มกำลัง ไม่ใช่ประกาศว่าลูกค้าทุกคนกำลังใช้ชิปนี้แล้ว

ตัวเลข headline คือ Jalapeño ทำ AI work ต่อวัตต์มากขึ้น 1.5–1.9 เท่าที่ peak throughput, ลด end-to-end latency 1.7–3.6 เท่า และใน workload แบบ interactive ให้ performance สูงขึ้น 2.1–4.1 เท่าเมื่อเทียบกับระบบที่บริษัทเลือกทดสอบ ตัวเลขเหล่านี้มาจาก OpenAI และควรอ่านพร้อมวิธีวัด ไม่ใช่นำไปเหมารวมกับทุกโมเดล ทุก batch size หรือราคาจริงทันที

WHY: Agent ช้าหนึ่งก้าว จะทบต้นหลายรอบ

แชตธรรมดาอาจเรียกโมเดลหนึ่งครั้ง แต่ agent ทำงานเป็นสายพาน: อ่านโจทย์ วางแผน เรียก tool ดูผล แล้วตัดสินใจก้าวถัดไป ถ้าแต่ละก้าวช้าเพิ่ม 300 มิลลิวินาที งาน 20 ก้าวก็เสียเวลาเพิ่มหลายวินาที Latency จึงไม่ได้กระทบความรู้สึกเท่านั้น แต่กำหนดว่างานแบบหลายขั้นจะใช้งานจริงได้หรือไม่

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

HOW: แยก prefill กับ decode ก่อนอ่านกราฟ

ช่วง prefill คือการอ่าน prompt และ context ทั้งก้อน งานส่วนนี้ใช้พลังคำนวณมาก คล้ายอ่านเอกสารกองใหญ่เข้าห้องประชุม ส่วน decode คือการสร้างคำตอบทีละ token มักติดข้อจำกัดการเคลื่อนข้อมูลจาก memory มากกว่า คล้ายเลขาฯ เปิดแฟ้มเดิมซ้ำเพื่อเขียนประโยคถัดไป

Jalapeño ออกแบบ compute, memory, network และ software เป็นระบบเดียว เป้าหมายคือเก็บ model state รวมถึง KV cache ให้อยู่ใกล้จุดคำนวณและลดเวลาที่หน่วยประมวลผลรอข้อมูล สิ่งสำคัญไม่ใช่ชิปตัวเดียววิ่งเร็วที่สุด แต่คือ request ทั้งเส้นทางไม่เสียเวลาย้ายข้อมูลระหว่างชิ้นส่วนที่แต่ละตัวเก่งคนละช่วง

OpenAI ทดสอบกับ GPT-OSS 120B, DeepSeek R1 670B และ Kimi K2.5 1T ผ่าน InferenceX ซึ่งวัดระบบ serving แบบ end-to-end บริษัทระบุชิปที่ 700 วัตต์ แต่กำลังไฟต่อเนื่องที่วัดได้ไม่เกิน 550 วัตต์ใน workload เหล่านี้ การรายงานสองค่านี้ช่วยให้เราไม่สับสนระหว่างค่ากำหนดบนสเปกกับสิ่งที่ใช้จริงระหว่างทดสอบ

AI ช่วยออกแบบ AI hardware ตรงไหน

OpenAI ระบุว่าใช้โมเดลช่วยสำรวจ implementation, ย่นวงจรวัดผลและ verification และ optimize วงจรคำนวณ จนเดินจาก design ไป tapeout ในเก้าเดือน อีกด้านหนึ่ง Jalapeño ถูกออกแบบให้เป็น programming target ที่บอกการวาง tensor, การสื่อสาร และ synchronization ได้ชัด เพื่อให้ทั้งคนและ AI ช่วยจัดตารางงานบนฮาร์ดแวร์

ตัวอย่างที่น่าสนใจคือ implementation ที่ AI สร้างสำหรับ attention และ mixture-of-experts บาง block เร็วกว่าของผู้เชี่ยวชาญเดิม 1.5–1.8 เท่า แต่บริษัทเตือนเองว่าตัวเลขนี้ใช้กับ block ที่เลือก ไม่ใช่ทั้งโมเดล ตรงนี้เป็นแบบอย่างการอ่าน benchmark: ถามเสมอว่า “เร็วขึ้นที่หน่วยไหน” ก่อนขยายข้อสรุป

Checklist สำหรับคนเลือกบริการ AI

เราอาจซื้อ Jalapeño ไม่ได้ แต่ใช้กรอบคิดเดียวกันเลือก API หรือวาง self-hosted inference ได้:

  • วัด time to first token แยกจากความเร็ว token ต่อเนื่อง
  • วัดงานหลายขั้นแบบจริง ไม่ใช่ prompt เดี่ยวที่สั้นสวย
  • วัด p95/p99 เพื่อเห็นผู้ใช้ท้ายแถว ไม่ดูเฉพาะค่าเฉลี่ย
  • วัด throughput ที่ latency เป้าหมายเดียวกัน
  • รวมพลังงาน ค่าเครื่อง network และ utilization ไม่ดูราคาชิปอย่างเดียว
  • ทดสอบ model และ context length ที่ production ใช้จริง

Recap

คุณค่าของ Jalapeño ไม่ได้อยู่ที่ตัวเลข “เร็วกว่า” เพียงคำเดียว แต่อยู่ที่การพยายามแก้ latency, throughput และพลังงานพร้อมกันผ่านการออกแบบทั้งระบบ ตั้งแต่ชิปถึง software

สำหรับทีมทั่วไป บทเรียนที่ยืมได้ทันทีคืออย่าปรับ inference จาก metric เดียว วัดเส้นทางผู้ใช้ครบก้าว วัดที่คุณภาพบริการเท่ากัน และระบุให้ชัดว่า benchmark มาจากใคร เมื่อ WHY คือ agent ต้องตอบสนองไวโดยไม่เผา capacity ทิ้ง HOW จึงเริ่มจากระบบทั้งเส้น ไม่ใช่เลือกกล่องที่มีตัวเลขใหญ่ที่สุดครับ