Step 3.5 Flash – LLM โอเพนซอร์สที่รองรับการอนุมานความเร็วสูง

• ใช้สถาปัตยกรรม Sparse Mixture of Experts ที่เปิดใช้งานเพียง 11B จากพารามิเตอร์ทั้งหมด 196B ทำให้รองรับการอนุมานความเร็วสูงและการโต้ตอบแบบเรียลไทม์
• ทำความเร็วการสร้างได้สูงสุด 350 โทเคนต่อวินาที และรองรับคอนเท็กซ์วินโดว์ขนาด 256K
• ด้วยผลลัพธ์ SWE-bench Verified 74.4% จึงแสดงประสิทธิภาพที่เสถียรในเบนช์มาร์กด้านโค้ดและเอเจนต์ และยังสามารถรันได้ใน สภาพแวดล้อมโลคัล (Mac Studio M4 Max, NVIDIA DGX Spark)
• พิสูจน์ความน่าเชื่อถือและความสามารถในการปฏิบัติการในสถานการณ์งานจริง เช่น การเงิน การวิเคราะห์ข้อมูล และระบบอัตโนมัติงานวิจัย ผ่าน การอนุมานที่อาศัยการใช้เครื่องมือ และ มัลติเอเจนต์ออร์เคสเทรชัน
• ใช้ เทคนิคการเพิ่มประสิทธิภาพ MIS-PO ที่อิงการเรียนรู้แบบเสริมกำลังเพื่อคงเสถียรภาพของการอนุมานระยะยาว และมอบ ความสามารถด้านการอนุมานและการลงมือทำระดับ frontier ด้วยต้นทุนต่ำกว่าโมเดลสมรรถนะสูงหลายตัว

---

ภาพรวมโมเดลและประสิทธิภาพ

• Step 3.5 Flash เป็น foundation model แบบโอเพนซอร์สที่ผสาน การอนุมานความเร็วสูงและความสามารถแบบเอเจนต์ เข้าด้วยกัน โดยทำคะแนนเฉลี่ยบนเบนช์มาร์กได้ 81.0
  • สูงกว่าคะแนนเฉลี่ยของโมเดลหลักอย่าง GLM-4.7(78.5), DeepSeek V3.2(77.3), Kimi K2.5(80.5)
• ด้วยโครงสร้าง Sparse MoE จึงเปิดใช้งานเพียง 11B จาก 196B พารามิเตอร์ ทำให้คำนวณได้อย่างมีประสิทธิภาพและตอบสนองแบบเรียลไทม์ได้
• บนพื้นฐาน MTP-3 ทำความเร็วการสร้างได้ 100~300 tok/s ในการใช้งานทั่วไป และสูงสุด 350 tok/s ในงานเขียนโค้ด
• ได้ SWE-bench Verified 74.4% และ Terminal-Bench 2.0 51.0% แสดงถึงประสิทธิภาพที่เสถียรสำหรับงานโค้ดและงานเอเจนต์ระยะยาว
• รองรับ คอนเท็กซ์วินโดว์ 256K ด้วยโครงสร้าง 3:1 SWA ทำให้ยังคงความคุ้มค่าด้านต้นทุนแม้ในบริบทยาว

กรณีการใช้งานจริงและการใช้เครื่องมือ

• ปรับปรุงประสิทธิภาพในงานคณิตศาสตร์ โค้ด และการวิเคราะห์ข้อมูล ผ่าน การอนุมานแบบใช้เครื่องมือ (tool-augmented reasoning)
  • เมื่อรวมการรัน Python เข้าด้วยกัน คะแนนใน AIME 2025(99.8), HMMT 2025(98.0), IMOAnswerBench(86.7) ดีขึ้น
• ใน สถานการณ์การลงทุนหุ้น สามารถผสานเครื่องมือ MCP มากกว่า 80 รายการ เพื่อทำงานเก็บข้อมูล วิเคราะห์ และแจ้งเตือนอัตโนมัติ
• Autonomous Business Intelligence Engine ทำงานอัตโนมัติตั้งแต่การประมวลผล CSV ไปจนถึงการพยากรณ์ พร้อมระบุความต่างด้านคุณภาพข้อมูลได้ 1.6 เท่า
• Large-Scale Repository Architect วิเคราะห์โค้ดเบสขนาดใหญ่และสร้างวิกิเฉพาะทางที่เชื่อมโยงแพตเทิร์นการออกแบบเข้ากับรายละเอียดการติดตั้งใช้งาน

งานวิจัยและประสิทธิภาพของเอเจนต์

• บนเบนช์มาร์ก ResearchRubrics ได้ 65.3% สูงกว่า Gemini DeepResearch(63.7) และ OpenAI DeepResearch(60.7)
  • ดำเนินกระบวนการวางแผน ค้นหา ตรวจสอบ และเขียน ภายในลูปแบบ ReAct เดียว
• ในสภาพแวดล้อม Claude Code ทำคะแนนเบนช์มาร์กด้านการวิเคราะห์ข้อมูลได้ 39.6% สูงกว่า GPT-5.2(39.3) เล็กน้อย
• ผ่าน Multi-Agent Framework ให้ Master Agent ประสานงานเอเจนต์ค้นหา ตรวจสอบ และสรุป เพื่อสร้างผลลัพธ์ที่มีโครงสร้าง
• ด้วย Cloud-Device Synergy เมื่อทำงานร่วมกับ Step-GUI จะได้ 57 คะแนนบนเบนช์มาร์ก AndroidDaily Hard (เทียบกับ 40 คะแนนเมื่อรันเดี่ยว)

สถาปัตยกรรมและคุณลักษณะทางเทคนิค

• ใช้ แบ็กโบน Sparse MoE เพื่อแยก global capacity (196B) ออกจากการคำนวณต่อโทเคน (11B) ทำให้ เพิ่มประสิทธิภาพด้านต้นทุนและความเร็วของการอนุมาน
• โครงสร้าง Sliding-Window Attention + Full Attention(3:1) ช่วยรักษาประสิทธิภาพเมื่อประมวลผลบริบทยาว
• ใช้ Head-wise Gated Attention เพื่อควบคุมการไหลของข้อมูลแบบไดนามิกและคงเสถียรภาพเชิงตัวเลข
• ทำ throughput การถอดรหัสได้ 350 tok/s บน GPU NVIDIA Hopper
• รองรับ การอนุมานแบบโลคัล (20 tok/s, คอนเท็กซ์ 256K) ผ่าน โมเดล quantization แบบ INT4 GGUF

เฟรมเวิร์กการเรียนรู้แบบเสริมกำลัง

• นำ Metropolis Independence Sampling Filtered Policy Optimization(MIS-PO) มาใช้
  • ใช้ การกรองแบบไบนารี เพื่อตัดตัวอย่างที่ไม่เสถียรออก แทนการทำ importance sampling
  • ใช้ truncation-aware value bootstrapping และ routing confidence monitoring เพื่อทำให้การอนุมานระยะยาวเสถียรมากขึ้น
• โครงสร้างนี้เปิดทางให้เกิด การพัฒนาตนเองอย่างต่อเนื่อง ในงานคณิตศาสตร์ โค้ด และการใช้เครื่องมือโดยรวม

การเปรียบเทียบเบนช์มาร์ก

• Step 3.5 Flash แสดง ประสิทธิภาพระดับบนที่สมดุล ในสามด้านคือ Reasoning, Coding และ Agentic
  • AIME 2025: 97.3 / HMMT 2025: 98.4 / LiveCodeBench-V6: 86.4
  • τ²-Bench: 88.2 / BrowseComp-ZH: 66.9 / ResearchRubrics: 65.3
• ต้นทุนการถอดรหัส ที่คอนเท็กซ์ 128K อยู่ที่ 1.0x ซึ่งมีประสิทธิภาพมากกว่า DeepSeek V3.2(6.0x) และ Kimi K2.5(18.9x)

ข้อจำกัดและทิศทางในอนาคต

• ประสิทธิภาพต่อโทเคน: เมื่อเทียบกับ Gemini 3.0 Pro ยังต้องสร้างข้อความยาวกว่าเพื่อให้ได้คุณภาพเท่ากัน
• การผสานความเชี่ยวชาญเฉพาะทาง: กำลังวิจัย on-policy distillation เพื่อผสานความเป็นโมเดลทั่วไปและความเชี่ยวชาญเฉพาะทางอย่างมีประสิทธิภาพ
• การขยาย RL แบบเอเจนต์: มีแผนขยายการประยุกต์ใช้ RL ไปสู่งานที่ซับซ้อนในระดับงานวิชาชีพและงานวิจัย
• เสถียรภาพการปฏิบัติงาน: ในการสนทนายาวหรือเมื่อสลับโดเมน อาจยังเกิดการอนุมานซ้ำหรือการสร้างผลลัพธ์หลายภาษาปะปนกันได้

การเผยแพร่และการเข้าถึง

• ใช้งานได้ผ่านการผสานเข้ากับ แพลตฟอร์ม OpenClaw ด้วยการติดตั้งและลงทะเบียนโมเดลที่ไม่ซับซ้อน
• เข้าถึงได้ผ่าน แพลตฟอร์ม API (อังกฤษ/จีน) และ เว็บ·แอปมือถือ(iOS/Android)
• มีการอัปเดตและการสนับสนุนผ่าน ชุมชน Discord

[sftblw]

โมเดลนี้ใช้ได้เลย
ถ้าใครสะดวกลองรันด้วย llama.cpp จะต้องใส่พรอมป์ต์ที่อยู่ในคอมเมนต์ของเธรดด้านล่างแยกต่างหากด้วย ไม่อย่างนั้นจะเกิดปัญหาที่ไม่มี <think> เปิด แต่มีแค่ </think> โผล่มากลางทางอันเดียว
https://huggingface.co/stepfun-ai/Step-3.5-Flash-GGUF-Q4_K_S/…

llama-server \  
  옵션생략 \  
  --jinja \  
  --chat-template-file 경로/step3p5_flash_chat_template.jinja  

[GN⁺]

ความคิดเห็นใน Hacker News

• คิดว่านี่เป็นหนึ่งในรีลีส LLM ที่ ถูกประเมินค่าต่ำเกินไป มากที่สุดตัวหนึ่งในช่วงไม่กี่เดือนที่ผ่านมา
  ลองทดสอบเวอร์ชัน 4-bit quant บนเครื่องโลคัลแล้ว (Step-3.5-Flash-GGUF) พบว่าทำได้ดีกว่า Minimax 2.5 หรือ GLM-4.7 เสียอีก (GLM ใช้ได้แค่ 2-bit)
  จุดเด่นหลักมีดังนี้

  • ประสิทธิภาพด้านคอนเท็กซ์ สูงมาก บน Mac 128GB สามารถรันคอนเท็กซ์เต็ม 256k หรือรันสองสตรีมที่ 128k พร้อมกันได้
  • ความเร็วบน M1 Ultra ก็ดีมาก (36 t/s tg, 300 t/s pp) และถึงคอนเท็กซ์จะใหญ่ขึ้น ความเร็วก็ลดลงไม่มาก
  • ปรับมาเหมาะกับ agentic coding และดูเหมือนจะเทรนมาให้เข้ากับ Claude code ได้ ยกเว้น Codex ที่มีปัญหาเรื่องเครื่องมือแก้ไขแพตช์
    นี่เป็นโมเดลโลคัลตัวแรกในระดับ 200B พารามิเตอร์ที่ใช้ได้จริงบน CLI harness กำลังใช้คู่กับ pi.dev อยู่ และเป็นประสบการณ์ที่ดีที่สุดเท่าที่เคยมีมา
    ข้อเสียคือมี บั๊กวนลูปการให้เหตุผลไม่สิ้นสุด (ประเด็นที่เกี่ยวข้อง)
    ดูเหมือนว่า StepFun จะเป็นบริษัทที่สร้าง ACEStep (โมเดลสร้างเพลง) ด้วย และมีการกล่าวถึงใน เอกสาร ComfyUI
  • ลองทดสอบ Qwen3 Coder Next กับ OpenCode แล้ว พบว่าทำงานได้ค่อนข้างดี
    บางครั้งเรียกใช้เครื่องมือผิด แต่เมื่อใช้ค่า temperature=1 ที่ Qwen แนะนำ ก็ไม่ค้าง
    Nemotron 3 Nano ใช้เครื่องมือได้ไม่เก่งพอ จึงมักลงเอยด้วยการใช้ shell tool เป็นหลัก
    โดยรวมแล้วดูเหมือนว่า โมเดล open weight แบบ agentic จะไม่ค่อยเก่งในการเรียกใช้เครื่องมือที่ไม่คุ้นเคย
  • อยากรู้ว่าการรันโมเดล OSS บน M3 Ultra (RAM 512GB) จะ คุ้มกว่า การจ่ายค่าสมาชิก Claude หรือ Codex หรือไม่
    อยากถามว่ามีใครเคยลองคำนวณเรื่องนี้หรือยัง
  • อยากรู้ว่าปัญหา ลูปการให้เหตุผลไม่สิ้นสุด จะแก้ได้ด้วยการเปลี่ยน inference engine หรือไม่
    ส่วนตัวคิดว่าน่าจะเป็นปัญหาที่ต้องแก้ที่ตัวน้ำหนักโมเดลเอง
  • อยากรู้ว่ามีใครลองรันเวอร์ชัน MLX บ้างไหม ตามทฤษฎีน่าจะเร็วกว่า แต่ก็ยังลังเลที่จะต้องดาวน์โหลดหลายเวอร์ชัน
  • gpt-oss 120b และ 20b ก็ทำงานร่วมกับ Codex ได้ดีเหมือนกัน

• ช่วงนี้อ่าน กระบวนการให้เหตุผล (reasoning) ของทริก “Walk or drive to the carwash” แล้วรู้สึกน่าสนใจมาก
  ลิงก์ที่เกี่ยวข้อง: gist, บทสนทนาใน stepfun.ai

• มีการบอกว่าได้คะแนน 51.0% บน Terminal-Bench 2.0 แต่ก็ยังไม่แน่ใจว่านั่นรับประกันถึง ‘ความสามารถในการจัดการงานระยะยาวอย่างเสถียร’ ได้จริงหรือไม่

  • ตัวเลข 51% เพียงอย่างเดียวไม่ได้มีความหมายมากนัก เบนช์มาร์กประเภทนี้ใช้คะแนนแบบสัมบูรณ์ ดังนั้น 100% ไม่ได้หมายความว่าเท่าระดับมนุษย์
    ดูจากลีดเดอร์บอร์ด คะแนนสูงสุดคือ 75% ดังนั้น 51% ก็ประมาณ ⅔ ของระดับ SOTA
  • คะแนนนี้ใกล้เคียงกับ Gemini 3 Flash แต่ในทางปฏิบัติดูเหมือนว่า การจัดการเอเจนต์ จะมีผลต่อคะแนนมากกว่าตัวโมเดลเอง
  • TerminalBench แม้ชื่อจะเป็นแบบนั้น แต่แทบไม่เกี่ยวกับเทอร์มินัลเลย และส่วนใหญ่ใกล้เคียงกับ การทดสอบไวยากรณ์ของเครื่องมือแบบสุ่ม มากกว่า
    เป็นไปได้ว่าโมเดลอาจแค่จำแฟลกของคำสั่งได้

• พอลองทดสอบแล้วพบว่า หลอน (hallucination) เยอะมาก แม้แต่คำถามง่าย ๆ อย่าง “ช่วยหาเด็คแชมป์เปียนโปเกมอนให้หน่อย” ก็ยังตอบไม่แม่น
  Opus 4.6, Deepseek และ Kimi กลับทำงานได้ดีตามคาด

  • ถ้าเอาไว้ใช้งานจริง ผมคิดว่าใช้โมเดลขนาดกลางน่าจะดีกว่า
  • โมเดลอย่าง Gemini อาจเร็วและแม่นยำกว่า เพราะใช้ ความสามารถด้านการค้นหา อย่างจริงจัง

• เป็นโมเดลที่เพิ่งเปิดตัวไม่นาน ใช้สถาปัตยกรรม Mixture of Experts (MoE) โดยเปิดใช้งานเพียง 11B จากทั้งหมด 196B ต่อโทเคน
  ทำได้ดีกว่า Kimi K2.5 และ GLM 4.7 ในหลายเบนช์มาร์ก
  และยังรันเวอร์ชัน 4-bit quant ได้บนเครื่อง 128GB ด้วย (ลิงก์อ้างอิง)

  • ก็ยังสงสัยว่าแต้มต่อในเบนช์มาร์กนั้นมีความหมายจริงแค่ไหน สำหรับผม การทำตามคำสั่ง การให้เหตุผลกับบริบทยาว และการไม่หลอน สำคัญกว่า
  • อยากรู้ว่า Q4_K_S(116GB), IQ4_NL(112GB), Q4_0(113GB) แบบไหนดีกว่ากัน
    ดู หน้าของโมเดล ได้

• ช่วงหลัง ๆ โมเดลใหม่ได้คะแนนเบนช์มาร์กสูง แต่ก็มาพร้อมกับ การใช้โทเคนที่พุ่งสูงมาก
  ถ้าจะให้เป็นนวัตกรรมจริง ต้องแก้ปัญหา ประสิทธิภาพด้านพลังงาน ให้ได้

  • ไม่ใช่แค่จำนวนโทเคน แต่ ประสิทธิภาพพลังงานต่อโทเคน (tokens/joule) ก็สำคัญเช่นกัน
    การใช้สถาปัตยกรรม MoE อย่างมีประสิทธิภาพส่งผลทั้งต่อ tokens/joule และ tokens/sec

• SWE-bench Verified ก็โอเค แต่เราต้องการ SWE benchmark ที่ดีกว่านี้
  ถ้าจะทำเบนช์มาร์กที่ยุติธรรมจริง ต้นทุนในการรันต่อเนื่องจะสูงมาก
  แนวคิดเรื่อง “live benchmark” นั้นดี แต่ยังสะท้อนโมเดลใหม่ล่าสุดได้ไม่เพียงพอ

  • มีข้อเสนอให้ไปช่วยพัฒนา Terminal Bench 3.0
    ลิงก์เอกสาร

• ผมคิดว่าตัวชี้วัดที่สำคัญกว่าจำนวนพารามิเตอร์คือ tokens per dollar/sec
  เพราะโมเดลระดับบน ๆ ไม่รองรับการทำ local inference

  • แต่ถ้าเป็นโมเดลโอเพนซอร์ส จำนวนพารามิเตอร์ก็ยังสำคัญสำหรับคนที่คิดจะ self-hosting
  • จำนวนพารามิเตอร์ยังคงเป็น ตัวชี้วัดคร่าว ๆ ของประสิทธิภาพโมเดล
    ตัวอย่างเช่น Qwen3 0.6b แม้ tok/dollar จะยอดเยี่ยม แต่ก็ยังไม่พอสำหรับการใช้งานส่วนใหญ่
  • โมเดลนี้มีความหมายตรงที่สามารถรันแบบโลคัลได้บนเครื่องราคา ต่ำกว่า $3,000

• จากการทดสอบง่าย ๆ มีข้อสังเกตอยู่บางอย่าง

  1. trace ของเอาต์พุตยืดยาวมาก และย่อหน้าก็สั้นแบบ สไตล์ LinkedIn
  2. ความเร็วในการปล่อยโทเคนของเวอร์ชันโฮสต์นั้นสูงมาก
  3. การทำตามคำสั่งและคุณภาพของเอาต์พุต ดีกว่าโมเดลหลัก ๆ อย่าง Opus 4.5

• งงเพราะ แกน x ของกราฟกลับด้าน

  • ผมก็คิดเหมือนกัน ไม่รู้ว่าทำไปทำไม
  • น่าจะตั้งใจทำให้กราฟดูดีกว่าเดิม แต่ในความเป็นจริงไม่ได้ช่วยเลย