GPU Taskman показывает расход видеопамяти в ГБ по процессам и помогает искать перегрузку

Запустили локальную LLM, увеличили контекст — и свободная видеопамять закончилась. Прежде чем выбирать модель поменьше или покупать другую видеокарту, полезно понять, куда ушли гигабайты. GPU Taskman собирает расход памяти по процессам и помогает связать его с конкретной нагрузкой: моделью, браузером или соседней задачей.

Для разработчика здесь понятная польза: получить картину до изменения настроек и после него. Если проблема появилась после увеличения контекста, сравнение снимков поможет проверить, какой процесс стал занимать больше памяти. А оценка состава памяти модели подскажет, какую гипотезу проверять дальше.

Что показывает диспетчер

GPU Taskman работает в терминале. Он объединяет сведения о видеопамяти процессов, активности GPU, загруженных библиотеках и файлах моделей. В поддерживаемых конфигурациях можно увидеть, через какой стек работает приложение: CUDA, Vulkan или Direct3D. Для локальных LLM предусмотрено распознавание моделей и оценка памяти под веса, KV-кэш и рабочие буферы.

Это разные по надёжности сведения. Счётчик памяти сообщает измеренный расход. Название модели и предполагаемый состав этого расхода требуют дополнительных признаков. Наличие библиотеки CUDA само по себе ещё не объясняет, какая модель загружена и что именно она сейчас делает. Автор отдельно отмечает экспериментальный статус программы в документации проекта.

Поэтому удобнее читать экран в два прохода. Сначала найти процесс с большим расходом памяти. Затем посмотреть, какие объяснения утилита смогла для него собрать. Такой порядок помогает не принять правдоподобную подпись за результат прямого измерения.

Как проверить, куда уходит память

Возьмём обычную рабочую ситуацию: модель запускается, но после изменения настроек приложение начинает выдавать ошибку нехватки памяти. Сохраните исходный снимок, измените один параметр и снимите показатели повторно. В GPU Taskman для этого предусмотрены разовый вывод --once, машинный формат --json и сравнение diff.

Первым параметром для проверки может быть длина контекста. KV-кэш хранит данные, которые модель использует при обработке последовательности, и его объём связан с контекстом. Но конкретное поведение зависит от движка и настроек: память может резервироваться заранее. Поэтому полезно сравнивать одинаковые стадии работы приложения, например состояние после загрузки модели или после одинакового запроса.

Если одновременно поменять модель, размер контекста и другие настройки, прирост расхода будет сложнее объяснить. Практический смысл такого сравнения — сузить поиск причины. Оно также помогает заметить соседний процесс, который продолжает держать память после завершения вашей задачи. Сам монитор память не освобождает и настройки модели не исправляет.

Где начинаются ограничения

Особого внимания требует WSL. Там сведения о памяти приходят со стороны Windows, а принадлежность отдельных значений Linux-процессам приходится восстанавливать. Программа помечает уверенные сопоставления и догадки, а при недостатке данных может показать n/a. Перед выводом о конкретном процессе нужно посмотреть на эту пометку.

У проекта заявлена поддержка Windows, Linux, WSL и Apple Silicon, однако доступность отдельных показателей зависит от платформы, драйвера и видеокарты. Одинаковый интерфейс не означает одинаковую глубину наблюдения на любой машине. Разбивку памяти LLM тоже стоит использовать как диагностическую подсказку: утилита не читает содержимое VRAM и не выдаёт полный каталог находящихся там объектов.

Для установки предусмотрены команды uv tool install gputaskman и pipx install gputaskman; затем можно запустить gputaskman или gtm. Начать стоит с одной воспроизводимой проверки на своей нагрузке. Если снимки помогают объяснить расход памяти, инструмент уже приносит пользу: появляется основание менять конкретную настройку и проверять результат, прежде чем тратить время и деньги на замену оборудования.