Qwen3-VL 8B + Ollama: разбор сессии настройки auxiliary.vision

Дата: 2026-08-30. Хост: RTX 5060 Ti 16 GB VRAM, Ollama в Docker (контейнер ollama), main-модель Hermes — облачная polza.ai (deepseek/deepseek-v4-flash-0731).

Итог

auxiliary.vision переведён на локальную qwen3-vl:8b:

model: qwen3-vl:8b (~6.14 GB на диске, ~7.2 GB VRAM при ctx 4096/8192)
provider: custom, base_url: http://localhost:11434/v1, api_key: ollama
остальные auxiliary остались на auto → облачный main-провайдер

Проверено E2E: vision-запрос через Hermes-клиент (resolve_provider_client) отвечает "red"/"blue" на тестовых PNG.

Ключевые факты о Hermes auxiliary (agent/auxiliary_client.py)

Раздел конфига: auxiliary.<task>.provider/model/base_url/api_key в config.yaml.
provider: auto цепочка (текст): main-провайдер → OpenRouter → Nous Portal → custom endpoint → Anthropic → прямые провайдеры. Для vision своя цепочка: main-провайдер (если поддерживает vision) → OpenRouter → Nous → Anthropic → custom endpoint (локальные Qwen-VL/LLaVA/Pixtral).
MINIMUM_CONTEXT_LENGTH = 64_000 (agent/model_metadata.py:405) — флор только для compression. Остальные задачи без флора.
resolve_provider_client() сигнатура: explicit_base_url / explicit_api_key (не base_url/api_key — TypeError).
Vision-capable локальных моделей определяется через query_ollama_supports_vision (capabilities в /api/show, или model_info.*.vision.block_count на старых серверах).

Ошибки в процессе (транскрипт)

HTTP 500 на /api/chat с картинкой 1×1 px:
```
panic: height:1 or width:1 must be larger than factor:32
github.com/ollama/ollama/model/models/qwen3vl.(*ImageProcessor).SmartResize
```
→ Ошибка картинки, не конфигурации. Входной образ должен быть ≥ 32 px.
Пустой content при finish_reason: stop на картинке 64×64 — reasoning ушёл в reasoning поле. На 256×256 ответ нормальный ("red").
hermes chat -m ... --provider custom в CLI: "No API key found for provider 'custom'" — CLI-запуск не отражает auxiliary-резолв; auxiliary берётся из config.yaml напрямую.
curl ... | python3 в terminal — блокируется security scan (pipe to interpreter); использовать execute_code с urllib вместо пайпов.

VRAM-планирование (qwen3-vl:8b, GGUF)

GGUF-контекст: qwen3vl.context_length = 262144, layers=36, embedding=4096.
KV cache (f16) ≈ 2 · layers · dim · 2 · ctx · 2 bytes:
- 32K → ~38.7 GB, 64K → ~77 GB, 128K → ~155 GB, 262K → ~309 GB. → Физически полный контекст не влезает в 16 GB. Ollama грузит с num_ctx 4096 по умолчанию, для запросов задавать options: {num_ctx: 8192}.
Итоговое распределение: qwen3-vl 7.19 GB + bge-m3 1.21 GB = 8.4 GB занято, ~7.3 GB свободно.
qwen3:8b и qwen2.5-coder:14b имеют GGUF-контекст 40960/32768 (имена "-64k"/"-65k" лгут) — ниже 64K флора compression, поэтому compression оставлен на облаке.

Полезные команды

# Pull в Docker
docker exec ollama ollama pull qwen3-vl:8b

# Проверка caps/контекста
curl -s http://localhost:11434/api/show -d '{"model":"qwen3-vl:8b"}' | jq '.capabilities, .model_info["qwen3vl.context_length"]'

# Тест vision напрямую
curl -s http://localhost:11434/api/chat -d '{"model":"qwen3-vl:8b","messages":[{"role":"user","content":"What color?","images":["<b64>"]}],"options":{"num_ctx":8192},"stream":false}'

# OpenAI-совместимый путь (что использует Hermes)
curl -s http://localhost:11434/v1/chat/completions -d '{"model":"qwen3-vl:8b","messages":[{"role":"user","content":[{"type":"text","text":"What color?"},{"type":"image_url","image_url":{"url":"data:image/png;base64,<b64>"}}]}],"max_tokens":50}'

# Выгрузка из VRAM
docker exec ollama ollama stop qwen3-vl:8b

Откат конфигурации

hermes config set auxiliary.vision.provider auto
hermes config set auxiliary.vision.model ""

4.7 KiB Raw Blame History Unescape Escape