Show HN: รัน GLM 5.2 บนคอมพิวเตอร์ช้าๆ

 (github.com/JustVugg)
2 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • colibrì เป็นเอนจิน C ล้วนที่สร้างมาเพื่อรัน GLM-5.2 744B MoE บนเครื่องคอนซูเมอร์ที่มี RAM ราว 25GB โดยสตรีม routed expert จากดิสก์และทำงานได้โดยไม่ต้องใช้ GPU
  • โครงสร้างหลักคือเก็บส่วน dense ราว 17B พารามิเตอร์ไว้ใน RAM แบบ int4 ใช้ 9.9GB ส่วน routed expert จำนวน 21,504 ตัวจะอยู่บนดิสก์ราว 370GB และอ่านเมื่อจำเป็น
  • การติดตั้งประกอบด้วย GLM-5.2 forward, MLA attention และ compressed KV-cache, router สไตล์ DeepSeek-V3, MTP speculative decoding, เคอร์เนล quantization แบบ int8/int4/int2 และ byte-level BPE tokenizer
  • ในสภาพแวดล้อม WSL2 12 คอร์ · RAM 25GB · NVMe VHDX ใช้เวลาโหลดราว 30 วินาที, peak RSS ระหว่างแชตอยู่ราว 20GB, และ cold decode มีการอ่านดิสก์ราว 11GB ต่อโทเค็น ทำความเร็วได้ประมาณ 0.05~0.1 tok/s
  • บนเครื่องที่มี NVMe เร็วกว่าและ RAM มากกว่า cache กับ pinning มีความสำคัญมาก และจากการวัดของชุมชนจริง Apple M5 Max 128GB ทำได้ 1.06 tok/s เมื่อปิด MTP

ปัญหาที่ colibrì พยายามแก้

  • colibrì ใช้สโลแกนว่า “Tiny engine, immense model” และเป็นเอนจินที่รันโมเดล GLM-5.2 744B-parameter MoE บนเครื่องคอนซูเมอร์ที่มี RAM ราว 25GB
  • runtime เป็น C ล้วน และไม่มี dependency กับ Python, BLAS หรือ GPU
  • เอนจินประกอบด้วยไฟล์ C เดียว c/glm.c ราว 1,300 บรรทัด พร้อมไฟล์ header ขนาดเล็กไม่กี่ตัว
  • ตัวอย่างการรันคือ ./coli chat โดยตัวอย่างผลลัพธ์แสดง colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU พร้อมเวลาเตรียมราว 32 วินาที และ resident memory 9.9GB

วิธีรัน MoE แบบสตรีมจากดิสก์

  • โมเดล 744B Mixture-of-Experts ของ GLM-5.2 จะเปิดใช้งานพารามิเตอร์เพียงประมาณ 40B ต่อโทเค็น
  • routed expert ที่เปลี่ยนไปทุกโทเค็นมีขนาดประมาณ 11GB
  • ส่วน dense จะอยู่ใน RAM ตลอด
    • รวม attention, shared experts, embeddings
    • ประมาณ 17B พารามิเตอร์
    • ใช้ RAM ราว 9.9GB ในแบบ int4
  • routed expert จะเก็บไว้บนดิสก์
    • 75 MoE layer × 256 experts รวม MTP head
    • มี 21,504 routed experts ทั้งหมด
    • แต่ละ expert มีขนาดราว 19MB ในแบบ int4
    • ใช้พื้นที่ดิสก์รวมประมาณ 370GB
  • การโหลด expert ใช้ per-layer LRU cache, optional pinned hot-store และ OS page cache

ฟีเจอร์หลักที่ติดตั้งแล้ว

  • GLM-5.2 forward ถูกติดตั้งตามโครงสร้าง glm_moe_dsa และตรวจสอบความถูกต้องแบบ token-exact เทียบกับ transformers oracle
    • teacher-forcing 32/32 บนโมเดล tiny-random
    • greedy generation 20/20
  • MLA attention มี q/kv-LoRA และ interleaved partial RoPE
    • compressed KV-cache ใช้ 576 floats ต่อโทเค็น
    • เล็กกว่าค่าเดิม 32,768 floats/token ถึง 57 เท่า
    • GLM-5.2 มี 64 heads และไม่มี GQA
  • มีการติดตั้ง sigmoid router แบบ DeepSeek-V3
    • noaux_tc
    • routed_scaling_factor
    • shared expert
    • first-3-dense layers
  • Native MTP speculative decoding ใช้ multi-token-prediction head ของ GLM-5.2 (layer 78) สร้าง draft token แล้วให้โมเดลหลักตรวจสอบด้วย batched forward
    • MTP head ต้องเป็น int8
    • ถ้าเป็น int4 ค่า draft acceptance จะลดลงเหลือ 0~4% ทำให้ speculation ใช้งานไม่ได้
    • ถ้าเป็น int8 วัด acceptance ได้ 39~59% และ 2.2~2.8 tokens/forward
    • ระหว่าง sampling ก็ยังคงเป็นแบบ lossless ผ่าน rejection sampling
    • ใน cold cache draft ที่ผ่านการตรวจสอบอาจ route ไปยัง expert เพิ่ม ทำให้ expert-loads/token เพิ่มจากประมาณ 660 เป็นประมาณ 1100
    • ในกรณีนี้ก่อนที่ cache และ pin จะ warm-up เสร็จ อาจใช้เวลานานขึ้น จึงมี adaptive guard และตัวเลือก DRAFT=0
  • True sampling รองรับ temperature และ nucleus
    • ค่าเริ่มต้นคือ 0.7 / 0.90
    • มีคำอธิบายว่าค่าทางการ 1.0 / 0.95 จะไปสุ่ม quantization noise ในส่วน tail บนสภาพแวดล้อม int4
  • integer-dot kernel ใช้ activations แบบ int8 สไตล์ Q8_0 และ AVX2 maddubs
    • int8 matmul เร็วขึ้น 1.4~2.5 เท่า
    • วัดประสิทธิภาพได้ 119 GFLOP/s
    • int4 เร็วขึ้น 1.8 เท่าเมื่อทำเป็น batch
    • แต่ int4 แบบ single-row ช้ากว่าในการวัดจริง จึงคงไว้เป็น f32
  • MLA weight absorption หลีกเลี่ยงการสร้าง k/v ต่อโทเค็นใหม่ในช่วง decode
    • query จะดูดซับ kv_b และ context จะถูก project หลัง attention
    • แม้ในสภาพแวดล้อม forced absorption ก็ยังตรวจสอบได้ 32/32 สำหรับ TF และ 20/20 สำหรับ generation
  • expert readahead จะอ่านบล็อก expert ถัดไปด้วย WILLNEED ระหว่างคูณ expert block ปัจจุบัน
  • เคอร์เนล quantization รองรับ int8, packed int4, packed int2, per-row scales, AVX2 และ dequant-on-use
  • DSA sparse attention ยังอยู่ระหว่างพัฒนา
    • lightning-indexer weights อยู่ในรูปการดึงออกมาราว 108GB จาก FP8 repo
    • indexer forward เป็นขั้นตอนถัดไป
    • จนกว่าจะถึงตอนนั้น attention จะเป็นแบบ dense และ exact เมื่อ context ≤ 2048 tokens
  • ใน prefill และ MTP verification มี Batch-union MoE ที่อ่าน unique expert ของ batch เพียงครั้งเดียว แล้วนำไปใช้กับทุกตำแหน่งที่ route ไปยัง expert นั้น
  • tokenizer เป็น byte-level BPE tokenizer ที่เขียนด้วย C ใช้ Unicode-property regex สไตล์ GPT-2 และ 320k merges
  • กลไกความปลอดภัยด้าน RAM จะปรับขนาด expert cache อัตโนมัติตอนเริ่มต้นตาม MemAvailable
    • คำนึงถึง peak projection ของ working set, KV, MTP row และ reconstruction buffer
    • ออกแบบมาเพื่อไม่ให้ kernel OOM-killer ทำงาน
  • offline converter มีให้ใน c/convert_fp8_to_int4.py
    • ดาวน์โหลด GLM-5.2 FP8 shard ทีละชิ้น
    • dequant ด้วย 128×128 block scales แล้ว requantize เป็น engine container
    • ลบ shard ไปเรื่อยๆ ระหว่างทำงาน จึงไม่จำเป็นต้องมี FP8 checkpoint ขนาด 756GB อยู่บนดิสก์พร้อมกันทั้งหมด
    • รองรับการแปลงต่อจากจุดเดิม

ประสิทธิภาพพื้นฐานที่วัดได้และข้อจำกัด

  • สภาพแวดล้อมพัฒนาคือ WSL2, 12 คอร์, RAM 25GB, NVMe ผ่าน VHDX
  • ค่าที่วัดได้มีดังนี้
    • ขนาดโมเดล int4 container: ประมาณ 370GB
    • resident RAM: 9.9GB
    • load time: ประมาณ 30 วินาที
    • peak RSS ระหว่างแชต: ประมาณ 20GB, ถูกจำกัดอัตโนมัติ
    • ต้นทุน cold decode: อ่านดิสก์ประมาณ 11GB ต่อโทเค็น
    • เพดาน random disk ของ VHDX: ประมาณ 1GB/s
    • ความเร็ว cold decode: ประมาณ 0.05~0.1 tok/s
    • MTP speculation: 2.2~2.8 tok/forward เมื่อใช้ int8 head
  • มีการระบุชัดว่าไม่ใช่ระบบที่เร็ว และอธิบายว่า warm cache, pinned hot experts และ MTP ช่วยลด useful-response latency ได้
  • มีข้อควรระวังเกี่ยวกับ SSD สองข้อ
    • การสตรีมของ colibrì เป็นแบบ read-only จึงไม่ได้ส่งผลต่อการสึกหรอของ SSD อย่างมีนัยสำคัญจากการอ่านเพียงอย่างเดียว
    • หาก RAM ไม่พอจนเกิด swap traffic จะมีการเขียนและอาจทำให้ไดรฟ์สึกหรอ
    • การอ่านเต็ม duty cycle เป็นเวลานานอาจทำให้ไดรฟ์ราคาประหยัดร้อน จึงควรมีการติดตามอุณหภูมิและสุขภาพไดรฟ์

การดาวน์โหลดและรันโมเดล

  • มีโมเดล GLM-5.2 int4 ที่แปลงไว้ล่วงหน้าบน Hugging Face
  • หากใช้โมเดลที่แปลงไว้แล้ว จะข้ามขั้นตอนแปลง FP8 → int4 ได้
  • การรันกำหนด COLI_MODEL ให้ชี้ไปยังไดเรกทอรีของโมเดล
COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat
  • quick start ใช้ ./setup.sh ในไดเรกทอรี c เพื่อตรวจสอบ gcc/OpenMP, build และรัน self-test
  • หากต้องการแปลงเอง ให้ใช้ ./coli convert --model /nvme/glm52_i4
    • ต้องมีพาธ ext4/NVMe ที่มีพื้นที่ว่างประมาณ 400GB
    • การแปลงต้องใช้ Python และ torch, safetensors, huggingface_hub, numpy
    • แต่ runtime engine เองเป็น C ล้วน โดย Python ใช้เฉพาะกับ converter แบบครั้งเดียว
  • ตัวเลือกที่มีประโยชน์มีดังนี้
    • --temp T: sampling temperature, ค่าเริ่มต้น 0.7 และ nucleus 0.90, ค่า 0 คือ greedy
    • --topp 0.7: adaptive expert top-p ลดการใช้ดิสก์ลง 30~40%
    • --ngen N: จำนวนโทเค็นสูงสุดต่อคำตอบ
    • AUTOPIN=0: ปิด learning cache auto-pin
    • THINK=1: เปิด reasoning block ของ GLM-5.2
    • DRAFT=n: ความลึกของ MTP draft
    • TF=1: ตรวจสอบแบบ teacher-forcing

Learning cache และความคาดหวังตามฮาร์ดแวร์

  • Learning cache จะบันทึก expert ที่ถูก route จริงระหว่างใช้งานไว้ที่ .coli_usage ข้างโมเดล
  • ตอนเริ่มต้นจะ pin expert ที่ hot ที่สุดลงใน RAM ส่วนเกินโดยอัตโนมัติ
  • คำอธิบายโครงการระบุว่า colibrì จะเร็วขึ้นตามปริมาณการใช้งานที่สะสม
  • สภาพแวดล้อมที่ต้องการคือ Linux หรือ WSL2, gcc ที่รองรับ OpenMP, AVX2, RAM อย่างน้อย 16GB และ local NVMe ที่มีโมเดล int4 ขนาดประมาณ 370GB
    • แนะนำพาธแบบ ext4
    • แนะนำว่าไม่ควรใช้ network/9p mount
  • ลำดับการทดสอบคือ build และ self-test, วัดดิสก์ด้วย iobench, ตรวจสอบ tok/s · expert hit-rate · RSS ระหว่างแชต, บันทึกการใช้งาน expert แล้วทำ pinning และรัน quality benchmark
  • ค่าคาดการณ์ตามฮาร์ดแวร์เป็นเพียงการประเมิน ไม่ใช่ค่าที่วัดจริง
    • เครื่องพัฒนา WSL2 VHDX, ประมาณ 1GB/s, RAM 25GB: 0.05~0.1 tok/s แบบ cold
    • native Linux, PCIe4 NVMe random 3~5GB/s, 32GB: 0.5~1 tok/s
    • PCIe5 NVMe หรือ 2×NVMe RAID0 8~12GB/s, 64GB, PIN ประมาณ 40GB: 2~4 tok/s
    • RAM 128~256GB, 12 คอร์, cached hot experts: 2~4 tok/s
    • RAM เท่าเดิมแต่ 24~32 คอร์ หรือเคอร์เนล AVX-512/VNNI: 5~15 tok/s

เบนช์มาร์กจากชุมชน

  • ในสภาพแวดล้อม Intel Core Ultra 7 270K Plus, 24 threads, WSL2, RAM 24GB, NVMe VHDX ค่าตั้งต้นทำได้ 0.07 tok/s
    • disk iobench: 1.96GB/s buffered, 2.74GB/s O_DIRECT
    • expert hit: 3~4%
    • RSS: 14.1GB
  • ในสภาพแวดล้อมเดียวกัน --topp 0.7 ทำได้ 0.11 tok/s
    • expert hit: 11%
    • RSS: 14.7GB
    • ความเร็ว end-to-end เพิ่มขึ้น 1.6 เท่า
  • Apple M5 Max, 18 cores, macOS, unified memory 128GB, internal SSD ทำได้ 1.06 tok/s
    • disk iobench: 14.2GB/s O_DIRECT
    • default, ปิด MTP
    • expert hit: 23%
    • RSS: 21.8GB
  • บนเครื่อง RAM 24GB expert cache จะถูก auto-cap เหลือ 2 slot ต่อ layer ทำให้ถึงแม้ดิสก์จะเร็วกว่าเครื่องพัฒนา 2~2.7 เท่า decode ก็ยังอยู่ในสถานะ cold
  • บนเครื่อง RAM น้อย คอขวดคือ RAM cap มากกว่าดิสก์
  • ค่าที่วัดบน M5 Max เป็นกรณีตัวอย่างที่โมเดล 744B ทำความเร็วราว 1 tok/s บน SSD ของแล็ปท็อป และดิสก์ 14GB/s ทำให้คอขวดย้ายกลับไปที่งบ RAM และเคอร์เนล

quality benchmark และการวัดที่ยังเหลือ

  • ต้นทุนด้านความแม่นยำจาก quantization แบบ int4 ยังไม่ได้วัด
  • มีการติดตั้ง benchmark harness แล้ว แต่บนเครื่องพัฒนาที่มีดิสก์ราว 1GB/s การรันทั้งหมดจะกินเวลาแทบทั้งวัน
  • คำสั่ง benchmark ที่มีให้จะรัน hellaswag, arc_challenge, mmlu
cd c
./coli bench
./coli bench hellaswag --limit 200
./coli bench mmlu arc_challenge --ram 100
  • ผลลัพธ์เป็น accuracy แยกตาม task และใช้ log-likelihood scoring กับรูปแบบสไตล์ EleutherAI-harness
  • มีการระบุว่าคะแนน public ของ GLM-5.2 แบบ full-precision อยู่ราว 85~95% บน task เหล่านั้น
  • หาก int4 container อยู่ห่างเพียงไม่กี่คะแนน ก็ถือว่า quantization ผ่านการตรวจสอบ แต่หากไม่ใช่ ก็จะเป็นเหตุผลให้ลงทุนกับ mixed หรือ grouped-scale quantization

โครงสร้าง repository และไลเซนส์

  • ไฟล์หลักมีดังนี้
    • c/glm.c: เอนจินที่รวม GLM-5.2 forward, streaming MoE, MTP และ serve mode
    • c/st.h: safetensors reader ที่ใช้ pread และ fadvise, ไม่ใช้ mmap
    • c/tok.h: C byte-level BPE tokenizer
    • c/coli: CLI สำหรับ chat, run, bench, convert, info
    • c/iobench.c: parallel disk microbenchmark ที่สะท้อนสิ่งที่เอนจินเจอจริง
    • c/convert_fp8_to_int4.py: converter แบบ disk-safe สำหรับ FP8 → int4
    • c/make_glm_oracle.py: ตัวสร้าง tiny-random oracle สำหรับ validation
    • c/olmoe.c: Stage-A engine และเป็น validation target แรก
  • ชื่อ colibrì มาจากนกฮัมมิงเบิร์ดที่มีน้ำหนักน้อย บินนิ่งกลางอากาศได้ และแวะดอกไม้ได้มากในหนึ่งวัน
  • โครงการใช้ไลเซนส์ Apache 2.0 และ weights ของ GLM-5.2 ถูกเผยแพร่โดย Z.ai ภายใต้ MIT

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

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

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

  • สิ่งที่อยากรู้ที่สุดคือเวลาใช้งานจริงจะอยู่ในระดับที่วัดเป็น โทเค็น/วินาที ได้ หรือใกล้เคียงกับ 1 โทเค็นต่อนาทีมากกว่ากัน
    ถ้า local LLM ช้าระดับ 1 โทเค็น/วินาที ก็ยังค่อนข้างมีประโยชน์ ถ้าปล่อยให้มันทำโปรเจกต์ข้ามคืนแล้วกลับมาดูผลอีก 6~8 ชั่วโมงให้หลัง
    แต่ 0.05~0.1 โทเค็น/วินาทีบนฮาร์ดแวร์สเปกต่ำสุดตามลิงก์นั้นดูแทบไม่มีกรณีใช้งานที่พอใช้ได้เลย
    ถึงอย่างนั้นแนวคิดโดยรวมยอดเยี่ยมมาก และหวังว่าจะมีความพยายามแบบนี้มากขึ้นเพื่อให้คนทั่วไปสามารถรันโมเดลระดับ 350B~900B แบบโลคัลบนฮาร์ดแวร์ที่พอจ่ายไหวได้ ต่อให้ได้แค่ 1 โทเค็น/วินาทีก็ตาม
    ชอบแนวคิดที่ว่า “มี NVMe SSD ที่อ่านได้เร็ว และมีโมเดลขนาดมหึมาอยู่บนดิสก์โลคัล ดังนั้นก็ไม่ต้องโหลดทั้งหมดขึ้นมา แต่อ่านทีละ 11GB/โทเค็นเมื่อจำเป็น”

    • ตลกดีที่ Claude Cowork ทำให้ชินกับการรอเวลาตอบกลับไปแล้ว
      ตอนนี้คิดว่าอย่างช้าสุดก็น่าจะได้รันแบบโลคัลภายในปี 2028
      ตั้งงบไว้ต่ำกว่า 10,000 ดอลลาร์ และอยากรันโมเดลที่พอจะเทียบกับโมเดลระดับท็อปทุกวันนี้ได้
    • สำหรับ local model ที่ช้า หรือบางโปรเจกต์ การใช้ อินเทอร์เฟซแชต อาจเป็นแนวทางที่ผิด และอะไรที่คล้ายระบบตั๋วงานอาจเหมาะกว่า
      ก่อนจะทุ่มเงินซื้อ Mac Studio หรือ GPU ผมได้คิดวิธีทดสอบไอเดียนี้บนฮาร์ดแวร์ที่มีอยู่ตอนนี้ไว้แล้ว และน่าจะทำ proof of concept ได้ภายในสัปดาห์นี้
      ไม่ใช่ไอเดียใหม่ แค่ต้องใช้เวลาให้มันเข้ากับวิธีทำงานของผม
    • ใน README มี เบนช์มาร์ก การรัน Colibrì บนฮาร์ดแวร์หลายแบบ และผมเคยเห็นเวลาที่ค่อนข้างดีอยู่
      ตอนนี้ก็กำลังพยายามปรับปรุงต่อไปเรื่อย ๆ
    • สำหรับโปรเจกต์ส่วนใหญ่ การใช้ คลาวด์ที่ให้ GLM 5.2 ฟรี น่าจะใช้งานได้จริงมากกว่า
      1 โทเค็นต่อนาทีนั้นน้อยเกินไป แม้เทียบกับโควตาใช้งานฟรีก็ตาม
    • เดี๋ยวนี้ก็อดคิดไม่ได้ว่า “คนทั่วไป” ยังพอรับไหวกับ RAM 24GB และ NVMe SSD 0.5TB หรือเปล่า

  • กำลังทำอะไรคล้าย ๆ กันสำหรับ macOS บน Apple Silicon
    ใช้แนวทาง Unsloth split GGUF, การคงส่วนที่บีบอัดไว้ในหน่วยความจำรวม, native Metal kernel, และ native compressed KV ที่อยู่ใน RAM ล้วน ๆ
    ดูจะเข้าท่ากว่าบนเครื่อง 128GB มากกว่าบน 64GB ของผม และพอพร้อมแล้วตั้งใจจะปล่อยขึ้น GitHub

    • ผมมี MacBook Pro M4 128GB รออยู่และยินดีลองทดสอบให้

  • ฝั่งการสร้างภาพ/วิดีโอก็เคยใช้กลยุทธ์คล้ายกันกับ https://github.com/cretz/thinfer
    มีงานอยู่บน video branch ค่อนข้างเยอะ
    เพราะยังต้องการ inference engine ที่สามารถดึงและไล่น้ำหนักเข้าออกแบบ LRU ได้ตามเวลาที่ต้องใช้ สุดท้ายเลย vibe coding ทำเครื่องมือที่รับ --vram-budget และพยายามอยู่ภายในงบนั้น
    ปรากฏว่าต้นทุนของการย้ายไบต์ที่ mmap ไว้เข้าออก VRAM นั้นถูกมากเมื่อเทียบกับการคำนวณ และถ้าผสมการทำ pipeline กับ double buffering ก็แทบจะกลายเป็นคอขวดด้านการคำนวณแทนที่จะเป็นคอขวดด้านหน่วยความจำเกือบตลอด
    แน่นอนว่าผมใช้โมเดลที่เล็กกว่ามาก

    • ดูเหมือนคุณจะใส่โมเดลไว้เยอะมากจริง ๆ เช่น krea, wan, hunyan
      เลยสงสัยว่าคุณทำ ฮาร์เนสร่วม ที่รันทั้งหมดได้หรือเปล่า
      แล้วก็สงสัยว่าโมเดลไหนบ้างที่อยู่ในงบ VRAM ได้สม่ำเสมอกว่า

  • llama.cpp รองรับ quantization ต่ำกว่า 4 บิตได้หลากหลาย และ mmap โมเดลโดยปริยายอยู่แล้ว จึงไม่จำเป็นต้องเก็บน้ำหนักทั้งหมดไว้ในหน่วยความจำ
    ระบบปฏิบัติการจะดึงจากสตอเรจมาให้เมื่อจำเป็น
    การทำสิ่งนี้ได้ด้วยโค้ดน้อยมากและแทบไม่มี dependency นั้นเท่มาก แต่ก็สงสัยว่ามันมีข้อได้เปรียบด้านประสิทธิภาพจริงหรือไม่

  • เจ๋งมาก
    สัปดาห์นี้ผมเองก็ลองเล่น GLM 5.2 มา และก็ประทับใจเหมือนกัน
    ที่บริษัทกำลังทดสอบการรันแบบโลคัลบนฮาร์ดแวร์ราคาแพงมากก่อนจะเริ่มโปรเจกต์ถัดไป แต่ก็ดีที่มีคนพยายามรันโอเพนซอร์สโมเดลขนาดมหึมาที่เพิ่งปล่อยออกมานี้บนเครื่องทั่วไป
    ถึงตอนนี้มันอาจยังไม่ค่อยใช้งานได้จริงนัก แต่ก็เป็นงานที่ดี

    • อยากรู้ว่าเป็นฮาร์ดแวร์อะไร

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

  • ผมมีเครื่องที่ RAM 64GB และ VRAM 24GB เลยสงสัยว่าจะปรับให้ตัวนี้ใช้ RAM มากขึ้น ได้หรือไม่
    หรืออาจรัน Gemma/Qwen บน GPU แล้วให้ GLM-5.2 มอบหมายงานย่อยให้โมเดลนั้นก็ได้
    อาจต้องฝึก GLM-5.2 เพิ่มพอสมควรด้วย
    แล้วก็สงสัยว่าถ้าใช้หลายดิสก์แบบขนานเพื่อเพิ่มแบนด์วิดท์จะช่วยให้เร็วขึ้นได้ไหม
    ในคำเตือนเรื่องการสึกหรอของ SSD มีบอกว่า cold start หนักมากในแง่การอ่านแบบสุ่มประมาณ 11GB/โทเค็น และแม้การอ่านเองจะปลอดภัย แต่ page cache ของระบบปฏิบัติการอาจทำให้เกิดการเขียนได้ และการใช้งานหนักเกินไปอาจเร่งการสึกหรอของ SSD ราคาถูก
    วิธีที่ปลอดภัยอาจเป็นการสร้างพาร์ทิชันแยกสำหรับน้ำหนักโมเดลและตั้งเป็นอ่านอย่างเดียว
    ไม่แน่ใจว่า page cache เป็นระดับพาร์ทิชันหรือระดับดิสก์ แต่ถ้าเป็นระดับดิสก์ ก็อาจมีวิธีฟอร์แมต data.iso แบบอ่านอย่างเดียวให้เป็นเหมือนพาร์ทิชันแล้วเมานต์เป็นดิสก์

    • ผมใช้แล็ปท็อปเครื่องเล็กอยู่
      ถ้ามีดิสก์เพิ่มก็น่าจะลองทดสอบจริงได้
      ถ้ามีเบนช์มาร์กแล้วเอามาลงเป็น pull request หรือ issue ได้เลย จะได้ช่วยทำต่อร่วมกัน
    • สงสัยว่าข้อความที่ว่า “page cache ของระบบปฏิบัติการอาจทำให้เกิดการเขียนได้” เป็น ภาพหลอน หรือเปล่า
      ผมกำลังพลาดอะไรไปหรือ? ทำไมการอ่านจำนวนมากถึงจะทำให้เกิดการเขียนได้?
    • อาจเป็นไอเดียที่ดี และเราน่าจะช่วยกันทำได้

  • บนหน้านี้มี คำเตือนเรื่องการสึกหรอของ SSD อยู่ https://github.com/JustVugg/colibri#ssd-wear-warning
    ถ้าใช้เดสก์ท็อปพีซีที่ประกอบเองก็ยังเปลี่ยน SSD ได้ แต่คนที่ใช้ SSD แบบบัดกรีติดบอร์ดจะทำอย่างไรดี?
    ควรหลีกเลี่ยงแอปพลิเคชันแบบนี้ หรือยอมรับความเสี่ยงที่สตอเรจจะพังก่อนเวลาแล้วใช้งานต่อไป?
    ดูเหมือนควรใช้สตอเรจภายนอกเป็น SSD แบบสิ้นเปลืองแทน

    • ควรหลีกเลี่ยง
      แล็ปท็อปที่มี SSD แบบบัดกรีติดบอร์ดควรเฝ้าดูการใช้งานอย่างใกล้ชิดและใช้อย่างระมัดระวัง
      โปรเจกต์นี้ดูเหมือนการทดลองมากกว่าจะเป็นของที่ทุกคนควรรัน แต่ก็ยังเจ๋งมาก
    • เท่าที่ผมเข้าใจ คำเตือนนั้นเกี่ยวกับ การสลับหน่วยความจำออก ระหว่างที่ใช้หน่วยความจำมากเกินไป
      ไม่จำเป็นต้องคิดแบบเชื่อโชคลางกับเรื่องนี้
      กิจกรรมของดิสก์ โดยเฉพาะการเขียน สามารถวัดได้
      เช่นบน Linux ก็ใช้ iostat หรือ vmstat ได้
    • เป็นคำเตือนที่ค่อนข้างเผื่อไว้มาก
      แอปพลิเคชันไม่ได้ทำการเขียน ดังนั้นตัวแอปเองจึงไม่ได้ทำให้ SSD สึกหรอจริง ๆ
      ที่เหลือก็เป็นคำแนะนำการดูแลทั่วไปซึ่งไม่ได้เฉพาะกับแอปนี้
    • ถ้าใช้งานแบบนั้น การใช้ไดรฟ์ภายนอกก็น่าจะเหมาะ

  • ในเชิงเทคนิคมันน่าประทับใจ แต่ผมสงสัยว่าจะ ใช้งานได้จริงในทางปฏิบัติหรือไม่

  • จริง ๆ ผมก็ทำอะไรคล้ายกันอยู่เหมือนกัน แต่เลือกใช้การ mmap โมเดลทั้งหมดเข้าเมมโมรีเพื่อหลีกเลี่ยงการใช้ RAM เพิ่ม
    อีกอย่าง ผมให้ Claude ช่วย implement Medusahttps://arxiv.org/abs/2401.10774 ให้กับโมเดล เพื่อพยายามได้ประโยชน์จากการทำนายหลายโทเค็นโดยไม่ต้องโหลดโมเดลเพิ่มเข้าเมมโมรี
    เพิ่งกลับถึงบ้านเลยขอเสริมว่า ผมกำลังแก้ทุกอย่างใน llama.cpp และเป้าหมายสุดท้ายคือเอาไปลงบนอะไรอย่าง single-board computer ที่จัดการไฟล์ mmap ผ่าน NVMe
    จากการทดสอบก่อนหน้านี้ ขีดจำกัดเชิงทฤษฎีของการตั้งค่าปัจจุบันดูเหมือนจะอยู่ที่ประมาณ 1.8 โทเค็น/วินาที แต่ผมก็ยังไม่แน่ใจนักว่า Medusa head เพิ่มเติมนั้นฝึกเสร็จสมบูรณ์หรือยัง และมันถูกนับรวมในโทเค็นที่สร้างขึ้นหรือไม่
    สุดท้ายแล้วไอเดียก็ดูคล้ายกัน แต่ผมยังเขียน LLM parser/runner ตั้งแต่ศูนย์ไม่เป็น เลยปล่อยให้ Linux kernel จัดการแทน แทนที่จะระบุเองว่าจะเก็บอะไรไว้ในหน่วยความจำ
    สุดท้าย ผมจำกัดการใช้ llama.cpp ไว้ที่ 16GB จากทั้งหมด 32GB ของผม ดังนั้นอาจลดลงได้อีกก็ได้

    • Colibrì ยังต้องปรับปรุงอีกมาก ดังนั้นถ้ามีไอเดียหรืออย่างอื่นก็ยินดีรับทั้ง pull request, issue และ benchmark
    • นี่แหละคือแนวทางที่ผมสงสัยอยู่พอดี