Mercury - โมเดลภาษาความเร็วสูงพิเศษที่ใช้ Diffusion

 (arxiv.org)
10 คะแนน โดย GN⁺ 2025-07-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mercury คือ โมเดลภาษาขนาดใหญ่ (LLM) เชิงพาณิชย์ แบบใหม่ที่ใช้แนวทาง diffusion
  • โมเดลนี้มีจุดเด่นคืออิงบน สถาปัตยกรรม Transformer และคาดการณ์โทเค็นหลายตัวแบบขนาน
  • Mercury Coder เป็นชุด diffusion LLM ชุดแรก พัฒนามาสำหรับการเขียนโค้ด และมีให้เลือก 2 ขนาดคือ Mini และ Small
  • บน NVIDIA H100 GPU ทำ throughput ได้ 1109 (Mini) และ 737 (Small) โทเค็นต่อวินาที และให้ความเร็วสูงสุดมากกว่าโมเดลเดิมที่เน้นความเร็วได้ถึง 10 เท่าที่คุณภาพระดับเดียวกัน
  • ทั้งในเบนช์มาร์กการใช้งานจริงและการประเมินโดยนักพัฒนา เช่น Copilot Arena ก็ทำได้ คุณภาพอันดับ 2 และความเร็วสูงสุด พร้อมให้บริการทั้งAPI สาธารณะ และเพลย์กราวด์

ภาพรวม

  • Mercury คือ ซีรีส์โมเดลภาษาขนาดใหญ่แบบใหม่ที่อิงกับ diffusion ซึ่งเป็น LLM ยุคใหม่ที่ทำงานได้ในระดับการใช้งานเชิงพาณิชย์
  • โมเดลทั้งหมดถูกพารามิเตอร์ด้วย สถาปัตยกรรม Transformer และถูกฝึกให้คาดการณ์โทเค็นหลายตัวพร้อมกันแบบขนาน
  • รายงานนี้แนะนำไลน์อัปแรกของ Mercury Coder ซึ่งออกแบบมาเป็นหลักสำหรับแอปสร้างโค้ด
  • ขณะนี้ Mercury Coder มีให้ใช้งาน 2 ขนาดคือ Mini และ Small

ผลงานสำคัญ

  • Mercury Coder สร้างมาตรฐาน state-of-the-art ใหม่ในด้านสมดุลระหว่าง ความเร็วและคุณภาพ
  • จากเกณฑ์ของ Artificial Analysis ซึ่งเป็นหน่วยประเมินภายนอก:
    • Mercury Coder Mini: 1109 โทเค็นต่อวินาที
    • Mercury Coder Small: 737 โทเค็นต่อวินาที บน NVIDIA H100 GPU
    • เร็วกว่าโมเดลฟรอนเทียร์ที่เร็วที่สุดโดยเฉลี่ย สูงสุด 10 เท่า พร้อมคุณภาพใกล้เคียงกัน
  • ยังมีผลประเมินเพิ่มเติมจากเบนช์มาร์กโค้ดใน ภาษาโปรแกรมและกรณีการใช้งานที่หลากหลาย
  • ในสภาพแวดล้อมนักพัฒนาจริง (Copilot Arena) ก็ทำได้
    • อันดับ 2 ด้านคุณภาพ
    • อันดับ 1 ด้านความเร็วโดยรวม
  • รองรับทั้ง API สาธารณะ ( platform.inceptionlabs.ai ) และ แชตเพลย์กราวด์ฟรี ( chat.inceptionlabs.ai ) ที่ทุกคนใช้งานได้

คำอธิบายโครงสร้างสารบัญ

  • Introduction (บทนำ)
    • ผลงานสำคัญ (Contributions)
  • Inception Mercury Model Family (คำอธิบายตระกูลโมเดล)
    • กระบวนการฝึก (Training)
    • วิธีการอนุมาน (Inference)
  • Capabilities (ความสามารถของโมเดล)
    • ประสิทธิภาพพื้นฐาน (Baselines)
    • ความสามารถด้านการเขียนโค้ด (Coding Capabilities)
      • เบนช์มาร์กการประเมิน (Evaluation Benchmarks)

สรุป

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

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

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

 
GN⁺ 2025-07-08
ความคิดเห็นบน Hacker News

  • มีการย้ำว่าเมื่อมีการนำ LLM agent มาใช้ ประสิทธิภาพของการทดสอบจะยิ่งกลายเป็นคอขวดฝั่ง CPU ที่รุนแรงขึ้น และตอนนี้ทุกทีมก็เจอคอขวดจากความเร็วของ CI กันอยู่แล้ว
    ต่อให้เอเจนต์เขียนโค้ดได้เร็วกว่าคน 100 เท่า ก็ไม่มีความหมายถ้าการทดสอบใช้เวลาหนึ่งชั่วโมง
    ในหลายโปรเจกต์ที่ฉันเคยทำ เวลาของนักพัฒนาถูกเปลืองไปมากกับการรอให้การเปลี่ยนแปลงมีผล และหลายงานก็ติดคอขวดที่ I/O หรือจำนวน worker ไม่พอ
    เมื่อ coding agent เปลี่ยนงาน ticket ง่าย ๆ ให้กลายเป็น PR ได้อย่างรวดเร็ว และคอยแก้แบบเรียลไทม์ตามผลทดสอบที่ล้มเหลว คอขวดที่ CI ก็จะยิ่งแย่ลง
    สภาพแวดล้อมการทดสอบของโปรเจกต์ส่วนใหญ่ยังมีช่องให้ปรับปรุงได้มาก แต่ในความเป็นจริงกลับเคยชินกับ CI ที่ช้าและต้นทุนสูงมาหลายปีโดยแทบไม่มีความคืบหน้า
    บางที่ปิดแคชเพื่อแยก build ออกจากกันอย่างสมบูรณ์ หรือย้ายจาก on-premise ไปเป็น cloud VM ที่ช้ากว่า ทำให้ CI ยิ่งช้าลงไปอีก
    ความเร็วของ Mercury เร็วจนน่าตกใจ และจากที่ลองทดสอบไม่กี่ครั้ง คุณภาพโค้ดก็ดีมากและแม่นยำ แต่ตอนนี้โจทย์คือทำอย่างไรให้การรันทดสอบตามความเร็วนี้ให้ทัน

    • ฉันไม่ค่อยเห็นด้วยกับประเด็นที่ว่าในโปรเจกต์ส่วนใหญ่ เวลานักพัฒนาถูกเปลืองไปกับการรอ PR อนุมัติ
      ในมุมบริษัท เวลาของนักพัฒนาแพงกว่าเวลาเครื่องมาก ดังนั้นถ้านักพัฒนาบ่น ก็เป็นปัญหาที่แก้ได้ด้วยการเพิ่ม CI worker เป็นสองเท่า
      ที่ Google เคยมีกรณี debug ปัญหา test flakiness โดยรันเทสต์ 10,000 ครั้งบนเครื่อง 10,000 เครื่องเพื่อหา failure ที่เกิดขึ้นนาน ๆ ครั้ง
      ที่ทำงานปัจจุบันของฉันก็มีแนวทางคล้ายกัน โดยใช้คำสั่งเดียวรันทุกเทสต์แบบขนานบน 1,000 worker เพื่อให้โปรเจกต์ขนาด 1M LOC ได้ feedback ภายใน 5 นาที
      การแยก build ออกอย่างสมบูรณ์กับการไม่ใช้แคชเป็นคนละเรื่องกัน และควรแยก build ให้สมบูรณ์พร้อมใช้ทุกแคชให้คุ้มที่สุด

    • ถ้าความเร็วในการ implement สูงขึ้น คอขวดก็น่าจะย้ายไปอยู่ฝั่ง PM และในกรณีนี้ความขัดแย้งอาจลดลงมาก เพราะการเปลี่ยนแปลงจะถูกทำแบบอนุกรมมากขึ้น
      ยังมีความเป็นไปได้ที่จะเกิดการกลับมาของภาษาอธิบายสเปก (เช่น TLA+) เพราะเอเจนต์สามารถเขียนและตรวจสอบได้อย่างรวดเร็ว จนอาจลดจำนวน integration test ทั้งหมดลงได้
      เมื่อ background agent จัดการโค้ดซ้ำซ้อน ก็อาจจัดการเทสต์ที่ซ้ำซ้อนตามไปด้วย
      AI ดูมีแนวโน้มจะทำงานกับโครงสร้างแบบ monolithic ได้มีประสิทธิภาพกว่าทีมวิศวกรมนุษย์ ซึ่งอาจเพิ่มสัดส่วนการทดสอบที่รันในเครื่องโลคัลได้ ทำให้ flaky ลดลงและลดภาระของ CI
      แม้ AI จะเพิ่มประสิทธิภาพได้ แต่มันก็จะนำไปสู่โค้ดที่มากขึ้น การสร้างและรันโค้ดที่เร็วขึ้น และปัญหาใหม่ ๆ ที่ตามมาอย่างต่อเนื่อง ซึ่งสุดท้ายก็ยังต้องมีวิศวกรมนุษย์คอยแก้อยู่ดี

    • LLM เหมาะกับงานแก้ไขเล็ก ๆ ที่ไม่เกิน 100 บรรทัด หรือทำหน้าที่คล้าย rubber duck ได้โอเค แต่ถ้าเอา LLM ใส่เข้าไปตรง ๆ ใน CI pipeline ของโปรเจกต์ขนาดใหญ่ อาจทำให้ประสิทธิภาพการทำงานลดลงเป็นหลักหลายร้อยชั่วโมง
      ถ้าสุดท้ายต้องใช้เวลาไปกับการจูน prompt และจัด context แทนที่จะพัฒนาทักษะการเขียนโค้ดจริง ๆ ก็ไม่มีความหมาย
      รู้สึกว่าความมั่นใจต่อ tooling ของ LLM สูงเกินไป และคิดว่ามันใช้กับระบบซับซ้อนได้ไม่ดี
      มีความไม่ไว้วางใจอย่างมากถึงขั้นว่า การปล่อย LLM แบบไม่มีการกำกับดูแลเข้าไปใน repository สำคัญนั้นคงไม่เกิดขึ้น “เว้นแต่จะถูกเอาปืนจ่อ”
      สุดท้ายแล้วก็มักต้องกลับมาแก้ผลลัพธ์ของ LLM อยู่ครึ่งหนึ่ง และถ้าเป็นแบบนั้นทำเองน่าจะดีกว่า

    • ก่อนมีรถยนต์ แทบไม่ต้องเสียเงินกับน้ำมัน น้ำมันเครื่อง หรือการบำรุงรักษา แต่เมื่อระบบก้าวหน้าขึ้น ก็ต้องมีโครงสร้างพื้นฐานและค่าใช้จ่ายประกอบตามมา
      นี่เป็นวงจรที่ใช้ AI แก้คอขวดหรือสร้างฟีเจอร์เพิ่มเพื่อเพิ่มรายได้สูงสุด แล้วเอารายได้ส่วนเพิ่มนั้นไปซื้อทรัพยากร CI เพิ่ม
      AI ก็ไม่ต่างจากการเพิ่มนักพัฒนาอีก 10 คน ดังนั้นต้นทุนสนับสนุนที่เพิ่มขึ้นจึงเป็นเรื่องธรรมดา
      เป็นมุมมองที่ชวนให้ย้อนคิดว่า เราสามารถอธิบายเรื่องประสิทธิภาพอย่างมีเหตุผลเพื่อขอทรัพยากร CI เพิ่ม หรือชี้แนวทางในการ optimize ได้หรือไม่
      อยากรู้ว่าต้นทุนต่อเครื่องของทรัพยากร CI อยู่ที่เท่าไร

    • มีประสบการณ์เร่งความเร็ว CI ได้มากในแอป Python ด้วยการใช้ toolchain ของ astral.sh และการติดตั้งแพ็กเกจผ่าน uv พร้อมใช้แคช
      อีกไม่นานมีแผนจะย้ายจาก mypy ไปใช้ type checker ของ astral ซึ่งก็น่าจะยิ่งเร็วขึ้น
      ถ้าเป็นแอปที่มี frontend ส่วนที่ช้าที่สุดน่าจะเป็นการทดสอบ Playwright แต่กับแอปอื่น ๆ ก็อาจไม่ใช่ประเด็น
      (ป.ล. ถ้า Mike คนนี้ใช่คนที่คิดไว้ ก็น่าจะเป็น SRE ที่เคยทำงานด้วยกันใน Google Maps ช่วงต้นทศวรรษ 2000 เป็นความเห็นที่เชื่อถือได้)

  • ฉันลองขอ regex pattern ใน Mercury playground แล้วพบว่าโมเดลเริ่มวางแผนเอง เขียน pattern แล้วต่อด้วยการสร้างเทสต์
    แต่จากนั้นมันก็เพิ่มจำนวนเทสต์ไปเรื่อย ๆ ไม่หยุด จนชนขีดจำกัดของ context แล้วคำตอบก็ขาดไป
    พอเกินราว 30 อัน มันเริ่มใส่คอมเมนต์ผลทดสอบผิด ๆ และหลัง 120 อันไปแล้ว input ของเทสต์เองก็เริ่มเพี้ยน มีตัวอักษรสุ่มเต็มไปหมด
    ตัว pattern เองก็ไม่ใช่คำตอบที่ถูกต้องอยู่แล้ว แต่ปรากฏการณ์ “ลูปไม่รู้จบ” นี้น่าสนใจกว่า

    • อนึ่ง จำได้ว่าเมื่อไม่นานมานี้ LLM ทั่วไปก็เคยมีเอาต์พุตซ้ำ ๆ ที่ดูเหมือน “ลูปเกือบไม่สิ้นสุด” แบบนี้เหมือนกัน
      เป็นการติดอยู่กับรูปแบบที่ผลลัพธ์ต่างกันออกไปเพียงเล็กน้อย

    • คิดว่ากรณีนี้เป็นหลักฐานชั้นดีว่า “การทำนาย token อย่างเดียวไม่สามารถสร้างโค้ดได้อย่างแม่นยำ”
      เป็นการประเมินว่า LLM ไม่ได้ถูกออกแบบมาให้เหมาะกับการใช้เหตุผลด้านโค้ดตั้งแต่ต้น

  • จากที่ฉันอ่านรายงานทางเทคนิค Mercury ดูเหมือนจะอิงจากงาน Lou et al. 2023, SEDD
    ฉันเป็นคนแรก ๆ (อาจจะคนแรก) ที่ reimplement SEDD แบบ from-scratch และ เปิดโค้ดไว้
    ฉันยัง implement วิธี denoising ที่ซับซ้อนด้วยตัวเอง
    ออกแบบให้สะอาดและอ่านง่ายกว่า SEDD เดิม และสามารถรันบน single GPU กับชุดข้อมูลขนาดเล็กได้ภายในไม่กี่ชั่วโมง

  • อนึ่ง ที่ DeepMind ก็มีโมเดล Gemini แบบ diffusion เหมือนกัน (ลิงก์)
    จากที่ลองเอง มันเร็วมากแบบเดียวกับ Mercury แต่คุณภาพคำตอบด้อยกว่า Gemini รุ่นอื่นค่อนข้างมาก

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

    • สงสัยว่า Gemini Diffusion demo ใช้งานฟรีหรือเปล่า
      ฉันอยู่ใน waiting list มาหลายวันแล้ว เลยยังไม่มีโอกาสได้ลองใช้จริง เสียดายมาก

  • ส่วนตัวตื่นเต้นกับพัฒนาการแบบนี้มาก
    ตอน game jam ล่าสุด ฉันใช้ AI ช่วยเขียนเกมง่าย ๆ แต่เวลาส่วนใหญ่กว่าครึ่งหมดไปกับการรอผลลัพธ์
    ถ้าจากเดิมต้องรอ 1–2 นาทีต่อ prompt แล้วลดเหลือแค่ 10 วินาที ก็จะทดลองได้ 5 ถึง 10 รอบในเวลาที่เมื่อก่อนทดสอบได้ครั้งเดียว
    ตอนนี้ Mercury ยังไม่โตพอจะใช้งานจริงได้อย่างสะดวก แต่ Claude 3.0 เมื่อหนึ่งปีก่อนก็ยังไม่ดีนัก ดังนั้นต่อจากนี้ก็น่าจะดีขึ้นอีก
    เป็นช่วงเวลาที่น่าตื่นเต้นมากสำหรับอนาคต

  • ลองใช้ Mercury playground แล้ว ความเร็วสุดยอดจริง ๆ
    ภาพแสดงผลของ diffusion mode ก็สดใหม่ดี แต่ในทางปฏิบัติดูเหมือนมันกำลังแสดงกระบวนการค่อย ๆ ขัดเกลาจากเส้น noise ที่มองเห็นให้กลายเป็นสถานะที่แม่นยำขึ้น
    ในความเป็นจริงน่าจะมองได้ว่าเป็นกระบวนการค่อย ๆ ลู่เข้าสู่ token ที่แน่ชัดยิ่งขึ้นใน vector space แบบสุ่ม

    • โมเดล text diffusion บางตัวใช้ latent space แบบต่อเนื่อง แต่ประสิทธิภาพไม่ค่อยดีนัก
      ช่วงหลังมานี้ส่วนใหญ่มักเน้นการทำนายเอาต์พุต token จริง แล้วค่อยแก้ค่าก่อนหน้าเป็นขั้น ๆ จนลู่เข้าสู่ผลลัพธ์สุดท้าย
      แนะนำให้อ่าน ลิงก์อธิบายการทำงานของ text diffusion ที่ฉันเขียน

    • ลิงก์ : https://chat.inceptionlabs.ai/

    • เร็วจนน่าตกใจจริง ๆ

  • โค้ดที่ทำงานใกล้ชิดกับ GPU ส่วนใหญ่ยังมีช่องให้ปรับจูนประสิทธิภาพได้อีกมาก
    แต่ก็มีการตั้งข้อสงสัยว่า paper บน arXiv นี้ดูคล้ายงานการตลาดมากกว่างานวิจัยจริง
    ยินดีรับฟังความเห็นอื่น

    • ก็ไม่ถึงกับเป็นประเด็นที่ผิดนัก แต่กรณีแบบนี้ใน arXiv ก็ไม่ใช่ครั้งแรก

  • นโยบายราคาโมเดล Mercury
    1 ดอลลาร์ต่อ output token 1 ล้านตัว และ 0.25 ดอลลาร์ต่อ input token 1 ล้านตัว
    ดูรายละเอียดราคาเพิ่มเติมได้ที่ นี่

    • ราคาค่อนข้างสูงนิดหน่อย
      ถ้าเน้นเรื่องประสิทธิภาพ ตอนเปรียบเทียบ Mercury กับ Groq (Llama 3.1 8b, Llama 4 Scout) ประสิทธิภาพพอ ๆ กัน แต่ราคาของ Groq ดีกว่ามาก
      กำลังจับตาดูด้วยความสนใจและหวังว่าจะได้เห็น diffusion model แบบโอเพนซอร์สออกมา

  • ในโค้ดของ playground และคำตอบจาก API มี gpt-3.5-turbo กับ "openai": true โผล่มา เลยสงสัยว่าจริง ๆ แล้วมันเรียก OpenAI อยู่ ไม่ได้ใช้ dLLM ของตัวเองหรือเปล่า
    ฟีเจอร์ diffusion effect มุมขวาบนก็ดูเหมือนเป็นแค่อนิเมชันประกอบ

    • ความเร็วระดับเกือบเรียลไทม์แบบนี้ ไม่น่าใช่การใช้ backend ของ OpenAI จริง

  • ทุกอย่างฟังดูดีมาก แต่
    ถ้าส่งโพสต์ของผู้ใช้เข้าไปในบริการ จะถือว่าผู้ใช้มอบไลเซนส์แบบไม่ผูกขาด ถาวร ปลอดค่าลิขสิทธิ์ ฟรี และโอนสิทธิ์ต่อได้ทั้งหมดให้ Inception ทั่วโลกตามเงื่อนไขการใช้งาน
    นั่นหมายความว่าเนื้อหาของผู้ใช้สามารถถูกนำไปใช้ฝึกโมเดล AI ได้
    (แต่มีข้อยกเว้นว่าหากเข้าผ่าน OpenRouter จะไม่ถูกนำไปใช้ฝึก)