EVO-X2にLLMを寄せてしまい、DGX Sparkの出番がなくなった。しかし、DGX Sparkは、VRAMの間仕切りが不要なので、VRAMを大量に使う検証ができる。EVO-X2だと一度再起動して間仕切りを変える必要があるので面倒。
今日は立て込んでいてしっかり確認できず、なんとなく見ていた現象だったが、あまり深く追えていなかったので一通りの検証をしてみた。
DGX Spark / Qwen3.6:35B-A3B / Context 32K・48K・64K 比較
2026年現在、Ollama 0.24系では New Engine がデフォルト化された様子で、Runner管理やモデル再利用の挙動が大きく変わってきている。
今回は DGX Spark 上で、以下を実機検証した。
-
同一GGUF派生モデルは複数同時ロードされるのか
-
Contextサイズ違いは別Runnerになるのか
-
OLLAMA_MAX_LOADED_MODELSは実際に効くのか -
System Prompt はRunner共有時にどう扱われるのか
-
Open WebUI運用ではどの構成が最適か
自分の想像と違い、かなり面白い結果になった。
検証環境
Hardware
|
項目
|
内容
|
|---|---|
|
Machine
|
DGX Spark
|
|
GPU
|
NVIDIA GB10
|
|
CUDA
|
13.0
|
|
Driver
|
580.142
|
|
GPU Memory
|
約120GBクラス
|
Software
|
項目
|
内容
|
|---|---|
|
Ollama
|
0.24.0
|
|
Runtime
|
New Engine
|
|
Model
|
qwen3.6:35b-a3b
|
|
Quant
|
Q4_K_M
|
作成したモデル
以下の4モデルを作成。
|
Model
|
Context
|
|---|---|
|
qwen3.6:35b-a3b
|
65536
|
|
qwen3.6:35b-a3b-main-32k
|
32768
|
|
qwen3.6:35b-a3b-agent-48k
|
49152
|
|
qwen3.6:35b-a3b-code-32k
|
32768
|
さらに後半では：
main-32k
agent-32k
という完全同一Context構成でも検証した。
Ollama設定
environment:
OLLAMA_HOST: “0.0.0.0”
OLLAMA_ORIGINS: “*”
OLLAMA_KEEP_ALIVE: “30m”
OLLAMA_LOAD_TIMEOUT: “5m”
OLLAMA_NUM_PARALLEL: “1”
OLLAMA_NUM_THREADS: “6”
OLLAMA_CONTEXT_LENGTH: “65536”
OLLAMA_MAX_LOADED_MODELS: “3”
OLLAMA_MAX_QUEUE: “64”
OLLAMA_GPU_OVERHEAD: “2147483648”
OLLAMA_FLASH_ATTENTION: “0”
まずはVRAM使用量比較
Base 64K
qwen3.6:35b-a3b
CONTEXT 65536
VRAM：
38582 MiB
Main 32K
qwen3.6:35b-a3b-main-32k
CONTEXT 32768
VRAM：
31609 MiB
Agent 48K
qwen3.6:35b-a3b-agent-48k
CONTEXT 49152
VRAM：
35096 MiB
VRAM比較まとめ
|
Model
|
Context
|
VRAM
|
|---|---|---|
|
base
|
65536
|
約38.5GB
|
|
main
|
32768
|
約31.6GB
|
|
agent
|
49152
|
約35.1GB
|
かなり素直に増減している。
重要な発見その1
同一GGUF派生モデルは同時常駐しない
期待していた：
main-32k
agent-48k
の同時ロードは発生しなかった。
実際には：
main-32k
↓
agent-48k
で切り替わる。
つまり：
同一GGUF派生モデルは、Ollama New Engine 上では1つのRunnerとして扱われる可能性が高い
重要な発見その2
CodeモデルはMain Runnerを再利用
さらに面白いのがこれ。
qwen3.6:35b-a3b-code-32k
を呼んでも、表示は：
qwen3.6:35b-a3b-main-32k
のまま。
つまり：
main-32k と code-32k は同一Runnerとして再利用される
可能性が非常に高い。
ここで疑問
System Prompt はどうなる？
最初は、
Runner共有されるなら、mainのSYSTEM promptが使われ続けるのでは？
と思った。
そこで追加検証。
SYSTEM Prompt 検証
System Promptの設定を細工して、呼び出されたモデル毎に応答が変わるようにした。
main-32k
応答：
Qwen
agent-32k
応答：
Open WebUI Native mode
しかし
ollama ps は：qwen3.6:35b-a3b-main-32k
のまま。
ここがかなり重要
つまり：
Runnerは共有されている
しかし：
SYSTEM prompt は呼び出したモデルごとに切り替わっている
可能性が高い。
つまり New Engine はこう動いている？
かなり推測だが、おそらく内部では：
GGUF実体
+
KvSize
+
推論条件
でRunnerをキャッシュ。
一方で：
SYSTEM prompt
はリクエスト単位で適用している。
これかなり合理的
35Bクラスになると：
毎回30秒ロード
はかなり重い。
New Engine の：
Runner共有
は非常に合理的。
Open WebUI運用への影響
これはかなり良いニュース。
例えば：
|
用途
|
モデル
|
|---|---|
|
Main
|
main-32k
|
|
Agent
|
agent-32k
|
|
Code
|
code-32k
|
にしても、
VRAMは共有
SYSTEMは用途別
になる可能性が高い。
つまり：
-
ロード高速化
-
VRAM節約
-
モデル切替高速化
が期待できる。
Agentだけ48Kにする意味
Agentは：
-
長い履歴
-
ツール呼び出し
-
推論ログ
-
Function Calling
でContextを食いやすい。
そのため：
main-32k
agent-48k
という分離は非常に合理的。
実運用でおすすめの構成
Open WebUI用途
|
用途
|
モデル
|
|---|---|
|
普段のChat
|
main-32k
|
|
Agent
|
agent-48k
|
|
長文RAG
|
base 64K
|
|
Code
|
code-32k
|
DGX Sparkでは64Kも十分実用
DGX Sparkクラスでは：
35B + 64K
でも十分余裕がある。
EVO-X2では？
EVO-X2（128GB / VRAM64GB）でも基本挙動はかなり近いと考えられる。
ただし：
-
ComfyUI併用
-
GTT使用
-
Unifiedではない
ため、
48K中心運用
の方が安全。64kにするならVRAMの容量を増やした方がいいかもしれない。その分RAMが減るが。
結論
今回かなり重要なことが確認できた。
Ollama 0.24 New Engine は：
同一GGUF派生モデルを積極的にRunner再利用する
しかし同時に：
SYSTEM prompt はモデル単位で適用している
可能性が高い。
つまり：
VRAM節約
+
ロード高速化
+
用途別SYSTEM
を両立しようとしているように見える。
これは Open WebUI 運用ではかなり理想的な挙動。
特に：
main-32k
agent-32k
code-32k
を用途別に分けつつ、VRAMを無駄に消費しない設計ができる。
2026年のOllamaは、かなり進化している。自分でもついていくのが精一杯。去年とまるで違う。