Spark X2.5-4B/1.7Bはローカルで動く？ 1Mコンテキストとllama.cpp対応状況を確認

Spark X2.5-4B/1.7Bは何が新しい？

Spark X2.5は、XHTokenが公開した小型の汎用LLMシリーズだ。2026年9月時点で、Spark-X2.5-4BとSpark-X2.5-1.7Bの2サイズが案内されている。

公式READMEでは、会話、文章作成、翻訳、推論、コーディング、ツール利用、エージェントワークフローまでを対象にしており、特にオンデバイスでのエージェント利用を強く打ち出している。4B/1.7Bというサイズだけを見ると軽量モデルの範囲だが、もう一つ大きな特徴が最大1Mトークンのネイティブコンテキストだ。

アーキテクチャは、1層の全体アテンションと3層のスライディングウィンドウ・アテンションを組み合わせるハイブリッドアテンション。XHTokenは、この構成で長文処理の計算負荷を抑えながら最大1Mトークンを扱えるとしている。また、200以上の言語への対応も公式に記載されている。

ただし、重要なのは、「最大1Mトークン対応」と「一般的なPCで1Mトークンを快適に常用できる」は同じ意味ではないことだ。

4B/1.7Bだから1Mコンテキストも軽い、とは限らない

モデル本体が小さくても、コンテキストを長くするとKVキャッシュなど推論時に必要なメモリは増える。

Spark X2.5が1Mトークンをアーキテクチャとしてサポートしていることは、長い入力を扱う可能性を広げる。一方で、自分のPCで実際にどこまで伸ばせるかは、使う精度、実行環境、GPU/CPUへの配置、KVキャッシュの形式などで変わる。

そのため、4Bモデルだからといって最初から1Mを設定するより、32K、64K、128Kなど実際に必要な長さから段階的に増やす方が現実的だ。

コンテキスト長とメモリの関係は、32K・128K・256K・1Mコンテキストの違いとKVキャッシュでVRAMが増える理由も合わせて確認したい。

llama.cpp対応は「公式手順あり」と「上流対応済み」を分ける

Spark X2.5の公式READMEには、llama.cpp、Ollama、LM Studioを使う手順が用意されている。

ただし、2026年9月2日時点では注意が必要だ。

公式のOllama手順では、通常のllama.cppをそのまま使うのではなく、XHToken/llama.cppを取得し、そのソースを使ってOllamaをビルドする方式になっている。LM Studioについても、XHToken側のllama.cpp派生版をビルドし、その出力をLM Studioのバックエンド実行環境へ配置する手順が示されている。

つまり、公式が「Ollama・LM Studioで使える」と案内していること自体は正しいが、現時点では一般ユーザーが標準版を入れて即ロードできる、という意味ではない。

上流のggml-org/llama.cppでは、Spark2_5対応PR #27868が提出されている。GGUF変換、トークナイザー、モデル読み込み、CPU/CUDAでの推論などを追加する内容だが、2026年9月2日の確認時点ではドラフトかつオープンで、本流へ取り込み済みではない。

このため、Spark X2.5をGGUFで試すときは、GGUFがLM Studio・Ollama・llama.cppで使えるか確認する方法と同じように、モデル形式だけでなくその実行環境ビルドがSpark2_5アーキテクチャを実装しているかまで確認する必要がある。

エージェント用途では4Bと1.7Bのどちらを見るべき？

公式ベンチマークでは、Spark-X2.5-4Bはツール利用、エージェント、コーディング系の複数評価で同規模モデルに対する強さを示している。ただし、これらはXHTokenが公開している提供元ベンチマークであり、独自実測ではない。

モデル選択では、まず4Bと1.7Bの役割を分けて考えるとよい。

候補	まず試す用途
Spark-X2.5-4B	ツール呼び出し、軽量コーディングエージェント、長めの指示や資料を使うローカルエージェント
Spark-X2.5-1.7B	より軽い常駐処理、分類・抽出・単純なツールルーティング、端末側での試験

ただし、1.7Bだからエージェントとして十分、4Bなら大型コーディングモデルを代替できる、とまでは言えない。自分が実際に使うツール定義や指示で評価する必要がある。

ローカルLLMのツール呼び出しを評価する方法のように、成功率、引数の正確さ、不要なツール呼び出しの有無を同じテストセットで比べる方が、公開ベンチマークだけを見るより実用判断につながる。

どんなPCなら動く？

Spark X2.5は4B/1.7B級なので、大型モデルよりローカル候補に入れやすい。ただし、2026年9月2日時点で、すべての量子化・実行環境・コンテキスト長に共通する固定の必要VRAM/RAMを示す根拠は確認できていない。

そのため「VRAM○GBなら1Mコンテキストまで動く」といった断定は避けるべきだ。

まず確認したいのは次の4点になる。

1. 使う配布形式と量子化
2. 使用する実行環境がSpark2_5を実装しているか
3. 必要なコンテキスト長
4. 実行時のVRAM/RAMピーク

4B級と1.7B級そのもの位置づけは、3B・4Bと7B・8BのローカルLLMをどう選ぶかも参考になる。

選ぶときの判断

Spark X2.5は、小型モデルでエージェント用途と長いコンテキストを両方狙うという点で、試す価値のある新しい選択肢だ。特に4Bモデルで最大1Mトークンをネイティブに掲げ、ツール利用やコーディングを主要用途としている点は、小型ローカルエージェントを作りたい人にとって注目度が高い。

一方、公開直後の現時点では実行環境対応の読み方に注意したい。公式READMEにllama.cpp、Ollama、LM Studioの名前があるからといって、各ソフトの通常版で即利用できるとは限らない。少なくとも上流のllama.cppの対応はまだドラフトPR段階で、公式手順はXHToken側の派生版を使う。

したがって、現時点の判断は**「モデル自体は有望。標準実行環境への取り込み状況を確認しながら試す」**が妥当だ。上流のllama.cppへの取り込みやLM Studio/Ollama側の標準対応が進めば、導入難度は大きく下がる可能性がある。