Spark X2.5-4B/1.7Bはローカルで動く？ 1MコンテキストとOllama・LM Studio対応を整理

長い文書を手元のPCで読ませたいけれど、大きなモデルを常駐させる余裕はない。Spark X2.5は、そんなときに仕様と動作条件を確かめたい、XHToken公開の4Bと1.7Bの小型LLMシリーズです。最大1Mトークンの文脈、200以上の言語、コーディングやツール利用を特徴として掲げています。

ここで扱うのはSpark X2.5の版別解説です。2026年10月21日には後継X2.6が公開され、旧GitHub URLもX2.6へ転送されるようになりました。以下はX2.5の公式READMEの固定版を基準にしています。ダウンロード前にはモデル名を確認し、X2.6のファイルへX2.5の設定をそのまま当てはめないようにしましょう。

X2.5を試すなら、モデルの規模と文脈長に加え、アプリがこの構造を読み込めるかも確認します。公開直後の未対応情報と、9月に追加された対応履歴を分けて見てから、4Bか1.7Bかを絞っていきます。

Spark X2.5の基本仕様

まず、公表仕様を並べてみましょう。二つとも同じ最大文脈長を掲げているので、上限だけを見ても選び分けられません。

項目	Spark-X2.5-4B	Spark-X2.5-1.7B
規模	4B	1.7B
最大コンテキスト	1Mトークン	1Mトークン
対応言語	200以上	200以上
主な用途	会話、推論、コーディング、ツール利用、エージェント	会話、軽量処理、ツール利用、端末側処理
ライセンス	Apache 2.0	Apache 2.0

内部では、1層のフルアテンションと3層のスライディングウィンドウ・アテンションを組み合わせています。文脈全体を見る層と、一定範囲を中心に見る層を使い分けることで、すべての層が全トークン同士を計算する方式より、長文の計算量を抑えやすくする設計です。モデル側が1Mまで想定していることと、その長さが手元で快適に動くことは、ここで分けておきましょう。

1Mコンテキストは「1Mを常用すべき」という意味ではない

モデル本体を置けても、長い文脈を扱うときには、途中の計算を保存するKVキャッシュなどの場所も要ります。小さい重みだから1M入力も軽い、と考えて最大値から始めると、メモリ不足や長い待ち時間で、何が原因か分かりにくくなります。

まずは、次の順で必要な長さを探してみてください。

1. 16Kまたは32Kで動作確認する
2. 必要なら64Kや128Kへ伸ばす
3. 実際のVRAM・RAM使用量と速度を見る
4. 本当に必要な場合だけさらに長くする

ここで挙げた長さは試す順序の例で、動作を保証する値ではありません。普段読む文書が短ければ、そこで止めて構いません。最大長まで伸ばすことより、必要な文書を読み込めて、回答を待てることを目標にします。

実行環境の対応状況

公式READMEのリリース欄には、次の対応追加が載っています。以前の記事で「未対応」と読んだ場合は、その記事の確認日と照らしてみてください。ただし、公開元の告知があっても、手元のアプリが使う推論処理に、その変更が入っているとは限りません。

実行環境	対応追加の案内
llama.cpp	2026年9月6日。Spark2_5アーキテクチャのネイティブ対応。llama.cppのリリース情報にも追加項目として記録
LM Studio	2026年9月8日
Ollama	2026年9月15日

llama.cppの本流にはSpark2_5を理解する処理が追加されていますが、対応前のビルドではGGUFを読み込めないことがあります。LM StudioやOllamaも、アプリ本体と、それが利用する推論エンジンの版を見ます。

この表は公開元のX2.5対応履歴を整理したもので、本稿で各アプリの実行を確認した表ではありません。手元で試すときは、X2.5のモデル名・量子化・実行エンジンの版・設定した文脈長を一組で控え、短い質問に返答が出たところから、必要な長さへ伸ばします。短い返答の成功だけで1M入力まで確認できたとは扱わないようにしましょう。

読み込めなければ、まずモデル名と形式、アプリ・実行環境の版、表示されたエラーを控えます。配布元が指定する対応版と照合し、必要な更新を検討してください。読み込みエラーを容量不足と決めつけて、すぐ別のGPUを用意する必要はありません。

まず1.7Bの単体GGUFから、短い質問を試す

配布と実行条件を一組にするなら、XHToken公式のSpark-X2.5-1.7B-GGUFにあるSpark-X2.5-1.7B-Q4_K_M.ggufを選べます。固定revisionは1f7fa33b1245c14730da39e125714ad3a327901b、容量は1,107,457,856 bytes（約1.11GB）です。単体ファイルなので、別の分割パートを集める必要はありません。Base版やX2.6と取り違えず、この名前を確認して保存します。

同じ固定版の公式モデルカードは、必要な版をllama.cpp b10828以降、Ollama v0.34.1以降、LM Studioの推論ランタイム 2.34.0以降としています。上のリリース履歴にあるb10829は対応追加の告知先で、ここではモデルカードの最低版と区別します。LM Studioはアプリ本体の番号だけで判断せず、使用するランタイムを見てください。

Windowsのllama.cppで始める経路は次のとおりです。このコマンド例は文脈長4096・生成上限256の案内です。下で紹介する実測は文脈長1024で行っており、設定を分けて読んでください。

1. Windows CUDA版の用意とGPU確認に沿って対応版を用意し、llama-cli.exe --versionでb10828以降か確認します。説明例のb11576もこの範囲です。
2. 配布一覧で上記のQ4_K_Mファイルを選び、例としてC:\modelsへ保存します。別の保存先ならコマンドの引用符内を替えます。
3. 実行ファイルのフォルダーでPowerShellを開き、まず短い入力だけを送ります。

.\llama-cli.exe -m "C:\models\Spark-X2.5-1.7B-Q4_K_M.gguf" -c 4096 -n 256 --single-turn -p '日本語で短く自己紹介してください'

モデルを読み込み、質問に沿った返答が出るかを見ます。途中で生成上限に達した場合は、長文を追加する前に上限と終了理由を調べましょう。この4K設定は最初の確認用で、1Mの動作証明にはなりません。読めない場合はファイル名・ランタイム版・エラーの順に戻り、返答が得られてから必要な文書の長さへ広げます。

同じ日本語3問で比べたら、担当者の抽出に差が出た

2026年10月25日、公式の1.7Bと4Bを同じQ4_K_M・文脈長1024で実行しました。RTX 5090、Ryzen 9 9950X、RAM約61.6GiBのWindows環境で、公式llama.cpp b11576（358a420ec）のCUDA12.4版を使っています。ログ上のGPU配置は1.7Bが29/29層、4Bが37/37層でした。

配布はそれぞれXHToken公式の別リポジトリです。1.7Bは固定revision 1f7fa33b…、4Bは固定revision 9826e0be…の単体GGUFを選び、公開LFSの容量・SHA-256と取得ファイルが一致することを確認しました。別シリーズやBase版の結果ではありません。

最初は生成上限64トークンで各3問を送りましたが、両モデルとも推論の途中で上限に達し、最終回答を出せませんでした。 そこで、入力・文脈長・temperature 0・seed 20261025・既定の推論設定をそろえたまま、上限だけ512へ変えて各3問を一度ずつ再実行しました。

入力と採点条件	1.7Bの最終回答	4Bの最終回答
「17と25を足した結果を、数字だけで」	42。条件を満たした	式と「答え：42」も付いた。計算は正しいが、数字だけの指定から外れた
「田中さんは10月30日までに画像を3枚用意します」から担当者と期限だけを抽出	期限と画像の数量を答え、担当者を落とした	「担当者：田中さん／期限：10月30日」。必要な2項目を残した
「9、2、5を小さい順に、数字と読点だけで」	2、5、9	2、5、9

採点は、事前に決めた正答・必須項目・出力形式と最終回答を照合して行いました。推論文の途中に正しい数字が出ただけでは、回答成功に数えていません。この3問では担当者の抜け方に差がありましたが、4Bなら常に正しい、1.7Bは使えない、という順位には広げられません。

512トークン上限では全6回が最終回答まで到達しました。プロセス起動から終了までは、1.7Bが約1.61〜2.40秒、4Bが約2.52〜3.67秒です。読み込み・推論・出力を含み、TTFTではありません。先に実行したモデルのキャッシュや初期化の影響もあるため、常用時の速度差を決める数字には使いません。短い質問での比較で、1M文脈の検証でもありません。

入力全文・最終回答・64トークンで止まった記録・容量・メモリの観測を保存できます。まず自分の仕事でも「欠けてはいけない項目」を決めて、完成した回答で照合してみてください。小さいモデルで担当者を落とすなら、同じ入力を4Bへ渡す、入力を短くする、出力形式を具体化する、という順で試せます。

4Bと1.7Bはどう選ぶ？

同じ長さの質問を扱うなら、回答やツール利用を優先するか、常駐時の負担を抑えたいかで、先に試す方を決めると進めやすくなります。

4Bを先に試したいケース

複雑な指示をどこまで扱えるか知りたい場合は、まず4Bを試す候補にします。特に、次の用途を考えているときです。

• ツール呼び出し
• コーディング
• 複数段階の指示
• ローカルエージェント
• ある程度長い文書を読ませた判断

公開元もエージェントやコーディング系の評価を示しています。ただ、それは提供元の条件で得られた値なので、自分が使うツールの説明や質問に対する結果は別に確かめます。

1.7Bを先に試したいケース

いつでも呼べる小さなモデルが欲しいなら、1.7Bも比較してみましょう。例えば、次のように担当を絞れる仕事です。

• 分類
• 情報抽出
• 短い要約
• 単純なツール振り分け
• バックグラウンド常駐
• メモリの少ない端末での試験

ここでも、1.7Bだから長文を大量に入れてよい、とは考えず、担当する処理に必要な長さへ合わせます。回答の条件を満たしていれば、規模の大きさだけで4Bへ上げる必要はありません。

例えば、架空の会議メモを渡すなら「担当・期限・作業を三行にする」と条件をそろえます。元メモにない期限を補ったら不合格、必要な三項目が残り、待ち時間も許容できるならその用途の候補です。1.7Bで項目を落とす場合は、同じ入力を4Bへ渡して比べます。この三行へ整理する例は、上の実測で使った「担当者と期限だけ」の抽出とは別の課題です。

エージェント用途では公開ベンチマークだけで決めない

エージェントとして使いたいなら、実際の送信や書き換えを許す前に、自分のツールを正しく選べるかを比べます。例えば10〜30件ほどの同じ質問を用意し、4Bと1.7Bへ渡して、次の点を記録します。

• 正しいツールを選べたか
• 引数を正確に作れたか
• 不要なツールを呼ばなかったか
• ツール実行後の結果を正しく利用できたか
• 同じ入力で結果が大きくぶれないか

質問だけでなく、道具の定義と実行条件もそろえます。最初は読み取りなど副作用のない操作にすると、間違った呼び出しを外部へ反映せずに確かめられます。これは試験の進め方の提案で、本稿で両モデルを動かして得た実測結果ではありません。

どんなPCなら動かせる？

数十B級と比べれば持ち込みやすい規模ですが、必要VRAMを「4Bだから○GB」と一つには決められません。量子化、実行環境、文脈長、KVキャッシュの形式、CPU側へ配置する量でも変わります。手元では次の順に確かめましょう。

1. 使用するGGUFや量子化形式のファイルサイズを見る
2. モデルを短いコンテキストでロードする
3. VRAMとRAMの使用量を確認する
4. 必要なコンテキスト長へ段階的に伸ばす
5. 速度とメモリの増え方を見る

同じ普段の質問を両方へ渡せば、回答の不足と待ち時間を並べて見られます。起動できたところで終えず、必要な内容を返せて、他のアプリと同時に使える余裕があるかまで見ると、常用する方を選びやすくなります。

X2.5の2モデルならどちらから試す？

コーディングや複数段階のツール利用を比べたいなら4Bから、常駐時の省メモリや単純な処理を重視するなら1.7Bから試してみてください。4Bで待ち時間が長い端末でも、担当を絞った1.7Bなら条件に合うかもしれません。

対応版を用意できたら、次に決めたいのは、自分が必要とする文脈長と回答品質です。1Mという最大値を使い切るより、必要な資料を扱える長さで、回答・メモリ・待ち時間をそろえて確認しましょう。

X2.5を選んで試す場合は、X2.5の公式配布一覧からモデル名を確認してください。最新シリーズの導入が目的なら、X2.6の公式案内へ進み、本稿の対応履歴や選定理由をそのままX2.6の評価に使わないようにします。