เปิดตัว LongCat-2.0 - โมเดลโอเพนซอร์ส 1.6 ล้านล้านพารามิเตอร์ที่ฝึกโดยไม่ใช้ Nvidia

 (longcat.chat)
2 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดลภาษา MoE ขนาดใหญ่ที่มี พารามิเตอร์รวม 1.6 ล้านล้าน (1.6T) และเปิดใช้งานราว 48 พันล้านพารามิเตอร์ต่อโทเคน มาพร้อมการโอเพนซอร์สและการปรับปรุงสถาปัตยกรรมหลายด้าน
  • การฝึกทั้งหมดและการดีพลอยขนาดใหญ่ดำเนินการบน AI ASIC superpod ทั้งหมด โดยฝึก pretraining บนโทเคนมากกว่า 35 ล้านล้านโทเคนจนเสร็จ โดยไม่มี loss spike ที่ต้อง rollback หรือกู้คืนไม่ได้
  • นำ LongCat Sparse Attention (LSA) มาใช้ และฝึกด้วยข้อมูล context 1M ระดับหลายแสนล้านโทเคน เพื่อเพิ่มประสิทธิภาพในงานระยะยาว
  • ผสานรวมอย่างใกล้ชิดกับ harness กระแสหลัก เช่น Claude Code, OpenClaw, Hermes ให้ประสิทธิภาพสูงในการเข้าใจโค้ด การแก้ไขระดับ repository การรันงานอัตโนมัติ และเวิร์กโฟลว์เอเจนต์
  • พิสูจน์ว่า การฝึกระดับ frontier เป็นไปได้บนฮาร์ดแวร์ทางเลือกที่ยังไม่成熟เท่าระบบนิเวศ Nvidia GPU และการปรับแต่งทั้งโครงสร้างพื้นฐานกับ post-training ส่งผลโดยตรงต่อความสามารถในการทำงานจริง

ภาพรวมโมเดล

  • โมเดลภาษา MoE ขนาดใหญ่ระดับ 1.6 ล้านล้านพารามิเตอร์ โดยเปิดใช้งานเพียงราว 48 พันล้านพารามิเตอร์ต่อโทเคน ถือเป็นความก้าวหน้าครั้งใหญ่เมื่อเทียบกับโมเดล LongCat รุ่นก่อนหน้า
  • ทั้งการรันฝึกทั้งหมดและการดีพลอยขนาดใหญ่สร้างอยู่บน AI ASIC superpod
    • pretraining ใช้ทรัพยากรระดับหลายล้าน accelerator-day บนโทเคนมากกว่า 35 ล้านล้านโทเคน และเสร็จสิ้นโดยไม่มีการ rollback หรือ loss spike ที่กู้คืนไม่ได้
    • พิสูจน์ศักยภาพในการฝึกระดับ frontier บนแพลตฟอร์มฮาร์ดแวร์ทางเลือก
  • นำ LongCat Sparse Attention มาใช้เพื่อเพิ่มความสามารถในงานระยะยาว และฝึกด้วยข้อมูล context 1M จำนวนหลายแสนล้านโทเคน
  • ผสานรวมลึกกับ harness กระแสหลัก เช่น Claude Code, OpenClaw, Hermes เพื่อมอบประสบการณ์ทำงานร่วมกันที่เสถียรและมีประสิทธิภาพในด้านการเข้าใจโค้ด การแก้ไขระดับ repository การรันงานอัตโนมัติ และเวิร์กโฟลว์เอเจนต์โดยรวม

สถาปัตยกรรม

  • ต่อยอดจาก LongCat-Flash โดยผลักดันประสิทธิภาพพารามิเตอร์ให้มากขึ้น และปรับปรุงความเร็วของการฝึกกับ inference สำหรับ context ยาว
  • ในส่วน attention นำ LongCat Sparse Attention (LSA) มาใช้
    • เป็นวิวัฒนาการของ DeepSeek Sparse Attention โดยใช้ indexer ที่เบากว่าเพื่อเร่งการประมวลผล context ยาวโดยไม่กระทบคุณภาพโมเดล
  • เพิ่มโมดูล N-gram Embedding
    • ขยายพื้นที่ embedding ราว 100 เท่าด้วยการผสมโทเคนแบบ N-gram ช่วยจับ local context ได้สมบูรณ์ขึ้นและเสริมการแทนค่าระดับโทเคน

LongCat Sparse Attention

  • เมื่อแอปพลิเคชันแบบเอเจนต์แพร่หลายขึ้น LLM กำลังมุ่งไปสู่การประมวลผลอินพุตยาวอย่างมีประสิทธิภาพ
    • DSA รับมือด้วย sparse attention ที่ละเอียด แต่จากการ profiling พบว่า Lightning Indexer ของ DSA ยังเป็นคอขวดหลัก เนื่องจากความไม่ต่อเนื่องของ output และต้นทุน scoring แบบกำลังสอง (quadratic)
  • LSA นำการปรับปรุงประสิทธิภาพ 3 แบบที่เป็นอิสระต่อกัน (orthogonal) มาใช้กับ indexer
    • Streaming-aware Indexing (SI): จัดงบการเลือกโทเคนใหม่ให้ผสานการเข้าถึงต่อเนื่องที่จัดแนวกับฮาร์ดแวร์และการสุ่มเลือกแบบไดนามิก เปลี่ยนการเข้าถึงหน่วยความจำที่แตกกระจายเป็นการอ่านตามลำดับที่คาดการณ์ได้ เพื่อให้ได้ coalesced HBM access และแบนด์วิดท์ใช้งานจริงสูง
    • Cross-Layer Indexing (CLI): ใช้เสถียรภาพเชิงประสบการณ์ของ attention saliency ระหว่างเลเยอร์ใกล้กันเพื่อกระจายต้นทุน indexing ระหว่าง inference การ indexing เพียง pass เดียวถูกใช้กับหลายเลเยอร์ต่อเนื่อง และทำได้ระหว่างการฝึกผ่าน cross-layer distillation
    • Hierarchical Indexing (HI): scoring แบบ coarse-to-fine สองขั้น เริ่มจาก scoring โดยประมาณระดับบล็อกเพื่อ recall คร่าว ๆ แล้วค่อยเลือกโทเคนละเอียดภายใน candidate ใน LongCat-2.0 ใช้แบบไม่ต้องฝึก (training-free) และเปิดใช้งานกับงาน context ยาวมากบางประเภท
  • องค์ประกอบทั้งสามเป็นอิสระตามการออกแบบ จึงสามารถเปิดหรือปิดใช้งานแยกกันได้
  • ขยายทั้งสามกลยุทธ์ไปยังโมดูล Multi-Token Prediction (MTP) 3 ขั้น เพื่อเร่ง speculative decoding
    • Cross-Layer Indexing ถูกใช้ต่างกันในโมเดล draft และ target โดยโมเดล target ให้ 2 เลเยอร์ต่อเนื่องแชร์ indexing pass เดียว
    • ใน MTP หลายขั้น draft step 3 ขั้นแชร์ pass เดียว โดย step 2 และ 3 นำ index set ที่ step 1 สร้างไว้มาใช้ซ้ำ

N-gram Embedding

  • สืบทอดจาก LongCat-Flash-Lite โดยขยายพารามิเตอร์ผ่านมิติ sparse ที่เป็นอิสระจาก MoE เพื่อเพิ่มประสิทธิภาพการใช้พารามิเตอร์
    • กำหนดขนาด n-gram เป็น 5 และโมเดลมี พารามิเตอร์ N-gram Embedding 135B
  • ปฏิบัติตามหลักการ scaling ต่อไปนี้
    • sparsity ของ MoE เกิน sweet spot แล้ว: แม้ไม่มี N-gram Embedding sparsity ก็แตะราว 97% แล้ว การเพิ่ม expert อีก 135B จึงให้ประโยชน์ด้านประสิทธิภาพเพียงเล็กน้อย ขณะที่ N-gram Embedding ในขนาดพารามิเตอร์เท่ากันให้ประโยชน์มากกว่า expert มาตรฐานอย่างชัดเจน
    • จำกัดสัดส่วนของ N-gram Embedding ให้อยู่ในช่วงเหมาะสม: ผลการทดลอง scaling พบว่าเมื่อพารามิเตอร์ n-gram embedding กินสัดส่วนมากเกินไปของงบทั้งหมด (เกิน 50%) ข้อได้เปรียบเมื่อเทียบกับการขยาย expert จะลดลง ใน LongCat-2.0 จึงควบคุมสัดส่วนนี้ไว้อย่างเข้มงวดให้ต่ำกว่า 10%
  • ระหว่าง inference การย้ายพารามิเตอร์จาก expert ไปยัง N-gram Embedding ช่วยลด memory I/O ของการ decode แบบ batch ขนาดใหญ่และเร่งการสร้างผลลัพธ์

โครงสร้างพื้นฐานแบบขยายได้บน AI ASIC superpod

  • การฝึกและดีพลอยอยู่บนคลัสเตอร์ขนาดใหญ่ที่มี AI ASIC superpod หลายหมื่นตัว
  • เมื่อเทียบกับระบบนิเวศ Nvidia GPU ที่成熟กว่า คอมมูนิตี้ซอฟต์แวร์สนับสนุนยังพัฒนาไม่เท่า จึงต้องทุ่มความพยายามอย่างมากในการสร้างโครงสร้างพื้นฐานที่เสถียร ปลอดภัย และขยายได้

การฝึก (Training)

  • pretraining บน AI ASIC มากกว่า 50,000 ตัว ทำให้เกิดความท้าทายระดับระบบจากขนาดของโมเดลและคลัสเตอร์

    • ด้วยการปรับแต่งอย่างเป็นระบบ ทำให้ throughput การฝึกดีขึ้นมากกว่า 35% เมื่อเทียบกับ implementation แบบ naive พร้อมเพิ่มความน่าเชื่อถือด้วย

  • Determinism & Reliability

    • บังคับ determinism ตลอดเส้นทาง communication และ computation เพื่อให้ทำซ้ำได้ พร้อมมี operator และโมดูล deterministic ที่พัฒนาขึ้นเอง ครอบคลุมเลเยอร์ Embedding, FA, LSA และ MoE
    • ปรับปรุง operator พื้นฐานใหม่เพื่อความน่าเชื่อถือเชิงตัวเลข เช่น operator กลุ่ม reduction ทั้งหมดใช้กลยุทธ์สะสมแบบ binary-tree partition เพื่อลดการสะสม error ของ floating point
      • ตรวจสอบความแม่นยำของการคำนวณบน accelerator ใน workload LLM จริง เทียบกับ baseline ความแม่นยำสูงแบบเข้มงวด เพื่อยืนยันความถูกต้องทางคณิตศาสตร์และความพร้อมใช้งานระดับ production
      • ใส่การตรวจจับ bit-flip ใน operator ที่เน้นการคำนวณบางส่วน เพื่อจับความผิดปกติจาก bit flip ของฮาร์ดแวร์ได้ทันที
    • การกู้คืนเมื่อเกิดปัญหาทำผ่าน end-to-end monitoring ที่ระบุปัญหา สลับ traffic และกู้คืนโดยไม่ต้องให้คนแทรกแซง เมื่อแยก link ที่มีปัญหาออก จะไม่มีผลกระทบที่รู้สึกได้ต่อการฝึก และ link ที่กู้คืนแล้วจะกลับเข้าระบบหลังผ่าน stress test

  • การฝึกขนาดใหญ่ (Training at Scale)

    • หน่วยความจำต่ออุปกรณ์ของ accelerator น้อยกว่า H800 (80GB) มาก ทำให้หน่วยความจำเป็นคอขวดหลักของการขยายขนาด จึงรับมือด้วยสองแกนคือกลยุทธ์ parallelization และการจัดการหน่วยความจำ
    • 6D parallelization: นอกจาก TP/CP/EP/DP/PP มาตรฐานแล้ว ยังนำ EMBP มาใช้เพื่อ parallelize และเร่ง N-gram Embeddings
    • superpod: ฝึกบน superpod เชิงกายภาพที่แต่ละชุดมีเครื่องสูงสุด 48 เครื่อง ภายในใช้ all-to-all แบนด์วิดท์สูง และระหว่าง pod เชื่อมผ่าน RoCE fabric เพื่อขยายโดเมน communication แบนด์วิดท์สูงสำหรับ parallelization ที่ต้องใช้แบนด์วิดท์มาก (TP/CP/EP) ไปยังอุปกรณ์หลายร้อยตัว
      • ให้ throughput pretraining เพิ่มขึ้นอีกราว 30% ภายใต้ขนาดและสภาพแวดล้อมเดียวกัน
      • logical superpod เป็นหน่วย affinity scheduling ที่ปรับสมดุลระหว่าง locality ของ communication กับความสามารถในการ schedule
    • การปรับแต่งหน่วยความจำ: ใช้ ZeRO-1, selective recomputation, OOM-aware offloading ระดับ allocator และ route padding token ไปยัง zero-expert
    • Muon optimizer: ดีพลอยขนาดใหญ่บน accelerator พร้อมการปรับแต่งเฉพาะเป้าหมายทั่วทั้ง TP parallelization, การลด state ซ้ำของ DP และ kernel คูณเมทริกซ์สมมาตรที่มีประสิทธิภาพ

  • การฝึก context ยาว (Long Context Training)

    • รับมือความท้าทายของการฝึก context ยาวขนาดใหญ่จากสามมุม
    • LSA operator & การปรับแต่ง forward: สร้าง attention operator แบบ deterministic ของตัวเองสำหรับ dense-warmup, ขั้น sparse และ operator KL-loss ใช้กลยุทธ์ forward-only dense-warmup เพื่อคำนวณ KL loss และ gradient ใน forward pass เดียว ช่วยเพิ่มประสิทธิภาพ
    • การ scale context 1M: ทำการฝึกความยาว native 1M ด้วย CP parallelization แบบ all-gather ที่ขยาย CP ได้มากกว่า 512 และรักษาสมดุล workload ด้วยการ reshuffle ข้อมูลในขั้น get-batch กับกลยุทธ์ CP balancing
    • การ overlap ระหว่าง computation กับ communication: เช่น สถาปัตยกรรม shortcut-layer overlap การสื่อสาร MoE กับการคำนวณ branch แบบขนาน และการคำนวณ top-k index ของ LSA overlap กับ KV all-gather เพื่อลด overhead จาก synchronization

Inference

  • การ serve โมเดล 1.6T พารามิเตอร์ที่ context 1M โทเคนเป็นความท้าทายใหญ่ภายใต้ข้อจำกัดเข้มงวดของความจุ HBM, แบนด์วิดท์ HBM I/O และแบนด์วิดท์ interconnect ระหว่าง node จึงรับมือด้วย stack การปรับแต่งระดับโมเดล อุปกรณ์ และ deployment

  • การปรับแต่งเฉพาะโมเดล

    • Attention: ปรับแต่งคอขวดด้าน I/O, computation และ memory ของ context ยาวมากจากสามมุม
      • (1) ใช้โหมดการคำนวณ absorb ทั้งในขั้น prefill และ decode
      • (2) pipeline indexer เป็น stream พร้อมกับ MLA prolog เพื่อซ่อน overhead ของ indexer
      • (3) shard KV-cache ข้ามอุปกรณ์ด้วย KV-cache parallelism (KVP)
    • ScMoE: พัฒนาตารางเวลาเพิ่มเติมบนฐาน computation-communication overlap ของ LongCat-Flash ใช้การควบคุม per-core แบบ explicit ของ accelerator เพื่อรัน branch dense และ MoE แบบขนานเต็มรูปแบบ เกินกว่าระดับ overlap ธรรมดา

  • การปรับแต่งที่มุ่งสู่ accelerator

    • Super Kernel: แม้ graph mode จะลบช่องว่างระหว่าง kernel ได้ แต่ยังมี overhead การ launch ภายใน kernel จึงใช้ super kernel เพื่อลดต้นทุน intra-kernel launch นี้
    • Weight Prefetch: อุปกรณ์มีแบนด์วิดท์ HBM จำกัด แต่มี L2 cache ค่อนข้างใหญ่ จึง prefetch weight เข้า L2 cache ขนาดใหญ่นี้เพื่อซ่อน latency ของ I/O ระหว่างที่ operator ก่อนหน้ากำลังคำนวณ
    • Scale Up and Scale Out: การส่ง KV-cache ระหว่าง node P·D ใช้ network adapter 200Gbps ในตัว accelerator โดยส่ง KV-cache เป็นรายเลเยอร์, KV-cache store สร้างจาก host RDMA network adapter และ TP/SP/KVP ดำเนินการภายในโดเมน interconnection แบบ scale-up

  • Deployment & Serving

    • parallelization ที่เหมาะสมที่สุด: ใช้การดีพลอยแบบแยก prefill–decode (PD) เพื่อปรับสมดุล TTFT และ TPOT
      • Prefill node: การประมวลผล sequence ยาวถูกจำกัดด้วยแบนด์วิดท์ communication ระหว่าง node และ traffic ของ MoE dispatch/combine ครอง runtime จึงใช้ multi-node chunked pipeline parallelism (CPP) เพื่อลดโดเมน expert-parallel (EP) และใช้ Attention Sequence Parallelism (SP) ภายในแต่ละ pipeline stage เพื่อลดแรงกดดันจากการคำนวณ sequence ยาว
      • Decode node: ข้อจำกัดหลักคือหน่วยความจำอุปกรณ์และ KV-cache I/O ใช้ KVP เพื่อ shard KV-cache ลด memory footprint ต่ออุปกรณ์ และใช้ระดับ EP สูง (EP128) เพื่อลดทั้งหน่วยความจำ weight ต่ออุปกรณ์และ expert I/O
      • ออกแบบให้รูปแบบ parallelization (CPP/SP·KVP) ในทั้งสองขั้นผสานกับการปรับแต่งช่วง inference เช่น constrained decoding, multi-step scheduling และ MTP ได้อย่างเรียบร้อย
    • Expert-Parallel Load Balancing (EPLB): ระดับ EP สูงของ decode node อาจเพิ่มความไม่สมดุลของ load ระหว่าง expert จึงใช้ EPLB รับมือ และเพื่อลด overhead การ serve การเก็บสถิติและ batch operation จะทำแบบ async นอก forward critical path

การเรียนรู้จากครูหลายราย (Learning from Multiple Teachers)

  • เพื่อยกระดับประสิทธิภาพรวมและขยายขอบเขตความสามารถ นำการออกแบบ expert-group เฉพาะทางมาใช้ใน post-training pipeline แบ่งเป็นสามหมวด
  • Agent Experts: ปรับปรุงการรันงานอัตโนมัติในสถานการณ์จริงที่ซับซ้อน บรรลุประสิทธิภาพระดับ SOTA ใน vertical domain ละเอียด เช่น โค้ด งานสำนักงาน และการค้นหา
    • ปรับแต่งไม่เพียงอัตราความสำเร็จของงานแบบ end-to-end แต่ยังรวมถึงความสามารถย่อยที่รองรับความแข็งแกร่งของเอเจนต์ เช่น การเรียก tool อย่างแม่นยำ การ parse พารามิเตอร์ที่เชื่อถือได้ในการโต้ตอบ API หลาย turn และกลไก self-correction ที่ลด infinite loop กับการเรียกซ้ำ
  • Reasoning Experts: ขยายความลึกของ logical reasoning และเปิดใช้ computation แบบปรับตามความยากของปัญหา ให้ประสิทธิภาพสูงในคณิตศาสตร์ การแก้ปัญหา STEM และ multi-hop reasoning เพิ่มความสามารถในการจัดการสถานการณ์วิเคราะห์ที่ซับซ้อน
  • Interaction Experts: มุ่งเน้น human alignment และการปรับแต่งประสบการณ์ผู้ใช้ ปรับปรุงการทำตามคำสั่งอย่างละเอียดในแอปพลิเคชันหลากหลาย ใช้เทคนิค alignment ขั้นสูงเพื่อยับยั้ง factual hallucination และวางกลไกความปลอดภัยที่มีขอบเขตชัดเจนโดยไม่ลดทอนความมีประโยชน์
  • สุดท้ายรวมความสามารถที่แข็งแกร่งที่สุดของ expert ทั้งสามกลุ่มด้วย สถาปัตยกรรม MOPD ผสานการรันเอเจนต์ที่แข็งแกร่ง reasoning เชิงลึก และ interaction คุณภาพสูง เพื่อเข้าใจความต้องการซับซ้อนของผู้ใช้อย่างแม่นยำและทำงานจริงที่ยากได้อย่างเชื่อถือได้

การสาธิตความสามารถของโมเดล

  • เด่นในการทำงานจริงด้วย long-context reasoning และ post-training เฉพาะทาง

  • Codebase Migration

    • อ่าน codebase ทั้งหมดพร้อมเอกสาร migration ทำแผนที่สถาปัตยกรรม และเขียน plugin ทั้งหมดใหม่ให้ใช้ SDK ใหม่
    • คงฟังก์ชันเดิมทั้งหมด ตรวจจับ bug ที่อาจเกิดขึ้น และ compile ได้สะอาดตั้งแต่ build แรก

การประเมินผล (Evaluations)

  • เปรียบเทียบกับโมเดลเชิงพาณิชย์หลักในด้านโค้ด เอเจนต์ทั่วไป และความสามารถพื้นฐาน คะแนนทั้งหมดนอกจากที่มีเครื่องหมาย * เป็นการวัดเองด้วย harness แบบรวม (normalize 0–100)

  • Code Agent

    • Terminal-Bench 2.1: LongCat-2.0 70.8, Gemini 3.1 Pro 70.7*, GPT-5.5 73.8*, Claude Opus 4.7 71.7*, Opus 4.8 78.9*
    • SWE-bench Pro: LongCat-2.0 59.5, Gemini 3.1 Pro 54.2*, GPT-5.5 58.6*, Opus 4.6 57.3*, Opus 4.7 64.3*, Opus 4.8 69.2*
    • SWE-bench Multilingual: LongCat-2.0 77.3, Gemini 3.1 Pro 76.9*, Opus 4.6 77.8*, Opus 4.7 80.5*, Opus 4.8 84.8*

  • General Agent

    • FORTE†: LongCat-2.0 73.2, Gemini 3.1 Pro 70.3, GPT-5.5 77.8, Opus 4.6 73.2, Opus 4.7 77.6, Opus 4.8 77.2
    • BrowseComp: LongCat-2.0 79.9, Gemini 3.1 Pro 85.9*, GPT-5.5 84.4*, Opus 4.6 84.0*, Opus 4.7 79.3*, Opus 4.8 84.3*
    • RWSearch: LongCat-2.0 78.8, Gemini 3.1 Pro 76.3, GPT-5.5 85.3, Opus 4.6 81.3, Opus 4.7 79.3, Opus 4.8 77.3

  • Foundational

    • IFEval: LongCat-2.0 90.0, Gemini 3.1 Pro 96.1, GPT-5.5 95.0, Opus 4.6 92.2, Opus 4.7 88.7, Opus 4.8 86.0
    • Writing Bench: LongCat-2.0 83.8, Gemini 3.1 Pro 83.7, GPT-5.5 84.7, Opus 4.7 85.3, Opus 4.8 85.2
    • IMO-AnswerBench: LongCat-2.0 81.8, Gemini 3.1 Pro 90.0, GPT-5.5 79.5, Opus 4.6 75.3*, Opus 4.7 81.8, Opus 4.8 75.3
    • GPQA-diamond: LongCat-2.0 88.9, Gemini 3.1 Pro 94.3*, GPT-5.5 93.6*, Opus 4.6 91.3*, Opus 4.7 94.2*, Opus 4.8 92.4

  • เงื่อนไขการประเมิน

    • Terminal-Bench 2.1: ประเมินด้วย Claude Code, sandbox instance ละ 8c16g, พารามิเตอร์ inference temperature=1.0/top_k=-1/top_p=0.95, timeout ของเอเจนต์ 6 ชั่วโมง
    • SWE-Bench series: ประเมินด้วย Claude Code, sandbox instance ละ 4c8g, temperature=1.0/top_k=-1/top_p=1, แก้ task ที่มีปัญหาแล้ว
    • FORTE: benchmark general agent ที่ประเมิน AI agent ด้วย productivity งานสำนักงานประจำวันของ 15 สายงานในองค์กร รองรับเฟรมเวิร์ก OpenClaw/Hermes/Claude Code, task ทั้งหมด timeout 45 นาที, 2 CPU/4GB RAM, timeout การเรียก API รอบเดียว 500s, retry สูงสุด 10 ครั้ง (เครื่องหมาย †)
    • RW-Search: benchmark เชิงวัตถุประสงค์ที่สร้างเองสำหรับ search agent เป็นการประเมิน bare-model ที่มีเพียงเครื่องมือ Search และ Browse พื้นฐาน ไม่ใช้กลยุทธ์จัดการ context
    • Foundational: reasoning คณิตศาสตร์ เช่น IMO-AnswerBench ใช้ temperature=1.0/top_k=-1/top_p=0.95 ส่วนที่เหลือใช้ temperature=0.7/top_k=-1/top_p=0.95

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

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

 
GN⁺ 6 시간 전
ความคิดเห็นจาก Hacker News

  • ประเด็นที่ว่า “การฝึกและการนำ LongCat-2.0 ไปใช้งานถูกสร้างขึ้นบนคลัสเตอร์ขนาดใหญ่ที่ประกอบด้วย AI ASIC superpod หลายหมื่นชุด… ชุมชนซอฟต์แวร์สนับสนุนยังไม่เติบโตเท่าระบบนิเวศของ Nvidia GPU…” ดูเหมือนจะเป็น ข่าวสำคัญจริง ๆ
    ดูมีความเป็นไปได้ว่าใช้ชิป Huawei Ascend 910C: https://nitter.net/teortaxesTex/status/2071708141037781407#m

    • ถ้าพวกเขาทำโมเดล 1.6 ล้านล้านพารามิเตอร์ได้จริงตั้งแต่ pretraining ไปจนถึง post-training โดย ไม่มี NVIDIA นั่นก็เท่ากับสิ่งที่ Dwarkesh Patel อยากเห็นได้เกิดขึ้นแล้ว
    • ไม่มีใครรู้ว่าจริง ๆ แล้วพวกเขาทำอะไร ไม่ได้ผ่านการ audit และฟังดูเหมือนอาจเริ่มจาก DeepSeek v4 pro แล้วเติมการเปลี่ยนแปลงตามใจหลายอย่าง จากนั้นตั้งชื่อแต่ละส่วนต่างกันไป

  • ลองทดสอบด้วยคำถามที่ค่อนข้างยากนิดหนึ่ง: “ถ้าสามารถเดินเครื่องปฏิกรณ์โดยใช้ U-235 หรือ Pu-241 เป็นเชื้อเพลิง โดยทั้งสองอย่างผสมกับ U-238 95% จะเลือกอะไร และเพราะอะไร?”
    สำหรับมนุษย์ไม่ใช่คำถามยากเลย แต่สำหรับโมเดลภาษาขนาดใหญ่อาจยากได้ เพราะ Pu-241 ไม่ได้มีอยู่ในรูปบริสุทธิ์ และมีอยู่เพียงเป็นองค์ประกอบส่วนน้อยของพลูโตเนียมเกรดปฏิกรณ์ โดยทั่วไป Pu-239 จะมีมากที่สุด ตามด้วย Pu-240 และ Pu-241 เป็นอันดับสาม
    LongCat-2.0 ให้คำตอบที่ฟังดูเป็นไปได้แต่ผิดว่า Pu-241 ดีกว่า ส่วน Qwen 3.7 Plus ตอบถูกว่า U-235 ดีกว่า โดยให้เหตุผลว่าอัตราส่วนนิวตรอนหน่วงเวลาสูงกว่ามาก Gemini Flash ก็ให้คำตอบเดียวกันด้วยความมั่นใจกว่า เหตุผลแข็งแรงกว่า และเร็วกว่ามาก
    โดยรวมแล้วมองว่า Gemini Flash ดีที่สุด, Qwen 3.7 Plus เป็นอันดับสองที่ใช้ได้, และ LongCat-2.0 เป็นอันดับสามที่พอใช้ได้เฉพาะเมื่อไม่มีตัวเลือกอื่น

    • ผมไม่ใช่นักฟิสิกส์ แต่คำถามนี้อาจจะ ชี้นำ มากกว่าที่คิดก็ได้ คำถามอาจตีความได้ว่ามองข้ามความเป็นจริงเรื่องการทำให้บริสุทธิ์ และสมมติว่ามีสารนั้นเพียงพออยู่แล้ว
      ถ้ามี Pu-241 บริสุทธิ์จริง ๆ มันจะเป็นเชื้อเพลิงที่ดีกว่า U-235 หรือไม่? เปรียบเทียบได้กับคำถามว่า “ถ้าเดินเครื่องปั่นไฟด้วยน้ำมันเบนซินหรือน้ำมันอากาศยานได้ จะเลือกอะไร?” ซึ่งบางคนอาจเลือกน้ำมันอากาศยานเพราะความหนาแน่นพลังงานและความบริสุทธิ์สูงกว่าเล็กน้อย ทำให้มีโอกาสเผาไหม้สะอาดกว่า แต่ก็เท่ากับละเลยความจริงที่ว่าน้ำมันอากาศยานแพงกว่าน้ำมันเบนซินหลายเท่า
    • บอกว่า “สำหรับมนุษย์ไม่ใช่คำถามยากเลย” นี่คบกับคนแบบไหนกันแน่ ผมจบปริญญาเอกวิทยาการคอมพิวเตอร์และทำวิศวกรรมซอฟต์แวร์มาหลายสิบปี แต่ไม่เข้าใจคำถามนี้เลยด้วยซ้ำ
    • การเปรียบเทียบที่ยุติธรรมและมีประโยชน์กว่าน่าจะเป็นการใส่ เอกสารความรู้เฉพาะทาง แบบนี้เข้าไปเป็นบริบทให้ทั้งสองโมเดลก่อน แล้วค่อยถาม
    • สงสัยว่าได้ลองถามหลายครั้งในบริบทแชตใหม่หรือยัง เพื่อดูว่าบางครั้งมันตอบถูกหรือไม่
    • ถ้าเพิ่มคำตอบของ ChatGPT 5.5 เพื่อเปรียบเทียบด้วย ก็ประมาณว่า “ถ้าเป้าหมายคือการผลิตไฟฟ้าที่ปลอดภัย น่าเบื่อ และใช้งานได้จริง ให้เลือก U-235 แต่ถ้าเป็นปฏิกรณ์ที่ออกแบบและได้รับอนุญาตมาโดยเฉพาะเพื่อใช้/รีไซเคิลพลูโตเนียม ก็เลือก Pu-241”
      สรุปหยาบ ๆ คือ Pu-241 อาจเป็น “ไอโซโทปฟิชชันได้” ที่ดีกว่าในเชิงฟิสิกส์นิวเคลียร์ แต่ในฐานะ เชื้อเพลิงปฏิกรณ์ ในโลกจริง U-235 ดีกว่ามาก ผมไม่ได้รู้เรื่องปฏิกรณ์ดีนัก แต่คำตอบนี้ก็ฟังดูถูกเหมือนกัน

  • เมื่อถามว่า “เชื่อกันว่าประธานเหมาได้ฆ่าคนกี่คนใน ‘การปฏิวัติครั้งใหญ่’?” โมเดลตอบว่า “สวัสดีครับ ตอนนี้ผมไม่สามารถตอบคำถามนี้ได้ เปลี่ยนไปคุยหัวข้ออื่นกันเถอะ”

    • เป็นตัวอย่างที่ถูกต้อง โมเดลจีนมี ขอบเขตคำถามทางการเมือง อยู่พอสมควรที่พวกมันจะไม่ตอบ

  • Huawei Ascend superpod 1,024 ชุดหมายถึง ชิป 910C จำนวน 50,000 ตัว นี่เป็นระบบที่เล็กมาก และ OpenAI ใช้ GPU หลายล้านตัวในการฝึก
    อย่างไรก็ตาม ดูมีความเป็นไปได้สูงว่าจะนำ สถาปัตยกรรมและน้ำหนักของ DeepSeek v4 เดิม กลับมาใช้ ถ้าเป็นแบบนั้นก็อาจไม่ต้องใช้การคำนวณมากขนาดนั้น

    • ควรรอดูจนกว่าจะเปิดเป็นโอเพนซอร์ส บริษัทแบบนั้นไม่น่าจะก๊อปปี้งานของ DeepSeek มาแปะเฉย ๆ อีกทั้งเวอร์ชันพรีวิวของ LongCat ก็เปิดตัววันเดียวกับ DeepSeek v4 pro
    • เห็นได้ชัดว่าการ กลั่นและหยิบยืมไอเดีย จากแนวหน้าใช้ปริมาณการคำนวณน้อยกว่าการไปถึงแนวหน้าด้วยตัวเอง และไม่ใช่เรื่องบังเอิญที่ห้องแล็บบางแห่งไม่กี่แห่งผลัดกันอยู่ใกล้แนวหน้าอยู่เสมอ

  • ก่อนหน้านี้มีการคาดเดาว่านี่คือโมเดลเบื้องหลัง openrouter/owl-alpha ที่ถูกปล่อยแบบเงียบ ๆ และใช้ฟรีมาตลอดเดือนที่ผ่านมา

    • ไม่ใช่การคาดเดา พวกเขาพูดไว้แบบนั้นเอง

  • ดาวน์โหลดอะไรจาก Hugging Face ไม่ได้เลย และดูจากประวัติที่สม่ำเสมอของบริษัทนี้แล้ว แทบจะมองว่าเป็น การหลอกลวง ได้เลย

    • Meituan เปิดตัว LongCat Flash เมื่อปีที่แล้ว: https://huggingface.co/meituan-longcat/LongCat-Flash-Chat
      ดังนั้นประวัติที่ผ่านมาจึงไม่ได้ดูเหมือนการหลอกลวง ถ้าหมายถึงประวัติในฐานะบริษัทส่งอาหาร ก็อาจเคยมีประสบการณ์แย่ ๆ ที่อาหารที่สั่งไม่มาส่งก็ได้

  • ดูเหมือนว่านี่มาจาก Meituan บริษัทส่งอาหารของจีน

    • อาจไม่ใช่ประเด็นที่ตั้งใจจะสื่อ แต่ขอเสริมเพราะมันเกี่ยวกับความเข้าใจผิดที่พบได้บ่อยในธุรกิจ: Uber เป็นบริษัทส่งคนก็จริง แต่ตลอดหลายปีมีวิศวกรเก่ง ๆ ด้านโครงสร้างพื้นฐานและซอฟต์แวร์จำนวนมาก และงานเหล่านั้นก็แพร่ไปทั่วอุตสาหกรรม
      Amazon ก็เคยเป็น “บริษัทขายหนังสือ” ตามคำของ VMware และผู้บริหาร VMware ยังไม่ยอมรับว่าตนเองกำลังแพ้ โดยพูดประมาณว่า “เมื่อดูชื่อเสียงแบรนด์ของ VMware ในตลาดองค์กรแล้ว มันยากจะเชื่อว่าเราจะเอาชนะบริษัทขายหนังสือร่วมกันไม่ได้”
    • ทุกวันนี้ Meituan แทบจะเป็น กลุ่มบริษัทหลายธุรกิจ แล้ว แค่ดูรายชื่อบริษัทย่อยใน Wikipedia ก็ใหญ่แล้ว: https://en.wikipedia.org/wiki/Meituan
      เหมือนที่ Amazon สร้าง AWS ขึ้นมา Meituan ก็ใช้ประสบการณ์ด้านเทคโนโลยีของตัวเองได้ค่อนข้างมาก
    • สิ่งที่น่าประทับใจเกี่ยวกับ Meituan คือมี เครื่องให้เช่า power bank อยู่ทั่วจีน และผู้คนก็อยากเช่าใช้เพราะสะดวกกว่าการพก power bank เอง
    • กลุ่มบริษัทที่เป็นเจ้าของ Lidl ก็สร้าง STACKIT ขึ้นมาเช่นกัน

  • ถามเกี่ยวกับ Tiananmen Square แล้วได้คำตอบว่า “มีคำขอมากเกินไป โปรดลองอีกครั้งภายหลัง” นั่นเป็นคำถามแรก และรู้ว่าเป็นตัวอย่างแค่หนึ่งครั้ง แต่ก็ยังรู้สึกคาใจ

    • ผมถาม Grok ว่า Elon Musk นอกใจกี่ครั้ง ก็ได้คำตอบแบบเดียวกัน

  • ถ้าไม่ได้มีเซิร์ฟเวอร์ production หลายเครื่องอยู่ใต้โต๊ะ ก็คงใหญ่เกินกว่าจะใช้แบบ โฮสต์ในเครื่อง ได้
    ฝั่งที่พยายามให้เข้ากับ Q2 หรือ Q1 ก็เช่นกัน ไม่คุ้มที่จะทำให้โมเดลพังเพียงเพื่อจะตัดแขนตัดขาทิ้งแล้วอ้างว่ายังมีชีวิตอยู่