В этом материале
keep_alive управляет временем удержания модели; это не настройка размера контекста или скорости вычислений.
Параметр keep_alive в Ollama управляет временем, на которое модель остаётся загруженной после обращения. Удержание помогает избежать повторной загрузки при следующем запросе, но занимает память. Выгрузка освобождает ресурс для другой работы, добавляя холодный старт позже. Выбор зависит от частоты обращений и необходимости совместного использования машины.
Разделите загрузку и генерацию
Первый запрос после выгрузки может включать чтение весов и подготовку вычислений. Повторный запрос к уже загруженной модели проходит другой путь. Если смешать эти измерения, создаётся впечатление непостоянной скорости GPU, хотя основное различие относится к жизненному циклу модели.
API generate Ollama описывает параметр и поля времени ответа. Сохраните отдельно время загрузки и генерации, если они доступны в вашей версии. Не считайте весь интервал ответа чистым вычислением токенов и не сравнивайте холодный запрос одной модели с прогретым запросом другой.
Проверьте явное удержание
Учебный пример для уже доступной модели:
curl http://127.0.0.1:11434/api/generate \
-d '{"model":"qwen3:8b","prompt":"Ответь одним словом.","stream":false,"keep_alive":"10m"}'
Значение 10m задаёт экспериментальное время удержания, а не рекомендуемый режим для всех систем. Идентификатор замените установленным тегом. После запроса посмотрите ollama ps, затем повторите обращение до истечения интервала и сравните время загрузки.
Семантика длительности и серверной переменной описана в официальном FAQ. Учитывайте, что параметр отдельного API-запроса может переопределять общую настройку: клиентское приложение нужно проверять вместе с сервером.
Проверьте выгрузку отдельно
В документации предусмотрено значение 0 для выгрузки после обращения. Для штатного завершения удержания также есть команда остановки модели. Выбирайте способ по своей версии и убедитесь в результате через список загруженных моделей, а не только по завершению команды клиента.
Не выгружайте модель, которой прямо сейчас пользуются другие задачи, без согласования. На общей машине изменение жизненного цикла влияет на соседние запросы. Завершение генерации, удержание весов и доступность файла на диске — разные состояния: выгрузка из памяти не означает обязательного повторного скачивания checkpoint.
Сравните два расписания обращений
Практический тест: три запроса с короткими паузами, затем обращение после длинного простоя. Повторите сценарий с удержанием и с выгрузкой, сохранив модель и контекст. Запишите занятую память между запросами и задержку следующего ответа.
Если задача использует две модели по очереди, добавьте переключение A → B → A. Удержание обеих возможно только при подходящих условиях; оно не создаётся одним большим keep_alive. Подробная проверка приведена в материале о двух моделях. Фактическое размещение разобрано в статье CPU/GPU.
В отчёте подпишите длительность пауз между запросами. Без неё наблюдение о повторной загрузке невозможно воспроизвести, а одинаковое название модели не объясняет различие времени начала ответа.
Согласуйте режим предоставления машины
Для владельца рабочей станции полезно понимать, сколько памяти останется другим приложениям в паузах. Для выделенного сервера важнее предсказуемое начало ответа после простоя. Финансовое обсуждение должно связывать эти требования с доступной ёмкостью и расписанием, а не считать занятый кеш доказательством постоянной полезной нагрузки.
Такая карточка показывает, как машина ведёт себя между обращениями и какой следующий эксперимент нужен для рабочего пилота.