GLM-5.2をローカルで実行する方法

 (unsloth.ai)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Z.aiの新しいオープンモデル GLM-5.2 は、744Bパラメータ、40Bアクティブパラメータ、1Mコンテキストウィンドウを備えた巨大モデルをローカルで扱う事例である点が要点
  • Unslothは Dynamic GGUF によってローカル実行の経路を提供しており、推奨の2-bit UD-IQ2_M quantは239GBのディスクと少なくとも245GB RAM級の環境を必要とする
  • Dynamic 1-bitは約 76.2% top-1 accuracy と86%のサイズ削減、Dynamic 2-bitは約82%のaccuracyと84%のサイズ削減を示し、「小さくなった割合ぶん性能が悪化する」という解釈とは異なる
  • 実行方法は Unsloth Studio と llama.cpp の2系統で、StudioはMacOS・Windows・Linuxでのモデル検索・ダウンロード・実行、RAM offloading、multiGPU検出をサポートする
  • 長いコンテキストを実際に使うには llama.cpp の KV cache quantization でメモリを削減する必要があり、q4_0 は約3.5倍、q4_1 は約3.2倍長いコンテキストを可能にする

GLM-5.2モデル概要

  • GLM-5.2 はZ.aiの新しいオープンモデルで、Unsloth Dynamic GGUFを通じてローカルハードウェアで実行できる
  • モデル仕様は以下の通り
    • 総パラメータ数: 744B
    • アクティブパラメータ数: 40B
    • 最大コンテキストウィンドウ: 1,048,576
  • long-horizon coding、reasoning、agentic tasksでSOTA性能を提供すると紹介されている
  • Artificial Analysisおよび複数のベンチマーク基準で Claude 4.8 Opus、GPT-5.5、Gemini 3.1 Pro と同等の性能を示すとしている
  • UnslothはZ.aiから day-zero access を提供されたと明かしている
  • GLM-5.2向けGGUFモデルファイルはHugging Faceの GLM-5.2-GGUF から入手できる

推奨quantとメモリ要件

  • アクセシビリティと精度のバランスのため、2-bit dynamic quant である UD-IQ2_M の使用を案内している
    • ディスク使用量: 239GB
    • 256GB unified memory Macにそのまま収まる
    • MoE offloadingを使えば 1x24GB GPU + 256GB RAM でも十分動作するとしている
  • 1-bit quantは 223GB RAM に収まり、8-bitは 810GB RAM が必要
  • 推論ハードウェア要件の表で、総メモリは RAM + VRAM または unified memory を意味する
    • 表示されている総メモリ値: 223GB, 245GB, 290–360GB, 372–475GB, 570GB, 810GB
  • 最適な性能を出すには、VRAMとシステムRAMを合算した利用可能メモリが quantized model file size を十分に上回る必要がある

Thinkingモードとサンプリング設定

  • GLM-5.2は3つの thinking mode を提供する
    • non-thinking
    • thinking High
    • thinking Max
  • 複雑なタスクには Max Thinking の使用を推奨
  • Unsloth StudioではUIからHigh/Max Thinkingとnon-Thinkingを切り替えられる
  • ほとんどのユースケース向け設定は以下の通り
    • 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はGLM-5.2-GGUF quantizationの精度を評価するために KLD(KL Divergence) ベンチマークを使用している
  • Dynamic 4-bit UD-Q4_K_XL と Dynamic 5-bit UD-Q5_K_XL は大半がlosslessだと案内されている
  • より小さいquantでも重要なレイヤーはhigher precisionで、あまり重要でないレイヤーはlow bitsにする 動的精度配置 方式で動作する
  • pure top-1% accuracy基準の数値は以下の通り
    • Dynamic 1-bit: 約 76.2% accuracy、86% size reduction
    • Dynamic 2-bit: 約 82% accuracy、84% size reduction
    • 精度比較: {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%の確率でgibberishや誤った出力を出すことを意味しない
  • KLDはbaselineであるBF16またはQ8_0の確率とquantized versionの確率の間の 距離 である
    • quantizationの目標は f(q(W)) と f(W) の間のKL divergence平均を最小化すること
    • f はlanguage model forward、q はquantization operation、W はモデルパラメータまたはweights
    • KLDが0ならモデルを完全に再構成したことになる
  • 学習コーパス全体の例である15T tokens全体に対してKLDを実行するのはコストが高いため、Unslothはmean KLDと小さな代表subset samplingで最適化している
  • 99.9% KLDも一般には良好で、4bit以上からより大きなupliftがあるため、massive out-of-distribution tasksにはDynamic 4-bitが最も適している可能性が高いとしている

Unsloth Studioで実行する

  • Unsloth Studio はlocal AI向けの オープンソース web UI で、GLM-5.2の実行をサポートする
  • 主な機能は以下の通り
    • MacOS、Windows、Linuxでローカルモデルを実行
    • GGUFおよびsafetensorモデルの検索、ダウンロード、実行
    • RAM offloadingとmultiGPU setupの自動検出
    • llama.cpp による高速なCPU + GPU inference
  • インストールコマンドは以下の通り
  • 実行コマンドは以下の通り
    • unsloth studio -H 0.0.0.0 -p 8888
    • 実行後、ブラウザで http://127.0.0.1:8888 またはユーザーごとのURLを開けばよい
  • HTTPSでStudioを安全に実行する方法も提供されている
    • 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 チュートリアルは UD-IQ2_M quantの実行を扱っており、最低 245GB RAM が必要
  • 高速なローカルinferenceのため llama.cpp を使用する
  • GPUがない、あるいはCPU inferenceのみを望む場合は -DGGML_CUDA=ON を -DGGML_CUDA=OFF に変更する
  • Apple Mac / Metalデバイスは -DGGML_CUDA=OFF で進めればよく、Metal supportはデフォルトで有効化されている
  • ビルド手順は以下の流れ
    • 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 のようにモデルを直接loadおよびdownloadするのにも使える
  • 希望するquantization typeの例として 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 実行例では2-bit GGUFの最初のshardを --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 generationを行う例が含まれている
  • llama-cli 実行後、「short Flappy Bird game」の生成を依頼した結果が続く
  • 生成された単一のHTML/JavaScriptゲームは Sunset Flier という名前を使用する
    • canvas、開始画面、ゲームオーバー画面、HUDスコア、NEW BEST!、RETRY ボタンを含む
    • 外部アセットなしで Web Audio API により flap、score、hit、die の効果音を生成する
    • ゲーム状態は READY、PLAYING、DYING、OVER の4段階で管理される
    • 最高スコアは localStorage.getItem('sunsetFlierBest') と localStorage.setItem() で保存される
  • ゲームロジックには重力、フラップのインパルス、ランダムなパイプ、衝突、パーティクル、画面揺れ、メダルシステムが含まれる
    • 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 でもうまく動作し、音も正常に機能したという文脈で提示されている

長いコンテキストとKV cache quantization

  • llama.cpp で長いコンテキストを活用するには、KV cache quantization によってメモリ使用量を削減する必要がある
  • llama.cpp は最近、より高い精度のためのKV cache quantization手法を追加しており、関連PRは https://github.com/ggml-org/llama.cpp/pull/21038
  • サポートされるKV cache dtypeは以下の通り
    • f32
    • f16
    • bf16
    • q8_0
    • q4_0
    • q4_1
    • iq4_nl
    • q5_0
    • q5_1
  • デフォルト値は f16
  • q4_0 はweightあたり約4.5ビットなので、コンテキスト長を 16 / 4.5、約 3.5倍 に拡張できる
    • 例えば従来10Kまで対応していたモデルなら、35Kまで可能な範囲に入る可能性がある
  • q4_1 はshifting parameterが追加されているため、より良い可能性があり、weightあたり5ビットで約 3.2倍 長いコンテキストを提供する
  • KV cache quantizationの実行例では、GLM-5.2 GGUFモデルとサンプリングパラメータを指定する
    • モデルパス: 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を2枚、llama.cpp -cmoeがあれば十分
    今はしょぼいDDR4 2400MHzだからそうなのであって、3200MHzなら9tk/sec前後までは上がりそう。CPUも32コアのEPYCなので悪くないが、もっと良い64コアなら11tk/secまで行けそう
    ハードウェア価格が狂う前に低予算で組んだが、毎日後悔している。それでもこのモデルを家で回せるのは素晴らしい。計画を立てたり、必要なコンテキストを全部集めたうえでワンショットのプロンプトに向いている
    ハードウェア全体の費用は組み立て当時で2,400ドルだったし、足を使って探せばこういうモデルを自宅で回す方法はある。なぜそんなことをするのか、クラウドAPIを使えばどれだけ節約できるのかとよく聞かれるが、Fableの件は独立して運用することの価値を示したと思う
    unslothチームに感謝、Q4_K_XLは堅実だ。量子化モデルを入手するなら、収まるのであればK_XLバリアントを選ぶのがよい

    • こういうホームブリュー実験で可能性の限界を押し広げる人たちには拍手を送りたい。暗号資産と同じで、AIも商売人の雑音に埋もれているが、レジリエンスを高める話はほとんどない
      オープンソースモデルを電動歯ブラシやTamagotchiに押し込もうとする研究者たちも同じく最高だ
    • その負荷を回し続けると最低でも600Wで、1日あたり約14kWhになる。kWhあたり0.2ドルなら1日2.80ドル、電気代だけで年間1,000ドルほどかかる
      プライバシーや自分で所有する満足感がどうしても必要でないなら、ハイパースケーラーに払ったほうが安くて楽で、トークン毎秒もずっと速い
      それでもこの方向性は好きだし、2年後にどんなセルフホスト向けハードウェアが出てくるのか楽しみだ
    • ほぼ同じ構成を持っている。RTX 3090を2枚、少し速いDDR4 512GB、64コアEPYC構成だ [0]
      かなり楽しく使っているし、このモデルも早く回してみたい
      ローカルモデル実行以外にも、この機材をメインのリモート開発基盤として使っている。Claude Codeのセッションはすべて今ではそこでtmuxを使って回している
      ずっと熱いノートPCに触らなくてよくなったので、指が喜んでいる。Claude Codeがバッテリーをものすごく食うというのもある
      [0] https://medium.com/@rathko/i-built-an-epyc-64-core-512gb-ram...
    • 「回すのに必要なのはこれくらい」という表現は、2,400ドルで買えた当時なら正しいかもしれないが、今の総額は1万ドルにはるかに近い
      RAMだけでほぼ5,000ドル、GPUもそれぞれ2,000ドル前後なので、現在の基準ではかなり高価なハードウェアだ
    • 私の理解では、このモデル向けのllama.cpp実装はまだDSA疎アテンションのサポートが欠けていて、かなり未完成だ
      そのため、学習時に使われていない別のメカニズムでモデルを動かすことになり、品質と性能が落ちるという結果も出ていた
      いずれにせよGLM 5.2は、多くの面でDeepSeek V4系統ほど興味深くはないと思う。DeepSeek V4はより進んだアテンション機構を使っていて、特に長いコンテキストでKVキャッシュのメモリを大きく節約できる
      その結果、コンシューマ向けプラットフォームでも大きなバッチ処理が可能になる。GLMにはそれがなく、基礎的な性能の構造としてはKimi 2.6とおおむね似たような印象だ。どちらも一般的なハードウェアでフル品質のまま合理的に回すには少し重すぎる

  • ほぼ行けそうだった。自分の機材はRAM 192GB + RTX 3090 24GBで、これをほとんど回せそうだった
    MoEオフロードにはVRAM 24GBとRAM 256GBが必要と書かれている
    https://unsloth.ai/docs/models/glm-5.2#usage-guide
    前のスレッドでは、誰かがハードウェアに50万ドルかかると言っていた
    https://news.ycombinator.com/item?id=48629970

    • 50万ドルはとんでもない過大評価だ。FP8やBF16で大規模な同時実行性を狙うならそうなることもある
      NVFP4でそこそこの速度、だいたい120 tok/sと同時実行性なら、現在の価格でも8万〜9万ドル程度で可能で、もっと安くなるかもしれない
      その金額があればRTX 6000 PRO Blackwellを6枚、まともなCPUとマザーボード、電源を買える。VRAMは576GBだ
      デコード40 tok/s、プリフィル約1200 tok/sでよければ5万ドル未満でも可能だ
    • 2ビットでは良い結果は出にくい。コーディングに理想的な範囲は少なくともQ8だ
    • 今回のブームが、90年代のようなコンピューティングハードウェアの進歩をもう一度引き起こしてほしいと思っている
      この20年間、ハードウェアが相対的に停滞していた理由のひとつは、企業がハードウェア更新を正当化できる用途が不足していたからだと感じる
      この15年間、資金とエネルギーの大半はモバイルに向かっていた
      安価なローカル推論は、サーバー、デスクトップ、ノートPCのメーカーが再び動き出すために必要な収益源になるかもしれない
    • RAMはあるがVRAMがない。24GB RAMの3090で、どれくらいの速度やtok/sが期待できるだろうか？
      24GB RAMを積んだGPUを1枚買ってみようか少し惹かれている
    • 興味本位でGeminiに聞いてみたら、量子化なしでまともなスループットを出すには50万ドル必要だと答えた

  • 「入る」というのはRAM 256GBに収まるという意味だが、強く量子化された状態であり、それでもなお非常に遅く動くはず
    見出しの数字はトークン生成速度ではなく、プロンプト処理速度を指している
    10 tok/s出ていてAPIが20〜30 tok/sなら見た目にはそれほど悪くないように見えるが、Mac Studioや全体をGPUに載せない機材は、純GPU構成よりプロンプト処理が20〜50倍遅い
    結局ここが、GPUに5万ドル使わないと実用にならない部分だ。しかも依然として強く量子化されたモデルを使うことになる

    • NvidiaのSparkのような機材には統合RAM 128GBがある
      こうした機材向けのデュアルポート版もある: https://www.nvidia.com/content/dam/en-zz/Solutions/networkin...
      つまり2 x 100GB/sポートで、もしかすると2 x 200GB/sかもしれない。実際に手元に来ればもっと分かるだろう
      こうした機材はクラスタリングも可能だ。2台や3台なら、IPサブネットを2つ使えばかなり分かりやすい。4台以上では、ネットワーク遅延がどれだけ響くかによってはスイッチが必要になるかもしれない
      Appleは大容量RAMを積んだMシリーズを忘れてしまったようだ。Apple Storeでは統合RAM 96GB超の構成が見当たらず、それでいて値段は腎臓ひとつ級だ

  • 複数の方向から同時に押し進められている: GB10を使う新しいAIデスクトップは比較的安価で、クラスタリングによってVRAM 1TBを構成できる
    Nvidia、AMD、Intel、Cerebrasなどが新ハードウェアを押し出しており、GLM 5.2のようなオープンソースモデルは信じがたいほど良くなっている
    DeepSeek V4 Flashのようなフラッシュモデルも非常に良くなっており、量子化も進歩している
    難しい仕事には大きなモデル、雑務には小さなモデルというように、異なるモデルを使い分けられるハーネスも可能になってきている
    なので、APIから離れたい人たちは、近いうちに妥当な価格のAIデスクトップクラスタを自宅でホストしながらOpus級の性能を使えるようになることを期待している

    • ここでの「比較的」という言葉はかなり多くを背負っている。GB10 1台が約4,000ドルなら、1TBクラスタは36,000ドルだ
      同等クラスのH200と比べれば安いが、OpenAIやAnthropicのRSUで資金が支えられていないホームラボには依然として手が届かない

  • コーディングも含めて十分に良いモデルをローカルで動かせる水準まで差が縮まってきている感覚があり、いくつかの企業は少し不安になるのではと思う。自分は間違っているだろうか?

    • 今RAM/GPU不足でなかったなら、その企業たちは今よりもっと不安だったはずだ
      ただ、現時点ではこのモデルを効果的に動かせる機材を負担できる人は非常に少ない。今後数年で大きく変わることもなさそうだ
      Z.aiがコーディング特化のGLM-5.2 Flashのような版を約80Bパラメータ規模で出せば、米国のフロンティア研究所はもっと心配するだろう
      全体として、中国のAI企業はより少ない資源、ときにははるかに少ない資源で同じことを行う方法を示しており、この流れが続けばフロンティア研究所を不安にさせるはずだ
      ただし中国のAI企業も、現在の主力モデルよりはるかに小さいのに強力なモデルを公開しないことで、自分たちの堀を守ろうとするだろう
      Alibaba Qwenは今まさにそういう位置に来ているようだ。最近はかなり静かで、最新の395Bモデルは大半の人が自宅で回すには大きすぎる。今回はより小さいモデルを出しそうな気配もない
    • そうは思わない。企業が社内開発向けにこうしたモデルをホストして動かすと決めるのは十分あり得る
      開発チームが10人くらいなら、LLMサーバーに5万ドルを一度投資する選択はかなり魅力的かもしれない
      トークン無制限、まずまずの性能、アップグレードの選択肢、製品統合の可能性がある
      一般にLLMを製品に組み込みたい会社にとっては、ローカルLLM方式のほうがなおさら魅力的だと思う。多少おバカなモデルでも、人々が製品に統合する多くの用途には十分良い
    • 脅威になるには必ずしもローカルで回る必要はない。多くの企業は、こうしたモデルをホストしてくれるサードパーティに料金を払う形を見ており、価格はフロンティア研究所の数分の一だ
    • RAM要件はいまだかなりつらい
    • ローカルで回すのは経済的ではない。プライバシー面では素晴らしく、楽しい趣味ではある
      だが選択肢は、極端に遅いCPUビルドと1万ドル分のRAM、9万ドル分のGPU、あるいは品質比較が難しい強い量子化モデルのいずれかだ
      趣味で1台作ることはできるが、それだけで経済性が変わるわけではない。それでも可能だという事実は興味深い

  • OpenAIとAnthropicはGLM 5.2のリリース時期を嫌うだろう
    魔法のような堀があったのではなく、単に先行者利益があっただけだということをかなり示している

  • RAM 192GBのMac Studioは使えるが、明記された最小RAMを下回っている
    特にMoEなのだから、高速ディスクにスワップして何とか動かせたりしないだろうか?

    • そこまで大量にスワップをかけると、NVMe SSDの総書き込み寿命(TBW)を消費して寿命を大きく縮める良い方法に見える
      性能も0.1 tok/sレベルで悲惨なものになるだろう

  • unslothが何百万人もの人にローカルAIを始めさせた働きは非常に評価しているが、この記事は少しダウンロードの釣りっぽく見える
    あまりに多くのレイヤーをCPUにオフロードすると、まったくうまくいかない。何度も試したが、結局は重いHugging Faceのキャッシュフォルダ群にrm -rfをかけることになった
    GLM 5.2の1ビットや2ビット量子化を大半VRAM外で動かすのが、VRAMに完全に載ったQwen3.6-27B Q8_0より実用性で上なのかも疑わしい

  • 記事で何と書いてあろうと、RAM 256GBの機材でこれを回そうとする人は、良い時間を過ごせそうにない
    もっと現実的な最低ラインは512GBだ
    幸い、価格が上がる前に安く買ったRAM 512GBのデュアルXeonワークステーション2台がホームオフィスにあるので、あれこれ実験できそうだ