เปิดตัว Muse Spark 1.1

• Muse Spark 1.1 ที่ Meta Superintelligence Labs เปิดตัว เป็นโมเดล reasoning แบบมัลติโมดัลที่มุ่งเป้าไปที่งานของเอเจนต์ โดยยกระดับการใช้เครื่องมือและคอมพิวเตอร์ การเขียนโค้ด และความเข้าใจมัลติโมดัลจากรุ่นก่อนหน้า
• จุดสำคัญคือรับหน้าที่ วางแผนและออร์เคสเตรต ข้ามแอปและบริการภายนอกต่าง ๆ และสามารถ generalize แบบ zero-shot ไปยัง native tools, MCP servers และ custom skills ได้
• จัดการ หน้าต่างคอนเท็กซ์ 1 ล้านโทเคน อย่างเชิงรุก เพื่อค้นคืนข้อมูลจากงานในอดีต และบีบอัดพร้อมเก็บบริบทสำคัญที่จำเป็นสำหรับขั้นตอนถัดไปไว้
• นักพัฒนาสามารถเข้าถึงโมเดลได้ผ่าน Meta Model API ที่เปิดเป็นพรีวิวสาธารณะ และใช้งานได้ในโหมด “Thinking” บนแอป Meta AI และ meta.ai
• Meta ระบุว่าได้ประเมินความปลอดภัยก่อนนำไปใช้งานตาม Advanced AI Scaling Framework และประเมินว่าอยู่ภายในช่วงเผื่อความปลอดภัยในหมวด Chemical & Biological, Cybersecurity และ Loss of Control

---

ตำแหน่งของ Muse Spark 1.1 และวิธีให้บริการ

• Muse Spark 1.1 เป็นโมเดลล่าสุดจาก Meta Superintelligence Labs และถูกนำเสนอว่าเป็นการอัปเกรดสำคัญจาก Muse Spark เดิม
• เป็น โมเดล reasoning แบบมัลติโมดัล สำหรับงานเอเจนต์ โดยเน้นการปรับปรุงในด้านต่อไปนี้
  • การใช้เครื่องมือ
  • การใช้คอมพิวเตอร์
  • การเขียนโค้ด
  • ความเข้าใจมัลติโมดัล
• การเปิดตัวครั้งนี้เชื่อมโยงกับการเปิดตัว Muse Image ในฐานะอีกก้าวที่ Meta กล่าวว่าจะเข้าใกล้วิสัยทัศน์ “personal superintelligence”
• นักพัฒนาสามารถเข้าถึง Muse Spark 1.1 ได้ผ่าน Meta Model API ที่เปิดเป็นพรีวิวสาธารณะ
• ในแอป Meta AI และ meta.ai จะให้บริการในโหมด “Thinking”

งานเอเจนต์และการประมวลผลคอนเท็กซ์ยาว

• วางแผนและออร์เคสเตรตลำดับการทำงานใน งานเอเจนต์ส่วนบุคคล ที่ครอบคลุมแอปและบริการภายนอกหลายรายการ
• generalize แบบ zero-shot ไปยัง native tools, MCP servers และ custom skills
• ถูกฝึกให้จัดการโปรเจกต์ซับซ้อนได้เร็วกว่า Muse Spark มาก
  • เอเจนต์หลักรวบรวมคอนเท็กซ์ วางแผน แล้วมอบหมายการดำเนินงานให้ subagent แบบขนาน
  • subagent ทำตามงานที่ได้รับ เข้าใจเครื่องมือที่ใช้งานได้ และ escalate กลับไปยังเอเจนต์หลักเมื่อจำเป็น
• จัดการ หน้าต่างคอนเท็กซ์ 1 ล้านโทเคน อย่างเชิงรุก
  • จดจำการกระทำที่ทำไปแล้ว
  • ค้นคืนข้อมูลจากงานที่เกิดขึ้นก่อนหน้านานมาก
  • บีบอัดเพื่อเหลือขั้นตอนสำคัญที่จำเป็นสำหรับงานถัดไป

การทำงานอัตโนมัติบนคอมพิวเตอร์

• Muse Spark 1.1 แสดงจุดแข็งใน เวิร์กโฟลว์การใช้คอมพิวเตอร์ ที่ต้องสลับไปมาระหว่างหลายแอปพลิเคชันและมีข้อมูลเปลี่ยนแปลงแบบเรียลไทม์
• รักษาคอนเท็กซ์ได้แม้ในเซสชันยาว ปรับตัวต่อข้อกำหนดที่เปลี่ยนไป และสำรวจอินเทอร์เฟซที่ไม่คุ้นเคยโดยต้องให้มนุษย์แทรกแซงน้อยที่สุด
• ไม่ได้จัดการงานเดสก์ท็อปเป็นระดับการคลิกเสมอไป แต่เลือกใช้ระบบอัตโนมัติหรือการควบคุมโดยตรงตามสถานการณ์
  • เมื่อระบบอัตโนมัติเร็วกว่า ก็เขียนสคริปต์
  • เมื่อการโต้ตอบโดยตรงทำได้ง่ายกว่า ก็ใช้การคลิก
  • สร้างการกระทำหลายอย่างรวมกันในแต่ละขั้นตอน
• ในตัวอย่างการเตรียมดินเนอร์ปาร์ตี้ เมื่อเกิดคอนเท็กซ์ใหม่ระหว่างขั้นตอนการสั่งซื้อ โมเดลรับรู้สิ่งนั้นและดำเนินการอัปเดตที่จำเป็นโดยไม่ต้องให้ผู้ใช้แทรกแซง

ประสิทธิภาพการเขียนโค้ดและเวิร์กโฟลว์การพัฒนา

• ประสิทธิภาพของ Muse Spark 1.1 ดีขึ้นอย่างมากใน งานเขียนโค้ดภาคปฏิบัติ ที่เกี่ยวข้องกับโค้ดเบสขนาดใหญ่และซับซ้อน
• สามารถวิเคราะห์และแก้บั๊กที่ซับซ้อน ติดตั้งฟีเจอร์ใหม่ในระบบระดับองค์กร และทำ code migration ขนาดใหญ่ได้
• แสดงการปรับปรุงครั้งใหญ่เมื่อเทียบกับโมเดลรุ่นแรกในกรณีใช้งานอย่างการสร้างเว็บแอปพลิเคชันและการถามตอบแบบ end-to-end
• ถูกฝึกให้ปรับตัวเข้ากับ harness ต่าง ๆ ได้อย่างราบรื่น และจัดการ พฤติกรรมแบบมัลติเทิร์น ที่ซับซ้อนได้อย่างเสถียร
  • planning mode
  • goal conditioning
  • subagent delegation
  • รองรับฟังก์ชันการเขียนโค้ดแบบเอเจนต์ทั่วไป เช่น context compaction
• ในเดโมดีบัก OpenCode โมเดลสร้างเว็บแอปแชต ค้นหาความล้มเหลวที่ผู้ใช้มองเห็นได้จากสกรีนช็อตอัตโนมัติ ไล่ตามไปยังโค้ดที่เกี่ยวข้องเพื่อแก้ไข แล้วตรวจสอบความถูกต้องของการเปลี่ยนแปลง
• นักพัฒนาและนักวิจัยภายใน Meta ใช้ Muse Spark 1.1 อยู่ทุกวัน และบน Meta Internal Coding Bench แสดงผลลัพธ์ที่ดีขึ้นมากเมื่อเทียบกับ Muse Spark รวมถึงแข่งขันได้กับทางเลือกหลัก ๆ
• นักวิจัยยังใช้ Muse Spark 1.1 ในเวิร์กโฟลว์เพื่อทำ งานพัฒนาและประเมินโมเดล ให้เป็นอัตโนมัติ
• ในตัวอย่างการประเมิน DeepSWE โมเดลประเมินงานบางส่วนของ DeepSWE ด้วยตัวเองภายใน OpenCode ในหลายระดับความเข้มข้นของ reasoning และสร้างแดชบอร์ดวิเคราะห์จากผลลัพธ์

ความเข้าใจและการดำเนินการแบบมัลติโมดัล

• Muse Spark 1.1 แสดงจุดแข็งในงานที่ผสานการรับรู้, reasoning แบบมัลติโมดัล และการใช้เครื่องมือ
• สามารถสร้างผลลัพธ์ที่มีหลักฐานรองรับขณะโต้ตอบกับสภาพแวดล้อมจริง
  • สร้างโค้ดจากสื่อภาพ
  • สร้างแคปชันที่ละเอียดมากสำหรับรูปภาพและวิดีโอ
  • ดำเนินเวิร์กโฟลว์เอเจนต์สำหรับกรณีใช้งานมัลติโมดัล
• ความสามารถมัลติโมดัลมีประโยชน์เป็นพิเศษในสถานการณ์ที่ต้องใช้ทั้งการรับรู้และการกระทำร่วมกัน
  • ตรวจสอบภาพและเสียง
  • เก็บรักษารายละเอียดไว้ตลอดเวิร์กโฟลว์ยาว
  • ใช้รายละเอียดเหล่านั้นเมื่อควบคุมคอมพิวเตอร์แทนผู้ใช้
• ในตัวอย่างเอเจนต์ Facebook Marketplace โมเดลดึงภาพถ่ายที่มีประโยชน์จากวิดีโอที่ถ่ายด้วยสมาร์ทโฟน อนุมานสินค้า แล้วควบคุมเบราว์เซอร์ของผู้ใช้เพื่อสร้างรายการขายบน Marketplace

การประเมินความปลอดภัย

• Meta ดำเนิน การประเมินความปลอดภัย อย่างกว้างขวางก่อนนำไปใช้งานตาม Advanced AI Scaling Framework
• เฟรมเวิร์กนี้กำหนดการประเมิน โมเดลภัยคุกคาม และเกณฑ์การนำไปใช้งานสำหรับโมเดลขั้นสูงที่สุดของ Meta
• หมวดการประเมินรวม frontier risk ต่อไปนี้
  • Chemical & Biological
  • Cybersecurity
  • Loss of Control
• จากการประเมินของ Meta, Muse Spark 1.1 ทำงานอยู่ภายใน ช่วงเผื่อความปลอดภัย ในทุกหมวด frontier risk
• แสดงความทนทานสูงต่อ direct jailbreak, การโจมตีทางอ้อมจากข้อมูลที่ไม่น่าเชื่อถือ, prompt injection และ developer-prompt attack
• ส่งผลให้ adversarial robustness ดีขึ้น และอัตรา hallucination กับ sycophancy ลดลง
• รายละเอียดด้านความปลอดภัยทั้งหมดถูกบันทึกไว้ใน Muse Spark 1.1 Evaluation Report

ปฏิกิริยาจากพาร์ทเนอร์ช่วงแรกและแผนถัดไป

• พรีวิวสาธารณะของ Meta Model API ทำให้นักพัฒนาเริ่มสร้างบนพื้นฐาน Muse Spark 1.1 ได้เป็นครั้งแรก
• พาร์ทเนอร์ช่วงแรกประเมินว่าเป็นโมเดลพื้นฐานที่สามารถรวมความสามารถด้านคอนเท็กซ์ยาว การเขียนโค้ด และ reasoning เพื่อรองรับเวิร์กโหลดเอเจนต์ขนาดใหญ่
• Amjad Masad ซีอีโอของ Replit เน้นว่าโมเดลเดียวนี้รวมคอนเท็กซ์ 1 ล้านโทเคน, การรองรับมัลติโมดัลสำหรับรูปภาพ·วิดีโอ·PDF, การค้นหาในตัวพร้อมการอ้างอิง, structured output, การเรียกเครื่องมือแบบขนาน และแพ็กเกจที่เข้ากันได้กับ OpenAI
• Saoud Rizwan ซีอีโอของ Cline ระบุว่าอยากให้สิทธิ์เข้าถึงก่อนแก่ผู้พัฒนา Cline เพราะโมเดลนี้มีทั้งการใช้เครื่องมือที่แข็งแกร่งและระดับราคาที่ทำให้รันเวิร์กโหลดการเขียนโค้ดจริงในสเกลใหญ่ได้
• Yashodha Bhavnani จาก Box ประเมินว่าในชุดประเมินงานองค์กรของ Box, Muse Spark แสดงความสามารถระดับองค์กรที่แข่งขันได้กับโมเดล frontier ชั้นนำในปัจจุบัน
• Dave Morin จาก OpenClaw Foundation ประเมินว่า Muse Spark 1.1 เป็นโมเดลที่รวดเร็วและทรงพลังสำหรับการดำเนินงานแบบเอเจนต์
• Meta กำลังฝึกโมเดลที่มีประสิทธิภาพสูงขึ้นและมีแผนจะแชร์ต่อไป

[GN⁺]

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

• รายงานที่ลิงก์ไว้มีรายละเอียดมากกว่านี้มาก: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
  ถ้าดูรายละเอียดของ Terminal-Bench-2.1 จะระบุว่า “ประเมินงาน Terminal-Bench 2.1 จำนวน 89 งานจากรีโพซิทอรีทางการ ด้วยเอเจนต์ฮาร์เนสที่ใช้เฉพาะเครื่องมือ bash และจำกัดทรัพยากรไว้ที่ CPU 6 คอร์กับ RAM 8GB” ซึ่งแบบนี้ผลลัพธ์ถือว่า ขาดคุณสมบัติ
  งานของเทอร์มินัลเบนช์แต่ละงานมีเพดาน CPU และเพดาน RAM แยกกัน และถ้าเกินอย่างใดอย่างหนึ่งก็ถือว่าขาดคุณสมบัติ ตามเกณฑ์ tbench-2.1 ใน 89 งาน ไม่มีงานใดเลยที่อนุญาต CPU 6 คอร์ และมีเพียง 8 งานเท่านั้นที่อนุญาต RAM 8GB
  การทำเบนช์มาร์กที่น่าสงสัยแบบนี้ ทำให้ความสนุกในการสร้างฮาร์เนสเพื่อเพิ่มประสิทธิภาพเบนช์มาร์กของโมเดลหมดไปโดยสิ้นเชิง เพราะไม่ว่าจะทำอะไรก็เอาชนะตัวเลขไม่ถูกต้องบนพาดหัวไม่ได้อยู่ดี อาจเป็นเพราะเหตุนี้โมเดลนี้ถึงไม่อยู่บนลีดเดอร์บอร์ดทางการ https://www.tbench.ai/leaderboard/terminal-bench/2.1
  ในฐานะอดีตพนักงาน Meta ก็รู้สึกขมขื่นนิดหน่อย แต่ไม่ได้แปลกใจมากนัก ก่อนที่ PSC จะจบลงและย้ายไปเรื่องถัดไป การดันตัวเลขให้สูงขึ้น คือดัชนีชี้วัดผลงานหลัก

  • ยกเว้นกรณีที่โมเดลเผลอทำให้เกิด fork bomb ผมไม่เข้าใจว่าทำไมต้องคำนึงถึง ข้อจำกัดทรัพยากร ด้วย ผมนึกว่าเบนช์มาร์กนี้ดูความสามารถในการใช้เทอร์มินัล โดยเฉพาะการเรียกเครื่องมือ bash จำนวนมากมาต่อกัน แล้วกรณีทดสอบแบบไหนที่เรื่องนี้สำคัญขึ้นมา?
  • ปัญหาของโมเดลแบบปิดก็คือนี่แหละ เราไม่รู้แน่ชัดว่าสิ่งที่เราจ่ายเงินให้คือ โมเดลฐานที่เก่งกว่า หรือฮาร์เนสที่ออกแบบมาอย่างดีเพื่อทำคะแนนเบนช์มาร์กให้สูงสุดกันแน่
  • ถามด้วยความสงสัยจริง ๆ ข้อจำกัดทรัพยากรกลายเป็นคอขวดบ่อยแค่ไหน? ฮาร์เนสช่วยอะไรตรงนี้? เช่น จำกัด parallelism หรือใช้เครื่องมือที่มีประสิทธิภาพกว่า?
  • เข้าใจประเด็นนะ แต่ก็ไม่แน่ใจว่ามันสำคัญถึงขนาดนั้นหรือเปล่า
    harbor / tb2.1 ได้จำกัด swap ที่ใช้ได้ในการรัน Docker หรือเปล่า? เมื่อก่อนเคยมีบั๊กที่การรันอินสแตนซ์ Docker ใช้หน่วยความจำได้มากกว่าสเปกที่ระบุ งานต้นฉบับบางส่วนแทบจะทำให้เสร็จไม่ได้ถ้าไม่ใช้ swap และถ้าบล็อกไม่ให้ Docker เข้าถึง swap แม้แต่ oracle solution ก็ผ่านไม่ได้
    จากที่จำได้ crack-7z-hash กับ filter-js-from-html มีปัญหานั้น แต่ไม่ได้ดูมาหลายเดือนแล้ว เลยไม่แน่ใจ
  • ดูไม่ใช่ปัญหาใหญ่ขนาดนั้น เวลาเราประเมินผลิตภัณฑ์อะไรก็ตาม เราก็ไม่ได้เชื่อคำพูดของฝ่ายที่สร้างผลิตภัณฑ์ตรง ๆ อยู่แล้ว เพราะย่อมมีอคติเป็นธรรมดา นั่นจึงเป็นเหตุผลที่มี การทดสอบอิสระ อย่าง https://artificialanalysis.ai อยู่

• ผมได้ลองใช้ล่วงหน้ามาสองสามวัน และในช่วงนั้นก็ทำปลั๊กอินสำหรับ LLM ได้ สามารถลองโมเดลนี้ในเทอร์มินัลได้แบบนี้
  uv tool install llm
llm install llm-meta-ai
llm keys set meta-ai
# paste API key here
llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
  ผลลัพธ์อยู่ที่นี่: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
  ส่วนภาพนกเพลิแกนจาก Muse Spark 1 สำหรับเทียบอยู่ที่นี่: https://simonwillison.net/2026/Apr/8/muse-spark/

  • สงสัยว่าคุณหาเวลามา พรีวิว โมเดลเยอะขนาดนี้ได้ยังไง ช่วงนี้การเปิดตัวโมเดลถี่จนเวียนหัวจริง ๆ บางครั้งมันรู้สึกเหมือนเป็นงานบ้างไหม?

• Zuck อาจจะเหมาะกับการมุ่งเป็น ตัวป่วนตลาด ของตลาดโมเดล มากกว่าการแข่งขันตรง ๆ
  ไม่จำเป็นต้องไล่ให้ทันรายได้จากโมเดลของ Anthropic หรือ OpenAI แค่ทำให้รายได้นั้นลดลง 99% ได้ก็พอ ลงเงินหลายพันล้านดอลลาร์ต่อไปกับการพัฒนา frontier model แล้วปล่อยแบบ open weights เพื่อทำให้โมเดลเขียนโค้ดกลายเป็นสินค้าโภคภัณฑ์ทั่วไป พร้อมกับต้องมีฮาร์เนสเกณฑ์อ้างอิงโอเพนซอร์สที่ทำมาดีด้วย
  มีคนไม่กี่คนที่อยู่ในจุดที่ทำเรื่องนี้ได้และสมเหตุสมผลทางธุรกิจอยู่แล้ว ยังไงกระแสก็น่าจะไปทางนั้น และเขาสามารถเร่งความเร็วมันได้มาก เราควรหวังว่าโมเดลจะย้ายจากผลิตภัณฑ์ผูกขาดไปเป็นสินค้าโภคภัณฑ์ทั่วไป เหมือนที่คอมไพเลอร์เคยเป็น
  นี่อาจเป็นหนึ่งในสิ่งที่ดีที่สุดที่ Zuck ทำให้โลกได้

  • ถ้าพวกเขาสูญเสียรายได้ แล้วใครจะมาเช่าทรัพยากรคำนวณของ Meta ใช้?
  • ถ้าจะเป็น ราชาตัวป่วน ตัวจริง ก็เปิดซอร์สชุดข้อมูลฝึกสอนออกมาเลย แต่สงสัยว่าจะไปไกลถึงขั้นนั้นไหม
  • โมเดลเขียนโค้ดไม่ใช่จุดหมายปลายทาง โมเดลเขียนโค้ดเป็นเพียงส่วนหนึ่งของกระบวนการ bootstrapping ไปสู่ ปัญญาทั่วไป เท่านั้น
  • ไม่ใช่ว่าเขาเคยลองทำแบบนั้นไปแล้วกับ llama เหรอ?
  • สิ่งที่เขาต้องทำมีแค่พิสูจน์ว่าการสร้างโมเดลแบบนี้ไม่ได้ยากขนาดนั้นอีกต่อไป เพราะคูเมืองของบริษัทเหล่านี้คือ การรับรู้ ว่าการสร้าง frontier model นั้นยากมากจริง ๆ

• ราคาดีจนน่าเหลือเชื่อ อินพุต $1.25 ต่อ 1 ล้านโทเคน, เอาต์พุต $4.5 และ อินพุตที่แคชไว้ อยู่ที่ $0.15
  https://dev.meta.ai/docs/getting-started/pricing-rate-limits

  • อันนี้เทียบกับ xAI Grok 4.5 ได้ตรงที่สุด ทั้งคู่มีทิศทางใกล้เคียงกับ “สติปัญญาระดับ Opus ในราคา Haiku” และสำหรับนักพัฒนาแอปที่อยากใส่โมเดลแบบนี้ลงในแอป ถือเป็นเรื่องใหญ่มาก
    ผมกำลังทดสอบเปลี่ยน Haiku กับ Sonnet ไปใช้ Grok 4.5 อยู่ และคิดว่าจะลองใช้อันนี้ด้วย โดยเฉพาะราคาแคชถูกกว่ามาก
  • สัดส่วนราคาของอินพุตที่แคชไว้ดี
    Grok 4.5 ออกมาที่ $2/$6 แต่แอบคิดค่าอินพุตที่แคชไว้ $0.50 ต่อ 1 ล้านโทเคน ซึ่งแพงระดับเดียวกับ Opus 4.8 เลย
  • ตอนนี้ Meta ไม่ได้อยู่ในเรดาร์ของคนส่วนใหญ่ที่กำลังเลือกโมเดล ถ้ามีโมเดลที่ดีจริง การอุดหนุนราคาเพื่อดึงผู้ใช้ก่อนจะปรับให้เข้ากับราคาคู่แข่งก็สมเหตุสมผล
  • ถูกกว่า Qwen 3.7 Max หลังจาก Grok 4.5 ที่ราคาอินพุต $2 / เอาต์พุต $6 นี่เป็นสัญญาณที่สองว่าแล็บใหญ่ ๆ กำลังรู้สึกถึง แรงกดดันจาก GLM 5.2
  • ถึงอย่างนั้นก็ยังแพงแบบไร้สาระอยู่ดี ลองคิดว่าต้องจ่าย $10 เพื่อผลลัพธ์ Google Search 100 รายการ จริง ๆ แล้วนี่ก็ประมาณนั้น
    ผมไม่เข้าใจจริง ๆ ว่าทำไมถึงมีคนอยากจ่ายเกิน $1.50 ต่อเอาต์พุต 1 ล้านโทเคน นับประสาอะไรกับ $15~50 มีกรณีไหนที่ผู้บริโภคจ่ายตามการใช้งานจริงบ้างไหม?

• จนถึงเมื่อวานนี้เอง บรรยากาศเหมือน OpenAI กับ Anthropic นำหน้าไปไกลจนตามไม่ทันแล้ว แต่ตอนนี้ xAI กับ Meta ก็ออกของที่อย่างน้อยแข่งได้ในฐานะโมเดลใช้งานจริง แถมราคาถูกด้วย
  แน่นอนว่าถ้าดู Fable และอาจรวมถึง GPT-6 ที่น่าจะออกมาเร็ว ๆ นี้ เรื่องที่แล็บสองผู้นำยังนำหน้าอยู่ก็ยังคงจริง แต่เกมนี้ไม่ได้จบสนิทอย่างที่กลุ่มผู้นำความเห็นพูดกัน

  • ตอนนี้โดยรวมโมเดลดีพอแล้ว ถ้าไม่มี breakthrough ใหญ่ ๆ จากนี้สิ่งสำคัญก็เหลือแค่ ต้นทุน เท่านั้น
  • คนตีความการที่ Google ตามหลังผิดไปว่า Anthropic กับ OpenAI นำหน้าไปไกลมาก ทั้งที่จริง ๆ แล้วมันใกล้กับการที่ Google ตามหลังแบบตอน Tensorflow, Angular, GCP มากกว่า
  • นัยยะตรงนี้ต่างกันนิดหน่อย
    ความคาดหวังต่อ GLM 5.2 สูงมากอยู่แล้วก่อนหน้านี้ xAI หรือ Meta ไม่ได้สร้างความแตกต่างใหญ่ในอีกแบบหนึ่ง แต่ใกล้เคียงกับผลลัพธ์และราคาที่คล้าย GLM 5.2

• ส่วนตัวไม่ได้ชอบ Meta แต่เรื่องนี้ต้องยอมรับ ยิ่งมีการแข่งขันมากก็ยิ่งดีต่อผู้บริโภคทั่วไป และดีกับบริษัทด้วย
  การที่โมเดลจีน, Grok, Meta, Google, OpenAI, Anthropic แข่งกันทั้งหมดถือเป็นชัยชนะ ผมกำลังสร้างของอย่างบ้าคลั่งเพื่อใช้โทเคนที่มีการอุดหนุนพวกนี้ให้คุ้มที่สุดในช่วงที่ยังใช้ได้

  • โมเดล llama แบบโลคัลของ Meta เคยเป็นหน้าตาของ โอเพนซอร์ส AI อยู่ช่วงหนึ่ง เกมเปลี่ยนไปเยอะจริง ๆ
  • เห็นชัดว่าเป็นเรื่องดี แต่ในใจก็ยังถกเถียงอยู่เหมือนกันว่าความก้าวหน้าแบบนี้จะทำให้จำนวนซอฟต์แวร์เอนจิเนียร์ที่จำเป็นในยุค AI เพิ่มขึ้นหรือลดลง
    ด้านหนึ่ง การสร้างผลิตภัณฑ์ง่ายขึ้น คนก็จะสร้างมากขึ้น และจะมีผลิตภัณฑ์กับฟีเจอร์มากขึ้น คนที่ไม่ใช่สายเทคนิคก็จะพยายามสร้างกันเยอะ แต่ก็จะติดขัด และสุดท้ายก็ยังต้องการเอนจิเนียร์ ปริมาณผลิตภัณฑ์รวมที่บริษัทเทคที่มีทักษะ ผู้ก่อตั้งที่ไม่ใช่สายเทคนิค และว่าที่ผู้ก่อตั้งจะสร้างออกมาน่าจะมหาศาล สถานการณ์ขาขึ้น ที่ต้องการซอฟต์แวร์เอนจิเนียร์มากขึ้นในอนาคตอันใกล้ก็อยู่ตรงนี้
    ในทางกลับกัน อีกประมาณ 1 ปี ผู้คนจะสร้างผลิตภัณฑ์แบบนี้ออกมาเต็มไปหมด แต่ส่วนใหญ่จะทำการตลาด ขาย หรือทำเงินไม่ได้ สุดท้ายอาจไม่จำเป็นต้องมีซอฟต์แวร์เอนจิเนียร์มากขนาดนั้นก็ได้ ถึงอย่างนั้นโดยรวมแล้วผมมองว่าสถานการณ์ขาขึ้นน่าจะชนะในเชิงผลสุทธิ
  • ถ้าขยายความโมเดลจีนให้ชัดขึ้นก็มี DeepSeek, GLM(Z.ai), Minimax, Kimi(Moonshot), Hy3(Tencent), Qwen(Alibaba)
    แต่ละตัวสามารถดาวน์โหลดเวตมา รันแบบโลคัล ได้
  • เขาโพสต์ข่าวนี้ลง X ไม่ใช่ Meta Threads ของตัวเอง แสดงให้เห็นว่ามีความสนใจจะปั้นเรื่องนี้ให้ใหญ่แค่ไหน แน่นอนว่าในมุมของเรา ตราบใดที่บริษัทเหล่านี้ยังเผาเงินกันต่อ ค่าใช้จ่ายก็อาจยังอยู่ในระดับที่รับไหว
  • นี่คือ การแข่งขันทางเทคโนโลยี ที่ใหญ่ที่สุดเท่าที่เคยเห็นมา บริษัทที่ร่ำรวยที่สุด คนที่ฉลาดที่สุด และประเทศที่ร่ำรวยที่สุดต่างกระโดดเข้ามา
    ไม่รู้ว่าการแข่งขันเป็นเรื่องดีไหม อีกไม่กี่ปีก็คงได้เห็นกัน ผมกำลังตั้งตารอวันที่จะได้มีงานใช้แรงกายอีกครั้งหลังจากห่างหายไปนาน

• ทำไมทุกบริษัทถึงทำให้ตัวเองดูเหมือนอันดับ 1 ในทุก benchmark ได้กันนะ?

  • ก่อนอื่นดูว่าในชุด benchmark ที่เลือกเอง มีโมเดลไหนบ้างที่แย่กว่า
    จากนั้นก็เทียบกับ เวอร์ชันก่อนหน้า ของโมเดลคู่แข่ง ถ้ายังดูไม่ดี ก็เทียบกับโมเดลรุ่นก่อนหน้าของตัวเอง
  • เพราะ moat ไม่ได้ใหญ่ การปรับปรุงเป็นแบบค่อยเป็นค่อยไป และมีการเลือกโมเดลที่จะเอามาเปรียบเทียบเอง
    พูดอย่างเป็นธรรม ถ้าจุดแข็งหลักคือราคา การเทียบกับโมเดลที่ประสิทธิภาพใกล้เคียงกันก็ดูถูกต้องกว่า
  • ตอนนี้การเทียบกับ Gemini ให้ความรู้สึกเหมือน ช่องฟรีในบิงโก
  • ถ้าถามคนที่รู้ลึกด้าน AI มาตรฐานแล้ว benchmark มาตรฐาน สำหรับงานโค้ดควรมองว่าอะไร?
  • แค่รอจังหวะที่โมเดลของตัวเองนำหน้าใน benchmark อย่างน้อย N รายการพอดีแล้วค่อยประกาศก็ได้

• พลาดไปว่า Meta กำลังพัฒนาและปล่อย โมเดลแบบเวตปิด อยู่ น่าเสียดาย อยากเห็นความคืบหน้าในโมเดลโอเพนเวตจากสหรัฐฯ มากกว่านี้

• ทำให้มันทำงานร่วมกับ codex ในคอนเทนเนอร์ได้แล้ว อ้างอิงไว้ก่อน ดูเหมือนจะมีบั๊กที่คนส่วนใหญ่จะเจอในอินเทอร์เฟซ Codex:Muse
  เท่าที่ผมมอง codex ไม่ได้คาดว่าจะมี server-side tool calls และวิธีที่ Meta จัดการ ID เหล่านั้นทำให้เกิดข้อผิดพลาดบางอย่างด้าน parsing หรือ integration ตอนรัน codex กับ muse สองสามครั้งแรก มันล้มเหลวที่การเรียกครั้งแรกที่ไม่ใช่เว็บเสิร์ช
  แก้ไขแล้ว และส่วนตัวผมยังไม่ถูกโน้มน้าวเต็มที่กับ server-side tool calls แบบกำหนดเองและการเก็บไฟล์แบบไม่มีกำหนด แต่จนถึงตอนนี้เป็นโมเดลที่ค่อนข้างเจ๋งและใช้งานสนุก
  https://github.com/accretional/awesome-muse-spark/blob/main/...

• เมื่อดู benchmark ที่เผยแพร่แล้ว การเขียนโค้ดและ multimodal ก็ดูค่อนข้างดี แต่เหมือนว่า อัตราความสำเร็จในการเรียกใช้เครื่องมือ จะดีมาก
  use case ที่เหมาะกับรูปแบบประสิทธิภาพแบบนี้ที่สุดคืออะไร?

  • การดีบักและการวินิจฉัยต้องเรียกใช้เครื่องมือจำนวนมากมาก ทั้งการ grep หรือแปลง log, เรียก profiler หรือ tracer ไปจนถึงการเขียนรายงาน incident
    การวินิจฉัย bug เป็นงานที่ต้องเขียนโค้ดได้ระดับหนึ่ง แต่ยิ่งต้องใช้ เครื่องมือ ให้เก่งกว่า ถ้ามีรายงานวินิจฉัยที่ดีแล้ว ก็ส่งงานแก้ไขต่อให้ Opus ได้
    Opus เองก็เขียนรายงานได้พอสมควร แต่ในเอกสาร typst ยังมักทำความกว้างของตารางผิดอยู่บ่อย ๆ จนเกิดกรณีที่คอลัมน์สุดท้ายมีข้อความอัดแน่น แต่ความกว้างมีแค่ไม่กี่ตัวอักษร
  • Gemini 3.5 Flash ดีกว่า Fable ในการเรียกใช้เครื่องมือ การเรียกใช้เครื่องมือน่าจะเป็นหนึ่งในด้านที่ปรับปรุงได้ค่อนข้างง่ายด้วย post-training
  • สงสัยว่าใน release ใหม่ ๆ ต่อจากนี้เราจะเห็น pattern แบบนี้หรือไม่ การใช้เครื่องมือมีแนวโน้มเปลี่ยนเร็วมาก จน โมเดลที่ใหม่ที่สุด อาจได้เปรียบเหนือโมเดลที่ฉลาดที่สุดอยู่เสมอ
  • อันนี้ฟังดูไม่ค่อยมีประโยชน์นัก น่าสนใจที่ประสิทธิภาพของ constrained decoder แบบ JSON นั้นยอดเยี่ยม แต่ใน decoder ทั่วไป loop ที่ส่งผ่านตัวตรวจสอบเครื่องมือ รับข้อความ error ที่ดี แล้วลองใหม่ แทบจะทำให้เครื่องมือทำงานได้ในการลองครั้งที่สองเสมอ input ถูก cache ไว้แล้ว ค่าใช้จ่ายจึงไม่แพงด้วย