LINUX.ORG.RU

Использование VRAM при взаимодействии с MCP

 , ,


1

1

Имею llama.cpp, https://huggingface.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF

# llama-server --host 0.0.0.0 --port 8000 -m ./Qwen3-Coder-30B-A3B-Instruct-IQ4_NL.gguf --jinja --temp 0.7 --min-p 0.0 --top-p 0.80 --top-k 20 --repeat-penalty 1.05 -fa off -lm mlock --n-cpu-moe 99 -c 100000 --cache-type-k q8_0

Запускается, занимает 14637M VRAM.

Иду в web морду, делаю запрос вида «вот тебе код проекта (текст файлов в запросе), переведи комментарии на английский»
Запрос успешен, занятая VRAM увеличивается ну может быть до условных 14700M и сидит на этом уровне как долго его запросами не закидывай.

Второй вариант: беру https://github.com/Luxshan2000/fastmcp-file-server подключаю к llama.cpp серверу, делаю запрос «в директории $$$ проекта прочитай файлы [список относительных путей до всех нужных к переводу файлов] выполни перевод всех китайских сообщений на английский язык.»
Оно доходит до запроса MCP на чтение файла и с этого момента начинает медленно и уверенно «выедать» VRAM.
Далее оно или упадёт в OOM или закончит, но VRAM не высвободит.

Объясните почему так во втором варианте, можно ли его как-то заставить хотябы высвобождать VRAM по завершению запроса?

★★★

попробуй сделать следующий тест:

  1. выключи MCP у llama-cpp
  2. поставь любой агент opencode,hermes,openhands,pi (я советую pi, opencode мейнстрим)
  3. настрой в этом агенте подключение к mcp серверу (самое простое через stdio)
  4. запусти агент, убедись что к mcp есть подключение, настрой его так чтобы использовалась модель llama-cpp
  5. повтори запрос

в llama-cpp поддержка mcp протокола появилась недавно, поэтому есть нюансы, сначала убедись что все нормально работает через агента

gagarin0
()
Ответ на: комментарий от gagarin0

ок

Поставил opencode в VM, как подключить mcp не разобрался, но оно само позволяет читать локальные файлы, наверное сойдёт для теста.

Запрос «В проекте crispasr-webui_translated для файлов main.go, static/app.js, static/index.html выполни перевод всех китайских сообщений на английский язык.» Тот-же эффект оно начинает читать файлы и это отъедает VRAM.

Ну, я наверное догадываюсь что чтение файла/выполнение инструментов это отдельный новый запрос и на это надо выделить новую VRAM, но эту VRAM после ни кто не высвобождает, в контекст изначального запроса прочитанные файлы вроде как не оседают

Flotsky ★★★
() автор топика

Обновите llama.cpp до последней версии (ну или ищите работающую перебором )))).

Если это не помогает, отключите квантование KV-кэша (–cache-type-k f16).

В качестве крайней меры — отключите CUDA-графы (GGML_CUDA_DISABLE_GRAPHS=1).

psv1967 ★★★★★
()
Ответ на: комментарий от Flotsky

как подключить mcp не разобрался

тут надо мышление менять.

запускаете агента, подключаете его с LLM и просите его настроить агента для работы с MCP сервером, если LLM туповат, то можно скачать исходники агента git clone … /tmp/agent и попросить «изучи исходники и настрой мне mcp сервер»

gagarin0
()
Ответ на: комментарий от gagarin0

Не вижу смысла. Я уже запустил агента и он своим каким-то другим способом, полагаю аналогичным mcp, воспроизвёл проблему. На понимаю почему добавление/изменение посредника уберёт проблему.

Да, может быть можно извернуться под какие-то сильно частные сценарии предподготовки запросов, но это уже сильно за «пните запрос через агента»

Flotsky ★★★
() автор топика
Ответ на: комментарий от Flotsky

смысл есть, чтобы разобраться в проблеме. удачи вам, вашим моделям с таким подходом.

gagarin0
()
Ответ на: комментарий от psv1967

отключите квантование, отключите CUDA-графы

С виду этот флаг указывается при запуске. Для теста до обновления
# GGML_CUDA_DISABLE_GRAPHS=1 llama-server --host 0.0.0.0 --port 8000 -m ./Qwen3-Coder-30B-A3B-Instruct-IQ4_NL.gguf --jinja --temp 0.7 --min-p 0.0 --top-p 0.80 --top-k 20 --repeat-penalty 1.05 -fa off -lm mlock --n-cpu-moe 99 -c 100000

Более простой запрос «прочитай файл и перечисли методы в нём». Проблема остаётся. Чтение файла = рост VRAM и после этот VRAM ни кто не высвобождает. Заметил что повторное чтение файла к росту VRAM не приводит и флаг на поведение не влияет. Но если продолжать читать другие файлы VRAM закончится и довольно быстро и тогда только reboot…

Обновите llama.cpp до последней версии

Они эти версии по десятку в неделю штампуют, перебирать это спорно.
Полез обновлять и оно не собирается. Уже сильно позже посмотрю на чём оно там застряло.
заодно почитаю что делает флаг GGML_CUDA_DISABLE_GRAPHS

Flotsky ★★★
() автор топика
Ответ на: комментарий от Flotsky

Ну и контекст обрежьте, это сильно память освободит. Явно выставить один поток, по умолчанию по моему оно больше клепает.

Она еще подробный лог пишет в процессе работы и на что уходит память прекрасно видно.

psv1967 ★★★★★
()
Ответ на: комментарий от Flotsky

Обновление не меняет картину. Ожидаемо.

Почитал про флаг GGML_CUDA_DISABLE_GRAPHS. Не понимаю как отключение оптимизаций выполнения инструкций должно повлиять на использование VRAM.

На всё предложенное «добавьте ограничений по ресурсам» аналогично.

Что-то мне подсказывает что то, что я описываю как проблему является ожидаемым поведением и где-то должен быть метод для точечной выгрузки контекста или всей модели и надо просто дёргать его своими силами

Flotsky ★★★
() автор топика
Ответ на: комментарий от psv1967

https://pastebin.com/PMyUPXBm
на столько тонны инфо, что мне особо ни о чём не говорит

Заметки:

Немного увеличил контекст чтобы быстрее воспроизвести проблему.

# llama-server --host 0.0.0.0 --port 8000 -m ./Qwen3-Coder-30B-A3B-Instruct-IQ4_NL.gguf --jinja --temp 0.7 --min-p 0.0 --top-p 0.80 --top-k 20 --repeat-penalty 1.05 -fa off -lm mlock --n-cpu-moe 99 -c 110000

0.10.387.618 I srv llama_server: listening on http://0.0.0.0:8000
Загрузилось в 18421MiB VRAM

Иду в web интрфейс, новый чат. Запрос «Прочитай файл 1 и перечисли его методы»
1.09.903.832 I slot launch_slot_: id 3 | task 0 | processing task, is_child = 0
На момент когда оно начало читать файл было занято 18485MiB VRAM

1.41.691.894 I slot launch_slot_: id  2 | task 147 | processing task, is_child = 0
...
11.00.873.422 I slot print_timing: id  2 | task 147 | prompt processing, n_tokens =  22528, progress = 0.95, t = 558.95 s / 40.30 tokens per second

Уже 19173MiB VRAM

В этом-же чате повторяю запрос для ‘файл 2’. Перечисленные строки начало запроса, начало чтения файла и сообщение перед концом чтения файла.

14.22.218.608 I slot launch_slot_: id  2 | task 858 | processing task, is_child = 0
...
14.38.054.100 I slot launch_slot_: id  2 | task 1007 | processing task, is_child = 0
...
24.33.093.224 I slot print_timing: id  2 | task 1007 | prompt processing, n_tokens =  12288, progress = 0.97, t = 595.04 s / 20.65 tokens per second

19621MiB VRAM

В этом-же чате повторяю запрос для ‘файл 3’

30.06.857.304 I slot launch_slot_: id  2 | task 2860 | processing task, is_child = 0
...
31.42.214.276 I slot launch_slot_: id  2 | task 3006 | processing task, is_child = 0
...
39.58.970.675 E CUDA error: out of memory

Далее только kill -9.

Flotsky ★★★
() автор топика
Ответ на: комментарий от Flotsky

Ну в принципе все как я и говорил:

  1. Запущено 4 нитки и они делят между собой заказанные 100000 контекста + накладные расходы. Решение «-np 1». Причем кеш они несмотря на флаги шарить память не шарят и не освобождают.

  2. Оно дохнет сейчас задолго до 100000 контекста, выставить -c 49152 или -c 65536

  3. Выключенный флешь атеншен включить обратно если модель на нем не падает

Если модели запиханной в gpu не хватает памяти в пике, она падает и единственное решение подбирать флаги (прежде всего контекст) при котором устойчиво хватает памяти при длительной работе с учетами фрагментации, кешей и т.п.

У меня месяцами работает модель загруженная индексацией после выставление реалистичного для доступного ресурса контекста.

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

флешь атеншен включить обратно

хм, о как. Я думал моё gpu (CMP 50HX) не умеет в fa т.к. ранее на других моделях при попытке его включения просто отваливалось с шины pci с illegal instruction (по памяти). Но тут внезапно не отваливается. Интересно, понаблюдаю.

выставить -c 49152 или -c 65536

Вот тут мы приходим к изначальной проблеме. Пусть я даже дам ему условные 20К контекста. Мой условный запрос «Напиши мне web морду по $(список требований)». Оно пишет, но потом «я заметил возможную ошибку, я перечитаю файлы проекта» и в этом месте никакого VRAM ему не хватает. Это проблема постановки запроса, возможно, как лучше, пока не знаю.

Плюс это я сейчас начал так делать т.к. мне просто лень копировать блоки кода туда сюда из запросов. Обычное использование всё-же требует хотябы 50К контекста

Решение «-np 1»

Это попробую

Flotsky ★★★
() автор топика
Ответ на: комментарий от psv1967

4 нитки и они делят между собой заказанные 100000 контекста + накладные расходы. Решение «-np 1».

С пары беглых тестов выглядит успешно, VRAM дополнительно ни кто не выедает.

Спасибо, я понял со второго раза. Всего-то надо было меня более подробно пнуть в сторону документации.

Ранее проигнорировал т.к. понял «Явно выставить один поток» как ограничить по CPU потокам

Flotsky ★★★
() автор топика
Ответ на: комментарий от Flotsky

У агентов есть сжатие контекста. opencode-dcp например.

Кроме того агента заставить все прочитать и попасть в такую ловушку не возможно, он сопротивляется и читает минимально.

psv1967 ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария