วิธีรัน GLM-5.2 บนเครื่องโลคัล

 (unsloth.ai)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GLM-5.2 โมเดลโอเพนตัวใหม่จาก Z.ai มีจุดสำคัญอยู่ที่เป็นกรณีศึกษาของการใช้งานโมเดลขนาดใหญ่บนเครื่องโลคัล โดยมีพารามิเตอร์ 744B, พารามิเตอร์ที่ active 40B และ context window 1M
  • Unsloth เปิดทางให้รันบนเครื่องโลคัลด้วย Dynamic GGUF โดย quant ที่แนะนำคือ 2-bit UD-IQ2_M ซึ่งต้องใช้ดิสก์ 239GB และสภาพแวดล้อมระดับ RAM อย่างน้อย 245GB
  • Dynamic 1-bit แสดงผล top-1 accuracy ราว 76.2% พร้อมลดขนาดลง 86% ส่วน Dynamic 2-bit ได้ accuracy ราว 82% และลดขนาด 84% ซึ่งไม่ตรงกับการตีความว่า “เล็กลงเท่าไร ประสิทธิภาพก็แย่ลงเท่านั้น”
  • วิธีรันมี 2 แนวทางคือ Unsloth Studio และ llama.cpp โดย Studio รองรับการค้นหา·ดาวน์โหลด·รันโมเดลบน MacOS·Windows·Linux รวมถึง RAM offloading และการตรวจจับ multiGPU
  • หากต้องการใช้ long context จริง ๆ จำเป็นต้องลดการใช้หน่วยความจำด้วย KV cache quantization ของ llama.cpp โดย q4_0 ช่วยให้ใช้ context ได้ยาวขึ้นราว 3.5 เท่า และ q4_1 ราว 3.2 เท่า

ภาพรวมโมเดล GLM-5.2

  • GLM-5.2 เป็นโมเดลโอเพนตัวใหม่จาก Z.ai และสามารถรันบนฮาร์ดแวร์โลคัลได้ผ่าน Unsloth Dynamic GGUF
  • สเปกโมเดลมีดังนี้
    • พารามิเตอร์ทั้งหมด: 744B
    • พารามิเตอร์ที่ active: 40B
    • context window สูงสุด: 1,048,576
  • มีการแนะนำว่าให้ประสิทธิภาพระดับ SOTA ในงาน long-horizon coding, reasoning และ agentic tasks
  • ตามข้อมูลจาก Artificial Analysis และเบนช์มาร์กหลายชุด ระบุว่ามีประสิทธิภาพระดับเดียวกับ Claude 4.8 Opus, GPT-5.5, Gemini 3.1 Pro
  • Unsloth ระบุว่าได้รับ day-zero access จาก Z.ai
  • ไฟล์โมเดล GGUF สำหรับ GLM-5.2 ดาวน์โหลดได้จาก Hugging Face ที่ GLM-5.2-GGUF

quant ที่แนะนำและความต้องการด้านหน่วยความจำ

  • เพื่อให้สมดุลระหว่างการเข้าถึงได้ง่ายและความแม่นยำ จึงแนะนำให้ใช้ 2-bit dynamic quant คือ UD-IQ2_M
    • ใช้พื้นที่ดิสก์: 239GB
    • โหลดเข้า Mac ที่มี unified memory 256GB ได้โดยตรง
    • หากใช้ MoE offloading ระบุว่าสามารถทำงานได้ดีแม้มีเพียง GPU 1x24GB + RAM 256GB
  • 1-bit quant ใช้ RAM 223GB ส่วน 8-bit ต้องใช้ RAM 810GB
  • ในตารางความต้องการฮาร์ดแวร์สำหรับ inference หน่วยความจำรวมหมายถึง RAM + VRAM หรือ unified memory
    • ตัวเลขหน่วยความจำรวมที่ระบุไว้คือ 223GB, 245GB, 290–360GB, 372–475GB, 570GB, 810GB
  • หากต้องการประสิทธิภาพสูงสุด หน่วยความจำที่ใช้งานได้รวมกันของ VRAM และ system RAM ควรสูงกว่า ขนาดไฟล์โมเดลหลัง quantization อย่างชัดเจน

โหมด Thinking และการตั้งค่า sampling

  • GLM-5.2 มี thinking mode ให้เลือก 3 แบบ
    • non-thinking
    • thinking High
    • thinking Max
  • สำหรับงานซับซ้อน แนะนำให้ใช้ Max Thinking
  • ใน Unsloth Studio สามารถสลับ High/Max Thinking และ non-Thinking ได้จาก UI
  • การตั้งค่าสำหรับกรณีใช้งานส่วนใหญ่มีดังนี้
    • temperature = 1.0
    • top_p = 0.95
    • ในโหมดอื่นให้ใช้ top_p = 1.0
  • GLM-5.2 ใช้ reasoning เป็นค่าเริ่มต้น และสามารถเลือก reasoning_effort เป็น "high", "max" หรือปิดใช้งานได้
  • ตัวอย่างการปิด thinking มีดังนี้
    • เชลล์ทั่วไป: --chat-template-kwargs '{"enable_thinking":false}'
    • Windows PowerShell: --chat-template-kwargs "{\"enable_thinking\":false}"
  • ใน llama.cpp ก็สามารถใช้ --reasoning on หรือ --reasoning off ได้
  • ตัวอย่างการตั้งค่า reasoning effort มีดังนี้
    • --chat-template-kwargs '{"reasoning_effort":"max"}'
    • --chat-template-kwargs '{"reasoning_effort":"high"}'
    • --chat-template-kwargs '{"enable_thinking":false}'

การตีความความแม่นยำของ Dynamic GGUF และ KLD

  • Unsloth ใช้เบนช์มาร์ก KLD (KL Divergence) เพื่อประเมินความแม่นยำของ quantization ใน GLM-5.2-GGUF
  • Dynamic 4-bit UD-Q4_K_XL และ Dynamic 5-bit UD-Q5_K_XL ถูกระบุว่าโดยมากแทบจะ lossless
  • แม้เป็น quant ขนาดเล็กกว่า ก็ยังใช้วิธี จัดวางความละเอียดแบบไดนามิก โดยเลเยอร์สำคัญจะคง precision ที่สูงกว่า และเลเยอร์ที่สำคัญน้อยจะใช้บิตต่ำ
  • ตัวเลขตามเกณฑ์ pure top-1% accuracy มีดังนี้
    • Dynamic 1-bit: accuracy ราว 76.2%, ลดขนาด 86%
    • Dynamic 2-bit: accuracy ราว 82%, ลดขนาด 84%
    • เปรียบเทียบ accuracy: {b:76,82}
  • การที่เล็กลง 86% ไม่ได้หมายความว่าแย่ลง 86% และมีคำอธิบายเพิ่มว่า Dynamic 1-bit มีความแม่นยำต่ำกว่าโมเดลเต็มขนาด 1.5TB อยู่ราว 24%
  • คำว่า “76% accuracy” ไม่ได้หมายความว่าในคำถามอย่าง “The capital of France is” โมเดลจะเลือก Paris 76% และ Sydney 24%
    • ในตัวอย่างนี้ระบุว่า Paris จะยังเป็น 100% และ Sydney เป็น 0% เสมอ
    • ค่าตัวเลข 76% นี้รวมถึงความเปลี่ยนแปลงของการกระจายคำประเภท filler words และ stop words ทั้งคอร์ปัสด้วย
  • ในพรอมป์ต์อย่าง “Create a novel” ที่อาจมีจุดเริ่มต้นถูกต้องได้หลายแบบ การกระจายโทเค็นของโมเดล baseline กับโมเดล quantized อาจแตกต่างกัน
    • baseline อาจเลือก [I] ที่ 100% ขณะที่โมเดล quantized อาจกระจายเป็น [I] 76% และ [The] 24%
    • ตัวเลขนี้ไม่ได้หมายความว่ามีโอกาส 24% ที่จะได้ผลลัพธ์มั่วหรือผิดพลาด
  • KLD คือ ระยะห่าง ระหว่างความน่าจะเป็นของ baseline แบบ BF16 หรือ Q8_0 กับความน่าจะเป็นของเวอร์ชัน quantized
    • เป้าหมายของ quantization คือทำให้ค่า KL divergence เฉลี่ยระหว่าง f(q(W)) และ f(W) ต่ำที่สุด
    • f คือ language model forward, q คือ quantization operation, W คือพารามิเตอร์หรือ weights ของโมเดล
    • หาก KLD เป็น 0 แปลว่าสร้างโมเดลกลับได้สมบูรณ์แบบ
  • การรัน KLD กับคอร์ปัสฝึกทั้งหมดระดับ 15T tokens มีต้นทุนสูงมาก ดังนั้น Unsloth จึงใช้ mean KLD และการสุ่ม subset ตัวแทนขนาดเล็กเพื่อเพิ่มประสิทธิภาพ
  • ระบุว่าแม้ KLD 99.9% ก็ถือว่าดีโดยทั่วไป และตั้งแต่ 4bit ขึ้นไปจะได้ uplift มากกว่า ดังนั้นสำหรับงาน massive out-of-distribution นั้น Dynamic 4-bit น่าจะเหมาะที่สุด

การรันด้วย Unsloth Studio

  • Unsloth Studio เป็น open-source web UI สำหรับ local AI และรองรับการรัน GLM-5.2
  • ฟีเจอร์หลักมีดังนี้
    • รันโมเดลโลคัลบน MacOS, Windows, Linux
    • ค้นหา ดาวน์โหลด และรันโมเดล GGUF และ safetensor
    • ตรวจจับ RAM offloading และ multiGPU setup อัตโนมัติ
    • inference แบบ CPU + GPU ที่รวดเร็วผ่าน llama.cpp
  • คำสั่งติดตั้งมีดังนี้
  • คำสั่งรันมีดังนี้
    • unsloth studio -H 0.0.0.0 -p 8888
    • หลังรันแล้วให้เปิด http://127.0.0.1:8888 ในเบราว์เซอร์ หรือเปิด URL ที่ระบบสร้างให้ผู้ใช้
  • ยังมีวิธีรัน Studio แบบปลอดภัยผ่าน HTTPS ด้วย
    • บน Windows, Mac, Linux ใช้ unsloth studio --secure
    • ใช้ Cloudflare tunnel ฟรี
  • เมื่อเปิดครั้งแรก ต้องสร้าง password เพื่อความปลอดภัยของบัญชี และหลังจากนั้นต้อง sign in ใหม่
  • ในแท็บ Studio Chat ให้ค้นหา GLM-5.2 ในช่องค้นหา จากนั้นดาวน์โหลด model และ quant ที่ต้องการ
  • ก่อนรันโมเดลควรตรวจสอบว่ามี compute เพียงพอ
  • โดยปกติ Studio ควรตั้ง inference parameters ให้อัตโนมัติ แต่ผู้ใช้สามารถปรับ context length, chat template และค่าต่าง ๆ อื่นได้เอง
  • ข้อมูลเพิ่มเติมอยู่ที่ Unsloth Studio inference guide

การรันด้วย llama.cpp

  • ทุตอเรียล llama.cpp ครอบคลุมการรัน quant แบบ UD-IQ2_M และต้องใช้ RAM ขั้นต่ำ 245GB
  • ใช้ llama.cpp เพื่อทำ local inference ได้รวดเร็ว
  • หากไม่มี GPU หรืออยากรันแบบ CPU inference อย่างเดียว ให้เปลี่ยน -DGGML_CUDA=ON เป็น -DGGML_CUDA=OFF
  • สำหรับ Apple Mac / อุปกรณ์ Metal ให้ใช้ -DGGML_CUDA=OFF โดย Metal support เปิดใช้งานอยู่แล้วเป็นค่าเริ่มต้น
  • ขั้นตอนการ build มีลำดับดังนี้
    • apt-get update
    • apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
    • git clone https://github.com/ggml-org/llama.cpp
    • cmake ... -DGGML_CUDA=ON
    • cmake --build ... --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
    • cp llama.cpp/build/bin/llama-* llama.cpp
  • llama.cpp สามารถใช้โหลดและดาวน์โหลดโมเดลได้โดยตรง คล้าย ollama run
  • ตัวอย่างประเภท quantization ที่เลือกใช้คือ UD-IQ2_M และสามารถบังคับตำแหน่งจัดเก็บด้วย export LLAMA_CACHE="unsloth/GLM-5.2-GGUF"
  • มีคำแนะนำว่ากระบวนการดาวน์โหลดโดยตรงของ llama.cpp อาจช้ามาก จึงควรใช้วิธีดาวน์โหลดด้วยตนเองแทน

ตัวอย่างการดาวน์โหลดและรันแบบแมนนวล

  • สำหรับการดาวน์โหลดด้วยตนเองที่เร็วกว่า ให้ใช้ huggingface_hub
    • pip install huggingface_hub
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ2_M*"
  • หากต้องการแบบ near full precision สามารถใช้ --include "*UD-Q8_K_XL*"
  • หากการดาวน์โหลดค้าง มีคำแนะนำให้ดู Hugging Face Hub, XET debugging
  • คำสั่งดาวน์โหลด Dynamic 1-bit มีดังนี้
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ1_S*"
  • พาธโมเดลใน conversation mode มีดังนี้
    • 2-bit: unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • 1-bit: unsloth/GLM-5.2-GGUF/UD-IQ1_S/GLM-5.2-UD-IQ1_S-00001-of-00006.gguf
  • ตัวอย่างการรัน llama-cli กำหนด shard แรกของ 2-bit GGUF ผ่าน --model และใช้พารามิเตอร์ดังนี้
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
  • ในตัวอย่างการรันโดยตรงยังใช้ -hf unsloth/GLM-5.2-GGUF:UD-IQ2_M ได้ด้วย

พฤติกรรมที่ยืนยันจากตัวอย่างการสร้าง

  • ในเอกสารมีตัวอย่างที่ 2-bit GLM-5.2 ทำ tool-calling และสร้าง SVG ได้
  • หลังรัน llama-cli แล้วมีตัวอย่างการสั่งให้สร้าง “short Flappy Bird game”
  • เกม HTML/JavaScript ไฟล์เดียวที่สร้างขึ้นใช้ชื่อ Sunset Flier
    • มี canvas, หน้าจอเริ่มต้น, หน้าจอเกมโอเวอร์, HUD คะแนน, NEW BEST!, ปุ่ม RETRY
    • สร้างเสียงเอฟเฟกต์ flap, score, hit, die ผ่าน Web Audio API โดยไม่ใช้ไฟล์ภายนอก
    • สถานะเกมจัดการเป็น 4 ขั้นคือ READY, PLAYING, DYING, OVER
    • คะแนนสูงสุดถูกเก็บด้วย localStorage.getItem('sunsetFlierBest') และ localStorage.setItem()
  • ลอจิกเกมมีแรงโน้มถ่วง, flap impulse, ท่อสุ่ม, การชน, อนุภาค, การสั่นหน้าจอ และระบบเหรียญรางวัล
    • GRAVITY = 0.42
    • MAX_FALL = 9
    • PIPE_W = 68
    • PIPE_GAP = 180
    • PIPE_SPEED = 2.6
    • PIPE_SPACING = 220
  • อินพุตรองรับเมาส์, ทัช และคีย์บอร์ด Space, ArrowUp, Enter
  • ตัวอย่างเกมนี้ถูกยกมาในบริบทว่าแม้ใช้ 1-bit quantization ก็ยังทำงานได้ดีและเสียงก็ทำงานปกติ

long context และ KV cache quantization

  • หากต้องการใช้ long context ใน llama.cpp จำเป็นต้องลดการใช้หน่วยความจำด้วย KV cache quantization
  • ล่าสุด llama.cpp เพิ่มเทคนิคสำหรับ KV cache quantization เพื่อให้ได้ความแม่นยำสูงขึ้น โดย PR ที่เกี่ยวข้องคือ https://github.com/ggml-org/llama.cpp/pull/21038
  • dtype ของ KV cache ที่รองรับมีดังนี้
    • f32
    • f16
    • bf16
    • q8_0
    • q4_0
    • q4_1
    • iq4_nl
    • q5_0
    • q5_1
  • ค่าเริ่มต้นคือ f16
  • q4_0 ใช้ประมาณ 4.5 บิตต่อ weight จึงทำให้ความยาว context เพิ่มได้เป็น 16 / 4.5 หรือราว 3.5 เท่า
    • เช่น โมเดลที่เดิมรองรับ 10K อาจขยายไปอยู่ในช่วง 35K ได้
  • q4_1 มี shifting parameter เพิ่มเข้ามา จึงอาจให้ผลดีกว่า และด้วย 5 บิตต่อ weight ทำให้รองรับ context ยาวขึ้นราว 3.2 เท่า
  • ตัวอย่างการรัน KV cache quantization กำหนดโมเดล GLM-5.2 GGUF พร้อม sampling parameters ดังนี้
    • พาธโมเดล: unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
    • --cache-type-k q4_1
    • --cache-type-v q4_1

ตัวเลขที่ตรวจสอบได้จากตารางเบนช์มาร์ก

  • เอกสารมีตารางเบนช์มาร์กของ GLM-5.2 ต่อจากนี้ แต่ในข้อมูลที่ให้มาไม่มีหัวคอลัมน์ จึงไม่สามารถระบุได้ว่าตัวเลขแต่ละตัวสอดคล้องกับโมเดลหรือการตั้งค่าใด
  • เบนช์มาร์กด้าน Reasoning มีแถวและตัวเลขดังนี้
    • HLE: 40.5, 49.8*, 41.4*, 45, 31, 41.4, 37, 37.7
    • AIME 2026: 99.2, 95.7, 98.3, 98.2, 95.3, 97, -, 94.6
    • GPQA-Diamond: 91.2, 93.6, 93.6, 94.3, 86.2, 90, 93, 90.1
  • เบนช์มาร์กด้าน Coding มีแถวและตัวเลขดังนี้
    • SWE-bench Pro: 62.1, 69.2, 58.6, 54.2, 58.4, 60.6, 59, 55.4
    • NL2Repo: 48.9, 69.7, 50.7, 33.4, 42.7, 47.2, 42.1, 35.5
    • Terminal Bench 2.1 (Terminus-2): 81.0, 85, 84, 74, 63.5, 75, 65, 64
  • เบนช์มาร์กด้าน Agentic มีแถวและตัวเลขดังนี้
    • MCP-Atlas (Public Set): 76.8, 77.8, 75.3, 69.2, 71.8, 76.4, 74.2, 73.6
    • Tool-Decathlon: 48.2, 59.9, 55.6, 48.8, 40.7, -, -, 52.8

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

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

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

  • กำลังรัน Q4_K_XL อยู่ ถ้าจะให้ได้ราว 6tk/sec ก็ใช้ RAM 512GB กับ RTX 3090 สองใบ และ llama.cpp -cmoe ก็พอ
    ตอนนี้ยังติดที่ DDR4 2400MHz กาก ๆ เลยได้แค่นี้ แต่ถ้าเป็น 3200MHz ก็น่าจะขึ้นไปได้ประมาณ 9tk/sec CPU ก็เป็น EPYC 32 คอร์ ถือว่าโอเค แต่ถ้าได้ 64 คอร์ที่ดีกว่านี้ก็น่าจะไปถึง 11tk/sec ได้
    ตอนประกอบตั้งใจคุมงบก่อนที่ราคาฮาร์ดแวร์จะบ้าคลั่งไปกว่านี้ ทุกวันนี้ก็ยังเสียดายอยู่ แต่การที่สามารถรันโมเดลนี้ที่บ้านได้ก็ยอดเยี่ยมมาก เหมาะกับงานวางแผนหรือรวบรวมบริบทที่ต้องใช้ให้ครบก่อนโยนเป็น one-shot prompt
    ค่าเครื่องทั้งหมดตอนประกอบอยู่ที่ 2,400 ดอลลาร์ และถ้าหาข้อมูลกับเลือกของดี ๆ ก็ยังมีทางรันโมเดลระดับนี้ที่บ้านได้ คนชอบถามว่าทำไปทำไม หรือถ้าใช้ cloud API จะประหยัดกว่าแค่ไหน แต่ผมมองว่าเรื่อง Fable แสดงให้เห็นคุณค่าของการ รันใช้งานแบบอิสระ
    ขอบคุณทีม unsloth และ Q4_K_XL ก็ทำออกมาได้แข็งแรงดี ถ้าจะโหลดโมเดลแบบ quantized และเครื่องคุณพอรับไหว ก็ควรเลือก ตัวแปร K_XL

    • ขอชื่นชมคนที่ผลักขอบเขตความเป็นไปได้ด้วย การทดลองโฮมบรูว์ แบบนี้ แม้ AI จะถูกกลบด้วยเสียงรบกวนจากพ่อค้าหน้าเงินเหมือนคริปโต แต่แทบไม่มีใครพูดถึงเรื่องการสร้างความยืดหยุ่นทนทานเลย
      นักวิจัยที่พยายามยัดโอเพนซอร์สโมเดลลงไปในแปรงสีฟันไฟฟ้าหรือ Tamagotchi ก็เท่มากเหมือนกัน
    • ถ้ารันโหลดระดับนั้นต่อเนื่อง กินไฟอย่างน้อย 600W เท่ากับประมาณ 14kWh ต่อวัน ถ้าค่าไฟ 0.2 ดอลลาร์ต่อ kWh ก็วันละ 2.80 ดอลลาร์ หรือเฉพาะค่าไฟก็ราว 1,000 ดอลลาร์ต่อปี
      ถ้าไม่ได้ต้องการความเป็นส่วนตัวหรือความพอใจจากการเป็นเจ้าของเองจริง ๆ การจ่ายให้ hyperscaler จะถูกกว่า สะดวกกว่า และเร็วกว่าเยอะในแง่โทเคนต่อวินาที
      ถึงอย่างนั้นก็ชอบทิศทางนี้ และอยากเห็นว่าอีก 2 ปีฮาร์ดแวร์ self-hosted จะไปได้ไกลแค่ไหน
    • ผมมีชุดประกอบที่เกือบเหมือนกัน คือ RTX 3090 สองใบ, DDR4 512GB ที่เร็วกว่าเล็กน้อย และ EPYC 64 คอร์ [0]
      ใช้งานสนุกมาก และอยากลองรันโมเดลนี้เร็ว ๆ
      นอกจากรันโมเดลโลคัลแล้ว ยังใช้เครื่องนี้เป็นแพลตฟอร์มพัฒนาระยะไกลหลักด้วย ตอนนี้ทุก Claude Code session ของผมรันบนเครื่องนั้นผ่าน tmux หมดแล้ว
      ไม่ต้องจับโน้ตบุ๊กที่ร้อนตลอดเวลาอีกต่อไป นิ้วเลยมีความสุขขึ้นมาก และ Claude Code ก็กินแบตหนักจริงด้วย
      [0] https://medium.com/@rathko/i-built-an-epyc-64-core-512gb-ram...
    • คำพูดที่ว่า “ของที่ต้องใช้เพื่อรันมัน” อาจจะจริงถ้าซื้อมาได้ที่ 2,400 ดอลลาร์ แต่ตอนนี้ราคารวมจริง ๆ ใกล้ 10,000 ดอลลาร์ มากกว่าเยอะ
      แค่ RAM ก็เกือบ 5,000 ดอลลาร์แล้ว GPU ก็ราว ๆ ใบละ 2,000 ดอลลาร์ จึงนับว่าเป็นฮาร์ดแวร์ที่ค่อนข้างแพงในราคาปัจจุบัน
    • เท่าที่ผมเข้าใจ implementation ของ llama.cpp สำหรับโมเดลนี้ยังไม่รองรับ DSA sparse attention จึงยังค่อนข้างไม่สมบูรณ์
      นั่นทำให้ต้องใช้กลไกอื่นที่ไม่ได้ใช้ตอนเทรนมาเพื่อรันโมเดล และมีรายงานว่าคุณภาพกับประสิทธิภาพลดลง
      อย่างไรก็ตาม ผมคิดว่า GLM 5.2 ยังไม่น่าสนใจเท่าตระกูล DeepSeek V4 ในหลายด้าน DeepSeek V4 ใช้กลไก attention ที่ก้าวหน้ากว่า จึงประหยัดหน่วยความจำ KV cache ได้มากกว่า โดยเฉพาะกับบริบทยาว ๆ
      ผลคือสามารถรองรับ batch ขนาดใหญ่บนแพลตฟอร์มระดับผู้บริโภคได้ แต่ GLM ไม่มีตรงนี้ และในเชิงสถาปัตยกรรมพื้นฐานก็ให้ความรู้สึกคล้าย Kimi 2.6 โดยรวม ทั้งคู่หนักไปนิดสำหรับการรันเต็มคุณภาพบนฮาร์ดแวร์ทั่วไปอย่างสมเหตุสมผล

  • เกือบได้แล้ว เครื่องผมเป็น RAM 192GB + RTX 3090 24GB และแทบจะรันตัวนี้ได้อยู่แล้ว
    สำหรับ MoE offloading ดูเหมือนจะต้องใช้ VRAM 24GB กับ RAM 256GB
    https://unsloth.ai/docs/models/glm-5.2#usage-guide
    ในเธรดก่อนหน้านี้มีคนบอกว่าฮาร์ดแวร์ต้องใช้เงิน 500,000 ดอลลาร์
    https://news.ycombinator.com/item?id=48629970

    • 500,000 ดอลลาร์ นี่ประเมินสูงเกินจริงมาก ถ้าจะเอาคอนเคอร์เรนซีสูง ๆ บน FP8 หรือ BF16 ก็อาจใช่
      แต่ถ้าใช้ NVFP4 แล้วต้องการความเร็วพอใช้ได้ ประมาณ 120 tok/s พร้อมคอนเคอร์เรนซี ก็ทำได้ในช่วงราคา 80,000~90,000 ดอลลาร์ ตามราคาปัจจุบัน หรืออาจต่ำกว่านั้นด้วยซ้ำ
      เงินระดับนั้นซื้อ RTX 6000 PRO Blackwell ได้ 6 ใบ พร้อม CPU เมนบอร์ด และ PSU ที่ดีพอ โดยจะมี VRAM รวม 576GB
      ถ้ารับได้กับ decode 40 tok/s และ prefill ราว 1200 tok/s ก็อาจทำได้ต่ำกว่า 50,000 ดอลลาร์
    • ที่ 2 บิตคงยากจะได้ผลลัพธ์ดี ๆ สำหรับงานเขียนโค้ด ช่วงที่เหมาะจริง ๆ ควรอย่างน้อย Q8
    • ผมหวังว่ากระแสครั้งนี้จะจุดการพัฒนา ฮาร์ดแวร์คอมพิวติ้ง แบบยุค 90s กลับมาอีกครั้ง
      หนึ่งในเหตุผลที่ฮาร์ดแวร์ค่อนข้างนิ่งในช่วง 20 ปีที่ผ่านมา น่าจะเป็นเพราะองค์กรต่าง ๆ ไม่มี use case มากพอจะอธิบายการเปลี่ยนฮาร์ดแวร์
      ในช่วง 15 ปีที่ผ่านมา เงินและพลังงานส่วนใหญ่เทไปที่มือถือ
      inference แบบโลคัลที่ราคาถูกอาจกลายเป็นแหล่งรายได้ที่ผู้ผลิตเซิร์ฟเวอร์ เดสก์ท็อป และโน้ตบุ๊กต้องการเพื่อเริ่มขยับตัวอีกครั้ง
    • มี RAM แต่ไม่มี VRAM ถ้าใช้ 3090 ที่มี RAM 24GB ควรคาดหวังความเร็วหรือ tok/s ประมาณไหน?
      แอบอยากลองซื้อ GPU ที่มี RAM 24GB มาสักตัวเหมือนกัน
    • ลองถาม Gemini ขำ ๆ แล้วมันตอบว่าถ้าจะให้ได้ throughput ดีแบบไม่ quantize ต้องใช้ 500,000 ดอลลาร์

  • คำว่า “ใส่ได้” หมายถึงใส่ใน RAM 256GB ได้ แต่จะอยู่ในสภาพที่ถูก quantize หนักมาก และก็ยังรันได้ช้ามากอยู่ดี
    ตัวเลขในพาดหัวไม่ใช่ความเร็วในการสร้างโทเคน แต่เป็น ความเร็วในการประมวลผลพรอมป์ต์
    ถ้าได้ 10 tok/s และ API ได้ 20~30 tok/s ภายนอกอาจดูเหมือนไม่ได้แย่นัก แต่ Mac Studio หรือเครื่องที่ไม่ได้เอาทั้งหมดขึ้น GPU จะประมวลผลพรอมป์ต์ช้ากว่าชุดที่เป็น GPU ล้วน 20~50 เท่า
    สุดท้ายประเด็นนี้เองที่ทำให้ใช้งานจริงไม่ได้ถ้าไม่จ่าย 50,000 ดอลลาร์ ไปกับ GPU แถมก็ยังต้องใช้โมเดลที่ถูก quantize หนักอยู่ดี

    • อุปกรณ์อย่าง Nvidia Spark มี หน่วยความจำรวม 128GB
      ยังมีรุ่นพอร์ตคู่สำหรับอุปกรณ์แบบนี้ด้วย: https://www.nvidia.com/content/dam/en-zz/Solutions/networkin...
      นั่นคือพอร์ต 2 x 100GB/s และอาจจะเป็น 2 x 200GB/s ก็ได้ คงต้องรู้มากขึ้นถ้าได้ของมาลองเอง
      อุปกรณ์พวกนี้สามารถทำคลัสเตอร์ได้ด้วย ถ้า 2 หรือ 3 เครื่อง การใช้ IP subnet 2 ชุดก็ดูค่อนข้างชัดเจน ถ้า 4 เครื่องขึ้นไปอาจต้องมีสวิตช์ ขึ้นอยู่กับว่า network latency จะมีผลมากแค่ไหน
      ดูเหมือน Apple จะลืม M series ที่ใส่ RAM เยอะ ๆ ไปแล้ว หาแบบที่มีหน่วยความจำรวมเกิน 96GB ใน Apple Store ไม่เจอเลย และต่อให้มี ราคาก็ระดับขายไต

  • ตอนนี้กำลังเร่งกันจากหลายทิศทาง: AI desktop รุ่นใหม่ที่ใช้ GB10 มีราคาค่อนข้างจับต้องได้ และสามารถทำคลัสเตอร์ให้ได้ VRAM 1TB
    Nvidia, AMD, Intel, Cerebras และรายอื่น ๆ กำลังดันฮาร์ดแวร์ใหม่ ขณะที่โมเดลโอเพนซอร์สอย่าง GLM 5.2 ก็ดีขึ้นแบบเหลือเชื่อ
    โมเดลแฟลชอย่าง DeepSeek V4 Flash ก็พัฒนาขึ้นมาก และ quantization ก็ยังดีขึ้นเรื่อย ๆ
    เริ่มมีความเป็นไปได้ที่จะทำ harness ที่ใช้โมเดลต่างกัน เช่น โมเดลใหญ่ไว้ทำงานยาก โมเดลเล็กไว้ทำงานจุกจิก
    ดังนั้นคนที่อยากหลุดจาก API ก็น่าจะหวังได้ว่าอีกไม่นานจะโฮสต์ AI desktop cluster ราคาสมเหตุสมผลไว้ที่บ้านและได้ ประสิทธิภาพระดับ Opus

    • คำว่า “ค่อนข้าง” ตรงนี้ทำงานหนักมาก ถ้า GB10 เครื่องหนึ่งราคาราว 4,000 ดอลลาร์ คลัสเตอร์ 1TB ก็จะเป็น 36,000 ดอลลาร์
      แม้จะถูกกว่า H200 ระดับใกล้เคียง แต่สำหรับโฮมแล็บที่ไม่ได้มีเงินจาก OpenAI หรือ Anthropic RSU หนุนหลัง ก็ยังไกลเกินเอื้อมอยู่ดี

  • รู้สึกเหมือน ช่องว่างกำลังแคบลง จนถึงระดับที่รันโมเดลโลคัลที่ดีพอได้ แม้กระทั่งงานเขียนโค้ด และดูเหมือนบางบริษัทน่าจะเริ่มกังวล หรือผมคิดผิด?

    • ถ้าไม่ติดปัญหา RAM/GPU ไม่พอ ตอนนี้บริษัทพวกนั้นคงกังวลกว่านี้มาก
      แต่ ณ ตอนนี้ คนที่สามารถจ่ายค่าอุปกรณ์สำหรับรันโมเดลพวกนี้ได้อย่างมีประสิทธิภาพยังมีน้อยมาก และอีกหลายปีก็คงไม่เปลี่ยนมากนัก
      ถ้า Z.ai ออกรุ่นอย่าง GLM-5.2 Flash ที่เน้นงานโค้ดในขนาดราว 80B พารามิเตอร์ แล็บชั้นแนวหน้าในสหรัฐน่าจะกังวลมากขึ้น
      โดยรวมแล้ว บริษัท AI ของจีนกำลังแสดงให้เห็นว่าทำงานแบบเดียวกันได้ด้วยทรัพยากรน้อยกว่า บางครั้งน้อยกว่ามาก และถ้าแนวโน้มนี้ยังต่อเนื่อง ก็จะทำให้แล็บชั้นแนวหน้ากังวล
      อย่างไรก็ตาม บริษัท AI จีนเองก็คงพยายามปกป้องคูเมืองของตัวเอง โดยไม่ปล่อยโมเดลที่เล็กกว่ามากแต่ยังทรงพลังเมื่อเทียบกับโมเดลหลักในปัจจุบัน
      ตอนนี้ Alibaba Qwen ดูเหมือนจะอยู่ในจุดนั้น ช่วงหลังค่อนข้างเงียบ และโมเดล 395B ล่าสุดก็ใหญ่เกินกว่าที่คนส่วนใหญ่จะรันที่บ้านได้ คราวนี้ก็ยังไม่เห็นสัญญาณว่าจะออกโมเดลที่เล็กลง
    • ผมว่าใช่เลย นึกภาพได้ไม่ยากว่าบริษัทจะตัดสินใจโฮสต์และรันโมเดลแบบนี้ไว้ใช้ภายในสำหรับงานพัฒนาเอง
      ถ้าทีมพัฒนามีสัก 10 คน การลงทุนครั้งเดียว 50,000 ดอลลาร์กับเซิร์ฟเวอร์ LLM อาจเป็นตัวเลือกที่น่าสนใจมาก
      ได้โทเคนไม่จำกัด ประสิทธิภาพโอเค มีทางเลือกในการอัปเกรด และมีโอกาสในการผสานเข้ากับผลิตภัณฑ์
      โดยทั่วไป ถ้าเป็นบริษัทที่คิดจะใส่ LLM เข้าไปในผลิตภัณฑ์ วิธีใช้ LLM แบบโลคัลยิ่งน่าดึงดูดเข้าไปอีก โมเดลที่อาจจะดูทึ่มหน่อยก็ยังดีพอสำหรับหลายกรณีการใช้งานที่คนเอาไปฝังในผลิตภัณฑ์
    • จะเป็นภัยคุกคามก็ไม่จำเป็นต้องรันในเครื่องโลคัลด้วยซ้ำ หลายบริษัทกำลังมองแนวทางจ่ายเงินให้ผู้ให้บริการภายนอกที่โฮสต์โมเดลพวกนี้ให้ ซึ่งมีราคาเพียง เศษเสี้ยวหนึ่งของแล็บชั้นแนวหน้า
    • ความต้องการ RAM ยังเจ็บปวดอยู่มาก
    • การรันโลคัลไม่คุ้มในเชิงเศรษฐศาสตร์ มันยอดเยี่ยมในแง่ความเป็นส่วนตัวและเป็นงานอดิเรกที่สนุก
      แต่ตัวเลือกมีแค่บิลด์ CPU ที่ช้ามหาศาลพร้อม RAM มูลค่า 10,000 ดอลลาร์, หรือ GPU มูลค่า 90,000 ดอลลาร์, หรือไม่ก็โมเดลที่ถูก quantize หนักจนเทียบคุณภาพได้ยาก
      จะประกอบไว้เล่นสนุกสักชุดก็ได้ แต่แค่นั้นไม่ได้ทำให้ความคุ้มค่าเปลี่ยนไป ถึงอย่างนั้น แค่รู้ว่าทำได้ก็ยังน่าสนใจ

  • OpenAI และ Anthropic น่าจะไม่ชอบ จังหวะเวลาที่ GLM 5.2 เปิดตัว
    มันแสดงให้เห็นค่อนข้างชัดว่าไม่ได้มีคูเมืองวิเศษอะไร แค่ได้เปรียบจากการออกตัวก่อนเท่านั้น

  • ใช้ Mac Studio RAM 192GB ได้ แต่ก็ยังต่ำกว่าค่า RAM ขั้นต่ำที่ระบุไว้
    โดยเฉพาะเพราะมันเป็น MoE ถ้าสลับไปใช้ดิสก์เร็ว ๆ จะพอทำให้มันรันได้ไหม?

    • ถ้าสว็อปหนักขนาดนั้น ก็ดูเป็นวิธีชั้นดีในการเผาอายุการเขียนรวม (TBW) ของ NVMe SSD จนทำให้อายุใช้งานสั้นลงอย่างมาก
      แถมประสิทธิภาพก็น่าจะเละเทะระดับ 0.1 tok/s

  • ผมเคารพ unsloth มากกับงานที่ช่วยให้คนนับล้านเริ่มใช้ AI แบบโลคัลได้ แต่โพสต์นี้ดูคล้าย bait ให้ดาวน์โหลด นิด ๆ
    ถ้า offload layer ไป CPU มากเกินไป มันจะใช้งานได้ไม่ดีเลย ผมลองมาหลายรอบแล้ว สุดท้ายก็ต้อง rm -rf โฟลเดอร์ Hugging Face cache หนัก ๆ ทิ้ง
    ผมยังสงสัยด้วยว่าการรัน quantization 1-bit หรือ 2-bit ของ GLM 5.2 โดยที่ส่วนใหญ่ไม่ได้อยู่ใน VRAM จะมีประโยชน์กว่าการรัน Qwen3.6-27B Q8_0 ที่ลง VRAM ได้ครบทั้งโมเดลหรือไม่

  • ไม่ว่าบทความจะเขียนว่าอะไร คนที่พยายามรันสิ่งนี้บนเครื่อง RAM 256GB ก็น่าจะไม่ได้มีช่วงเวลาที่ดีนัก
    ขั้นต่ำที่สมจริงกว่าน่าจะเป็น 512GB
    โชคดีที่ผมมีเวิร์กสเตชัน dual Xeon พร้อม RAM 512GB อยู่ 2 เครื่องในโฮมออฟฟิศ ซื้อมาได้ถูกก่อนราคาจะขึ้น เลยพอจะลองอะไรได้หลายอย่าง