オープンウェイト

この記事の日付について。 2026-09-26に調査・執筆し、公開日の2026-10-04に、Ollama公式ライブラリのタグ別サイズ(gemma4・qwen3.6・qwen3・qwen3.8・qwen3-next)、Ollama公式FAQの ollama ps の説明、筆者環境の ollama list / ollama show の表示を再確認して更新しました。本文中の「2026-09-26確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-26の記録です。 この記事でわかること 手元のメモリが8GB・16GB・24GB・32GB以上のとき、Ollamaでそのまま使える日本語向けの候補がどれか 候補をモデル名の「B数」ではなく、Ollamaで落ちてくる実ファイルのサイズで選ぶ理由 DGX Spark(統合メモリ128GB)で実際に使い続けているモデルと、品質不足でやめた構成の記録 Gemma 4・Qwen3.6・Qwen3のライセンスと、商用利用の根拠URL 今日中に動かし始めるための最短のコマンドと、コンテキスト長の落とし穴 結論から書きます。32GB以上のメモリがあるなら、筆者が日常運用している qwen3.6:35b-a3b(23〜24GB)が最初に試す候補です。24GBなら gemma4:26b(16〜19GB)か qwen3.6:27b(18〜19GB)、16GBでは gemma4:12b(7.7〜8.0GB)か qwen3:14b(9.3GB)、8GBでは qwen3:8b(5.2GB)か qwen3:4b(2.5GB)が現実的な線です。サイズはいずれもOllama公式ライブラリの表示値です(2026-10-04確認)。 ただし、ファイルサイズがメモリより小さいことは動作の保証になりません。実行時にはKVキャッシュや作業用のバッファも必要で、短いコンテキストから試して ollama ps で配置を確かめる前提の候補です。筆者が実機で品質まで確かめたのは32GB以上の帯だけで、8〜24GB帯の候補は公式サイズから選んだ段階です。どこまでが実測で、どこからが公式値からの逆算かは、表ごとに明記します。 1. 選び方の基準──「何B」ではなく「何GB」で決める ローカルLLMの紹介記事は、モデルを「7B」「27B」のようなパラメータ数で並べがちです。しかし、手元のPCに載るかどうかの大部分を決めるのは、量子化したあとのファイルサイズと、会話中に増えるKVキャッシュの合計です。これに実行時のバッファや、画像入力を使う場合の処理分が加わります。同じ「26B」でも、16ビットなら57.7GB、4ビット(Q4_0)なら14.4GBと4倍の開きがあります(Google AI for Developers『Gemma 4 model overview』最終更新2026-07-08)。 この記事では、次の4点で候補を絞りました。 メモリに載るか: Ollama公式ライブラリに表示されるタグ別サイズが、手元のメモリより十分小さいこと 日本語が使えるか: 開発元のモデルカードが多言語対応を明記していること。実測できたものは実測結果を優先 Ollamaで1コマンドで取れるか: 公式ライブラリにタグがあり、ollama pull だけで始められること 商用で使えるか: ライセンスが開発元の一次資料で確認でき、商用利用を妨げる独自条項がないこと 「量子化」は、モデルの重みを16ビットから8ビットや4ビットに丸めて小さくする処理です。Ollamaの標準タグは多くが4ビット前後に量子化済みで、q8_0 や bf16 の付いたタグはより大きく、元の精度に近い版です。たとえば qwen3.6:27b は標準で18〜19GB、q8_0 で30GB、bf16 で56GBです(Ollama library qwen3.6 tags 2026-10-04確認)。 2. 一次資料の対応表 この記事の数字は、次の一次資料と筆者の作業記録から取っています。 主張 一次資料 種別 確認日 gemma4の各タグのサイズ(e2b 4.6〜7.5GB、e4b 6.6〜9.5GB、12b 7.7〜8.0GB、26b 16〜19GB、31b 19〜20GB)とコンテキスト長 Ollama library gemma4 tags 公式ライブラリ 2026-10-04 qwen3.6の各タグのサイズ(27b 18〜19GB、35b-a3b 23〜24GB、q8_0/bf16版を含む) Ollama library qwen3.6 tags 公式ライブラリ 2026-10-04 qwen3の各タグのサイズ(4b 2.5GB、8b 5.2GB、14b 9.3GB) Ollama library qwen3 公式ライブラリ 2026-10-04 Gemma 4の5サイズと、BF16・SFP8・Q4_0別の重みのメモリ量 Google AI for Developers『Gemma 4 model overview』 公式ドキュメント 2026-09-26 Gemma 4はApache 2.0、事前学習140超・そのまま使える35超の言語 Hugging Face google/gemma-4-26B-A4B-it、Google Open Source Blog 2026-04-02 モデルカード・公式ブログ 2026-09-26 Qwen3.6-35B-A3B・Qwen3.6-27BはApache 2.0 Hugging Face Qwen/Qwen3.6-35B-A3B、Qwen/Qwen3.6-27B モデルカード 2026-09-26 Qwen3-8BはApache 2.0、100超の言語と方言に対応 Hugging Face Qwen/Qwen3-8B モデルカード 2026-09-26 Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる Ollama docs: Context length 公式ドキュメント 2026-09-26 llama.cppはMITライセンス、1.5〜8ビットの整数量子化に対応 GitHub ggml-org/llama.cpp GitHub 2026-09-26 DGX Sparkでの速度・品質の実測、登録モデルとサイズ、ローカルLLMでの記事生成をやめた経緯 筆者の作業記録(2026-04-03、2026-07-14、2026-08-04、2026-09-08) 実測・運用記録 2026-09-26 Ollamaのqwen3.6のページには、ライセンスの記載がありませんでした(2026-09-26確認)。ライセンスはHugging Faceのモデルカードで確認しています。 ...

この記事の日付について。 2026-09-27に調査・執筆し、公開日の2026-10-04に、Ollama公式FAQ(プライバシー・ollama ps・クラウド無効化の記述)、Ollamaのクラウドモデル一覧とドキュメント、Ollama library qwen3.6 tags、Qwen3-8Bの設定ファイルとモデルカード(コンテキスト長)、筆者環境の ollama list / ollama show の表示を一次資料で再確認して更新しました。本文中の「2026-09-27確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-27の記録です。2026-10-11に第7節・第10節・第11節とよくある質問6項目を追記しました(「2026-10-11確認」はその日の確認です)。 この記事でわかること ローカルLLMの定義と、ChatGPTのようなクラウドLLMとの違い Ollama・LM Studioを使うとき、入力が手元に留まる範囲と、通信が発生する操作 重み・量子化・実行ソフトの3つで、手元の推論が成り立つ仕組み 自分のPCで動くかを、パラメータ数とビット数から見積もる計算方法 ローカルLLMが向く作業と、向かない作業 ローカルLLMとは、大規模言語モデル(LLM)の推論を自分のPCや自社サーバーの上で実行する使い方です。モデルの重みファイルを手元に置き、実行ソフトがそれを読み込んで文章を生成します。 ChatGPTとの違いは「どこで計算するか」です。クラウドLLMは入力を提供元のサーバーへ送って処理します。ローカルLLMは、モデルを取得したあとなら通信なしで応答できます。LM Studioの公式ドキュメントは、ダウンロード済みモデルとのチャットで入力した内容は端末の外に出ないと明記しています(LM Studio Docs『Offline Operation』2026-09-27確認)。動かせるかどうかは、主にメモリ量で決まります。小型の量子化モデルなら一般的なPCも候補になります。ただし必要量は重みだけでなくKVキャッシュや実行バッファでも変わるため、空きメモリと実際のロード状態を確認します。 1. ローカルLLMとは──「ローカル」は推論の実行場所を指す LLMを使う処理は、大きく「学習」と「推論」に分かれます。学習は大量の計算資源で重みを作る工程です。推論は、できあがった重みに文章を入力して続きを出させる工程です。 ローカルLLMの「ローカル」は、このうち推論をどこで実行するかを指します。学習まで手元で行う必要はありません。Qwen・Gemma・Llamaのように、開発元が重みを公開しているモデル(オープンウェイトモデル)をダウンロードして使うのが一般的です。 そのため「ローカルLLM」という名前のモデルがあるわけではありません。同じQwen3-8Bでも、自分のPCで動かせばローカル、クラウドのAPI経由で使えばクラウドです。 2. 一次資料の対応表 この記事の事実関係は、次の一次資料と筆者の運用記録から取っています。 主張 一次資料 種別 確認日 ローカル実行時、Ollamaはプロンプトやデータを見ない。既定の待ち受けは localhost の11434番ポート Ollama FAQ 公式ドキュメント 2026-09-27(プライバシーの記述は2026-10-04再確認) Ollamaはモデルをインターネットから取得する。モデルの保存場所、既定で5分間メモリに保持 Ollama FAQ 公式ドキュメント 2026-09-27 Ollamaのクラウド機能は OLLAMA_NO_CLOUD=1 で無効化できる Ollama FAQ 公式ドキュメント 2026-10-04 Ollamaのクラウドモデルには公開重みのモデルも並ぶ Ollama cloud models、Ollama docs: Cloud 公式ライブラリ・ドキュメント 2026-10-04 Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる。ollama ps の列の意味 Ollama docs: Context length 公式ドキュメント 2026-09-27 LM Studioはモデル取得後はオフラインで動き、入力と文書は端末外に出ない。通信が要る5つの操作 LM Studio Docs『Offline Operation』 公式ドキュメント 2026-09-27 llama.cppは1.5〜8ビットの整数量子化、CPUとGPUの併用推論に対応。MITライセンス GitHub ggml-org/llama.cpp GitHub 2026-09-27 Qwen3-8Bは8.2Bパラメータ、36層、KVヘッド8、Apache 2.0。コンテキスト長は標準32,768トークン、YaRN併用で131,072トークン Hugging Face Qwen/Qwen3-8B、config.json モデルカード・設定ファイル 2026-09-27(コンテキスト長は2026-10-04確認) qwen3:8b の標準タグはq4_K_Mで5.2GB、q8_0は8.9GB、fp16は16GB Ollama library qwen3 tags 公式ライブラリ 2026-09-27 DGX Sparkでのモデル重みのサイズ・メモリ配分・生成速度 筆者の作業記録(2026-03-15、2026-08-04) 運用記録 2026-09-27 CPUのみの動作、Apple M系の対応、生成速度とメモリ帯域の関係 Ollama docs: macOS、llama.cpp Discussion #4167、Apple Newsroom 公式ドキュメント・GitHub・公式発表 2026-10-11 Qwen・Llama 3.3・Gemmaの商用利用条件、Ollamaのコーディング連携 各モデルのLICENSE、Gemma Terms of Use、Ollama docs: Integrations ライセンス文書・公式ドキュメント 2026-10-11 企画段階では、DGX Spark上でネットワークを遮断した状態の動作と、ollama ps・生成速度を新たに測る予定でした。この記事の公開時点では、その測定はまだ行えていません。そのため後半の数字は、過去の作業記録にある値と、一次資料からの計算値に限っています。 ...

この記事でわかること 専有VRAMという区分を持たない統合メモリ機(DGX Spark / GB10・128GB・aarch64)でも、LTX-2.3のローカル動画生成は動きます。本記事の所要時間はすべて筆者環境での一次実測であり、第三者が検証できる公開情報源はありません。再現条件は2026-07-18計測、LTX-2.3 22B distilled 1.1、量子化fp8-cast、24fps、Image-to-Videoで、1本あたり512×960・10秒(241フレーム)が116秒、704×1216・10秒(241フレーム)が182秒でした 導入に必要なディスクは重みだけで約71.5GB(SI表記)。aarch64向けのwheelは公式に明記されていませんが、PyPIのltx-pipelinesとtorch 2.13.0はそのまま入りました ComfyUI-LTXVideoが書く「32GB+ VRAM」という要件が、統合メモリ機では何に対応するのか。実測のMemFree推移の落ち込みで答えます 導入時に実際に出た3つのエラー(循環インポート・SiglipVisionModel・metaテンソル)と、システムごと落ちたOOMの原因・対処 LTX-2.3の重みライセンスと商用利用の線引き(年間売上1,000万ドルの閾値) 1. なぜローカルなのか、この記事は誰向けか クラウドの動画生成サービスは、たたむときは一斉にたたまれます。OpenAIはSoraをローンチから約半年で終了し、ディズニーとの提携も解消しました(/posts/openai-sora-shutdown-disney-deal/)。従量課金とアップロード制限に加えて、そもそもサービスが来年もある保証がない。これがローカル実行を選ぶ実務的な理由です。 この記事は次の条件に当てはまる人向けです。 Linux + NVIDIA GPU環境を自分で管理できる 重み約71.5GBを置けるディスクがある 1本あたり2〜4分の待ちを許容できる そして、この記事が特に扱うのは専有VRAMを持たない統合メモリ機です。DGX Spark(GB10)やApple Silicon系のように、CPUとGPUが同じ物理メモリを共有する構成では、「VRAM 16GB / 24GB / 32GB」という一般的な物差しがそのまま使えません。ここが検索上位のページで空白になっている部分です。 なお本記事はモデル比較記事ではありません。LTX-2.3が他の動画生成モデルより良いかどうかは扱わず、「入れて回す」ことだけを扱います。 2. 検証環境 項目 値 確認方法 機材 NVIDIA DGX Spark(GB10 Blackwell) ─ メモリ ユニファイドメモリ128GB表記(メーカー公称値) 筆者環境の実行ログのMemFree最大値は110.8GBでした。OSから見えるメモリ総量(/proc/meminfoのMemTotal)は今回記録しておらず、本記事では総量の値を用いません 専有VRAM なし(CPU/GPUが同一メモリを共有) ─ アーキテクチャ ARM64(aarch64) ─ カーネル Linux 6.14.0-1015-nvidia 筆者環境のuname -r出力 Python 3.12 筆者環境のvenvパスlib/python3.12/ PyTorch 2.13.0(cu13系wheel) 筆者環境のpip show torch／導入ログ CUDA関連 cuda-toolkit 13.0.3.0 / nvidia-cuda-runtime 13.0.96 / nvidia-cudnn-cu13 9.20.0.48 / triton 3.7.1 筆者環境のpip list | grep -E 'cuda|cudnn|triton'の解決結果 パイプライン PyPI ltx-pipelines 1.0.0(ltx-core 1.0.0同梱) 導入ログ モデル LTX-2.3 22B distilled 1.1 + spatial upscaler x2 1.1 + Gemma-3-12B(テキストエンコーダ) ─ 量子化 QuantizationPolicy.fp8_cast() 実行ログquantization=fp8-cast 検証日 導入・実測とも2026-07-18。資料の再確認は2026-09-08 ─ この表のカーネル・Python・PyTorch・CUDA関連の各バージョンは、いずれも筆者環境で実際に解決された構成の記録であり、公開情報源で第三者が検証できる性質のものではありません。ディストリビューション名とバージョン文字列は今回の記録に残っていないため、カーネル版のみを載せます。x86 + 単体GPUの比較機は手元にないので、他環境との横並び比較はこの記事では行いません。 ...

何が起きたのか NVIDIAは2026年9月3日、Hugging Faceを買収することで合意したと公式ブログで発表しました。取得額は 12,930,300,000 ドルです（NVIDIA Blog 2026-09-03）。同ブログはHugging Face Hubの規模として、開発者・研究者・クリエイター1,800万人超、共有されたモデル300万件超、データセット50万件、アプリケーション100万件、利用企業20万社超という数字を挙げています。 この金額には、Hugging Faceの名前と結びつく数値の一致があります。上位6桁の 129303 は、抱擁する顔の絵文字 🤗 のコードポイント U+1F917 を10進数に直した値と一致します。Unicode Consortium公式のUnicode Utilitiesで確認すると、U+1F917 の正式名称は HUGGING FACE、追加バージョンは Unicode 8.0、General_Category は Other_Symbol、10進表記は 129303 です（Unicode Utilities）。Hugging Faceのロゴそのものが、値札の先頭に並んでいる構図です。 ただし記事の本題はここではありません。同じ日にNVIDIAがSECへ提出したForm 8-Kを読むと、この12,930,300,000ドルが一つの塊ではないこと、そして「オープンであり続ける」という約束が、公式ブログとSEC提出書類とで語られている粒度がかなり違うことが分かります。 129303を検算する 16進の 0x1F917 を10進に展開すると、次のようになります。 $$ \mathrm{0x1F917} = 1 \cdot 16^4 + 15 \cdot 16^3 + 9 \cdot 16^2 + 1 \cdot 16^1 + 7 \cdot 16^0 $$$$ = 65{,}536 + 61{,}440 + 2{,}304 + 16 + 7 = 129{,}303 $$取得額 12,930,300,000 の上位6桁は 129303。以降は 0 が5つ続くだけなので、金額は $129{,}303 \times 10^5$ ドル、つまり「🤗 のコードポイント × 10万ドル」という構造をしています。金額を先に決めてから桁を合わせたのか、コードポイントを先に置いたのかは公表資料からは判断できません。 ...

何が起きたのか ゼロショット音声クローンに対応した120MパラメータのTTS（text-to-speech、テキスト音声合成）モデル sopro-v2-turbo が、Apache 2.0ライセンスで公開されました。開発者は samuel-vitorino 氏で、モデルは Hugging Face でホストされています（Hugging Face モデルカード）。 モデルカードが示す速度は、次の3つです。 M3 CPU でオフライン 0.24 RTF、ストリーミング 0.21 RTF H100 で 0.07 RTF ラップトップCPUでのストリーミング時、最初の音声が出るまで**（TTFA）約300ms** Hugging Face の API が返すリポジトリのメタデータでは、モデルの作成日時は 2026-08-25 10:56:29 UTC、最終更新は 2026-08-27 00:39:57 UTC、API が F32 として集計する Safetensors パラメータ数は 121,574,193 です（Hugging Face API）。PyPI 側の sopro パッケージも 2.0.0 から 2.0.5 までが 2026年8月27日に一斉リリースされており（PyPI sopro）、公開は8月末の出来事です。 「CPUで実時間の5倍速」の出所は、開発者による r/StableDiffusion への告知投稿です。タイトルは「We open-sourced Sopro V2 Turbo - a 120M voice cloning TTS model that runs 5x faster than real time on CPU」で、当ブログのトレンド収集が8月30日朝に取得した記録と一致します。一方、モデルカードが記載しているのはオフライン 0.24 RTF（約4.2倍）とストリーミング 0.21 RTF（約4.8倍）で、「5倍」という数字そのものは配布物には現れません（Hugging Face モデルカード）。$1/0.21 \approx 4.76$ なので、ストリーミング値を整数に丸めた表現とみられます——ただし投稿者が丸め方を明言したわけではありません。以下では、この「5倍」と公称 RTF の数値上の対応を検証します。 ...

何が起きたのか Z.ai が 2026-08-26 に GLM-5.3-Flash を公開しました。総パラメータ320B・活性18Bの MoE(Mixture-of-Experts、トークンごとに一部の専門家だけを動かす方式)で、ライセンスは MIT、ウェイトは Hugging Face の zai-org/GLM-5.3-Flash に置かれています。モデルカードには「With 320B total parameters and just 18B active parameters」と明記されています。 同時に、OpenRouter と OpenCode へ提供元を伏せて投入され話題になっていた ox-alpha が、このモデルのプレビュー版だったことが公式に認められました。Z.ai 公式ドキュメントは「we tested GLM-5.3-Flash anonymously as ox-alpha on OpenCode and OpenRouter to gather user feedback」と書いています（Z.ai 公式ドキュメント）。TechCrunch も Z.ai が Ox Alpha の開発元であることを認めたと報じていますが、同記事が引いている確認は Bloomberg News の取材に対する Z.ai の回答であり、TechCrunch が独自に取ったものではありません（TechCrunch 2026-08-26）。Z.ai 公式アカウントの発表投稿も「Previously previewed as Ox Alpha, running entirely on Chinese AI chips」と書いており、匿名プレビューと自社の関係、および中国製AIチップ上での運用を明言しています（Z.ai 公式X 2026-08-26）。 筆者が本稿で取り上げたいのは、話題性そのものではありません。公称値として掲げられている数字と、モデルカードの脚注に書かれた測定条件が、ベンチマークごとにばらばらだという点です。 公称1Mコンテキストと、ベンチマークごとに違う評価条件 公式発表と各所の紹介文が揃って掲げているのは「1M-token context window」です。設定ファイル側にも対応する値があります。Hugging Face の config.json では設定上の最大長 max_position_embeddings が 1,048,576 で、$2^{20}$ ちょうどです。これは実装が受け付ける上限の宣言であって、その長さで測った品質を示す値ではありません。 ...

何が起きたのか Alibabaの Qwen チームが 2026-08-14、270億パラメータのdenseモデル Qwen3.8-27B を Apache 2.0 で公開しました。第三者測定機関 Artificial Analysis は同モデルの Intelligence Index を 52 と算出し、オープンウェイトの同クラス135モデル中1位と位置づけています（Artificial Analysis）。 この52という数字が話題になったのは、クローズドのフロンティアモデルと並んでしまったからです。Artificial Analysis の比較ページ上で、GPT-5.6 Luna（max）の Intelligence Index も 52（Artificial Analysis 比較ページ）。DeepSeek V4 Flash 0731（Reasoning, Max Effort）も 52 です（Artificial Analysis 比較ページ）。 ただし「互角」という言葉が指す範囲は、思ったより狭いです。以下、公称値・第三者指数・手元の実機という3層に分けて確認します。 第1層: 公称値は前世代から跳ねている Hugging Face の公式モデルカードに並ぶ数値は、いずれもAlibaba自社報告です（Hugging Face Qwen/Qwen3.8-27B）。前世代 Qwen3.6-27B との差分が大きいものを抜き出します。 ベンチマーク Qwen3.8-27B Qwen3.6-27B Qwen3.7-Plus Opus 4.6 Max SWE-bench Pro 61.7 53.5 57.6 53.4 DeepSWE 1.1 42.2 13.3 14.2 — QwenSWEBench 79.0 49.3 59.2 63.8 Terminal Bench 2.1 73.0 63.4 64.0 78.2 LiveCodeBench v6 90.3 83.9 89.6 88.8 OSWorld-Verified 84.3 63.9 73.3 72.7 GPQA Diamond 89.2 87.8 90.3 91.3 HLE 30.8 24.0 34.7 40.0 DeepSWE 1.1 の 13.3 → 42.2 は3倍以上です。一方で GPQA Diamond は 87.8 → 89.2 とほぼ横ばい、HLE は 30.8 で Opus の 40.0 に届いていません。伸び幅が大きいのはエージェント的なコーディングとGUI操作のタスクで、GPQA Diamond と HLE（24.0 → 30.8）はそれほどではない、という読み方になります。この非対称性は後処理（ポストトレーニング）に重点を置いた世代だからではないか、というのが筆者の推測です（Alibaba がそう説明しているわけではありません）。 ...

何が起きたのか Z.ai(智譜AI)が2026-08-14に GLM-5.3 を公開しました。特徴は2点あります。1つ目は、ベースモデルを前世代 GLM-5.2 と同じまま据え置き、性能向上をポストトレーニング由来と説明していること（MarkTechPost 2026-08-14）。そのベースの公式表記は744B-A40B、総パラメータ744Bのうちアクティブ40BのMoEです（Z.ai 公式リポジトリ）。2つ目は、オープンウェイトを掲げてきた同社が、今回はウェイト公開をローンチの約2週間後に置いたことです。公式ブログの記述は「We will release the weights in two weeks after launch, once safety evaluation and hardening are complete.」で、安全性評価とハードニングの完了を条件としています（Z.ai 公式ブログ）。 同じ発表の中で Z.ai は「As we scaled post-training, cyber capability developed faster than we expected.（ポストトレーニングをスケールさせる中で、サイバー能力が予想より速く伸びた）」とも書いています。ただし公式ブログはこの2つを別の箇所に並置しているだけで、サイバー能力の伸びがウェイト公開の時期を決めた、という因果までは明示していません。両者を因果として報じているのは Axios など媒体側です。 なお公式ブログ https://z.ai/blog/glm-5.3 は、通常のページ取得では本文が得られません。初期HTMLは598バイトの空シェルで、本文・比較表・脚注はページが読み込む JavaScript バンドル（/blog/assets/glm-5.3-*.js）に収録されています。本記事はこのバンドルを直接取得し、スコア表と評価条件の脚注を確認したうえで書いています。以下の数値は、特記のない限り公式ブログの比較表と脚注によるものです。 数字の分解:コーディングとエージェント 公式ブログの比較表から、GLM-5.2 との対比と、同表に並ぶクローズド勢の値を抜き出すと次のとおりです。表の列は GLM-5.3 / GLM-5.2 / Kimi K3 / DeepSeek-V4 Pro-0813 / Qwen3.8-Max / Opus 4.8 / Fable 5 (w/ fallback) / GPT-5.6 Sol の8モデルです。 ...

何が起きたのか Metaは2026年8月10日、300億パラメータ（公称。モデルカード表記では約29.6B）のオープンウェイトモデル「Muse Glimmer」をApache 2.0ライセンスで公開しました。なおMetaはライセンスとは別に、アクセス・利用へ適用されるUsage Policyを公開しています（後述）。公式リサーチブログは冒頭でこのモデルを「a 30-billion-parameter model optimized for always-on local agent workflows」と定義しており、汎用チャットではなく常時稼働のローカルエージェントを名指しした位置づけになっています（Meta AI Research 2026-08-10）。 学習方法についても公式ブログは踏み込んでおり、「We trained Muse Glimmer on Muse Spark’s outputs using logit distillation, leveraging a similar data mix as the teacher」と記述しています。上位モデルMuse Sparkのロジットを教師とした蒸留モデルであることが明記されている点は、後述するベンチマークの偏りを読むうえで効いてきます。 配布は Hugging Face 経由で、llama.cpp・MLX・ExecuTorch への統合が予告されました。このうち llama.cpp 対応は公開当日の2026年8月10日にマージ済みで、build b10353 以降で利用できます（meta-models/Muse-Glimmer-30B-GGUF）。言語については「more than 100 languages」のデータで学習したとされていますが、全言語で評価済みではなく、手厚くサポートされない言語では性能が落ち得るとモデルカードのLimitationsに明記されています。 本稿では「30Bが単一のコンシューマGPUで常時稼働する」という主張が、どの数値によって成立しているのかを、重みサイズとKVキャッシュの両側から検証します。そのうえで、勝っているベンチと負けているベンチがきれいに割れている点を確認します。 55.7GBから15.9GBへ──量子化の刻み方 公式ブログは、フル精度で「over 55 GB」の重みがK-Quant圧縮で「under 20 GB」に収まると述べています。Metaが24GB VRAM向けとして検証・配布する公式GGUFはK-Quant-17GB（実サイズ16.8GB）です（meta-models/Muse-Glimmer-30B-GGUF）。これとは別に、第三者のUnslothが独自の量子化ビルドを公開しており、ビット幅ごとの刻みはそちらで確認できます（unsloth/Muse-Glimmer-30B-GGUF）。 量子化 サイズ UD-IQ2_XXS（2bit） 10.7 GB UD-Q3_K_XL（3bit） 13.4 GB UD-Q4_K_XL（4bit） 15.9 GB UD-Q5_K_M（5bit） 19.2 GB UD-Q6_K_XL（6bit） 26.3 GB Q8_0（8bit） 29.6 GB BF16 55.7 GB 注意が要るのは、この55.7GBが何のサイズかという点です。UnslothのBF16 GGUFは合計55.7GBですが、これは視覚エンコーダを含まないテキストモデルのサイズです。モデル全体は約29.6Bパラメータで、公式のBF16 safetensorsは合計約59.6GB（meta-models/Muse-Glimmer-30B）。両者の約3.9GBの差は、主に別配布される約1.8Bパラメータの視覚エンコーダに対応します。「24GB級のGPU1枚」を一次的に裏付けているのはUnslothの15.9GBではなく、Metaが24GB向けとして検証している公式K-Quant-17GB（16.8GB）のほうです。 ...

何が起きたのか 2026-08-06 18:44 UTC（日本時間 8月7日 03:44）、Hacker News に「Qwen3.8 Max now ranked as the best overall model by agentic index」というスレッドが立ち、400ポイント超を集めました（Hacker News、2026-08-07 確認。ポイントは加算され続ける値です）。リンク先は Artificial Analysis の Agentic Index フィルタ付きリーダーボードです。 ところが、同じスレッド内でユーザー d2p が、数分のリロードを挟んで順位が反転したことをスクリーンショット付きで報告します。最初は Qwen が 55.4、Opus Max が 55.3。リロード後は Opus Max が 59.2、Qwen が 58.4。投稿者の apitman は「Welp. That didn’t last long.」と応じています。 種明かしはスレッドに現れた「Artificial Analysis チームの George」と名乗るユーザー（HN ID: Gcam）によるもので、投稿から5時間足らず後の同日 23:26 UTC（日本時間 8月7日 08:26）に「We published an update today that does result in a change of the order, Qwen3.8 Max to second rather than first.」と説明しました。指すのは同日公開の Intelligence Index v4.1.1 です（Artificial Analysis 2026-08-06）。なお、Qwen が実際に何時間首位に表示されていたかは、公式にも HN スレッドにも記録がありません。 ...