1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Mô hình mở mới GLM-5.2 của Z.ai có 744B tham số, 40B tham số hoạt động và cửa sổ ngữ cảnh 1M; điểm cốt lõi là đây là một ví dụ vận hành mô hình cực lớn trên phần cứng cục bộ
  • Unsloth cung cấp lộ trình chạy cục bộ bằng Dynamic GGUF; quant UD-IQ2_M 2-bit được khuyến nghị yêu cầu 239GB dung lượng đĩa và môi trường ít nhất cỡ 245GB RAM
  • Dynamic 1-bit cho khoảng 76.2% top-1 accuracy cùng mức giảm kích thước 86%, còn Dynamic 2-bit cho khoảng 82% accuracy và giảm kích thước 84%, khác với cách hiểu rằng “nhỏ đi bao nhiêu thì hiệu năng tệ đi bấy nhiêu”
  • Có hai cách chạy: Unsloth Studiollama.cpp; Studio hỗ trợ tìm kiếm, tải xuống, chạy mô hình trên MacOS·Windows·Linux, offloading sang RAM và phát hiện multiGPU
  • Để thực sự dùng được ngữ cảnh dài, cần giảm bộ nhớ bằng KV cache quantization trong llama.cpp; q4_0 cho phép ngữ cảnh dài hơn khoảng 3.5 lần, q4_1 khoảng 3.2 lần

Tổng quan mô hình GLM-5.2

  • GLM-5.2 là mô hình mở mới của Z.ai và có thể chạy trên phần cứng cục bộ thông qua Unsloth Dynamic GGUF
  • Thông số mô hình như sau
    • Tổng số tham số: 744B
    • Tham số hoạt động: 40B
    • Cửa sổ ngữ cảnh tối đa: 1,048,576
  • Được giới thiệu là mang lại hiệu năng SOTA trong long-horizon coding, reasoning và agentic tasks
  • Theo Artificial Analysis và nhiều benchmark, mô hình được cho là có hiệu năng ngang Claude 4.8 Opus, GPT-5.5, Gemini 3.1 Pro
  • Unsloth cho biết họ đã nhận được day-zero access từ Z.ai
  • Có thể tải tệp mô hình GGUF cho GLM-5.2 tại Hugging Face: GLM-5.2-GGUF

Quant được khuyến nghị và yêu cầu bộ nhớ

  • Để cân bằng giữa khả năng tiếp cận và độ chính xác, tài liệu hướng dẫn dùng 2-bit dynamic quantUD-IQ2_M
    • Dung lượng đĩa: 239GB
    • Có thể vừa trực tiếp trên máy Mac unified memory 256GB
    • Khi dùng MoE offloading, mô hình được cho là chạy tốt cả với 1x24GB GPU + 256GB RAM
  • Quant 1-bit nằm trong 223GB RAM, còn 8-bit cần 810GB RAM
  • Trong bảng yêu cầu phần cứng suy luận, tổng bộ nhớ nghĩa là RAM + VRAM hoặc unified memory
    • Các mức tổng bộ nhớ được nêu: 223GB, 245GB, 290–360GB, 372–475GB, 570GB, 810GB
  • Để đạt hiệu năng tối ưu, tổng bộ nhớ khả dụng từ VRAM và RAM hệ thống cần lớn hơn đáng kể quantized model file size

Chế độ Thinking và thiết lập sampling

  • GLM-5.2 cung cấp 3 thinking mode
    • non-thinking
    • thinking High
    • thinking Max
  • Với tác vụ phức tạp, tài liệu khuyến nghị dùng Max Thinking
  • Trong Unsloth Studio, có thể bật/tắt High/Max Thinking và non-Thinking qua UI
  • Thiết lập cho đa số trường hợp sử dụng như sau
    • temperature = 1.0
    • top_p = 0.95
    • Ở các chế độ khác thì top_p = 1.0
  • GLM-5.2 mặc định dùng reasoning; có thể chọn reasoning_effort"high", "max" hoặc tắt đi
  • Ví dụ tắt thinking như sau
    • Shell thông thường: --chat-template-kwargs '{"enable_thinking":false}'
    • Windows PowerShell: --chat-template-kwargs "{\"enable_thinking\":false}"
  • Trong llama.cpp cũng có thể dùng --reasoning on hoặc --reasoning off
  • Ví dụ thiết lập reasoning effort như sau
    • --chat-template-kwargs '{"reasoning_effort":"max"}'
    • --chat-template-kwargs '{"reasoning_effort":"high"}'
    • --chat-template-kwargs '{"enable_thinking":false}'

Độ chính xác của Dynamic GGUF và cách diễn giải KLD

  • Unsloth dùng benchmark KLD(KL Divergence) để đánh giá độ chính xác của quá trình quantization cho GLM-5.2-GGUF
  • Dynamic 4-bit UD-Q4_K_XL và Dynamic 5-bit UD-Q5_K_XL được giới thiệu là gần như lossless trong đa số trường hợp
  • Các quant nhỏ hơn hoạt động bằng cách dùng phân bổ độ chính xác động: layer quan trọng giữ precision cao hơn, layer ít quan trọng dùng số bit thấp
  • Các con số theo tiêu chí pure top-1% accuracy như sau
    • Dynamic 1-bit: khoảng 76.2% accuracy, giảm kích thước 86%
    • Dynamic 2-bit: khoảng 82% accuracy, giảm kích thước 84%
    • So sánh accuracy: {b:76,82}
  • Việc nhỏ hơn 86% không có nghĩa là tệ hơn 86%; Dynamic 1-bit được diễn giải là chỉ thấp hơn khoảng 24% accuracy so với mô hình đầy đủ 1.5TB
  • “76% accuracy” không có nghĩa rằng với câu hỏi như “The capital of France is”, mô hình sẽ chọn Paris 76% và Sydney 24%
    • Trong ví dụ đó, Paris luôn là 100% và Sydney là 0%
    • Con số 76% còn bao gồm cả thay đổi phân phối của filler words và stop words trên toàn corpus
  • Với prompt như “Create a novel”, nơi có nhiều cách mở đầu đúng, phân phối token giữa baseline và mô hình quantized có thể khác nhau
    • Baseline có thể chọn [I] với 100%, còn mô hình quantized có thể phân phối thành [I] 76%, [The] 24%
    • Điều này không có nghĩa là có 24% xác suất sinh ra output sai hoặc vô nghĩa
  • KLD là khoảng cách giữa xác suất của baseline BF16 hoặc Q8_0 và xác suất của phiên bản quantized
    • Mục tiêu của quantization là tối thiểu hóa trung bình KL divergence giữa f(q(W))f(W)
    • f là forward của language model, q là phép quantization, W là tham số hoặc trọng số của mô hình
    • Nếu KLD bằng 0 thì nghĩa là tái tạo mô hình hoàn hảo
  • Chạy KLD trên toàn bộ ví dụ corpus huấn luyện 15T tokens là rất tốn kém, nên Unsloth tối ưu bằng mean KLD và representative subset sampling nhỏ
  • KLD 99.9% nhìn chung cũng được xem là tốt; từ 4bit trở lên có mức uplift lớn hơn, nên với massive out-of-distribution tasks thì Dynamic 4-bit có lẽ là phù hợp nhất

Chạy bằng Unsloth Studio

  • Unsloth Studioweb UI mã nguồn mở cho local AI và hỗ trợ chạy GLM-5.2
  • Các tính năng chính gồm
    • Chạy mô hình cục bộ trên MacOS, Windows, Linux
    • Tìm kiếm, tải xuống và chạy mô hình GGUF và safetensor
    • Tự động phát hiện RAM offloading và thiết lập multiGPU
    • Suy luận CPU + GPU nhanh qua llama.cpp
  • Lệnh cài đặt như sau
  • Lệnh chạy như sau
    • unsloth studio -H 0.0.0.0 -p 8888
    • Sau khi chạy, chỉ cần mở http://127.0.0.1:8888 trên trình duyệt hoặc URL riêng được cấp cho từng người dùng
  • Tài liệu cũng cung cấp cách chạy Studio an toàn bằng HTTPS
    • Trên Windows, Mac, Linux: unsloth studio --secure
    • Sử dụng Cloudflare tunnel miễn phí
  • Lần chạy đầu tiên, cần tạo password để bảo vệ tài khoản rồi đăng nhập lại sau đó
  • Trong tab Studio Chat, tìm GLM-5.2 trong ô tìm kiếm rồi tải model và quant mong muốn
  • Trước khi chạy mô hình, cần kiểm tra có đủ compute hay không
  • Trong Studio, inference parameters được kỳ vọng sẽ được thiết lập tự động, nhưng người dùng vẫn có thể chỉnh thủ công context length, chat template và các thiết lập khác
  • Thông tin thêm có trong Unsloth Studio inference guide

Chạy bằng llama.cpp

  • Tutorial llama.cpp tập trung vào việc chạy quant UD-IQ2_M và yêu cầu tối thiểu 245GB RAM
  • Để suy luận cục bộ nhanh, tài liệu dùng llama.cpp
  • Nếu không có GPU hoặc chỉ muốn suy luận bằng CPU, đổi -DGGML_CUDA=ON thành -DGGML_CUDA=OFF
  • Với thiết bị Apple Mac / Metal, cũng dùng -DGGML_CUDA=OFF; hỗ trợ Metal đã được bật sẵn mặc định
  • Quy trình build theo luồng sau
    • 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 cũng có thể dùng để load và download mô hình trực tiếp như ollama run
  • Có thể chọn ví dụ quantization type như UD-IQ2_M, và dùng export LLAMA_CACHE="unsloth/GLM-5.2-GGUF" để ép vị trí lưu
  • Tài liệu lưu ý quá trình tải trực tiếp bằng llama.cpp có thể rất chậm, nên tải thủ công sẽ tốt hơn

Ví dụ tải thủ công và chạy

  • Để tải thủ công nhanh hơn, tài liệu dùng huggingface_hub
    • pip install huggingface_hub
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ2_M*"
  • Với near full precision, có thể dùng --include "*UD-Q8_K_XL*"
  • Nếu tải bị treo, tài liệu hướng dẫn xem Hugging Face Hub, XET debugging
  • Lệnh tải Dynamic 1-bit như sau
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ1_S*"
  • Đường dẫn mô hình cho conversation mode như sau
    • 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
  • Ví dụ chạy llama-cli chỉ định shard đầu tiên của GGUF 2-bit trong --model và dùng các tham số sau
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
  • Trong ví dụ chạy trực tiếp còn dùng -hf unsloth/GLM-5.2-GGUF:UD-IQ2_M

Hành vi được xác nhận qua ví dụ sinh nội dung

  • Tài liệu có ví dụ cho thấy GLM-5.2 2-bit thực hiện tool-calling và sinh SVG
  • Sau khi chạy llama-cli, kết quả tiếp theo là yêu cầu tạo một “short Flappy Bird game”
  • Trò chơi HTML/JavaScript một tệp được sinh ra dùng tên Sunset Flier
    • Bao gồm canvas, màn hình bắt đầu, màn hình game over, HUD điểm số, nút NEW BEST!, RETRY
    • Tạo hiệu ứng âm thanh flap, score, hit, die bằng Web Audio API mà không cần tài sản bên ngoài
    • Trạng thái trò chơi được quản lý qua 4 bước READY, PLAYING, DYING, OVER
    • Điểm cao nhất được lưu bằng localStorage.getItem('sunsetFlierBest')localStorage.setItem()
  • Logic game gồm trọng lực, xung flap, ống ngẫu nhiên, va chạm, hạt hiệu ứng, rung màn hình và hệ thống huy chương
    • GRAVITY = 0.42
    • MAX_FALL = 9
    • PIPE_W = 68
    • PIPE_GAP = 180
    • PIPE_SPEED = 2.6
    • PIPE_SPACING = 220
  • Input hỗ trợ chuột, chạm, bàn phím Space, ArrowUp, Enter
  • Ví dụ game này được nêu trong ngữ cảnh rằng nó vẫn hoạt động tốt cả với 1-bit quantization và âm thanh cũng chạy bình thường

Ngữ cảnh dài và KV cache quantization

  • Để tận dụng ngữ cảnh dài trong llama.cpp, cần giảm mức dùng bộ nhớ bằng KV cache quantization
  • Gần đây llama.cpp đã bổ sung kỹ thuật giúp KV cache quantization có độ chính xác cao hơn; PR liên quan là https://github.com/ggml-org/llama.cpp/pull/21038
  • Các dtype KV cache được hỗ trợ gồm
    • f32
    • f16
    • bf16
    • q8_0
    • q4_0
    • q4_1
    • iq4_nl
    • q5_0
    • q5_1
  • Giá trị mặc định là f16
  • q4_0 có khoảng 4.5 bit trên mỗi weight, nên có thể tăng độ dài ngữ cảnh lên 16 / 4.5, tức khoảng 3.5 lần
    • Ví dụ, mô hình trước đây hỗ trợ 10K có thể mở rộng lên khoảng 35K
  • q4_1 có thêm shifting parameter nên có thể tốt hơn, và vì dùng 5 bit trên mỗi weight nên cho ngữ cảnh dài hơn khoảng 3.2 lần
  • Ví dụ chạy KV cache quantization chỉ định mô hình GLM-5.2 GGUF và các tham số sampling sau
    • Đường dẫn mô hình: 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

Các con số có thể xác nhận từ bảng benchmark

  • Tài liệu tiếp tục với bảng benchmark GLM-5.2, nhưng phần được cung cấp không có tiêu đề cột nên không thể xác định mỗi con số tương ứng với mô hình hay cấu hình nào
  • Benchmark reasoning gồm các hàng và giá trị sau
    • 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
  • Benchmark coding gồm các hàng và giá trị sau
    • 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
  • Benchmark agentic gồm các hàng và giá trị sau
    • 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 bình luận

 
Ý kiến trên Hacker News
  • Đang chạy Q4_K_XL. Để đạt khoảng 6tk/giây, chỉ cần 512GB RAM và 2 chiếc RTX 3090, với llama.cpp -cmoe
    Hiện tại là do đang dùng DDR4 2400MHz cùi nên vậy, nếu là 3200MHz thì có vẻ sẽ lên được khoảng 9tk/giây. CPU cũng là EPYC 32 lõi nên ổn, nhưng nếu là bản 64 lõi tốt hơn thì có thể lên tới 11tk/giây
    Tôi lắp theo kiểu tiết kiệm trước khi giá phần cứng phát điên, và ngày nào cũng hối hận, nhưng dù sao việc có thể chạy mô hình này ở nhà vẫn rất tuyệt. Nó rất hợp cho việc lên kế hoạch hoặc gom đủ ngữ cảnh cần thiết rồi dùng prompt one-shot
    Tổng chi phí phần cứng là 2.400 USD vào thời điểm lắp máy, và nếu chịu khó săn đồ thì vẫn có cách chạy những mô hình như thế này tại nhà. Tôi thường bị hỏi tại sao lại làm vậy, hoặc dùng cloud API thì tiết kiệm hơn bao nhiêu, nhưng tôi nghĩ vụ Fable đã cho thấy giá trị của việc vận hành độc lập
    Cảm ơn đội unsloth, và Q4_K_XL rất chắc chắn. Nếu định tải mô hình lượng tử hóa thì nên lấy biến thể K_XL nếu nó vừa máy

    • Xin dành lời tán thưởng cho những người đang đẩy giới hạn khả năng bằng các thử nghiệm homebrew như thế này. Giống như crypto, AI cũng bị chôn vùi trong tiếng ồn của dân buôn, nhưng gần như chẳng mấy ai nói về khả năng phục hồi
      Những nhà nghiên cứu cố nhét mô hình mã nguồn mở vào bàn chải điện hay Tamagotchi cũng tuyệt không kém
    • Nếu cứ chạy tải đó liên tục thì sẽ ít nhất 600W, tức khoảng 14kWh mỗi ngày. Với giá 0,2 USD/kWh thì là 2,80 USD/ngày, riêng tiền điện vận hành đã khoảng 1.000 USD/năm
      Trừ khi bạn thực sự cần quyền riêng tư hoặc thích cảm giác tự sở hữu, còn không thì trả tiền cho hyperscaler sẽ rẻ hơn, tiện hơn và token/giây cũng nhanh hơn rất nhiều
      Dù vậy tôi vẫn thích hướng đi này, và khá háo hức xem sau 2 năm nữa phần cứng self-hosting sẽ ra sao
    • Tôi có cấu hình gần như y hệt. 2 chiếc RTX 3090, 512GB DDR4 nhanh hơn một chút, và EPYC 64 lõi [0]
      Tôi đang dùng khá vui và cũng rất muốn sớm thử chạy mô hình này
      Ngoài chuyện chạy mô hình local, tôi còn dùng cỗ máy này làm nền tảng phát triển từ xa chính. Mọi phiên Claude Code giờ đều được tôi chạy bằng tmux trên đó
      Không còn phải liên tục chạm vào chiếc laptop nóng ran nữa nên ngón tay của tôi rất vui. Claude Code cũng ngốn pin khủng khiếp
      [0] https://medium.com/@rathko/i-built-an-epyc-64-core-512gb-ram...
    • Câu kiểu “đây là mức cần để chạy” có thể đúng nếu mua với giá 2.400 USD, nhưng ở thời điểm hiện tại thì tổng giá đã gần 10.000 USD hơn nhiều
      Chỉ riêng RAM đã gần 5.000 USD, còn mỗi GPU cỡ 2.000 USD, nên theo giá hiện tại đây là dàn phần cứng khá đắt
    • Theo hiểu biết của tôi thì bản triển khai llama.cpp cho mô hình này vẫn chưa hỗ trợ DSA sparse attention, nên còn khá dang dở
      Vì vậy mô hình bị chạy bằng một cơ chế khác không dùng lúc huấn luyện, và đã có kết quả cho thấy chất lượng lẫn hiệu năng đều giảm
      Dù sao thì tôi cũng không thấy GLM 5.2 thú vị bằng dòng DeepSeek V4 ở nhiều mặt. DeepSeek V4 dùng cơ chế attention tiên tiến hơn, nên đặc biệt với ngữ cảnh dài có thể tiết kiệm rất nhiều bộ nhớ KV cache
      Nhờ đó có thể xử lý batch lớn trên cả nền tảng tiêu dùng. GLM thì không có điều đó, và về cấu trúc hiệu năng nền tảng thì nhìn chung cho cảm giác khá giống Kimi 2.6. Cả hai đều hơi quá nặng để chạy full chất lượng một cách hợp lý trên phần cứng phổ thông
  • Gần được rồi. Dàn của tôi là 192GB RAM + RTX 3090 24GB, và suýt nữa là có thể chạy được cái này
    Tài liệu ghi rằng MoE offloading cần 24GB VRAM và 256GB RAM
    https://unsloth.ai/docs/models/glm-5.2#usage-guide
    Trong một thread trước đó, có người nói phần cứng sẽ tốn 500.000 USD
    https://news.ycombinator.com/item?id=48629970

    • 500.000 USD là phóng đại quá mức. Nếu nhắm tới mức đồng thời rất lớn ở FP8 hay BF16 thì có thể là vậy
      Với NVFP4, để có tốc độ tương đối ổn, khoảng 120 tok/s và có concurrency, thì theo giá hiện tại chỉ cần khoảng 80.000~90.000 USD, thậm chí có thể thấp hơn
      Với số tiền đó bạn có thể mua 6 chiếc RTX 6000 PRO Blackwell, CPU và mainboard ổn áp, cùng bộ nguồn. Tổng VRAM sẽ là 576GB
      Nếu chấp nhận decode 40 tok/s và prefill khoảng 1200 tok/s thì có thể xuống dưới 50.000 USD
    • Với 2-bit thì khó mà có kết quả tốt. Khoảng lý tưởng cho coding ít nhất phải là Q8
    • Tôi đang hy vọng đợt bùng nổ này sẽ một lần nữa kích hoạt sự phát triển của phần cứng máy tính như những năm 90
      Tôi có cảm giác một phần lý do phần cứng tương đối chững lại trong 20 năm qua là vì các công ty thiếu những trường hợp sử dụng đủ sức biện minh cho việc nâng cấp phần cứng
      Trong 15 năm qua, phần lớn tiền bạc và năng lượng đều dồn vào mobile
      Suy luận local giá rẻ có thể trở thành nguồn doanh thu mà các hãng sản xuất server, desktop và laptop cần để thực sự chuyển động trở lại
    • Tôi có RAM nhưng không có VRAM. Với 3090 có 24GB RAM, có thể kỳ vọng tốc độ hay tok/s ở mức nào?
      Tôi hơi bị hấp dẫn bởi ý tưởng mua một GPU có 24GB RAM để thử
    • Tôi hỏi Gemini cho vui, và nó trả lời rằng để có throughput tử tế khi chưa lượng tử hóa thì cần 500.000 USD
  • Câu “chạy được” nghĩa là nhét vừa vào RAM 256GB, nhưng trong trạng thái lượng tử hóa rất mạnh và vẫn sẽ chạy rất chậm
    Con số trên tiêu đề không phải là tốc độ sinh token mà là tốc độ xử lý prompt
    Nếu ra 10 tok/s và API là 20~30 tok/s thì bề ngoài có vẻ không tệ đến thế, nhưng Mac Studio hoặc thiết bị không đưa toàn bộ mô hình lên GPU sẽ xử lý prompt chậm hơn cấu hình thuần GPU khoảng 20~50 lần
    Đây rốt cuộc là chỗ khiến nó thực tế không dùng được nếu bạn không chi 50.000 USD cho GPU. Hơn nữa bạn vẫn phải dùng mô hình bị lượng tử hóa rất nặng

    • Thiết bị như Nvidia Spark có RAM hợp nhất 128GB
      Cũng có phiên bản hai cổng cho loại máy này: https://www.nvidia.com/content/dam/en-zz/Solutions/networkin...
      Tức là 2 cổng x 100GB/s, hoặc có khi là 2 x 200GB/s. Có lẽ phải cầm tận tay mới biết rõ hơn
      Những máy như vậy cũng có thể ghép cụm. Với 2 hoặc 3 máy thì khá rõ ràng nếu dùng 2 subnet IP. Từ 4 máy trở lên có thể cần switch, tùy độ trễ mạng ảnh hưởng nhiều đến đâu
      Apple có vẻ như đã quên mất dòng M series với RAM lớn. Tôi không thấy cấu hình nào vượt quá RAM hợp nhất 96GB trong Apple Store, mà ngay cả mức đó cũng đắt như bán một quả thận
  • Họ đang thúc theo nhiều hướng cùng lúc: desktop AI mới dùng GB10 có giá tương đối phải chăng, và có thể ghép cụm để đạt VRAM 1TB
    Nvidia, AMD, Intel, Cerebras và các hãng khác đang đẩy phần cứng mới, còn các mô hình mã nguồn mở như GLM 5.2 thì đang tiến bộ đến mức khó tin
    Các mô hình flash như DeepSeek V4 Flash cũng đang tốt lên rất nhiều, và lượng tử hóa cũng tiếp tục phát triển
    Giờ đây cũng có thể xây dựng harness dùng nhiều mô hình khác nhau, kiểu mô hình lớn cho việc khó và mô hình nhỏ cho việc lặt vặt
    Vì vậy, những người muốn thoát khỏi API hy vọng rằng sớm thôi họ sẽ có thể tự host cụm desktop AI giá hợp lý tại nhà và dùng hiệu năng cấp Opus

    • Từ “tương đối” ở đây phải gánh khá nhiều ý nghĩa. Nếu một máy GB10 giá khoảng 4.000 USD thì cụm 1TB sẽ là 36.000 USD
      So với H200 cùng hạng thì là rẻ, nhưng với homelab không có vốn từ RSU của OpenAI hay Anthropic chống lưng thì vẫn ngoài tầm với
  • Có cảm giác khoảng cách đang thu hẹp đến mức có thể chạy cục bộ các mô hình đủ tốt, kể cả cho lập trình, và có lẽ vài công ty sẽ thấy hơi bất an. Tôi có sai không?

    • Nếu hiện giờ không bị giới hạn bởi RAM/GPU thì mấy công ty đó đã còn lo hơn bây giờ
      Nhưng tại thời điểm này, số người có đủ khả năng chi trả cho phần cứng để chạy hiệu quả các mô hình này là rất ít. Có lẽ vài năm tới cũng không thay đổi nhiều
      Nếu Z.ai tung ra phiên bản như GLM-5.2 Flash chuyên cho lập trình ở quy mô khoảng 80B tham số, các lab hàng đầu tại Mỹ sẽ lo hơn
      Nhìn chung, các công ty AI Trung Quốc đang cho thấy cách làm cùng một việc với ít tài nguyên hơn, đôi khi là ít hơn rất nhiều, và nếu xu hướng này tiếp tục thì các lab tuyến đầu sẽ phải bất an
      Tuy vậy, bản thân các công ty AI Trung Quốc cũng sẽ cố giữ hào lũy của mình bằng cách không công bố các mô hình nhỏ hơn nhiều nhưng vẫn mạnh so với mô hình chủ lực hiện tại
      Alibaba Qwen có vẻ đang ở đúng vị thế đó. Gần đây họ khá im ắng, và mô hình 395B mới nhất thì quá lớn để đa số mọi người chạy ở nhà. Cũng chưa có dấu hiệu lần này họ sẽ tung ra mô hình nhỏ hơn
    • Tôi không nghĩ vậy. Hoàn toàn dễ hình dung việc một công ty quyết định tự host và chạy những mô hình này cho nhu cầu phát triển nội bộ
      Nếu đội ngũ phát triển có khoảng 10 người thì lựa chọn đầu tư một lần 50.000 USD cho máy chủ LLM có thể khá hấp dẫn
      Bạn có token không giới hạn, hiệu năng ổn, tùy chọn nâng cấp và khả năng tích hợp vào sản phẩm
      Nói chung, nếu là công ty đang muốn đưa LLM vào sản phẩm thì cách tiếp cận LLM cục bộ thậm chí còn hấp dẫn hơn. Ngay cả mô hình hơi ngốc một chút cũng đủ tốt cho nhiều trường hợp tích hợp vào sản phẩm
    • Để trở thành mối đe dọa thì cũng không nhất thiết phải chạy cục bộ. Nhiều công ty đang nhìn vào phương án trả tiền cho bên thứ ba host những mô hình này, với mức giá chỉ bằng một phần nhỏ so với các lab tuyến đầu
    • Yêu cầu RAM vẫn còn khá đau đầu
    • Chạy cục bộ không kinh tế. Nó rất tuyệt cho quyền riêng tư và là một thú vui hay ho
      Nhưng các lựa chọn hiện tại là build CPU cực chậm với 10.000 USD tiền RAM, hoặc 90.000 USD tiền GPU, hoặc mô hình bị lượng tử hóa nặng mà rất khó so sánh chất lượng
      Bạn có thể dựng một bộ cho vui, nhưng chỉ riêng điều đó không làm thay đổi tính kinh tế. Dù vậy, việc nó khả thi vẫn rất thú vị
  • OpenAI và Anthropic có lẽ sẽ không thích thời điểm ra mắt của GLM 5.2
    Nó cho thấy khá rõ rằng đây không phải một hào lũy ma thuật, mà chỉ là lợi thế người đi trước

  • Có thể dùng Mac Studio RAM 192GB, dù thấp hơn mức RAM tối thiểu được nêu
    Vì đây là MoE nên liệu có thể swap ra đĩa nhanh để cố chạy được không?

    • Nếu swap nặng đến mức đó thì có vẻ là cách rất tốt để đốt sạch TBW của SSD NVMe và làm giảm tuổi thọ của nó đáng kể
      Hiệu năng cũng sẽ thảm hại, cỡ 0,1 tok/s
  • Tôi rất tôn trọng công việc của unsloth khi giúp hàng triệu người bắt đầu với AI cục bộ, nhưng bài này hơi giống mồi tải xuống
    Offload quá nhiều layer sang CPU thì hoàn toàn không ổn. Tôi đã thử nhiều lần rồi, và cuối cùng chỉ còn việc rm -rf các thư mục cache Hugging Face nặng trịch
    Tôi cũng nghi ngờ việc chạy bản lượng tử hóa 1 bit hay 2 bit của GLM 5.2 chủ yếu ngoài VRAM có thực sự hữu ích hơn Qwen3.6-27B Q8_0 đã nằm trọn trong VRAM hay không

  • Dù bài viết có nói gì thì tôi nghĩ ai định chạy cái này trên máy RAM 256GB sẽ khó mà có trải nghiệm tốt
    Mức tối thiểu thực tế hơn nhiều là 512GB
    May mắn là tôi có 2 workstation dual Xeon với RAM 512GB trong phòng làm việc ở nhà, mua rẻ trước khi giá tăng, nên có thể thử nghiệm đủ thứ