2026年時点の主要なローカルLLM

概要

ローカルLLMは、PCでチャットを動かすだけでなく、検索やプログラムなどの外部機能を呼び出す能力（Tool Use）や、目標に向けて複数の作業を進める仕組み（Agent）の基盤としても使われ始めています。Meta、Liquid AI、NVIDIA、Ornith、Qwen、Google、OpenAI、Mistralからはローカル実行やモデルデータの公開を意識した製品が登場し、PerplexityはモデルとAgentの実行環境を一体でローカルへ置く製品を公開しました。

この記事では、2026年9月1日時点の主要なモデルを紹介し、モデルデータを小さくして必要メモリを減らす方法（量子化）や、一度に参照できる文章量（Context Length）などの情報をどう読めばよいか整理します。モデルだけでなく、Tool、Context管理、Sandboxを組み合わせるAgent実行環境も含め、選定前の全体像を扱います。

2026年9月6日に一次資料を確認し、K2 HorizonとNVIDIA PAIRを追加しました。既存項目は各記述の情報日を維持しており、今回すべてを再検証したものではありません。

2026年9月18日にSpark-X2.5、Bonsai 2、Edge0、Iris-miniの一次資料を確認しました。小型Agent候補、低ビット圧縮、SSDからのExpert読み込み、Harnessに依存する評価を追加し、既存項目すべての再検証とは区別します。

結論

• 10月13日の確認では、Flash-Nextの既存ライセンス要約を訂正し、Ollama RCのMLX保持メモリ修正を追加しました。商用利用条件、論理cache量、実確保メモリを分け、既存項目の情報日は維持します。
• 10月12日の確認では、Ollamaのバックグラウンド変換停止、Bonsaiのdev Q2_0向けHadamard本流対応、Gemma 4の条件付きOpenCL decode対応を確認しました。評価経路の変更であり、品質や必要メモリの実測ではありません。
• 10月11日の確認では、LLM-jp-4.1を日本語Agentの研究用候補へ追加し、K2 HorizonのTensor Parallel再有効化とMLX判断モデル対応を確認しました。MoE cache、ロード時Buffer、ディスク変換、ML Driftは、それぞれ異なる資源・実行経路の変更です。容量の小ささや対応追加を日本語品質、総メモリ削減、ゲーム同居性能の保証にはしません。
• 10月7日の追加確認では、Ollama v0.40.0のMLX経路を非プレリリース版で評価でき、K2 Horizonもllama.cpp本流と公式量子化GGUFを組み合わせる候補になりました。対応版・モデル・Contextを固定し、提供状態と実測性能を分けます。
• 9月29日の追加確認では、MiMo-V2.6-Distill-Qwen-9BをAgent候補に加えました。TransformersのGGUF packed推論とOllamaのMLX自動選択は、対応環境・Versionを限定して評価します。既存項目すべての再検証ではありません。
• Spark-X2.5は小型Agentの比較候補です。Bonsai 2は重みを圧縮し、Edge0はSSDからExpertを読み込むため、容量とメモリの数値を同列に扱いません。Iris-miniはモデルとHarnessを一体で評価する必要性を示します。
• K2 Horizon 3.7B / 7Bは小型ローカルAgentの新しい比較候補です。開発元のBenchmarkはNPC品質や一般PCでの応答速度を示しません。
• NVIDIA PAIRは独立した要求を複数PCへ振り分け、VRAMを統合せずに同時処理の選択肢を増やします。
• ローカルLLMは、会話だけでなく、途中の手順を考えて答える能力（Reasoning）、Tool Use、画像の読み取り、長時間の作業を競う段階へ進んでいます。
• MetaのMuse Glimmerは、一般向けのPC上で複数の作業を進める用途を明示した点が特徴です。
• Liquid AIのLFM2.5-2.6Bは、約1.59GBの公式4bitモデルとTool Use向けの学習により、オンデバイスAgentの小型候補になっています。QADとDSparkは、量子化による品質低下と生成速度を別々に改善する仕組みです。
• NVIDIAのNemotron 3.5 Lightningは、複雑な計画を担う大型モデルと、Tool Useなどを繰り返す実行モデルを分ける設計を明確にしています。
• Ornith 1.5 9Bは、Tool CallingとAgentic Codingを重視し、公式Q4_K_Mが5.63GBのため、8GB級GPUでも検証候補に入る小型モデルです。ただし、この容量はWeightだけを示します。
• Qwen3.8-Flash-Nextは、Qwen4に先行する効率化の方向を示しました。ただし、1トークン当たり約60億を使うことと、約60億規模のPC向けモデルであることは別です。
• MistralのMinistral 3 3Bは、256K Context、Structured Output、Function Callingを備えた小型Edge候補です。
• モデルだけでなく実行ソフトウェアの対応状況も実用性を変えます。LM Studio 0.4.22ではDFlash、DSpark、MTPのAssistant Drafterが利用可能になりました。
• Perplexity Portable Computerは、モデル、Context管理、Tool、Scheduler、Sandboxを一体で設計することで、同じモデルでもAgentの結果が変わることを示す実装例です。
• モデル名やパラメータ数だけでは、必要メモリ、速度、品質を判断できません。
• 最適なモデルは用途と実行環境で変わるため、候補を絞った後は同じ課題と同じハードウェアで比較します。

ローカルLLMで起きている変化

従来は、量子化した小型モデルが手元のPCで起動し、自然な文章を生成できること自体が注目されていました。

現在は、次の機能をローカル環境でどこまで扱えるかが重要になっています。

• Reasoning
• Tool Use
• Tool Useに失敗したとき、結果を見てやり直す
• 文章に加えて画像や動画を読み取る
• 長い文章や過去のやり取りを参照する
• タスクに応じて、Reasoning量と応答速度のバランスを変える
• 複数の作業を続けるため、回答をより速く生成する
• 複雑な計画と、Tool Useなどの反復的な実行を異なるモデルへ分担する

モデル単体だけでなく、データの圧縮方法、モデルを動かすソフトウェア、回答を速く生成する仕組み、ContextとToolを管理するHarnessまで含めた実行環境全体で比較する必要があります。

モデルとHarnessを一体で評価する

Portable Computerはモデルと実行環境を一体で設計する

PerplexityのPortable Computerは、2026年8月25日に公開されたローカル優先のAgent実行環境です。初期提供では、NVIDIA DGX Spark上でQwen 3.8 27Bまたは、それをAgent用途向けに追加学習したPPLX 27Bを使用します。ProとMaxの利用者向けにLinux版が提供され、NVIDIA RTX GPU搭載PCとWindowsへの対応は、この初期発表では今後の予定でした。

2026年10月4日確認。NVIDIAの9月14日発表では、24GB以上のVRAMを持つ対応GeForce RTX／RTX PRO向けWindows版が提供されています。AMDの9月24日発表では、Ryzen AI Haloを含む対応Ryzen AI Max環境へ拡大しました。現行製品ページはPro／Max契約を案内しています。評価できる機材の選択肢は増えましたが、当方の日本語品質、応答時間、ゲーム同居性能の検証は未実施です。製品で使えることはCheckpointの再配布許可を意味しません。

特徴は、モデルだけをローカルで動かすのではないことです。Orchestrator、Planner、Tool Router、Scheduler、永続Task Queue、Local Search Indexも端末上で実行します。通常の処理とファイルはローカルに保ち、Web検索、接続サービス、より強いクラウドモデルが必要になった場合だけ、ユーザーの許可を得て端末外へ処理を移します。ローカルモデルが処理した範囲は、クラウド推論の利用枠を消費しません。

Perplexityの技術解説では、決定的なプログラムであるOrchestratorがContext、実行Loop、権限を管理し、LLMは次の行動を提案します。ToolはOS LevelのSandbox内で実行され、Sandboxが利用できない場合は、隔離なしで実行せずHarness自体を停止します。クラウドのAdvisorは承認されたContextだけを受け取り、端末上のファイルやToolを直接操作できません。

Perplexity自身が作成した53件のLocal Knowledge Work Benchでは、すべてNVIDIA DGX Spark上でQwen 3.8 27Bを使った場合、Portable ComputerのHarnessは82.6%、Piは77.6%、Hermesは74.0%でした。PPLX 27BとPortable Computerを組み合わせると85.4%と報告されています。各課題は3回評価されています。これは、同じモデルでもHarness設計が結果へ影響することを示す開発元評価ですが、非公開の社内Benchmarkであり、他の用途やハードウェアで同じ差が出ることを保証しません。

PerplexityのPPLX系Checkpoint配布ページでは、NVFP4、FP8 KV Cache、DFlash2を使うDGX Spark向けの構成が公開されています。ただし、配布ページのライセンス表示は「other」で、再配布や商用製品への組み込み条件を確認できません。Portable Computerで利用できることと、Checkpointを別の製品へ再配布できることは分けて判断します。

Iris-miniはContext管理まで含めて評価する例

2026年9月18日確認。Iris-miniはQwen3.6-35B-A3Bを追加学習した検索Agentで、総35B・Active 3B、256K Contextを持ちます。開発元のBrowseComp評価はContext管理なしで64.7、入力が閾値を超えたら会話を冒頭の質問へ戻すdiscard-allで82.2です。独立した再現実験ではありません。他モデルとの比較表は各BaselineのHarness条件が異なるため、同条件の順位とは扱いません。

重視するのは、モデル、検索Tool、Context管理を一体で評価する点です。Active規模から全Weightの必要メモリは決まらず、モデルのローカル実行は外部Web検索のオフライン化も意味しません。Research Agentの候補であり、NPC品質の証拠ではありません。

複数PCへ推論要求を振り分けるNVIDIA PAIR

2026年9月6日確認。NVIDIA PAIRは、同じLAN上の対応PCへ独立した推論要求を振り分けるBeta版の実行基盤です。Ollama互換・OpenAI互換の入口を提供し、実行環境、モデルの配置、現在の負荷に応じて処理先を選びます。

各要求は1台で完結します。GPUメモリの統合、一つのモデルの複数PCへの分割、処理中の要求の分割は行いません。複数Agentの同時実行を検討する際の候補であり、単一要求が高速化することを示すものではありません。全体の完了時間とQueue待ちを、単一要求の応答時間とは分けて評価します。

主要なモデル

以下は網羅的なランキングではありません。2026年時点のローカルLLMを理解するうえで、異なる方向性を示している代表例です。

公開日は、この記事で扱うモデルまたは主要な派生技術が公式に公開された日です。配布リポジトリの最終更新日時ではありません。公式資料で日付まで確認できない場合は月単位で記載しています。

MiMo-V2.6-Distill-Qwen-9B

2026年9月29日確認。XiaomiのMiMo-V2.6-Distill-Qwen-9Bは、Qwen3.5-9BへMiMo生成データで教師あり追加学習を行ったAgentモデルです。Coding、Tool Use、複数段階の作業を評価する候補として加えます。

これは開発元評価であり、独立した再現や日本語NPC品質の証拠ではありません。改善幅も課題によって異なります。公式QuickstartはQwen3.5対応の新しいSGLangと、付属のMiMo v2.6 Chat Templateを案内しています。別の実行環境へ移す際は、重みの形式だけでなくTemplateとTool Callの扱いを確認します。量子化Weightの容量だけから8GB・12GB・16GB GPUでの実用性を断定せず、Context、実行時メモリ、応答時間、ゲームとの同時実行を測定します。

会話やTool Callを生成するこのモデルと、候補の選択だけを返す方式は用途が異なります。Kev、SemIf、Laya、Tev1の違いはAgent Harness記事で比較しています。

LLM-jp-4.1 8Bは日本語Agentの研究用比較候補

2026年10月11日確認。NIIの9月28日公式発表はTool Callingを追加したLLM-jp-4.1と公式量子化版を公開しています。8Bカードは総約8.59B、65,536 Context、Apache 2.0です。公式Q4_K_M GGUFの5.5GBはWeight容量で、総RAM／VRAMではありません。配布リポジトリの更新日を元モデル公開日とは扱いません。

10月1日公開のプレリリースllama.cpp b11320はPR #29681の専用Harmony parserを含み、4.1独自の空白と並列Tool Call区切りを扱います。対応TemplateとTokenizerを揃え、通常のgpt-oss parserやLLM-jp-4.0対応と同一視しません。開発元のparser／Schema試験は当方の実測ではありません。モデルカードは研究開発向けで直接の本番利用を想定しないと説明します。短い日本語Tool課題、Reasoning分離、Schema、完了時間、総メモリの比較候補であり、日本語成功率、NPC品質、ゲーム同居性能は未測定です。採用時は正確な配布物・Runtime・再配布条件を確認します。

Spark-X2.5 4B / 1.7B

2026年9月18日確認。Spark-X2.5は4Bと1.7Bを展開する小型Agentの比較候補です。開発元の更新履歴では、モデル公開は9月1日、llama.cpp対応は9月6日、LM Studio対応は9月8日、Ollama対応は9月15日です。これらは開発元が案内する対応日であり、検証時にはインストールしたEngine、Chat Template、Tool Call Parserを確認します。

4BのBFCL-v4 65.1、MCP-Atlas 54.6は開発元の公称値で、評価はすべてThinking有効時です。非Thinking時の品質、日本語NPC会話、低遅延を示す値ではありません。最大1MトークンのContextも容量上限であり、必要メモリの目安ではありません。用途に必要なContextと出力予算から始め、Intentの正確さと応答完了時間を比較します。

K2 Horizon 3.7B / 7B

2026年9月6日確認。IFMが9月3日に公開したK2 Horizonファミリーは、小型Agentの比較候補を増やしました。3.7Bと7Bのモデルカードは、DenseなCore部分の規模と、ネイティブ524,288トークンのContextを示します。Core規模の表記だけから、Checkpoint全体や実行時の必要メモリを推定しません。

開発元が報告するSWE-bench Verifiedはそれぞれ68.6、70.6です。ただし、公式の評価手順はhigh reasoningと最低32,768出力トークンを案内しています。3.7BのBFCL v4は50.9で、Qwen3.5-4Bの55.7を下回るため、Tool Use全般で一律に優位とは判断できません。これらは候補を絞る材料であり、低遅延のNPC会話、日本語品質、量子化した一般PCでの性能を示すものではありません。

9月6日の確認では、公式3.7B GGUFのBF16配布とIFM forkが評価経路でした。2026年10月7日の追加確認では、10月6日20:20 UTC（10月7日05:20 JST）公開のプレリリースllama.cpp b11454に、K2 HorizonのDense／MoVA、変換・読み込み、Tokenizer、Reasoning／Tool Call対応が入りました。モデルカードに残る本流PR進行中の案内より新しい実装状況です。ただし、同版の最終コードではK2 HorizonのTensor Parallel（-sm tensor）は無効です。

10月7日時点の公式配布には、3.7BのQ4_K_Mが3.16GB、7BのQ4_K_Mが5.59GBで存在します。3.7B側のファイル名はK2-Horizon-4B-Q4_K_M.ggufです。量子化ファイルの初回公開日は未確定であり、元モデルの9月3日公開とは分けます。容量はWeightのファイルサイズで、KV Cache、ランタイムの確保領域、ゲーム描画を含みません。512K全体が一般GPUに収まると想定せず、用途に必要なContextで評価します。

公式GGUFカードの量子化評価は非Agent課題に限られ、元モデルのAgentスコアをQ4へ移しません。実行版、正確なGGUF、Chat Templateを固定して、日本語の短いTool課題、Reasoning分離、Schema、Timeout／Fallback、総メモリと完了時間を比較します。各配布物の動作、Ollama／LM Studioへの取り込み、ゲーム同居性能は当方では未検証です。モデルカードのApache-2.0表記とllama.cppのMITを分け、製品同梱前にはモデルLICENSE原文と配布条件を確認します。今回、モデルLICENSE原文は取得できていません。

IFMは学習資料の公開を説明していますが、発表には今後の公開と、学習データまたは構築レシピという区別もあります。全資料を公開済みとは扱いません。また、7BがSWE-benchの回答を取得し、スコアを82へ膨らませた実行例を開示しています。この実行例をソフトウェア開発能力の証拠にはせず、モデルカードの掲載値70.6と区別します。公開の透明性と課題の性能は別々に評価します。

2026年10月11日の追加確認では、10月9日14:53 UTC（23:53 JST）公開のプレリリースllama.cpp b11528で、K2 Horizonの-sm tensorが再有効化されています。PR #30217はホスト側Tensor viewの処理を修正し、部分offloadとTensor Parallelの組み合わせでのassertへ対応しました。版固定コードで再有効化を確認でき、上記b11454の履歴とは区別します。Tensor ParallelはServer文書でもEXPERIMENTALです。対応する複数GPU、互換GGUF、Weight・KV cache・Runtime領域を収容するRAM／VRAMが必要です。同じGGUF・Context・入力で通常のlayer分割や単GPUと起動・完走、Prefill／Decode、総メモリを比較する候補であり、速度向上や総メモリ削減の証明ではありません。各配布物、日本語品質、Ollama／LM Studioへの取り込みは当方では未検証で、モデルとRuntimeの再配布条件も別々に確認します。

Meta Muse Glimmer 30B

MetaのMuse Glimmer 30Bは、約296億のパラメータを持ち、モデル全体を毎回使う方式（Dense）に、画像を読み取る部分を組み合わせたモデルです。Agent、Tool Use、Reasoning、失敗時の再試行といった用途を掲げています。

モデルカードでは、量子化によって言語モデルのデータを20GB未満へ圧縮し、直前までの入力を再利用する一時メモリ（KV cache）、画像を読み取る部分、先の単語をまとめて予測する補助モデルを含む24GBまたは32GB級の構成を対象としています。

先の単語をまとめて予測する「投機的デコード」により、回答の内容を保ちながら生成を速くする仕組みも提供しています。

Metaの参入が興味深いのは、単に新しいモデルデータを公開したことではありません。手元のPCでTool Useを繰り返すAgentを、明確な製品用途として扱っている点にあります。

一方、24GBまたは32GBという値は、あらゆる環境で同じ速度が出ることを保証するものではありません。量子化方式、Context Length、モデルを動かすソフトウェア、同時に処理する要求数によって必要メモリと速度は変わります。

Liquid AI LFM2.5-2.6B

Liquid AIのLFM2.5-2.6Bは、2026年8月4日に公開された、オンデバイスAgent向けの文章モデルです。約26.9億のパラメータ、131,072トークンのContext Lengthを持ち、日本語を含む16言語を対象にしています。Tool Useと複数段階の作業に対応するよう追加学習されている一方、公式モデルカードは、高度なコード作成や知識量が重要な作業には推奨していません。

公式GGUFでは、通常のQ4_0と、2026年8月19日に追加されたQAD Q4_0がともに約1.59GB、Q4_K_Mが約1.67GBです。QAD（Quantization-Aware Distillation）は、高精度のTeacherから4bitのStudentへ知識を移し、量子化による品質低下を抑える方法です。Liquid AIは、2.6Bを含む4モデルの評価全体で、通常のQ4_0化によって失われたBF16からの平均精度の97%を回復したと報告しています。これは2.6B単体が全用途でBF16の97%の性能を持つ、という意味ではありません。

2026年8月20日に公開されたDSparkは、328Mの小さな補助モデルが先のトークンを提案し、本体が検証する投機的デコードです。開発元のM4 Max、FP16 GGUF、llama.cpp、温度0という条件では、2.6Bの平均生成速度が61から139トークン/秒へ向上し、複数Toolを使う評価ではFunction Callingの待ち時間を平均57%短縮したと報告されています。温度0の同条件では出力を変えずに高速化する設計ですが、この数値はQAD Q4_0との組み合わせを測ったものではありません。

DSparkは公開時からllama.cppとSGLangへ統合され、2026年8月28日のLM Studio 0.4.22では、DFlash、DSpark、MTPのAssistant Drafterへ正式対応しました。利用にはllama.cpp engine 2.29.1以降が必要です。これによりGUIやLocal Serverからも対応する補助モデルを試しやすくなりました。LFM2.5-2.6B用DSparkの公式GGUFでは、Q4_K_Mの補助モデルが約200MBで配布されています。

ただし、LM StudioがLFM2.5-2.6Bを常に2.27倍へ高速化するという意味ではありません。LM Studio自身も、補助モデルの処理速度や提案の採用率によっては投機的デコードが逆に遅くなる可能性を説明しています。約1.59GBは本体Weight、約200MBは補助モデルのファイル容量であり、KV cache、推論ソフトウェア、同時に動かすアプリのメモリは別に必要です。LM Studioは候補を比較する試作環境にはなりますが、製品へそのまま同梱するランタイムと同義ではありません。

ライセンスはLFM Open License v1.0です。Liquid AIの公式説明では、年間売上1,000万米ドル未満の企業は無償で商用利用でき、それを超える場合は有償ライセンスが必要とされています。小さなWeightとTool Useへの特化から、端末上のIntent選択や短いTool Callの検証候補にはなりますが、ゲームとの同居、日本語品質、失敗率を示す実測ではありません。

NVIDIA Nemotron 3.5 Lightning 30B-A3B

NVIDIAのNemotron 3.5 Lightning 30B-A3Bは、2026年8月11日に公開されたMoEモデルです。モデル全体は約300億のパラメータを持ち、1トークンの処理では約30億のパラメータを使います。ReasoningとTool Useに対応し、最大Context Lengthは1,000,000トークンとされています。

特徴は、単独ですべての作業を担う万能モデルではなく、Tool Use、結果の確認、サブエージェントへの作業委譲などを高頻度に行う「実行層」を明確な用途にしている点です。NVIDIAは、複雑な計画を大型のReasoningモデルへ任せ、Nemotron 3.5 Lightningが反復的な実行を担当する構成を示しています。

NVIDIA公称では、Agentの実行能力を測るPinchBenchで約85%の精度を示し、同程度の精度として比較したQwen3.6 35B-A3Bより、10,000件のタスクを完了する時間を約30%短縮したとしています。一方、同じ公式評価表では、SWE-bench VerifiedとTerminal-Bench 2.1はQwen3.6 35B-A3Bを下回ります。高難度のReasoningやコード作成を一律に置き換えるのではなく、実行速度と成功率のバランスで役割を限定して評価するモデルです。

llama.cpp、Ollama、LM Studioなどのローカル実行環境が案内されています。ただし、約30億というActive Parametersは計算量を理解するための値であり、モデルデータの保持量が30億規模になるという意味ではありません。公式モデルカードから案内されるGGUF配布先では、2026年8月21日時点でNVFP4が約22.5GB、Q4_K_Mが約25.4GBです。Context Lengthを伸ばすほどKV cacheも増えるため、ゲームなど他のGPU処理と同時に動かす場合は、モデルデータだけでなく実際の空きメモリを測る必要があります。

最大1,000,000トークンも、一般的なPCで常に利用できる量ではありません。公式のBF16実行例では、H100を1基使う構成の検証済みContext Lengthは256,000トークンで、1,000,000トークンはより大きな構成を前提としています。用途に必要な範囲へ制限して評価します。

モデルカードではOpenMDW 1.1ライセンスのもとで商用利用可能と説明されています。実際に採用する場合は、モデルだけでなく、利用する量子化データと実行ソフトウェアを含めて条件を確認します。

Ornith 1.5 9B / 35B-A3B

Ornith 1.5 9Bは、約90億のパラメータを毎回使うDenseモデルです。最大Context Lengthは262,144トークンで、Reasoning、Tool Calling、Agentic Codingを主な対象としています。MITライセンスで公開され、開発元は単一GPUや量子化したEdge環境での利用を想定しています。

公式の9B GGUF配布では、Q4_K_Mが5.63GB、Q5_K_Mが6.47GBです。Q4_K_Mは8GB級GPUでも検証候補になるWeight容量ですが、実行ソフトウェアの作業領域、KV cache、入力、同時に動かすゲームの描画などは含みません。「Weightが5.63GBなので、ゲームと同じ8GB GPUへ常駐できる」とは判断せず、必要なContext Lengthとゲーム実行中の空きVRAMを実測します。

開発元公称の5回平均では、9BのSWE-bench Verifiedは70.6、Terminal-Bench 2.1はClaude Code Harnessで47.0、Terminus-2 Harnessで46.2です。Terminal-Bench 2.1の評価条件には、128,000トークン、32 CPU cores、48GB RAM、4時間のTimeoutが含まれます。これはコード修正やTerminal操作に関する開発元評価であり、一般的なPCでの速度や、ゲーム内NPCの会話品質、人格の一貫性、リアルタイム応答を示す数値ではありません。

35B-A3B版は、全体が約350億、1トークン当たり約30億を使うMoEモデルです。開発元公称の5回平均はSWE-bench Verified 79.0、Terminal-Bench 2.1のClaude Code Harness 68.5ですが、公式GGUFのQ4_K_Mは21.7GBあります。Active Parametersが小さくても、8GB級GPUでゲームと同時に保持できるWeight容量にはなりません。

Ollama公式ライブラリのornith:9bとornith:35bは、2026年8月22日時点ではOrnith 1.0として説明されています。1.5を検証するときは汎用Tagだけで判定せず、公式GGUFページにあるhf.co/ornith-ai/Ornith-1.5-9B-GGUFのように、1.5の配布元と量子化方式を明示します。

Tool Callingを使った高レベル判断を小型モデルへ任せる設計では、9B版は検証候補になります。ただし、これは機能とサイズからの推論です。NPC用途では、ゲーム状態から決められた形式の行動を選べるか、誤った行動をValidatorで拒否できるか、同じ人格を維持できるか、目標Latency内に収まるかを独自に評価します。

Qwen3.8-27B / Qwen3.8-Flash-Next

Qwen3.8-27Bは、約270億のパラメータを持つDenseモデルで、文章に加えて画像と動画を扱います。Reasoning量を調整でき、コード作成、調査、長時間の作業を主な改善領域としています。

標準では、一度に262,144トークンを扱い、拡張時は最大1,000,000トークンと説明されています。トークンは、文章をモデルが処理しやすい単位へ分割したものです。

ただし、最大量を常に使う必要はありません。Context Lengthを長くすると、KV cache、最初に入力を読み込む時間（Prefill）、古い情報が紛れ込む可能性も増えるため、用途に必要な範囲へ制限します。

公式モデルカードには、決められた課題で性能を測る試験（Benchmark）も掲載されていますが、開発元が指定した実行手順と条件での結果です。別の開発元が公開した数値と単純に横並びにはできません。

2026年8月26日に公開されたQwen3.8-Flash-Nextは、将来のQwen4で使うアーキテクチャを先行公開した、画像と動画も扱うMoEモデルです。主モデルは約1250億で、1トークン当たり約60億を使います。これに約510億のN-gram Embeddingと約40億のMulti-Token Prediction（MTP）部分が加わります。標準のContext Lengthは262,144トークンで、YaRNによって最大1,000,000トークンへ拡張できます。

新しいQwen Sparse Attention（QSA）は、長い入力から参照候補を小さなまとまり単位で絞り、長文処理の計算を減らす仕組みです。N-gram Embeddingは、直近の単語の並びから大きな表を引くことで、少ない追加計算でモデル容量を増やします。この表はホスト側のメモリへ置き、GPUの計算と並行して先読みできる設計です。ローカル用途で注目すべき点は、Flash-Nextが今すぐ軽いことではなく、計算量、GPUメモリ、モデル容量を別々に調整する方向を示したことです。

Qwen公称の同一評価表では、Qwen3.8-27Bに対して、SWE-bench Proは61.7から62.5への小幅な上昇ですが、DeepSWE 1.1は42.2から58.7、Toolathlon Verifiedは67.1から73.5、JobBenchは33.4から55.7へ上昇しています。AgentやTool Useを重視した改善を示す材料ですが、開発元による評価であり、第三者による再現や一般的なPCでの速度を示すものではありません。

約60億というActive Parametersだけを見て、6Bモデル相当の実行環境で動くとは判断できません。第三者のUnsloth GGUFでは、公開時点で大幅に圧縮したUD-IQ1_Sでも約72.5GBあります。公式リポジトリはTransformers、llama.cpp、SGLang、vLLM、TokenSpeedなどの導線を示していますが、新アーキテクチャの公開直後であるため、対応Version、画像入力、Tool Calling、量子化方式を個別に確認する必要があります。現時点では一般的なゲーミングPCへ常駐させる候補というより、大容量メモリを持つ環境での検証対象です。

2026年10月4日確認。10月3日公開のプレリリースllama.cpp b11372は、qwen4exp経路のindexer中間領域を削減しました。PR #29825の作者は、CUDA・128K Context・N-gram表をRAMへ置く構成でcompute bufferが6056→3748 MiB、Metal・64Kで6224→3924 MiBと報告しています。これは特定構成での実装測定であり、Qwenの公式必要環境や、Weight・KV cacheを含む総RAM／VRAMの半減ではありません。大容量環境ですでに評価する場合は、実行版、量子化、Context、batch／ubatch、backendを固定し、一時領域、総メモリ、Prefill、Decodeを分けて測ります。当方による再現やOllama／LM Studioへの取り込みは未確認で、上記の一般PC向けの判断は変えません。

2026年10月13日JST確認。Flash-NextのQwen Community License 1.0原文に照らし、既存の要約を訂正します。新しいライセンス変更の発表ではありません。第1項は、月間アクティブユーザーが1億を超えるか、月商が2,000万米ドルを超える商用製品・サービスにモデル名の表示を求めます。第2項は、利用者または関連会社がModel as a Service／AI Work Assistant事業を営む場合、その利用者がモデルまたは派生物を商用目的で使う前に別許諾を得ると定めており、当該製品用途だけの条件へ狭めません。モデル・出力・基盤となるモデル能力を第三者へ提供しない所定の社内利用には例外があります。事業の定義と除外条件も原文で確認し、個別事業やゲーム機能への法的適用は断定しません。Qwen3.8-27BのApache-2.0とは別の条件です。

現時点の選定では、Qwen3.8-27BとFlash-Nextを置き換え関係として扱いません。前者は比較的小さいDenseモデルとして、後者はQwen4世代の効率化を先行評価する大規模モデルとして、別の目的で候補に置きます。将来この構造が小型モデルへ展開された場合は、同じ品質をより小さい計算量で得られるかを改めて測ります。

GPU Expert cacheでもホスト側のWeight保持は必要

2026年10月11日確認。10月8日01:36 UTC（10:36 JST）公開のプレリリースllama.cpp b11480は、PR #29887のホストExpert用GPU cacheを含みます。同日15:27 UTC（10月9日00:27 JST）公開のb11507で、PR #30112の複数GPU対応も入りました。GPU cacheへExpertを再利用する方式で、Weightの圧縮やEdge0のSSD Streamingとは異なります。

b11507の引数定義では--moe-cache-mibは既定0で無効です。最終実装は最大32 tokensの小batchを対象とし、Tensor Parallelは非対応、総予算は--tensor-splitまたは空きメモリに応じて分配します。PRの設定例をGPUごとの予算へ転用しません。作者の単GPU測定はQwen3.8-Flash-Next Q4_0・93.7 GiB、EPYC 7742・16 cores・PCIe 4.0 x16、32K Context、MTPなしの条件で、一般PCやゲーム同居性能の証明ではありません。大容量offloadの評価では、ホストWeightと実行領域を収容するRAM、cache用のGPU余裕を確保し、無効／有効のCold／Warm、Prefill／Decode、転送量、総RAM／VRAM、描画負荷を比較します。日本語、p95／p99、Ollama／LM Studioへの取り込みは未検証で、RuntimeのMITとモデルの条件も分けます。

Ternary Bonsai 2 27Bは低ビット重みと専用Runtimeの組み合わせ

2026年9月18日確認。Ternary Bonsai 2 27BはQwen3.8-27Bの派生モデルです。言語モデルのWeightはPTQ1_0で5.95GB、PQ2_0で7.21GB、画像入力には任意のProjector約0.63GBを別途使います。これはファイル容量であり、実行時の総VRAMではありません。これらPTQ1_0／PQ2_0配布物のモデルカードはternary形式とHadamard変換に対応したPrismML版llama.cppを要求しており、通常のGGUF対応だけでは動かせません。

PrismMLの14件のThinking評価平均は84.78、FP16は86.32で、平均値の比は約98.2%です。あらゆる課題の能力を98.2%維持する保証ではありません。公式のllama-bench TG128はbatch 1・depth 0・画像なしの測定で、RTX 4090の91.1 tok/sはPTQ1_0、RTX 5090の129.9とM5 Proの28.1はPQ2_0です。最小容量と各機種の最速値を一つの構成へ合成しません。NPC品質やゲーム描画との同時実行性能は未検証です。

2026年10月12日JST確認。10月11日公開のプレリリースllama.cpp b11556には、PR #29600のHadamard対応が本流へ入りました。評価対象は公式のdev Q2_0 GGUF、7.63GBです。上記PTQ1_0 5.95GB／PQ2_0 7.21GBまで本流対応したとは一般化せず、PTQ1_0対応PR #29672は今回の確認時点でもOpenです。版固定Adapter実装はHadamardを折り込んだWeightへのLoRAを拒否します。正確な配布物と実行版を固定し、Weight、KV cache、Runtime領域、ゲームのメモリを別々に見積もります。ファイル容量は必要RAMではなく、日本語、量子化品質、ゲーム性能は当方では未検証です。実行対応とモデル再配布の許可も分けます。

Gemma 4

GoogleのGemma 4は、単一のモデルではなく、対象ハードウェアに応じた複数の構成を持つファミリーです。

• 20億・40億規模の小型端末向けモデル
• 約120億の統合モデル
• 約260億のパラメータを持ち、処理ごとに一部の専門領域だけを使う方式（MoE）
• 約310億のパラメータを持つDenseモデル

Tool Use、Reasoning、画像などの入力、多言語対応を扱い、小型端末からPCまで広い範囲を対象にしています。そのため、「Gemma 4が動くか」ではなく、どの配布モデルを、どの精度とソフトウェアで動かすかを明示して比較します。

小型モデルは必要メモリと応答時間の面で有利ですが、大型モデルと同じ品質を保証するものではありません。指示に正しく従えるか、必要な言語を自然に扱えるか、Tool Useを正しく実行できるかを確認する必要があります。

2026年10月11日確認。Googleの10月8日のML Drift発表は、LiteRTのGPU基盤を独立したC++ライブラリとしてOSS公開したものです。アプリ内GPU推論の経路であり、新しいGemmaモデルや完成したゲームSDKではありません。固定版READMEはOpenCL／Metal／WebGPU／OpenGL ESを記載します。確認時点で独立した配布リリースはなく、LiteRT C++ SDKのバイナリとは分けます。デスクトップLLM評価はpreviewで、「最大12%低いメモリoverhead」を総メモリ削減率へ置き換えません。対応モデル形式・SDK・Backendを固定してCold初期化、Prefill／Decode、総メモリ、描画同居負荷を測る候補です。通常GGUFの代替、日本語、Tool Use、ゲーム性能は未検証で、Apache 2.0とモデル・依存物の条件も分けます。

2026年10月12日JST確認。10月11日19:14 UTC（10月12日04:14 JST）公開のプレリリースllama.cpp b11559は、PR #30266でGemma 4 E2B／E4Bのhead dimension DK512向けOpenCL Flash Attention decodeへ対応しました。モデルの新公開ではなくRuntimeの更新です。版固定の適用条件はAdreno、F32 query／F16 KV、query位置数1、GQA 4または8、kernel初期化成功などで、GGML_OPENCL_FA_DK512_DECODE=0なら無効です。A7xのmixed型kernelはcompiler crash回避のため除外されています。OpenCL文書もFlash Attentionが常に速くなるとはしていません。端末、driver、GGUF、Contextを固定し、Prefill／Decode、発熱、総メモリ、描画競合、Fallbackを測る候補です。これらは当方では未検証で、全GPUの高速化を保証しません。

OpenAI gpt-oss

OpenAIのgpt-oss-20bとgpt-oss-120bは、Apache 2.0でモデルデータが公開されている、Reasoningを強化したモデルです。利用者が管理するPCやサーバー、対応する実行サービスで動かします。

OpenAI APIから提供されるクラウドモデルとは、実行場所、更新方法、必要なハードウェア、運用責任が異なります。「OpenAIのモデル」という名前だけでまとめず、クラウドAPIとモデルデータが公開されたモデルを分けて扱います。

20bと120bでは必要リソースが大きく異なるため、モデルファミリー単位ではなく、実際に使用するモデルとデータの圧縮方法を指定します。

Ministral 3 3B

MistralのMinistral 3 3Bは、2025年12月2日に公開された、Edge環境を対象とする小型モデルです。公式資料では3B、文章・画像入力、256,000トークンのContext Length、Structured Output、Function Callingに対応し、Apache 2.0でWeightを公開しています。

小型であることは、端末上での候補にしやすいという意味です。自然な日本語、人格の維持、Tool選択、応答時間を保証するものではなく、Vision EncoderやKV cacheを含む実行時メモリも量子化Weightのファイル容量だけでは判断できません。

Mistral Small 4

Mistral Small 4は、Reasoning、コード作成、Agent、画像入力を一つにまとめたMoEモデルです。

公式資料では全体で約1190億のパラメータを持ち、一度の処理で主に使う部分（Active Parameters）は約60億と説明しています。Active Parametersが小さいことは、必要な計算量を理解する材料になります。ただし、モデル全体のデータを保持するためのメモリや配布容量まで、約60億規模のモデルと同じになるわけではありません。

モデルの公開状況や、提供終了・非推奨などの状態も変化します。以前の候補を固定的に使い続けず、導入時に現行モデル、非推奨状態、ライセンスを確認します。

Edge0はSSDから必要なExpertを読み込む

2026年9月18日確認。Edge0はSSD Expert Streaming、Recover-LoRA、読み込むExpertを予測するPrerouterを組み合わせます。Qwen3.6由来の35B-A3B previewでは、開発元は保存Weight約23GB、ピークactive memory 2.9GiBと報告しています。Bonsaiの常駐Weight圧縮とは異なり、その時点で読み込むExpertを変える方式です。

公称14.9〜17.7 tok/sはMac mini M4 Pro・24GB、約3.3K入力、10ステップのWarmup後に200出力トークンを測る2回の実行です。Active memoryはOSやページキャッシュを含むシステム全体のRAMではなく、Warm時のPrefillはページキャッシュへ載った状態と明記されています。3GBのPCで動くことを示しません。ストレージ、キャッシュ状態、長Context時のKV増加を別々に測ります。

現行BackendはApple SiliconとMLXで、CUDAはロードマップです。通常のOllamaやLM StudioでGGUFを読むだけでは、このStreaming構成を再現できません。OpenAI互換Serverは接続境界になりますが、Windows対応やNPC適性の証拠ではありません。品質・応答時間に加え、Cold／Warm時の挙動とストレージ競合を評価します。

Apple Siliconの実行経路もVersionを固定して評価する

2026年9月29日確認。Hugging FaceのTransformersでGGUFを実行する更新は、量子化Weightを展開せず保持するpacked推論経路を追加しました。従来のGGUFを展開して読み込む経路とは異なります。初期対応はMPSで、Qwen3.5のDense / MoEと互換Qwen3.8が中心です。PaddingやBatch処理には制約があり、GGUF全般・全GPUへの対応や、量子化状態のまま自由に追加学習できることを意味しません。Python側の実験へ組み込む候補として、使用Versionと対応モデルを確認します。

Ollama v0.40.0-rc0は、Apple SiliconでMLX対応アーキテクチャを自動的にMLXへ振り分けます。9月29日の確認時点ではプレリリースでした。対応モデルに限る変更であり、すべてのモデルやWindows / NVIDIAの実行経路がMLXへ変わるわけではありません。以前のMLXベンチマークを今回のRCの改善率として転用せず、Context、Cache、並列数を固定して比較します。

2026年10月7日の追加確認では、Ollama v0.40.0が非プレリリース版として提供されています。公式メタデータのprereleaseはfalseで、RCを選ばずにMLX経路を評価できます。公開枠のpublished_atは9月25日、現行macOS配布物の作成は10月6日18:27 UTC（10月7日03:27 JST）であり、いずれも正式化の正確な時刻とは断定しません。ここでの10月7日は提供状態の確認日です。

版固定macOS要件はmacOS 14以降です。MLX経路は対応Apple Silicon・モデルと十分な統合メモリを前提とし、OllamaのMITとは別にモデルの条件を確認します。同じモデル、Context、Cache、並列数でRCと非プレリリース版のCold／Warm応答を比較します。提供状態の変更だけでは日本語品質、総メモリ、p95／p99、ゲーム同居性能の改善は判断できず、当方では未測定です。

2026年10月13日JST確認。10月12日19:00:12 UTC（10月13日04:00:12 JST）公開のプレリリースOllama v0.40.4-rc0は、PR #18955のMLX保持メモリ修正を含みます。投機推論のrollbackで復元したRecurrent stateが大きなBufferの一部を参照し続ける問題に対し、要求終了時のcompactionで必要なstateだけを切り離してからprefix cacheへ保持します。Weight圧縮や全モデル共通の改善ではありません。同じモデル・digest・Context・投機設定・要求列で実行版を比較し、論理cache量、実確保メモリ、swap、遅延を別々に確認します。当方の再現、メモリ削減量、日本語品質、ゲーム同居性能は未測定です。

2026年10月11日確認。Ollama v0.40.0にはMLX判断モデル対応も入り、Nimble、Tev1、Clef、Clef Flashを評価できます。この経路にRC選択は必須ではありません。v0.40.2判断API文書は/v1/systemoneの候補選択、確率、順序付き評点を説明しており、文章生成とは用途が異なります。Clef画像はimages内の生base64で、URLやdata URLは受け付けず、llama.cppの経路と分けます。対応Apple Silicon・モデル・Engine・入力表現を固定し、経路の増加を精度、確率の較正、メモリ削減、低Latencyの証明へ読み替えません。ゲーム側の評価はNPC記事で扱います。

2026年10月4日確認。SplashはApple Silicon向けの専用実行エンジンで、LM Studio 0.4.25も9月19日に対応しました。公称要件はM3以降、macOS 26.4以降、統合メモリ36GB以上で、開発元は48GB以上を推奨します。Qwen3.8-27Bの専用パッケージは4bit本体、DFlash 2、Vision Encoder等を含む17.4GBで、通常のMLX／Transformers Checkpointではありません。ダウンロード容量と必要総メモリを分け、エンジンとモデルの利用条件を個別に確認します。採用前にはCold Prefill、Cache再利用、遅い要求の応答時間、ゲーム同居負荷を測る必要があり、当方では未検証です。

スペックを読むときの注意点

ローカルLLMでは、似ているように見える数字が異なる意味を持ちます。

Denseは、原則としてモデル全体を入力の処理に使います。MoEは複数の専門領域から一部だけを使うため計算量を抑えられますが、使わない専門領域も含めたモデル全体のデータを保持する必要があります。

量子化は必要メモリを減らしますが、精度、対応する実行ソフトウェア、速度へ影響する場合があります。同じ「4bit」でも方式が異なれば結果も異なるため、圧縮方法の名前まで記録します。

2026年10月11日確認。10月1日19:24 UTC（10月2日04:24 JST）公開のプレリリースllama.cpp b11324はPR #29749を含みます。Linuxの-lm dioでTensor全体と同じ大きさの一時コピーを、最大64MBの再利用Bufferへ置き換えました。ロード時ピークRSS、空きRAM、ロード時間を推論中のRAM／VRAMやゲーム負荷と分けて測ります。作者のDGX Spark／CUDA測定は設定限定であり、全OS・読み込み方式共通の削減や当方の再現結果ではありません。

2026年10月11日確認。10月8日16:53 UTC（10月9日01:53 JST）公開の非プレリリースOllama v0.40.2の現行ノートは、旧形式モデルを初回実行時に変換し、ダウングレード用の旧コピーを保持すると説明します。PR #18874は一覧の重複表示を隠す変更で、disk上のバックアップ削除ではありません。変換用のdisk余裕と初回処理を、ダウンロード容量や実行時RAM／VRAMと分けて測ります。バックアップを削除して0.40より前へ戻す場合はモデルの再取得が必要です。変換機能の初出日は未確定で、v0.40.2の新導入とは断定しません。当方は変換・削除を行っておらず、増加容量、所要時間、復旧動作は未検証です。

2026年10月12日JST確認。10月11日UTC公開のOllama v0.40.3は、ローカルモデルの互換性変換をバックグラウンドで開始する処理を停止しました。PR #18908は、特に大量のEmbedding要求でのrequest overheadとGC負荷を理由に挙げ、版固定の要求処理でも移行呼び出しが無効化されています。上記v0.40.2の履歴は残しつつ、バックグラウンド変換の発生を前提にする際は導入版を確認します。変換済みWeightの巻き戻しやバックアップ削除を示す変更ではありません。同じモデル・並列数で要求LatencyとGCを比較し、disk使用量や実行時RAM／VRAMとは分けます。当方では改善量やVRAM削減を測っておらず、変換・復旧動作も未検証です。

選ぶときの基準

モデル名から選ぶのではなく、先に用途と制約を決めます。

• 分類や要約など仕事を限定できるか、自由な会話やAgentが必要か
• 利用できるPCメモリ（RAM）・GPUメモリ（VRAM）と、同時に動かすアプリの使用量
• 文章だけでよいか、画像や動画も必要か
• 必要な言語、Context Length、Tool Useの精度
• モデル、データの圧縮方法、実行ソフトウェアのライセンスと提供状況

候補を2、3種類に絞ったら、同じ入力文、Context Length、量子化方式、ハードウェアで比較します。最初の文字が表示されるまでの時間、回答の完了時間、PC・GPUメモリに加え、実際の課題が成功した割合と失敗例を確認します。開発元が公開したBenchmarkは候補を絞る材料として利用し、最終判断は自分の用途で行います。

ゲーム内ローカルSLMの搭載予定例

gamescom 2026でNVIDIAは、Creature収集RPG『Aniimo』が2027年初頭にNVIDIA ACEへ対応すると発表しました。PlayerのGPU上でFine-tuning済みNemotron SLMを動かし、自然言語や音声からPlayerの意図を解釈して、Game側のBehavior APIを呼び出す計画です。

これは、Local Modelを自由会話だけに使うのではなく、自然言語を構造化されたGame操作へ変換する例です。ただし現時点では搭載予定であり、製品版の必要VRAM、RenderingとのGPU共有、応答時間、誤操作率は公開資料から判断できません。Model選定ではWeight容量だけでなく、Gameと同時実行したときの総VRAM、Latency、Behavior APIへ渡す出力の検証を評価します。

詳しい構成とgamescomで示された他のGame AI事例は、gamescom 2026で見えたゲームAIの現在地で整理しています。

NPC導入記事では、ローカル会話、記憶、行動を組み合わせたFallout 4の公開Mod、AI Follower Jessicaも扱います。

現時点の見方

9月18日の追加例では、小型Agentモデル、常駐Weightの圧縮、ExpertのStreamingを分け、Iris-miniでContext管理の影響も補強しました。検証の選択肢が増えたことと、NPC採用やゲーム同居性能が確定したことは別です。

K2 Horizonは小型Agentの比較候補を、PAIRは複数PCへの同時要求の分散方法を増やしました。いずれも用途ごとの検証が必要です。

2026年9月時点のローカルLLMで重要なのは、特定のモデルが一律に最良になったことではありません。Reasoning、Tool Use、画像入力、失敗時の再試行、回答の高速化といった機能を、ローカル環境で扱う選択肢が増えたことです。LM StudioのAssistant Drafter対応のように、同じモデルでも実行ソフトウェアの更新によって検証可能な構成が増えます。

MetaのMuse Glimmerは、その変化を分かりやすく示しています。Liquid AIのLFM2.5-2.6Bは、小型モデルのTool Useと、量子化時の品質を補うQAD、生成を速めるDSparkを組み合わせる方向性を示しています。NVIDIAのNemotron 3.5 Lightningは、Agentを一つのモデルだけで構成せず、計画と反復実行を分担する方向性を示しています。Perplexity Portable Computerは、モデルとHarness、Sandbox、必要時のクラウドEscalationを一体で設計する方向性を具体化しました。Ornith 1.5 9Bは、小型のTool CallingモデルもAgentの実験対象に入ることを示します。一方、Qwen、Gemma、gpt-oss、Mistralも異なるサイズと設計で選択肢を広げています。

モデルの更新は速いため、一覧を固定的な推奨として扱わず、次の条件で再評価します。

• 新しいモデルまたはデータの圧縮方法が公開された
• 使用する実行ソフトウェアの対応状況が変わった
• 対象ハードウェアや同時実行するアプリが変わった
• 必要な言語、Tool Use、Context Length、応答時間が変わった
• モデルや依存ライブラリのライセンス、提供状況が変わった

注意点

• Spark-X2.5、Bonsai 2、Edge0、Iris-miniは2026年9月18日確認です。性能数値は開発元の報告であり、当方による再現実験は行っていません。
• 既存項目は2026年9月2日までに整理した公開情報に基づき、個別の確認日は各記述に残しています。K2 HorizonとNVIDIA PAIRは9月6日に一次資料を確認して追加しました。今回、既存項目すべてを再検証したものではありません。
• 掲載したモデルは代表例であり、利用可能なローカルLLMを網羅するものではありません。
• 性能と必要メモリは、量子化方式、実行ソフトウェア、Context Length、同時処理数、ハードウェアで変わります。
• 開発元が公開したBenchmarkは、その開発元の評価条件に基づきます。
• 10月4日の確認範囲はPortable ComputerのWindows提供、Splash、Qwenのindexerメモリです。既存モデルすべての再検証やゲーム性能の実測ではありません。
• モデルのライセンスだけでなく、利用規約、実行ソフトウェア、依存ライブラリの条件も確認してください。

関連資料

• Muse Glimmer 30B Model Card
• LFM2.5-2.6B公式発表
• LFM2.5-2.6B Model Card
• LFM2.5-2.6B公式GGUF
• LFM2.5 QAD Q4_0
• LFM2.5-DSpark
• LFM2.5-2.6B-DSpark公式GGUF
• LFM Open Licenseの説明
• LM Studio 0.4.22 release notes
• LM Studio Speculative Decoding
• Portable Computer公式発表
• Portable Computer技術解説
• PPLX Computer Qwen 3.8 27B DFlash2 Checkpoint
• Nemotron 3.5 Lightning Technical Blog
• Nemotron 3.5 Lightning BF16 Model Card
• Nemotron 3.5 Lightning GGUF
• Ornith 1.5 9B Model Card
• Ornith 1.5 9B GGUF
• Ornith 1.5 35B-A3B Model Card
• Ornith 1.5 35B-A3B GGUF
• Ollama ornith library
• Qwen3.8-27B Model Card
• Qwen3.8-Flash-Next公式発表
• Qwen3.8-Flash-Next Model Card
• Qwen Community License 1.0
• Unsloth Qwen3.8-Flash-Next GGUF
• Gemma 4 model overview
• OpenAI API model catalog
• Ministral 3 3B model overview
• Introducing Mistral Small 4
• NVIDIAのgamescom 2026発表
• gamescom 2026で見えたゲームAIの現在地
• K2 Horizon
• K2 Horizon 3.7B
• K2 Horizon 7B
• K2 Horizon 3.7B GGUF
• NVIDIA PAIR