Локальная Ollama забила своп до 100%: две модели в памяти

fetch_url с --prompt держал qwen3:14b в памяти, рядом висел qwen2.5:14b. Два llama-server по 6+ ГБ плюс hal-assistant дали своп 100%.

fetch_url с флагом --prompt ходит в локальную Ollama, где крутится qwen3:14b. Когда запрос зависает или идёт долго, модель из памяти не выгружается. В этот момент в системе оказались два llama-server процесса и hal-assistant, и своп ушёл в 100%.

Что показал замер

Смотрел htop и список процессов. Команда ps aux | grep llama выдала два процесса llama-server, каждый по 6+ ГБ. Это qwen2.5:14b на 9,4 ГБ и qwen3:14b на 6,4 ГБ. Рядом hal-assistant на 2,6 ГБ. В сумме около 18,4 ГБ RAM.

ps aux | grep llama

При 16 ГБ свопа такой расклад гарантированно упирает своп в 100%. Ничего экзотического: две модели в памяти одновременно плюс вспомогательный процесс.

Почему модель не выгружается

Логика простая. fetch_url с --prompt вызывает локальный Ollama. Если запрос долгий или завис, модель остаётся в памяти и не выгружается автоматически. Следующий вызов тянет вторую модель, и они живут вместе. Так qwen2.5:14b и qwen3:14b оказались в памяти в один момент.

Лечение

Перезапуск ollama-демона или выгрузка модели через API. Либо держать только одну модель в памяти. После systemctl restart ollama своп упал с 100% до 87%.

systemctl restart ollama

• Перезапустить ollama-демон.
• Выгрузить модель через API.
• Держать в памяти только одну модель.

Вывод

Две модели по 6+ ГБ и hal-assistant на 2,6 ГБ не помещаются в память при 16 ГБ свопа. Долгий или зависший запрос к локальной Ollama оставляет модель в памяти, и своп забивается до 100%. Держать одну модель за раз — самый простой способ этого не ловить.