Needle - โมเดล 26 ล้านพารามิเตอร์ที่กลั่นจาก Gemini Tool Calling

• โมเดลโอเพนซอร์สสำหรับการใช้เครื่องมือ (tool use) ขนาด 26 ล้านพารามิเตอร์ ออกแบบมาให้ทำงานบนอุปกรณ์ผู้บริโภคขนาดเล็ก เช่น สมาร์ทโฟน สมาร์ทวอตช์ และแว่นตา
• เริ่มจากข้อสังเกตว่าการเรียกใช้เครื่องมือไม่ใช่การให้เหตุผล แต่เป็นการ ค้นหาและประกอบ (คิวรี→จับคู่ชื่อเครื่องมือ→ดึงอาร์กิวเมนต์→ส่งออก JSON) จึงไม่จำเป็นต้องใช้โมเดลขนาดใหญ่
• ใช้สถาปัตยกรรม Simple Attention Network ทำให้ทั้งโมเดลประกอบด้วย attention และ gating เท่านั้น โดยไม่มี MLP เลย
  • Encoder 12 ชั้น + Decoder 8 ชั้น เชื่อมต่อกันด้วย cross-attention
  • d=512, 8H/4KV, BPE=8192
• สร้างขึ้นด้วยการ กลั่น (distill) จาก Gemini 3.1 โดยพรีเทรน 200B โทเค็นบน TPU v6e จำนวน 16 ตัว (27 ชั่วโมง) และฝึกต่อด้วยข้อมูล function calling 2B โทเค็น (45 นาที)
• ในโปรดักชัน ทำความเร็วบน Cactus inference engine ได้ที่ prefill 6,000 tok/s, decode 1,200 tok/s
• ในเบนช์มาร์กการเรียกใช้ฟังก์ชันแบบ single-call ทำได้ดีกว่า FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M
  • อย่างไรก็ตาม ในสภาพแวดล้อมแบบสนทนา โมเดลเหล่านั้นยังมีความอเนกประสงค์โดยรวมกว้างกว่า
• แม้ไม่มี FFN ก็ยังสามารถทำให้ทั่วไปกับทุกงานที่เข้าถึงความรู้เชิงโครงสร้างจากภายนอกได้ (RAG, การใช้เครื่องมือ เป็นต้น)
  • หากข้อมูลข้อเท็จจริงถูกป้อนมาในอินพุต ก็ไม่จำเป็นต้องจดจำไว้ในน้ำหนัก FFN
• ใช้คำสั่ง needle playground เพื่อทดสอบเครื่องมือของตนเองผ่าน เว็บ UI และทำ fine-tuning แบบคลิกเดียวได้ พร้อมรองรับการทำ local fine-tuning บน Mac/PC
• ชุดข้อมูลการฝึกถูกสังเคราะห์ด้วย Gemini และมี 15 หมวดหมู่เครื่องมือ เช่น ตัวจับเวลา ระบบส่งข้อความ ระบบนำทาง และสมาร์ตโฮม
• ไลเซนส์ MIT พัฒนาด้วย Python และเปิดเผยทั้งเวตและกระบวนการสร้างชุดข้อมูลบน Hugging Face แบบครบถ้วน

[wedding]

ภาษาเกาหลีจะใช้ได้ดีไหม..?

[GN⁺]

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

• สงสัยว่ามีตัวอย่างหรือข้อมูลเกี่ยวกับความสามารถในการแยกแยะของโมเดลที่ใช้เครื่องมือไหม
  ตัวอย่างเช่น “อากาศที่ซานฟรานซิสโกเป็นยังไง” และเครื่องมือที่ส่งให้ก็ประมาณ tools='[{"name":"get_weather","parameters":{"location":"string"}}]'
  เมื่อกว่า 10 ปีก่อนเคยสร้างสิ่ง[1]ที่จัดการปัญหาแบบนี้ด้วย SPARQL และ knowledge graph
  สิ่งที่อยากรู้จริง ๆ คือมันจัดการกับความกำกวมได้ดีแค่ไหน
  ถ้าส่งข้อความอย่าง “พรุ่งนี้ 10 โมงมาเจอกันดื่มกาแฟนะ” และคำสั่งอย่าง “บันทึกอันนี้ไว้” มันจะเลือกการทำงาน “เพิ่มกำหนดการ” ได้หรือไม่ จากบรรดาเครื่องมือที่เป็นไปได้หลายสิบตัว แม้จะไม่ถึงหลายร้อยก็ตาม
  [1] https://github.com/nlothian/Acuitra/wiki/About

  • ลองทดสอบกับ Hugging Face ที่ลิงก์ไว้ด้านล่างแล้ว แต่ไม่ค่อยน่าประทับใจ
    พรอมป์ต์คือ “ต้องติดต่อหัวหน้าว่าจะไปสาย” และผลลัพธ์คือ 20mins [{"name":"set_timer","arguments":{"time_human":"20 minutes"}}]
    มันไม่ได้ใช้เครื่องมืออีเมล และลองถามอีก 2–3 แบบก็ได้ผลคล้ายกัน

• สงสัยว่าไม่กังวลกับการตอบโต้ของ Google หรือ
  มีรายงานว่า Google ตอบโต้ความพยายามในการกลั่นโมเดลด้วย “การป้องกันเชิงรุกแบบเรียลไทม์ที่อาจลดประสิทธิภาพของ student model”
  ถ้าตรวจจับได้ ก็อาจจงใจป้อน Gemini เวอร์ชันที่ดูน่าเชื่อถือแต่โง่ลงให้: https://cloud.google.com/blog/topics/threat-intelligence/dis...
  แต่โมเดลนี้เล็กและโฟกัสแค่การใช้เครื่องมือ จึงอาจยังห่างไกลมากในแง่การใช้โทเคน เมื่อเทียบกับคนที่พยายามกลั่นทั้งโมเดล

  • จะกลั่นจากโมเดล Gemmaที่รันในเครื่องก็ได้ และโมเดลอื่นที่ใช้เครื่องมือได้ก็เช่นกัน
  • ในมุมของข้อมูลฝึก มันก็ให้ความรู้สึกเหมือนขโมยจากโจรเหมือนกัน

• อาจเป็นไปได้ที่จะสร้างอะไรอย่างโปรแกรมบรรทัดคำสั่งที่ให้ระบุอาร์กิวเมนต์แบบเลือกได้ด้วยภาษาธรรมชาติ
  แน่นอนว่าจะมีหลายคนที่คัดค้านการเพิ่มขนาด 14MB และการคำนวณเข้าไปเพื่อ “พาร์ส” และถ้าทุกคนเริ่มทำแบบนี้กันหมดก็คงไม่ค่อยดีนัก
  แต่ถึงอย่างนั้น การที่ตอนนี้มันทำได้แล้วก็น่าสนใจมาก
  สามารถใส่โมเดลที่ fine-tune ให้เข้าใจวิธีใช้โปรแกรมไว้ด้วยกันได้
  เช่น > toolcli what can you do ก็ไปรัน toolcli --help summary และ toolcli add tom to teamfutz group ก็กลายเป็น toolcli --gadd teamfutz tom

  • Needle ถูกฝึกมาสำหรับINT4 และสิ่งที่เห็นใน playground ก็เป็น INT4 เช่นกัน เลยมีขนาดแค่ 14MB
    แต่โจทย์แบบเดียวกันก็ยังคงอยู่

• น่าจะดีถ้าเปิดเดโมสดของ “needle playground”
  ด้วยขนาดที่เล็ก ค่าใช้จ่ายในการรันบน VPS เล็ก ๆ ที่ไหนสักแห่งก็น่าจะค่อนข้างถูก

  • ดูเหมือนจะทำผ่าน WebGPU ได้เร็วและง่ายด้วย
  • ปัญหาคือการรองรับสเกลเท่านั้น และโครงสร้างพื้นฐานแบบพร้อมใช้ยังไม่พร้อม
    ถึงอย่างนั้นใคร ๆ ก็ทำได้ และก็รันบนโน้ตบุ๊กได้ง่ายมากเช่นกัน
    จะลองแนวทาง VPS ดูด้วย
  • จะลองเอาไปลงบน chonklm.com

• ข้อสังเกตที่ว่า “งานค้นหาไม่ต้องใช้ FFN” น่าสนใจ
  ถ้าความรู้อยู่ในบริบท ก็แทบจะเป็นการบอกว่าสำหรับงานนั้นน้ำหนัก FFNเป็นส่วนเกิน
  สงสัยว่ามันจะทั่วไปไปถึงการเรียกใช้เครื่องมือหลายเทิร์นที่ต้องติดตามสถานะข้ามหลายครั้งได้หรือไม่ หรือจะพังตรงนั้น
  การเรียกครั้งเดียวเป็นกรณีที่ง่าย

• น่าสนใจ และสอดคล้องกับสิ่งที่เคยสังเกตตอนใช้ Claude Code ในช่วงแรก
  Sonnet มักเรียกเครื่องมือเร็วเพื่อรวบรวมบริบทเพิ่ม ส่วน Opus มักใช้เวลาคิดนานกว่าเพื่อแก้ปัญหาจากบริบทที่มีอยู่
  เรื่องนี้ทำให้เกิดฟังก์ชันซ้ำมากมายและทำให้การพัฒนาช้าลง แต่ในโมเดลใหม่อย่าง GPT-5.5 และ Opus 4.6 ปัญหานี้ดูเหมือนจะลดลง
  ข้อสรุปของฉันคือโมเดลที่ “โง่กว่า” หรือก็คือเล็กกว่า อาจดีกว่าสำหรับการเป็นเปลือกสำหรับรันเอเจนต์ และอย่างน้อยในหลายปัญหาก็อาจใช้งานได้จริงกว่าในด้านต้นทุนและความเร็ว
  ไม่ได้รู้สึกว่า Gemini เก่งเป็นพิเศษกับช่วงการเรียกเครื่องมือที่ยาว
  ถ้ากลั่นจากร่องรอยที่มีสายการเรียกเครื่องมือยาวระหว่างคำถามของผู้ใช้ แบบเซสชัน Codex หรือ Claude Code จริง ๆ ก็น่าจะน่าสนใจ
  ส่วนตัวอยากได้โมเดลที่ใหญ่ขึ้นอีกนิด แต่ยังรันได้ง่ายบนเครื่องอย่าง 32GB M2 MacBook Pro และมีreinforcement learning สำหรับการเรียกใช้เครื่องมือเป็นเป้าหมายหลัก
  โมเดลน้ำหนักเปิดอย่าง Kimi หรือ Qwen กำลังเข้าใกล้จุดนั้น แต่ดูเหมือนการควอนไทซ์ที่ต้องใช้เพื่อให้พอดีกับอุปกรณ์เล็กจะทำให้ประสิทธิภาพตกลงมาก

  • ประเด็นสำคัญคืออย่าเอา LLM ไปรันเป็นลูปวนซ้ำ
    กระแส agent framework ทุกวันนี้ดูงี่เง่า และฉันคิดว่าส่วนใหญ่มีไว้เพื่อเพิ่มรายได้ให้บริษัท LLM
    โดยทั่วไป LLM มีประโยชน์จำกัด แต่ถ้าจับคู่กับการใช้เครื่องมือเพียงครั้งเดียว จะมีประโยชน์และเชื่อถือได้มากขึ้นมาก
    ฉันทำชุดเครื่องมือเฉพาะงานมาก ๆ ของตัวเองบน openrouter API
    กดปุ่มแล้วให้ LLM ทำงานที่มีประโยชน์หนึ่งอย่าง ไม่ใช่กดปุ่มแล้วหวังให้ LLM วนลูปเรียกเครื่องมือ 5 นาทีและจัดลำดับให้ถูกต้อง
    ถ้าต้องเรียกหลายเครื่องมือ ก็เชื่อมมันแบบกำหนดแน่นอนในโค้ด
    เพราะสามารถตรวจผลลัพธ์จาก A ก่อนแล้วค่อยไป B หรือ C ได้ จึงเชื่อถือได้กว่ามาก และยังประหยัดเวลาและโทเคนกว่า
    ฉันมองว่า agent loop แทบจะเป็นการหลอกลวงขนาดใหญ่
  • อยากให้บริษัท AI ยักษ์ใหญ่เลิกเสียเวลาไปกับการอุดช่องโหว่ของ “เครื่องมือ” ของตัวเองที่ปล่อยค้างไว้แบบนั้น
    ไม่เข้าใจว่าทำไมเราต้องพยายามทุกวิถีทางเพื่อ “ทำให้มันพอใช้ได้”
    Google, MS, Meta, OpenAI ฯลฯ ตอนนี้พยายามเรียกเครื่องมือของตัวเองแบบอ้อม ๆ ว่า “Intelligence” ทั้งที่ไม่ใช่แม้แต่ “Artificial Intelligence” ด้วยซ้ำ ถ้าอย่างนั้นทำไมมันถึงไม่ฉลาดและทำไมมันถึงใช้การไม่ได้
    มีเงินลงทุนเกิน 1 ล้านล้านดอลลาร์แล้ว แต่เรายังต้องมาคิดคาถาและการตั้งค่าที่ดีที่สุดเพื่อให้เครื่องผลิตขยะสร้างผลลัพธ์ที่พอใช้ได้อยู่เลยหรือ
    ทั้งที่ผู้นำเทคโนโลยีบางคนยังขู่กันอย่างเปิดเผยว่าจะทำให้เราสยบอยู่ใต้ภาพฝัน “อารยธรรม” ประหลาด ๆ ของพวกเขา
    ฉันคิดว่าเราควรเอาสมองที่ดีกว่าของเราไปใช้กับอย่างอื่น และไม่ลดตัวเองลงไปเป็นผู้ช่วยไร้พลังของคำพยากรณ์วิเศษ

• ผลทดลอง Cactus ที่ว่า “ตราบใดที่โมเดลยังพึ่งพาแหล่งความรู้ภายนอก ก็สามารถตัด MLP ออกจากเครือข่ายทรานส์ฟอร์เมอร์ได้ทั้งหมด” น่าสนใจ
  บังเอิญว่าวันนี้นักศึกษาของฉันคนหนึ่งก็เพิ่งนำเสนอผลวิจัยที่ยืนยันเรื่องนี้
  เมื่อตัดMLPออกจาก Qwen โมเดลยังคงทำงานแปลงข้อมูลตามอินพุตได้ แต่สูญเสียความรู้ไป

• ความต่างระหว่าง M กับ B มันละเอียดเกินไป
  ขอเสนอให้เขียนเป็น 0.026B แทน

  • การเขียนแบบ “M” มีใช้มาตั้งแต่ยุค BERT และ T5/FLAN เป็นอย่างน้อย
    ถึงตอนนี้นักพัฒนา LLM จะคุ้นกับโมเดลระดับพันล้านพารามิเตอร์มากกว่า แต่วิธีเขียนนี้ก็ยังใช้ได้อยู่
  • หลายคอมเมนต์ในโพสต์นี้ทำให้สับสนมาก ขอบคุณที่ทำให้รู้ว่าบางคนอ่านเป็น 26B เลยทำให้คอมเมนต์ดูไม่สมเหตุสมผล

• น่าตื่นเต้นมาก งานยอดเยี่ยม
  โมเดล edge ของ Gemma4 ถูกวางตัวว่าจะเหมาะกับการใช้งานแบบเอเจนต์ แต่ในการทดสอบทุกอย่างที่ฉันลองกลับน่าผิดหวังมาก
  มันล้มเหลวแม้แต่ในสถานการณ์การใช้เครื่องมือพื้นฐานที่สุด
  สงสัยว่าได้รันเบนช์มาร์กการใช้เครื่องมือกับ Needle แล้วหรือยัง หรือมีแผนจะทำไหม
  ถ้ามี อยากให้เพิ่มผลลัพธ์ไว้ในรีโพซิทอรี

• เพิ่งลองตั้งนาฬิกาปลุกกับเพิ่มรายการซื้อของไป มันทำได้ดีกว่า Siri