Mercury 2: LLM อนุมานความเร็วสูงพิเศษบนพื้นฐาน diffusion

 (inceptionlabs.ai)
7 คะแนน โดย GN⁺ 2026-02-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดลภาษาที่ใช้แนวทางการสร้างแบบขนานบนพื้นฐาน diffusion model เพื่อ ก้าวข้ามข้อจำกัดด้านความเร็วของ LLM แบบ sequential decoding เดิม
  • โครงสร้าง parallel refinement ที่สร้างและแก้ไขหลายโทเค็นพร้อมกัน ทำให้ ตอบสนองได้เร็วขึ้นมากกว่า 5 เท่า
  • ด้วยความเร็วประมวลผล 1,009 โทเค็น/วินาที, 128K context, JSON output, และ ความสามารถในการใช้เครื่องมือ จึงเหมาะกับแอปพลิเคชันแบบเรียลไทม์
  • พิสูจน์ประสิทธิภาพในสภาพแวดล้อมที่ไวต่อ latency เช่น ผู้ช่วยเขียนโค้ด, agent loop, voice interface, ค้นหาและ pipeline แบบ RAG
  • รองรับ OpenAI API อย่างสมบูรณ์ และผสานเข้ากับระบบเดิมได้ทันทีโดยไม่ต้องแก้ไขโครงสร้างพื้นฐาน

ภาพรวมของ Mercury 2

  • Mercury 2 คือ โมเดลภาษาสำหรับการอนุมานที่เร็วที่สุดในโลก
    • เป้าหมายคือการมอบ การตอบสนองฉับไวทันทีในสภาพแวดล้อม AI ระดับ production
  • คอขวดของ LLM แบบเดิมคือโครงสร้าง autoregressive sequential decoding (one token at a time)
    • ทำให้เกิดปัญหาความหน่วงสะสมใน AI workflow แบบวนลูปซ้ำ

สถาปัตยกรรมการอนุมานแบบเรียลไทม์บนพื้นฐาน diffusion

  • Mercury 2 ใช้แนวทาง parallel refinement แทน sequential decoding
    • สร้างหลายโทเค็นพร้อมกัน และลู่เข้าได้ภายในไม่กี่ขั้นตอน
    • มีลักษณะเหมือน “บรรณาธิการ” ที่คอยแก้ไขร่างทั้งฉบับซ้ำ ๆ ไม่ใช่ “เครื่องพิมพ์ดีด” ที่พิมพ์ทีละตัว
  • ผลลัพธ์คือ ความเร็วในการสร้างที่เร็วขึ้นมากกว่า 5 เท่า และสร้าง เส้นโค้งความเร็วแบบใหม่
  • การอนุมานบนพื้นฐาน diffusion ช่วยให้ได้ การอนุมานคุณภาพสูงพร้อมลด latency และต้นทุนให้ต่ำที่สุด

ประสิทธิภาพและสเปก

  • ความเร็ว: 1,009 โทเค็น/วินาที บน NVIDIA Blackwell GPU
  • ราคา: อินพุต $0.25 ต่อ 1 ล้านโทเค็น, เอาต์พุต $0.75 ต่อ 1 ล้านโทเค็น
  • คุณภาพ: อยู่ในระดับแข่งขันได้กับโมเดลหลักที่ปรับแต่งเพื่อความเร็ว
  • ความสามารถ: tunable reasoning, 128K context, การใช้เครื่องมือ, เอาต์พุตที่จัดแนวตาม JSON schema
  • การเพิ่มประสิทธิภาพด้าน latency: รักษา p95 latency, การตอบสนองที่สม่ำเสมอในสภาพแวดล้อมที่มี concurrency สูง, และ throughput ที่เสถียร
  • ผู้เกี่ยวข้องจาก NVIDIA ระบุว่า Mercury 2 ทำความเร็วเกิน 1,000 โทเค็น/วินาทีเมื่อทำงานร่วมกับโครงสร้างพื้นฐาน AI ของ NVIDIA

กรณีใช้งานใน production

1. การเขียนโค้ดและการแก้ไข

  • ให้การตอบสนองแบบทันทีภายใน developer loop สำหรับงานอย่าง autocomplete, refactoring, และ code agent
  • Max Brunsfeld ผู้ร่วมก่อตั้ง Zed เน้นว่าเป็น “ความเร็วของข้อเสนอแนะที่เร็วราวกับเป็นส่วนหนึ่งของความคิด”

2. Agent loop

  • ลดความหน่วงของการเรียกใช้งานใน agent workflow ที่ต้องอาศัยการอนุมานหลายขั้นตอน
  • Viant ใช้ Mercury 2 เพื่อ เพิ่มประสิทธิภาพแคมเปญแบบเรียลไทม์และเสริมระบบโฆษณาอัตโนมัติ
  • Wispr Flow กำลังประเมินความเร็วของ Mercury 2 สำหรับ บทสนทนาแบบเรียลไทม์และการขัดเกลาการถอดเสียง
  • Skyvern ระบุว่า “เร็วกว่า GPT-5.2 อย่างน้อยสองเท่า”

3. เสียงแบบเรียลไทม์และการโต้ตอบ

  • voice interface มีข้อจำกัดด้าน latency ที่เข้มงวดที่สุด
  • Happyverse AI ใช้ Mercury 2 เพื่อสร้าง อวตารโต้ตอบแบบเรียลไทม์ที่เป็นธรรมชาติ
  • OpenCall ระบุถึงความเป็นไปได้ในการสร้าง voice agent ที่ตอบสนองได้ดีกว่าด้วย latency ต่ำและคุณภาพสูง

4. การค้นหาและ pipeline แบบ RAG

  • ลด ความหน่วงสะสมจากกระบวนการค้นหาหลายรอบ การจัดอันดับใหม่ และการสรุปผล เพื่อให้อนุมานได้แบบเรียลไทม์
  • SearchBlox ร่วมมือกับ Mercury 2 เพื่อสร้าง AI ค้นหาแบบเรียลไทม์
    และมอบ ข้อมูลอัจฉริยะระดับวินาที ในหลากหลายด้าน เช่น การสนับสนุนลูกค้า ความเสี่ยง และอีคอมเมิร์ซ

การเผยแพร่และการผสานระบบ

  • Mercury 2 พร้อมใช้งานทันที และ รองรับ OpenAI API อย่างสมบูรณ์
  • ผสานเข้ากับระบบเดิมได้โดยไม่ต้องแก้โค้ด
  • สำหรับการประเมินในระดับองค์กร มีการสนับสนุนด้าน ความเหมาะสมของ workload, การตรวจสอบประสิทธิภาพ, และการออกแบบการประเมิน
  • ข้อความทางการ: “Mercury 2 is live. Welcome to diffusion.”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-26
ความคิดเห็นจาก Hacker News

  • แนวคิดในการวัด ความฉลาด (metric) ต่อวินาทีน่าสนใจมาก
    เช่น มองทั้งความฉลาดต่อต่อโทเค็น และจำนวนโทเค็นต่อวินาทีไปพร้อมกัน
    ส่วนตัวถ้า Sonnet 4.6 เร็วกว่า Opus 4.6 ถึง 5 เท่า ก็น่าจะเลือกใช้ Sonnet เป็นหลัก
    ในรุ่นก่อน ๆ ตระกูล Sonnet ยังไม่ดีพอ แต่ตอนนี้ข้อได้เปรียบด้าน การวนซ้ำ (iteration) จากความเร็วมีผลมากจนสถานการณ์เปลี่ยนไปแล้ว
    เมื่อก่อนเคยใช้ OpenAI Deep Research แต่ o3-thinking + เว็บเสิร์ชเร็วกว่าเยอะและก็ฉลาดพอแล้ว

    • คิดว่า “ความเร็วเองก็เป็นมิติหนึ่งของคุณภาพ”
      ถ้าพัฒนา API บนฮาร์ดแวร์อย่าง Cereberas หรือ Groq ระดับความเร็วในการวนซ้ำและต้นทุนจะแตกต่างกันโดยสิ้นเชิง
      ใน บันทึกงานวิจัย ที่เพิ่งเขียนล่าสุด ก็แสดงให้เห็นว่าเมื่อแยกส่วนการวางแผนเป็น โมเดล AR และการสร้างเป็น โมเดล diffusion แล้ว ประสิทธิภาพดีขึ้นมาก
    • ถ้าเพิ่ม ประสิทธิภาพต่อหน่วยฮาร์ดแวร์ เข้าไปในตัวชี้วัดนี้ก็น่าจะสะท้อนความจริงมากขึ้น
      ตัวอย่างเช่น ถ้าใช้ถ่านหิน 5 ตันก็พอ แต่กลับใช้ 30 ตันเพื่อให้ดีขึ้นแค่ 0.0000000001% นั่นไม่ใช่ความก้าวหน้าที่แท้จริง
    • ตอนนี้เริ่มมีตระกูลโมเดลใหม่ที่ตั้งเป้าไปที่ การวนซ้ำของเอเจนต์อย่างรวดเร็ว
      โมเดลอย่าง Composer หรือรุ่น Flash ก็เป็นตัวอย่าง และ Mercury 2 ก็วางตำแหน่งตัวเองเป็นโมเดลที่แข็งแกร่งในหมวดนี้
    • ดูเหมือนว่าอีกไม่นานคงจะได้ลองทำ เบนช์มาร์ก จริง ๆ
      โมเดลเร็วจะวนซ้ำได้ไว ส่วนโมเดลใหญ่จะแม่นยำกว่าตั้งแต่ครั้งแรก
      ตอนนี้ยังชอบ Opus 4.6 อยู่ แต่ก็อยากเห็นความต่างด้านประสิทธิภาพเทียบกับ Sonnet เป็นข้อมูลจริง
    • ชอบแนวคิด “Intelligence per second” มากจริง ๆ
      นี่แหละคือเหตุผลที่ชอบ Gemini 3 Flash — ฉลาดพอและ เร็วอย่างเหลือเชื่อ

  • ลองทดสอบง่าย ๆ ดู พอถามเรื่อง “ผลงานของ Maradona” Mercury 2 กลับพิมพ์ผิดเป็น “Dieadona”
    เป็นคำถามที่แม้แต่โมเดล 3B รันโลคัลก็ตอบได้สมบูรณ์ แต่ Mercury 2 กลับ ช้าและผิดพลาดเยอะ

  • Mercury 2 สร้างคำตอบด้วยวิธี parallel refinement
    เป็นโครงสร้างที่สร้างหลายโทเค็นพร้อมกันแล้วค่อย ๆ ลู่เข้าในไม่กี่ขั้น แทนที่จะพิมพ์แบบเครื่องพิมพ์ดีด แต่เป็นการ ขัดเกลาร่างทั้งฉบับเหมือนโปรแกรมแก้ไขข้อความ
    ตอนนี้มีงานวิจัยที่พยายามรวม DDPM กับ SGM เข้าด้วยกันผ่าน SDE อยู่ เลยสงสัยว่าจะมองแต่ละเลเยอร์ของ transformer เป็นขั้น diffusion ได้หรือไม่
    ถ้า L เลเยอร์ของ transformer สอดคล้องกับการขัดเกลา L ขั้นของ diffusion ก็อาจเป็นไปได้ที่จะทำ การฟิตเข้าหากัน (fitting) ระหว่างสองโมเดล

  • ในฐานะผู้ร่วมก่อตั้งและ Chief Scientist ของ Inception ยินดีรับคำถามเชิงเทคนิคเกี่ยวกับ Mercury 2 หรือ diffusion LM

    • สงสัยว่า KV cache ทำงานอย่างไรในโมเดล diffusion
      ช่วยลด latency หรือต้นทุนได้ไหม มีลักษณะกราฟคล้ายกับการแคชแบบ autoregressive หรือว่าใช้ไม่ได้เลย
    • โมเดล diffusion ดูเหมือนจะทำ reasoning เป็นบล็อกข้อความ เลยสงสัยว่าถ้ามีการพึ่งพาข้อมูลระหว่างบล็อกจะจัดการอย่างไร
      และก็น่าสนใจว่าจะใช้ ความยาวบล็อกแบบไดนามิก ได้ไหม
    • อยากรู้ว่าระบบ Voice AI ที่พูดถึงในงานนำเสนอทำงานจริงอย่างไร
      ระบบเสียงส่วนใหญ่มักให้ความสำคัญกับ TTFT (time-to-first-token) มากกว่าความหน่วงรวมของทั้งคำตอบ
      เลยอยากรู้ว่าค่า TTFT ของ Mercury 2 ดีขึ้นจากโมเดล reasoning อื่นมากแค่ไหน
    • เคยเจออาการ วนลูป คล้าย transformer ที่อ่อนแอ
      ดู ลิงก์ตัวอย่าง
      เลยสงสัยว่าอะไรเป็นสาเหตุของอาการนี้
    • อยากรู้ด้วยว่ามีแผนจะพัฒนาไปเป็น โมเดล drifting เพื่อให้เร็วขึ้นอีกหรือไม่

  • สิ่งที่น่าสนใจที่สุดคือเริ่มมีโมเดลที่สร้างได้หลายพันโทเค็นต่อวินาทีแล้ว
    แบบนี้ต่อให้ใช้ multi-shot prompting หรือ nudging ผู้ใช้ก็แทบไม่รู้สึก ทำให้ลดปัญหา hallucination หรือคำตอบที่ไม่แน่นอนได้

    • เราก็คิดเหมือนกัน
      Mercury 2 ทำให้ การวนซ้ำงานของเอเจนต์อย่างรวดเร็ว เป็นไปได้
      แม้การลองครั้งเดียวอาจแม่นยำน้อยกว่า แต่เพราะเวลารันสั้นมากจึงปรับปรุงได้เร็วกว่าอย่างมาก
    • โมเดลทั่วไปก็เร็วได้มากถ้าใช้ batch inference
      เช่น GPT-OSS 20B บน 3090 ใบเดียว ถ้า bs=64 ก็ทำได้ราว 2k tok/s

  • ยังไม่ค่อยมั่นใจกับโมเดล diffusion
    Google และที่อื่น ๆ ก็ลองมาแล้ว แต่ส่วนใหญ่ยังตามหลังบน Pareto frontier
    ดู ลิงก์เปรียบเทียบราคา/ประสิทธิภาพ

    • มีข้อโต้แย้งจากมุมมอง Pareto อยู่
      ถ้าวัดที่คุณภาพระดับเดียวกัน Mercury เร็วกว่าโมเดล AR ที่ใกล้เคียงกัน มากกว่า 5 เท่า
      แม้ความฉลาดโดยรวมยังต่ำกว่า Opus หรือ Gemini Pro แต่ในแง่ ความเร็วในการอนุมาน มีข้อได้เปรียบมาก
    • text diffusion ยังมีพื้นที่ให้พัฒนาอีกมาก
      เป็นพื้นที่ที่ยังไม่ถูกสำรวจมากกว่า autoregressive transformer มาก จึงมี เพดานทางเทคนิค สูง
    • โมเดลนี้น่าจะเหมาะมากสำหรับงาน แก้ไข (edit) แบบรวดเร็ว
      ถ้ามีเวอร์ชัน “Mercury Edit” แบบเดียวกับ Fast Apply ของ Morph ก็อยากลองใช้มาก

  • แนวทาง diffusion-based น่าสนใจมาก
    transformer แบบดั้งเดิมจะสร้างโทเค็นแบบลำดับต่อเนื่อง แต่ diffusion สามารถ ขัดเกลา (refine) เอาต์พุตทั้งชุดแบบวนซ้ำได้
    ถ้าแก้ปัญหา latency ได้จริง ก็อาจเปิดความเป็นไปได้ใหม่สำหรับงาน reasoning ที่ซับซ้อน

  • สงสัยว่ามี open-weight diffusion LLM ที่รันบนฮาร์ดแวร์โลคัลได้ไหม
    อยากเห็นความต่างด้านประสิทธิภาพบน GPU ระดับผู้บริโภคด้วยตัวเอง

  • Mercury 2 ไม่ผ่าน Car Wash Test
    น่าจะเหมาะกว่าถ้าโฟกัสไปที่ งานเฉพาะทาง (เช่น coding agent) มากกว่าเป็นโมเดล reasoning ทั่วไป และเทียบกับโมเดล SOTA ในสายนั้นอย่าง Qwen3-Coder-Next

    • ส่วนตัวชอบ โมเดลที่ช้าแต่แม่นยำ มากกว่าโมเดลที่เร็วแต่ผิดเยอะ
      ต่อให้ต้องรันเซสชันยาว ๆ ความแม่นยำก็สำคัญกว่า

  • ถ้าโมเดลนี้ไปรันบน ชิป Talaas จะมีโอกาสสร้างได้เกิน 50,000 โทเค็นต่อวินาทีไหม

    • ถ้าฝังลงใน วงจรสไตล์ ASIC ที่ไม่มี memory latency ได้ ก็ดูเหมือนว่าโมเดลไหน ๆ ก็น่าจะได้ความเร็วเพิ่มขึ้นมหาศาล