เปิดตัวโมเดล Qwen3-Coder-Next

 (qwen.ai)
6 คะแนน โดย GN⁺ 2026-02-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Qwen3-Coder-Next เป็น โมเดลภาษาน้ำหนักเปิด ที่ออกแบบมาสำหรับเอเจนต์เขียนโค้ดและสภาพแวดล้อมการพัฒนาแบบโลคัล โดยมีพื้นฐานจากสถาปัตยกรรม hybrid attention และ MoE
  • ผ่านการฝึกด้วย การสังเคราะห์งานที่รันได้จริง ขนาดใหญ่, การโต้ตอบกับสภาพแวดล้อม และ การเรียนรู้แบบเสริมกำลัง ทำให้มี ความสามารถด้านการเขียนโค้ดและการเป็นเอเจนต์ ที่แข็งแกร่งแม้มีต้นทุนการอนุมานต่ำ
  • แทนที่จะขยายจำนวนพารามิเตอร์เพียงอย่างเดียว โมเดลนี้มุ่งเน้นที่ การขยายสัญญาณการฝึกของเอเจนต์ และใช้โจทย์โค้ดที่ตรวจสอบได้กับสภาพแวดล้อมการรันเพื่อเรียนรู้จากฟีดแบ็กโดยตรง
  • ทำได้มากกว่า 70% บน SWE-Bench Verified และแสดงประสิทธิภาพที่แข่งขันได้กับโมเดลขนาดใหญ่บน SWE-Bench Pro และในสภาพแวดล้อมหลายภาษา
  • แม้จะเป็นโมเดลขนาดเล็ก แต่ก็สร้าง สมดุลแบบพาเรโต ระหว่างประสิทธิภาพและสมรรถนะได้สำเร็จ ซึ่งมีความหมายสำคัญต่อ การปรับใช้เอเจนต์อย่างคุ้มค่า

ภาพรวมของ Qwen3-Coder-Next

  • Qwen3-Coder-Next เป็นโมเดลภาษาน้ำหนักเปิดที่พัฒนาบนพื้นฐานของ Qwen3-Next-80B-A3B-Base
    • ใช้สถาปัตยกรรม hybrid attention และ Mixture of Experts(MoE)
    • ฝึกด้วย การสังเคราะห์งานที่รันได้จริง ขนาดใหญ่, การโต้ตอบกับสภาพแวดล้อม และ การเรียนรู้แบบเสริมกำลัง
  • เป้าหมายคือการใช้งานอย่างมีประสิทธิภาพใน เอเจนต์เขียนโค้ด และ สภาพแวดล้อมการพัฒนาแบบโลคัล
    • มอบ ความสามารถในการให้เหตุผล และ ประสิทธิภาพการเขียนโค้ด ที่แข็งแกร่งแม้มีต้นทุนการอนุมานต่ำ

แนวทางการขยายการฝึกเอเจนต์

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

ประสิทธิภาพบนเบนช์มาร์กของเอเจนต์เขียนโค้ด

  • มีการประเมินบนเบนช์มาร์กหลากหลาย เช่น SWE-Bench (Verified, Multilingual, Pro), TerminalBench 2.0, Aider
    • ทำได้มากกว่า 70% บน SWE-Bench Verified
    • ยังคงรักษาความสามารถในการแข่งขันได้บน SWE-Bench Pro และในสภาพแวดล้อมหลายภาษา
    • แม้มีจำนวน active parameters น้อย แต่ให้ประสิทธิภาพเทียบเท่าหรือดีกว่าโมเดลโอเพนซอร์สที่ใหญ่กว่า
  • ใน งานเอเจนต์แบบหลายเทิร์น พบว่ายิ่งเพิ่มจำนวนเทิร์นของเอเจนต์ ก็ยิ่งเสริม ความสามารถในการให้เหตุผลระยะยาว

สมดุลระหว่างประสิทธิภาพและสมรรถนะ

  • Qwen3-Coder-Next (3B active) ทำผลงานบน SWE-Bench-Pro ได้ใกล้เคียงกับ โมเดลที่ใหญ่กว่าถึง 10~20 เท่า
  • แม้ โมเดลปิดที่ใช้ full attention จะนำหน้าในด้านประสิทธิภาพสูงสุด แต่ Qwen3-Coder-Next อยู่บนพาเรโตฟรอนเทียร์ที่โดดเด่นด้าน ความคุ้มค่าต่อค่าใช้จ่าย
  • สิ่งนี้แสดงให้เห็นว่าเป็นโมเดลที่เหมาะกับ การปรับใช้เอเจนต์อย่างคุ้มค่า

เดโมและตัวอย่างการใช้งาน

  • เป็นโมเดล coder ขนาดเล็กและรวดเร็วที่ผสานเข้ากับสภาพแวดล้อมการใช้งานได้หลากหลาย
    • มีการสาธิตบน OpenClaw, Qwen Code, Claude Code, Web Dev, Browser Use, Cline
    • ใช้งานผ่านเว็บได้ที่ coder.qwen.ai

สรุปและแผนในอนาคต

  • Qwen3-Coder-Next พิสูจน์ให้เห็นถึง ความเร็วและความสามารถในการให้เหตุผลที่ยอดเยี่ยมบนเบนช์มาร์กของเอเจนต์เขียนโค้ด
  • แม้จะแสดง ประสิทธิภาพที่แข่งขันได้ เมื่อเทียบกับโมเดลโอเพนซอร์สขนาดใหญ่ แต่ก็ยังมีพื้นที่ให้พัฒนาอีก
  • ในอนาคตมีแผนเสริม ความสามารถในการใช้เครื่องมือ, การแก้ปัญหาที่ซับซ้อน, ความสามารถในการตัดสินใจ และ
    • รองรับงานได้มากขึ้นพร้อม อัปเดตอย่างรวดเร็ว โดยอิงจากฟีดแบ็กของผู้ใช้

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

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

 
GN⁺ 2026-02-04
ความคิดเห็นบน Hacker News

  • โมเดล GGUF นี้มีขนาด 48.4GB จึงรันได้แม้บนโน้ตบุ๊กสเปกสูง
    จนถึงตอนนี้ฉันยังไม่เคยเห็นโมเดลโลคัลที่รันเอเจนต์เขียนโค้ดระดับ Codex CLI หรือ Claude Code ได้ดีจริงบน MacBook Pro 64GB ของฉัน
    เลยสงสัยว่าคราวนี้อาจจะแตกต่างออกไป ดูจากไกด์ของ Unslothแล้วก็น่าจะมีความเป็นไปได้

    • ฉันคิดว่าควรมีคำใหม่อย่าง “โมเดลบนเครื่องฉัน” แทนคำว่า “โมเดลโลคัล”
      แค่เชื่อมผ่าน llama.cpp บนเครื่องเดียวกันแล้วเรียกว่าโลคัลมันยังไม่พอ สิ่งที่ฉันหมายถึงคือ โมเดล LAN คือระดับที่สามารถรัน inference ได้แบบ ‘ฟรี’ บนฮาร์ดแวร์ที่ฉันควบคุมเองโดยตรง
      ตัวอย่างเช่น ชุด 5090 + Threadripper + RAM 256GB อยู่ที่ราว 10,000 ดอลลาร์ ส่วนสาย MLX อยู่ที่ราว 6,000 ดอลลาร์
      สถาปัตยกรรมภายในและวิธี quantization ของโมเดลมีผลมากต่อการใช้หน่วยความจำจริง ดังนั้นการเทียบกันด้วยจำนวนพารามิเตอร์อย่างเดียวจึงยิ่งมีความหมายน้อยลงเรื่อย ๆ
      เพราะแบบนั้นจึงน่าจะต้องมีระบบ benchmark งานจริงอย่าง tool calling, การสร้างโค้ด, การประมวลผลเอกสาร บนมาตรฐานฮาร์ดแวร์ที่กำหนดไว้
    • ฉันกำลังรัน Qwen3-Coder-30B-A3B-Instruct gguf บน VM RAM 13GB และ GPU RTX 2060 6GB
      แม้จะเป็นโน้ตบุ๊ก Razer Blade รุ่นเก่า แต่ก็ยังทำงานได้ค่อนข้างเสถียรถึง คอนเท็กซ์ 64k
      สำหรับงานอย่างโปรเจ็กต์เล็ก ๆ การแก้บั๊ก หรือการปรับปรุง UI ก็ถือว่าใช้งานได้ดีพอ
      แต่ฉันคิดว่าเกณฑ์ของคำว่า “usable” ต่างกันไปในแต่ละคน การประเมินก็จะเปลี่ยนไปตามงานที่ลองทำ
    • ฉันลองใช้ GPT-OSS-120b (MXFP4) กับ Codex แล้ว ซึ่งใช้ VRAM ราว 66GB
      ถ้ารวบรวมล็อกการรันที่ดีของโมเดล 120b แล้วเอาไป fine-tuning รุ่น 20b ต่อ ก็น่าจะมีประโยชน์มาก
      ถ้าเพิ่ม reasoning_effort ก็ให้ผลลัพธ์ที่ค่อนข้างดี แต่ด้วยข้อจำกัดหน่วยความจำ 64GB การปรับปรุง 20b จึงดูเป็นจริงได้มากกว่า
    • ฉันลองตั้งค่า Claude Code ให้ใช้โมเดลโลคัล (ollama run glm-4.7-flash) แล้วรันบน Mac mini M2Pro 32GB
      ใช้จัดระเบียบโค้ดของโปรเจ็กต์ git เก่า ทำเอกสาร และเพิ่มเทสต์ ได้ดีพอสมควร
      มาตรฐานของฉันอาจจะไม่สูงมาก แต่ในฐานะ ตัวช่วยเขียนโค้ดแบบโลคัล ก็ถือว่าพอใจทีเดียว
    • อีกประมาณ 5 ปีข้างหน้า ฉันคิดว่าโมเดลส่วนใหญ่น่าจะ รันแบบโลคัล ได้
      ถ้าการผลิต GPU ประสิทธิภาพสูงและหน่วยความจำเพิ่มขึ้น และมีการปรับแต่งโมเดลต่อเนื่อง ฮาร์ดแวร์ระดับกลางก็น่าจะให้ประสิทธิภาพที่ดีพอได้

  • มีการอัปโหลด Dynamic Unsloth GGUF สำหรับ deploy แบบโลคัลไว้บน Hugging Face แล้ว
    และยังเขียนไกด์สำหรับใช้ Claude Code / Codex แบบโลคัลด้วย

    • บนระบบของฉันทำความเร็วได้ราว 39 tok/s โดยใช้ GPU ประมาณ 60%
      รันเซิร์ฟเวอร์ llama.cpp บนสภาพแวดล้อมที่ใช้ Radeon RX 7900 XTX และทำงานได้เสถียรด้วยการตั้งค่า ctx-size 32768
    • ได้รับฟีดแบ็กว่ามีคนใช้โมเดลของฉันบน Framework Desktop
      มีคำถามว่าทำไมควรใช้เวอร์ชันของ Unsloth แทน GGUF ปกติของ Qwen3
    • มีคำขอให้นำ IQuest-Coder มาแจกจ่ายในรูปแบบเดียวกันด้วย
    • มีคนถามถึงความแตกต่างระหว่างเวอร์ชัน UD กับเวอร์ชันปกติ
    • ยังมีปฏิกิริยาแนวทึ่ง ๆ ว่า “ทำไมถึงทำสิ่งนี้ได้เร็วขนาดนี้”

  • ติดตั้ง llama.cpp ผ่าน Homebrew แล้วรันโมเดล quantized ของ Unsloth แบบโลคัล
    สามารถเปิดทั้งอินเทอร์เฟซ CLI และ เซิร์ฟเวอร์ API ที่เข้ากันได้กับ OpenAI พร้อมกันได้ และใช้ RAM ราว 28GB

    • มีคนถามว่าความเร็วโทเค็น (token/s) ได้เท่าไร
    • อีกคนก็อยากรู้ว่าความรู้สึกโดยรวมเป็นอย่างไร

  • ถ้าโมเดลนี้ทำได้จริงตามที่อ้างว่า ให้ประสิทธิภาพการเขียนโค้ดระดับ Sonnet 4.5 ด้วย active parameters แค่ 3B ก็ถือว่าใหญ่มาก

    • ฉันทดสอบเวอร์ชัน quantization แบบ Q2 และ Q4 แล้ว แม้จะน่าทึ่งที่รันโลคัลได้ แต่ ยังไม่ถึงระดับ Sonnet 4.5
      มันยังมีข้อผิดพลาดแม้กับปัญหาง่าย ๆ และบางครั้งก็ติดอยู่ใน thinking loop
      อาจเป็นบั๊กของ implementation ช่วงแรก แต่ตอนนี้ยังดูเหมือนเป็นคำกล่าวอ้างประสิทธิภาพที่เกินจริง
    • จากความรู้สึกของฉัน มันใกล้กับ ระดับ Haiku มากกว่า
    • ทำให้นึกถึงคำพูดที่ว่า “ถ้ามันดูดีเกินไป ก็มีโอกาสสูงที่จะไม่จริง”

  • ฉันลองรัน Qwen3 Coder 30B แบบโลคัลบน Mac M4 Max (36GB)
    แม้จะช้าแต่ก็ใช้งานได้ และให้ผลลัพธ์ที่ค่อนข้างดี
    เลยแชร์วิดีโอสาธิตและบล็อกวิธีตั้งค่า

  • บนโน้ตบุ๊ก VRAM 6GB ทำได้ 17 tok/s และคอนเท็กซ์สูงสุด 100k
    แม้จะน่าทึ่ง แต่เพราะความเร็วช้า สุดท้ายก็ยังคิดว่าจะใช้ cloud inference ต่อไป
    มีการแชร์ [docker-compose ตัวอย่างการตั้งค่า]

  • มีการ benchmark โมเดล FP8 บนสภาพแวดล้อม DGX Spark + vLLM 0.15.1
    สำหรับคำขอเดี่ยวทำได้ราว 43 tok/s และเมื่อรันหลายคำขอพร้อมกันขึ้นไปได้สูงสุด 62 tok/s

    • มีคนลองรันโมเดล FP8 บน vLLM แล้วพบว่าระหว่างรันมันถูก dequantize เป็น BF16 จนเกิด memory swap
      ส่วนเวอร์ชัน quantization 4-bit ของ llama.cpp ทำได้ราว 30~35 tok/s และใช้ RAM เพียง 50GB แม้ที่ คอนเท็กซ์ 200k

  • แม้ประสิทธิภาพจะต่ำกว่า GLM 4.7 เล็กน้อยด้วย active parameters 3B แต่ประสิทธิภาพเชิงความคุ้มค่านั้นน่าทึ่งมาก
    ฉันคิดว่าถ้าเอาเอเจนต์เขียนโค้ดที่เร็วแต่เรียบง่ายไปใช้ร่วมกับ orchestrator ความเร็วโดยรวมอาจยิ่งดีขึ้นได้

    • ฉันใช้ ฟังก์ชัน sub-agent ของ Claude เพื่อรันเอเจนต์ TypeScript ที่สร้างบน Mastra ผ่าน CLI
      ใช้ทำงานซ้ำ ๆ อัตโนมัติ เช่น สแกนโค้ด ค้นหาไลบรารี และสำรวจ SourceGraph
      ด้วย ฟีเจอร์ Workspace ของ Mastra จึงทำให้การพัฒนาแบบ agentic ทรงพลังขึ้นมาก
    • สุดท้ายแล้ว สิ่งเหล่านี้น่าจะแพร่หลายก็ตอนที่ บริษัท AI รายใหญ่ขึ้นราคา

  • ฉันลองรัน lmstudio-community/Qwen3-Coder-Next-GGUF:Q8_0 บน Strix Halo
    ทำได้ 32 tok/s และคอนเท็กซ์ถึง 128k แม้จะด้อยกว่า MiniMax M2.1 Q6 เล็กน้อยแต่ก็น่าประทับใจ

    • มีคนถามว่า Strix Halo เป็นอย่างไรบ้าง และมีความเห็นว่าอยากได้เครื่องที่ทำ local inference ได้โดยไม่ต้อง quantize
    • บน NVIDIA Spark ก็ได้ตัวเลขใกล้เคียงกัน และกำลังทดสอบเวอร์ชัน Q4_K_XL
      FP8 ใช้หน่วยความจำ 110GB จึงได้คอนเท็กซ์แค่ 16k
      มีการลองใช้สร้างโค้ด Rust แล้วพบว่ามันค่อนข้างมีความสามารถ ถ้าเรื่องความเร็วดีขึ้นก็น่าจะใช้งานจริงได้
      คิดว่าอีกไม่นาน ผู้ให้บริการ API ก็น่าจะเริ่มให้บริการโมเดลนี้ในราคาถูก

  • สงสัยว่ามี แหล่งจัดอันดับโมเดลโลคัลที่เชื่อถือได้ ที่ไหนบ้าง
    เพราะ benchmark ดูเหมือนถูกปรุงแต่งมากเกินไป เลยคิดว่า รีวิวจากผู้ใช้จริงมีความหมายมากกว่า
    อยากรู้ว่ามีที่ไหนรวบรวม โมเดลเด่นแยกตามโดเมน อย่างโค้ด เสียง ภาพ การสรุป เพลง ฯลฯ ไว้บ้าง