เปิดตัว Laguna S 2.1

 (poolside.ai)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Poolside เปิดตัว Laguna S 2.1 ที่เสริมความสามารถด้านงานระยะยาวและการให้เหตุผล ใช้งานพารามิเตอร์ 8B ต่อโทเค็นจาก MoE รวม 118B และรองรับ คอนเท็กซ์สูงสุด 1M โทเค็น ทั้งโหมด thinking และ no-thinking
  • ใช้เวลา น้อยกว่า 9 สัปดาห์ ตั้งแต่เริ่มเทรนจนถึงเปิดตัว ทำคะแนน 70.2% บน Terminal-Bench 2.1, 78.5% บน SWE-Bench Multilingual และ 40.4% บน DeepSWE v1.1 แข่งขันกับโมเดลที่ใหญ่กว่าได้
  • แกนหลักของการเพิ่มประสิทธิภาพอยู่ที่ ความต่อเนื่อง·การตรวจสอบ·การถอยกลับแล้วลองใหม่ มากกว่าการขยายโมเดลอย่างเดียว ใช้ rollout ที่ยาวขึ้น sandbox ที่ปรับปรุงแล้ว และ agent harness หลายแบบ เพื่อลดการประกาศว่างานเสร็จเร็วเกินไปและการ overfit กับ harness เดียว
  • ในงานจริง สร้าง HTML/CSS rendering engine ได้ใน 181 ขั้นตอน, เพิ่มความเร็ว harness ของตัวเอง 5.2% พร้อมลด memory allocation ราว 70%, และค้นพบชุดคำตอบอนันต์ของ Erdős problem #397 ขึ้นมาใหม่อย่างอิสระ
  • เปิดเผย trajectory การรันทั้งหมดของโมเดลและการประเมินขั้นสุดท้าย แต่ยังมีข้อจำกัดด้าน tool spec ของ harness จากภายนอก, JSON ของการเรียกเครื่องมือซ้อนกัน และการให้เหตุผลที่ยาวเกินไป สามารถใช้ weights และ คอนเท็กซ์สูงสุด 1M ได้บน Hugging Face รวมถึง inference framework และ hosting service หลัก ๆ

โครงสร้างโมเดลและความเร็วในการเปิดตัว

  • Laguna S 2.1 เป็นโมเดล Mixture-of-Experts ที่มีพารามิเตอร์รวม 118B และพารามิเตอร์ที่ใช้งาน 8B ต่อโทเค็น
    • รองรับ คอนเท็กซ์สูงสุด 1M โทเค็น ทั้งโหมด thinking และ no-thinking
    • ใช้เวลาน้อยกว่า 9 สัปดาห์ตั้งแต่เริ่มเทรนจนถึงเปิดตัว
  • เริ่ม pretraining บน NVIDIA H200 GPU จำนวน 4,096 ตัว เมื่อวันที่ 22 พฤษภาคม 2026 และเปิดตัวหลังจากนั้น 60 วัน
  • ด้วยขนาด active ที่เล็ก จึงทำงานซับซ้อนบนระบบ local ได้ และรันได้แม้บน NVIDIA DGX Spark เครื่องเดียว

ประสิทธิภาพบน benchmark งานโค้ดระยะยาว

  • ผลลัพธ์หลัก ณ วันที่ 21 กรกฎาคม 2026 มีดังนี้
    • Terminal-Bench 2.1: 70.2%
    • SWE-Bench Multilingual: 78.5%
    • SWE-Bench Pro public dataset: 59.4%
    • DeepSWE v1.1: 40.4%
    • SWE Atlas(Codebase QnA): 46.2%
    • Toolathlon Verified: 49.7%
  • Terminal-Bench 2.1 ประเมินงานระยะยาวหลากหลายที่ agent โต้ตอบกับสภาพแวดล้อมผ่าน terminal โดย Laguna S 2.1 ทำได้ 70.2% บน pool harness ที่เปิด thinking
  • benchmark ที่เติบโตเต็มที่แล้วมักมีคะแนนระดับบนสุดกระจุกอยู่ที่ 70~90% ทำให้โมเดลที่มีพฤติกรรมต่างกันมากอาจต่างกันเพียงไม่กี่คะแนน
  • DeepSWE มีงานที่ยาวกว่าและแก้ได้บางส่วนยาก ทำให้คะแนนกระจายกว้าง
    • ใน v1.1 โมเดล frontier ทำได้ 54~73% ส่วนโมเดลเปิดบางตัวที่มีขนาด 1T ขึ้นไปทำได้ต่ำกว่า 10%
    • Laguna S 2.1 ทำได้ 40.4% บน pool harness ของตัวเอง
    • เนื่องจากใช้ harness ของตัวเอง ไม่ใช่ mini-swe-agent ใน leaderboard อย่างเป็นทางการ จึงไม่ใช่การเทียบเท่ากับคะแนนโมเดลอื่นแบบสมบูรณ์
    • สำหรับโมเดลอื่น ใช้คะแนนสูงสุดจากประกาศของโมเดลเอง, benchmark leaderboard หรือ Artificial Analysis
  • trajectory การรันทั้งหมดของการประเมินขั้นสุดท้ายเปิดเผยที่ trajectories.poolside.ai

วิธีประเมินและการจัดการ reward hacking

  • การประเมิน agent มีปัญหา reward hacking คือการได้คะแนนจากการค้นหาคำตอบหรือ patch เดิมบนออนไลน์
  • เปิดให้เข้าถึงอินเทอร์เน็ตโดยค่าเริ่มต้น และใช้ LLM judge (LLMaaJ) ที่ปรับเทียบด้วย trajectory ที่คนติดป้ายกำกับ เพื่อทำเครื่องหมายกรณีน่าสงสัย
    • ในช่วง post-training ระยะแรก อัตรา reward hacking ต่ำกว่า 2%
    • เมื่อการเทรนดำเนินไป trajectory ที่ถูกทำเครื่องหมายในกลุ่ม SWE-bench เกิน 50%
    • จากการตรวจสอบด้วยมือ พบว่าหลายกรณีโมเดลหา PR หรือ repository ที่เป็นต้นตอของโจทย์แล้วนำ patch จริงมาใช้
  • หลังเพิ่มข้อความใน user prompt ว่าไม่ให้ใช้คำตอบโดยตรงที่พบออนไลน์ อัตรา reward hacking โดยรวมลดลงเหลือต่ำกว่า 2%
    • ไม่ใช่วิธีแก้สมบูรณ์ และมีข้อยกเว้นใน ProgramBench และ MirrorCode
  • การตรวจสอบเพิ่มเติมใช้การตรวจสอบด้วยมือของเคสสำเร็จที่ LLMaaJ ทำเครื่องหมาย, การวิเคราะห์ agent แบบปลายเปิดต่อ trajectory ทั้งหมด และผู้เชี่ยวชาญรีวิวการรันคะแนนสูงทั้งหมดบน Terminal-Bench 2.1
  • ล่าสุดเสริมการตรวจจับ reward hacking ด้วย adversarial judging และสามารถดู·ดาวน์โหลด trajectory การประเมินขั้นสุดท้ายของ checkpoint สาธารณะได้

ตัวอย่างงานจริง

  • สร้าง browser engine จากโฟลเดอร์ว่าง

    • Laguna S 2.1 ทำงาน 181 ขั้นตอนเป็นเวลา 50 นาที โดยไม่มีมนุษย์แทรกแซง เพื่อสร้าง HTML/CSS rendering engine จากโฟลเดอร์ว่าง
    • เมื่อตัวเองไม่มีความสามารถด้านภาพ ใช้ headless Chromium อ่าน canvas และเปรียบเทียบ screenshot เชิงตัวเลขเพื่อตรวจสอบผลลัพธ์
    • implement pipeline ทั้งหมดด้วย Vanilla JavaScript
      • HTML tokenizer และ DOM tree
      • CSS parser ที่จัดการ selector precedence
      • cascade engine ที่รองรับ inheritance
      • box model layout และ Canvas 2D renderer
    • ปิดงานด้วยแอปที่แสดงตัวอย่าง markup เดียวกัน 9 แบบเคียงข้างกันบน canvas ของตัวเองและ browser iframe
    • เปิดเผย trajectory การรันทั้งหมด

  • เพิ่มประสิทธิภาพ agent harness ของตัวเอง

    • ในลูปวิจัยอัตโนมัติที่ instrument benchmark วัดประสิทธิภาพหลังทุกการเปลี่ยนแปลง และจำกัดให้คงไว้เฉพาะการเปลี่ยนแปลงที่ยืนยันแล้วว่าดีขึ้น
    • ตลอดหลายชั่วโมง เพิ่มความเร็ว harness ได้ 5.2% และลด memory allocation ราว 70%
    • optimization หลักมีดังนี้
      • แทนที่การต่อ string แบบ O(n²) ที่ใช้สะสม streaming token ด้วย buffer
      • กำจัดการคัดลอกซ้ำในขั้นตอน materialize trajectory ด้วย memoization
      • pre-allocate slice ให้มีขนาดพอดีเพื่อลด over-allocation
    • หลังจากวัดความต่างด้านความเร็วได้ยากขึ้น จึงเปลี่ยนโฟกัสไปที่การ optimize memory allocation ที่วัดได้แม่นยำกว่า
    • benchmark ที่ใช้ไม่ใช่ production test แบบครบถ้วน แต่ตรวจสอบผลลัพธ์สุดท้ายด้วย Go race detector และ gate go vet รวมถึงยืนยันพฤติกรรมของ artefact
    • มี trajectory การรันทั้งหมด

  • ค้นพบ Erdős problem #397 ใหม่

    • ค้นพบ construction ที่สร้างชุดคำตอบอนันต์ใน Erdős problem #397 ซึ่ง Erdős, Graham, Ruzsa, Straus เสนอไว้ในปี 1975 อย่างอิสระ
    • ปัญหานี้ยังไม่ถูกแก้นานกว่า 50 ปี ก่อนที่ GPT-5.2 Pro จะแก้ได้ก่อนในเดือนมกราคม 2026 ดังนั้นนี่เป็นการค้นพบใหม่ ไม่ใช่คำตอบแรก
    • knowledge cutoff ของโมเดลคือพฤศจิกายน 2025 และเมื่อไม่มี Python ใน sandbox จึงหา Perl และทำงานเป็นเวลา 68 นาที
    • กระบวนการแก้มีดังนี้
      • brute-force การแยกตัวประกอบเฉพาะอย่างแม่นยำ
      • วิเคราะห์ pattern และคาดเดาชุดคำตอบ
      • พิสูจน์ชุดคำตอบอนันต์แบบ closed-form ที่ประกอบด้วย 8 indices
    • สูตรที่ค้นพบเป็นดังนี้สำหรับ n ≥ 0 ทุกค่า
    B(11+10n) · B(14+12n) · B(18+15n) · B(22+20n)
= B(12+10n) · B(13+12n) · B(17+15n) · B(23+20n)
    • ต่างจากชุดคำตอบเดิมที่มี 6 indices โดยใช้ โครงสร้าง 8 indices ที่เพิ่มขึ้นเชิงเส้น
    • เปิดเผย trajectory การรันทั้งหมด

โหมดการให้เหตุผลและความต่างของประสิทธิภาพ

  • โหมดการให้เหตุผลมีสองแบบคือ off และค่าเริ่มต้น max
    • max ให้โมเดลกำหนดงบการให้เหตุผลและ compute budget ณ เวลา test ของแต่ละปัญหาเอง
    • พบตัวอย่างที่ให้เหตุผลอย่างสม่ำเสมอต่อเนื่องเป็นเวลาหลายชั่วโมงและหลายแสนโทเค็น
  • เมื่อใช้ max thinking ประสิทธิภาพเพิ่มขึ้นอย่างมาก
    • Terminal-Bench 2.1: 60.4% → 70.2%
    • DeepSWE: 16.5% → 40.4%
  • ณ เวลาเปิดตัว ยังไม่มีการควบคุม reasoning intensity แบบกำหนดเองในรูป low·medium·high
  • ใน pool สามารถสลับการใช้ thinking ต่อ session ได้ด้วยคำสั่ง /thought-level

ข้อจำกัดที่ทราบ

  • เนื่องจาก harness overfitting เมื่อต้องเรียกเครื่องมือครั้งแรกที่คล้ายกับ harness ของตัวเองแต่รายละเอียด spec ต่างกัน เช่น terminal tool ของ Hermes Agent โมเดลอาจพึ่งพาความจำของ interface เดิม
    • หาก harness ปฏิเสธการเรียกที่ผิดและขอให้ลองใหม่ โดยมากจะแก้ได้ผ่าน in-context learning
  • ใช้รูปแบบการเรียกเครื่องมือแบบ tag-based คล้าย XML และเมื่อ argument ต้องเป็น JSON array อาจ escape ผิดหรือสร้าง JSON ที่ไม่ valid
  • โดยเฉพาะในโจทย์คณิตศาสตร์แข่งขัน อาจ ให้เหตุผลนานเกินไป โดยไม่มีความคืบหน้า
    • โมเดลถัดไปมีแผนเพิ่มการควบคุม reasoning intensity และปรับปรุงประสิทธิภาพการให้เหตุผล

การเปลี่ยนแปลงในการเทรนที่ทำให้ประสิทธิภาพดีขึ้น

  • ปรับปรุงวิธีทำงานมากกว่าขนาดโมเดล

    • เป้าหมายไม่ใช่แค่เพิ่มตัว intelligence เอง แต่เป็นการเสริมพฤติกรรมที่ ตรวจสอบมากขึ้น ไม่ตั้งสมมติฐานว่าแน่นอน และไม่ประกาศว่าสำเร็จเร็วเกินไป
    • Laguna รุ่นก่อน ๆ มีบางครั้งที่ประกาศเสร็จเมื่อ test ผ่านบางส่วน หรือเลิกแนวทางก่อนจะสำเร็จไม่นาน แต่ S 2.1 ทำงานต่อ
    • มองว่าความต่อเนื่อง การตรวจสอบ และความพร้อมจะย้อนกลับ เป็นแกนประสิทธิภาพสำคัญแยกจาก raw intelligence และลงทุนกับทั้งสองด้าน
    • โมเดล Laguna ขนาดใหญ่รุ่นถัดไปเริ่ม pretraining แล้ว

  • Pretraining และ post-training

    • เป็นโมเดลขยายขนาดที่ใช้ ข้อมูล pretraining เดียวกัน กับ Laguna XS 2.1
    • ความต่างจาก XS 2.1 คือขนาด, การแก้โค้ดเทรน และการปรับสูตรการเทรนขนาดเล็ก ไม่ใช่ข้อมูลใหม่
    • ทำ RL ด้วย FP8 precision เป็นครั้งแรก เพื่อเร่งขั้นตอนการเทรนนี้
    • post-training ดำเนินเป็นสองขั้นตอน
      • initialize ความสามารถด้วย supervised fine-tuning (SFT) ที่ใช้ข้อมูล synthetic บางส่วน
      • ใช้ RL กับงานที่ยังแก้ไม่ได้ด้วย pass rate สูง
    • session ของ agent ระยะยาวสะสมบริบทงานหลายแสนโทเค็น ดังนั้นการขยายคอนเท็กซ์เป็น 1M จึงเพิ่มประสิทธิภาพในงานที่ยาก

  • องค์ประกอบงานสำหรับ post-training

    • training corpus ประกอบด้วยสภาพแวดล้อม agent และ non-agent 409,000 รายการ
      • สภาพแวดล้อมที่ใช้ terminal 83,000 รายการ
      • งาน software engineering ทั่วไป 168,000 รายการ
    • ได้งานจาก open-source repository, synthetic data ภายใน, ระบบติดตั้ง dependency อัตโนมัติ และการซื้อกิจการผู้จัดหาข้อมูลภายนอก
    • งาน software engineering อิงกับประวัติโค้ดจริงเป็นหลัก
      • สัดส่วนใหญ่ที่สุดคือราว 38,000 งานที่สร้าง commit จริงจาก repository ประมาณ 17,000 แห่งขึ้นมาใหม่
      • รวมถึงการสร้าง merged PR ขึ้นมาใหม่, แก้ bug ที่ถูกใส่เข้าไป และกู้คืนไฟล์ที่ถูกลบโดยอิง test suite
    • S 2.1 เพิ่มงาน agent repository setup ที่ติดตั้ง dependency ทั้งหมดของ repository และรัน test suite
    • งาน terminal ใช้ dataset ที่สร้างสภาพแวดล้อมและโจทย์ที่ไม่เคยเห็นจาก seed

  • การปรับปรุง training loop

    • ใช้ rollout budget ที่ใหญ่ขึ้น กว่าโมเดลก่อนหน้า โดยเพิ่ม time limit, token ต่อ turn และจำนวน turn ต่องาน
    • ย้าย RL ไปยัง sandbox service ใหม่เพื่อใช้ฟีเจอร์ต่อไปนี้
      • รองรับ background process
      • บล็อก network แบบเลือกได้เพื่อลดพื้นที่ผิวของ reward hacking
      • cache artefact เพื่อป้องกัน external service overload
    • รัน prompt เดียวกันบน agent harness หลายแบบ เพื่อให้เรียนรู้พฤติกรรมที่ใช้ได้กับ harness หลากหลาย ไม่ใช่ scaffold เดียว

สองทิศทางที่ Poolside โฟกัส

  • ทิศทางแรกคือ ความสามารถด้าน agentic coding
    • มอง coding และ interface ที่ยืดหยุ่นของ software เป็นเส้นทางสู่ intelligence
    • โฟกัสตัวอย่างที่โมเดลใช้ software ในฐานะ agent และทำงานอย่างสม่ำเสมอเป็นเวลาหลายชั่วโมงหรือหลายวัน
  • ทิศทางที่สองคือแนวทางที่สามารถ กู้คืนกระบวนการคิด ที่นำไปสู่คำตอบจากคำตอบที่บันทึกอยู่บนเว็บได้ด้วย reinforcement learning
    • การเปิดตัวครั้งนี้เป็นผลจากทิศทางแรก ส่วนทิศทางที่สองยังอยู่ระหว่างพัฒนาต่อ

Model Factory และวงจรพัฒนา

  • ทำให้กระบวนการพัฒนาโมเดล เช่น data, architecture ablation experiment และ evaluation infrastructure เป็นอัตโนมัติด้วยแพลตฟอร์มวิจัย·วิศวกรรมภายใน Model Factory
  • หลังเปิดตัว Laguna M.1 ไม่ถึง 3 เดือน พัฒนาโมเดลที่มีขนาดรันเพียงครึ่งหนึ่งแต่แข็งแกร่งกว่า
  • ลงทุนเพื่อเพิ่มความเร็วของ research iteration และ integration และลดความสนใจที่นักวิจัยต้องใช้กับงานจัดการบันทึกและ infrastructure
  • ในช่วง 1 ปีข้างหน้า มีแผนนำวิธีพัฒนาเดียวกันไปใช้กับโมเดลที่ใหญ่กว่า

การเผยแพร่และวิธีใช้งาน

  • เปิดเผยบน Hugging Face ภายใต้ไลเซนส์ OpenMDW-1.1
    • มี weights แบบ BF16, FP8, INT4, NVFP4
    • มี official GGUF·MLX conversion และ DFlash draft model
  • สำหรับฮาร์ดแวร์ NVIDIA รองรับ optimization สำหรับ inference ตั้งแต่ TRT-LLM serving, NVFP4 บน Blackwell ไปจนถึง DGX Spark เครื่องเดียว
  • local และ public serving รองรับบน vLLM, SGLang, Ollama
  • ช่องทางเข้าถึงแบบ hosting มีดังนี้
  • endpoint ฟรีของ OpenRouter มี คอนเท็กซ์ 256K
    • endpoint แบบเสียเงินเฉพาะรองรับคอนเท็กซ์ 1M
    • ราคา input $0.10, output $0.20, cache read $0.01 ต่อ 1 ล้านโทเค็น
  • ใช้ได้กับ Kilo, Hermes Agent, pi, OpenCode, OpenClaw, Cline และ terminal coding agent pool
  • post-training รองรับ NVIDIA NeMo AutoModel และ Prime Intellect Prime Lab ส่วน ZML LLMD รองรับการรันบนฮาร์ดแวร์หลายแบบ
  • ผู้ใช้ที่ไม่ใช่นักพัฒนาสามารถใช้ web search และการรันโค้ดพื้นฐานได้ที่ chat.poolside.ai โดยไม่ต้องล็อกอิน
  • base model weights ก่อน post-training มีให้ตามคำขอทางอีเมล

เงื่อนไขการรัน benchmark

  • ใช้ Harbor Framework fork ภายใน, pool agent harness, สูงสุด 500 ขั้นตอน และ sandbox ภายใน
  • SWE-bench Multilingual, SWE-Bench Pro, Terminal-Bench 2.1 ใช้ค่าเฉลี่ย pass@1 จากการรัน 4 ครั้งต่องาน
  • DeepSWE v1.1 และ SWE Atlas ใช้งานละ 3 ครั้ง ส่วน Toolathlon Verified ใช้ค่าเฉลี่ยจากการรัน 3 ครั้ง
  • SWE Atlas ใช้วิธีการสาธารณะตามเดิมและให้ Opus 4.5 เป็นผู้ตัดสิน
  • Toolathlon Verified ใช้ harness ที่ทำซ้ำบน EC2 และ agent แบบกำหนดเอง โดยต่างจากเวอร์ชันทางการตรงที่จะ reset และ restore สภาพแวดล้อมทั้งหมดหลังการรันประเมินแต่ละครั้ง
  • ปรับ CPU·memory·storage limit ตามแต่ละ benchmark เพื่อป้องกัน sandbox preemption และรับประกันอย่างน้อย CPU 2 cores, memory 8GB, storage 25GB
  • การแก้ไขงานรายตัวสรุปไว้ใน technical report

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News
  • ตอนนี้กำลังทดสอบอยู่ และอย่างน้อยก็ดูเหมือนว่า อยู่ในระดับที่แข่งขันกับ DS4-Flash ได้ ในโค้ดเบสทดสอบภาษา C ที่เล็กแต่มีความหนาแน่นของความหมายสูงมาก มันพบปัญหาที่ก่อนหน้านี้มีแค่ gpt-5.2 ที่หาเจอ แต่ก็วินิจฉัยผิดอย่างน่าขันว่าใช้ memfd_create()/mmap สำหรับ IPC และ Sol เองก็พลาดจนกว่าผมจะชี้ให้เห็น
    การเทียบกับ DeepSeek V4 อาจเปลี่ยนไปได้ในพริบตาในสภาพแวดล้อมที่เปลี่ยนเร็วแบบตอนนี้ เพราะทั้ง Flash และ Pro จะผ่านการฝึกต่อเนื่องเพิ่มเติมอย่างเพียงพอและเปิดตัวอย่างเป็นทางการในเร็ว ๆ นี้ หวังว่าจะมีโมเดลแบบนี้ออกมาเรื่อย ๆ
    • อยากรู้ว่าใช้ test harness และวิธี quantization แบบไหน
  • ยอดเยี่ยม และโดดเด่นที่สุดในบรรดาสิ่งที่เปิดตัววันนี้อย่างชัดเจน ระดับที่เหนือกว่าผลิตภัณฑ์ใหม่ ๆ ของ Google โดยเฉพาะ ความสามารถในการแข่งขันด้านราคา น่าทึ่งมาก และคาดหวังสูงเพราะเป็นโมเดลสัญชาติอเมริกันตัวแรกที่น่าจะสู้กับ DeepSeek V4 Flash ได้
  • โมเดลนี้ไม่ธรรมดา และสร้าง PR หนึ่งรายการ ที่ใช้กับงานจริงได้แล้ว
    https://github.com/mozilla-ai/otari/pull/348
  • น่าประทับใจ และด้วยขนาดนี้ดูเหมือนจะรันบนฮาร์ดแวร์ใช้งานที่บ้านแบบสมเหตุสมผลได้ด้วย หวังว่าจะมี quantization สำหรับสภาพแวดล้อม 64GB แม้ต้องยอมรับประสิทธิภาพที่ลดลง
    เคยมีความเห็นว่าเวอร์ชัน 2 บิตของ Qwen 3.5 122B ก็ใช้ได้ดี และโมเดลนี้มีจุดตั้งต้นสูงกว่า จึงคุ้มค่าที่จะลองทดสอบ มีคนกำลังทำอยู่แล้ว: https://huggingface.co/vcruz305/Laguna-S-2.1-GGUF
    • น่าสนใจที่มีโปรเจกต์ซึ่ง benchmark เวอร์ชัน quantization ต่าง ๆ ไว้: https://github.com/tanishq-dubey/macos-laguna-s2.1
    • Laguna XS 2.1 33B ที่เล็กกว่าก็เปิดตัวแล้ว และขนาด Q4 GGUF คือ 20GB
      https://huggingface.co/poolside/Laguna-XS-2.1-GGUF/tree/main
    • Q4_K_M ก็มีขนาด 75GB ดังนั้นแม้เป็นสภาพแวดล้อม 64GB ก็คงไม่ quantize ให้ต่ำกว่านี้เท่าไร แทนที่จะทำแบบนั้น น่าจะดีกว่าถ้า คงน้ำหนักบางส่วนไว้ในหน่วยความจำ แล้วสตรีมส่วนที่เหลือจาก SSD
    • มี เวอร์ชัน unsloth ที่ทำหน้าที่เป็นตัวช่วยแก้ปัญหาเสมอออกมาแล้ว: https://huggingface.co/unsloth/Laguna-S-2.1-GGUF
    • llm-compressor ที่ผมใช้สามารถ quantize โมเดลที่ใส่ในหน่วยความจำไม่พอ ได้ด้วย โดยใช้ pipeline แบบลำดับ
      https://github.com/vllm-project/llm-compressor
      ตัวอย่างการตั้งค่าอยู่ที่ https://github.com/verdverm/quantr อย่างไรก็ตาม Poolside เปิดเผยเวอร์ชัน quantize และ dflash พร้อมกับโมเดลแล้ว ตอนนี้อาจไม่จำเป็นแล้วก็ได้
  • เป็นชุดที่น่ายินดีมาก: MoE ขนาด 118B พารามิเตอร์ แต่เปิดใช้งานเพียง 8B, การให้เหตุผลด้วย context ยาว และเปิดเผย weights แม้จะเป็นแล็บที่เพิ่งเคยได้ยินชื่อครั้งแรก แต่ดูเหมือนจะใกล้จุดที่ลงตัวที่สุดระหว่างขนาดโมเดลกับประสิทธิภาพ จึงอยากลองมาก
    • ถ้า ตัวเลขประสิทธิภาพที่เผยแพร่ออกมาเป็นจริง ก็เท่ากับว่าโมเดลที่รอคอยมาถึงในที่สุด
  • สิ่งที่ต้องการพอดีคือ โมเดลระดับกลาง ที่ self-host ได้จริง ฉลาดพอ และมี MoE ที่เร็วแม้มีแบนด์วิดท์หน่วยความจำจำกัด
    ที่ผ่านมาบน Strix Halo ยังไม่มีตัวเลือกที่ดีกว่าอย่างชัดเจนเมื่อเทียบกับ dense model อย่าง Gemma 4 หรือ Qwen 3.6 ที่รันบนเดสก์ท็อป GPU คู่ 32GB แต่โมเดลนี้ดูมีขนาดที่น่าจะให้ประสิทธิภาพจริงดีขึ้นได้
  • ต้องระวังเวลา test โมเดลนี้ ในค่าเริ่มต้น ฟังก์ชัน reasoning ไม่ได้ถูกเปิดใช้อย่างถูกต้อง จนอาจทำให้ผิดหวังกับผลลัพธ์หรือมองว่า benchmark ถูกอวดเกินจริง
    แม้ใส่ --default-chat-template-kwargs '{"enable_thinking": true}' ในการตั้งค่ารัน vLLM ก็ยังไม่เปิดใช้งาน และดูเหมือนค่าเริ่มต้น max_new_tokens ใน generation_config.json ที่แนบมาจะเป็น 32k ทำให้ตัด reasoning ทิ้ง จึงต้องเพิ่มค่า เมื่อเปิด reasoning แล้ว คุณภาพโค้ดดีขึ้นมาก แต่ยังต้องตรวจสอบเพิ่มเติมกับงานจริง
    https://www.reddit.com/r/LocalLLaMA/comments/1v2pg99/laguna_...
    • ดูเหมือนว่าไม่นานหลังจากโพสต์นี้ขึ้น chat template เริ่มต้น บน Hugging Face ถูกแก้ให้เปิด reasoning เป็นค่าเริ่มต้นแล้ว
    • ดูเหมือน โมเดลที่ให้บริการอย่างเป็นทางการ บน OpenRouter ก็มีปัญหาเดียวกัน และหวังว่าจะแก้ได้ง่าย ๆ
    • พอปรับการตั้งค่าการรันแล้ว ผลลัพธ์เปลี่ยนไปมาก
  • การที่ โมเดล 128B ชนะ DeepSeek V4 ขนาด 1.6T ใน benchmark ด้าน coding ส่วนใหญ่ เป็นสัญญาณที่น่าประทับใจมาก
    ชอบที่ Poolside ไม่ได้เทียบแค่กับโมเดลในรุ่นน้ำหนักใกล้กัน แต่ยังเทียบกับโมเดล open weights ระดับบนที่ใหญ่กว่ามากอย่าง Kimi-K3 2.5T ด้วย อยากให้ที่อื่น ๆ รวมถึง Mistral ทำแบบนี้เช่นกัน
  • ได้รู้จัก Poolside ครั้งแรกเมื่อประมาณหนึ่งสัปดาห์ก่อน หลังจากเจอ coding harness แบบ local ชื่อ pool และ โมเดล MoE 33B มันทำงานได้เร็วและมีประสิทธิภาพแม้บน Mac mini 32GB รุ่นเก่า และตั้งใจจะลองประเมินโมเดลขนาดใหญ่แบบ hosted ด้วย
  • Poolside chat ที่แนะนำไว้ในหน้านั้นใช้งานได้ที่นี่: https://chat.poolside.ai