Для многих рынок ИИ-решений представляется как конкурентная борьба облачных и open source-моделей, но спектр применения языковых моделей постоянно расширяется, закрывая все более узкие ниши. И сейчас все больше команд, даже среди лидеров, выкладывают свои специализированные модели в общий доступ открытыми не только для запуска, но и дообучения и доработок. Эти модели часто имеют более скромные системные требования по сравнению с облачными. Иногда настолько, что некоторые из них можно запускать на мобильных и встраиваемых устройствах даже без специальных нейро- или графических вычислителей. Такие тенденции требуют от ИТ-специалистов навыков в обращении с моделями, некоторые из которых мы рассмотрим в данной статье на примере настройки модели, ассистирующей в разработке программного кода на локальном ПК. Учитывая высокую динамику развития индустрии ИИ, приведенные решения не могут быть ультимативными и актуальными, однако, возможно, кому-то он помогут продвинуться в освоении навыков работы с LLM-моделями (Large Language Models - Большие языковые модели). 

Итак, несмотря на в целом высокие системные требования, модели могут запускаться на обычных компьютерах или ноутбуках с использованием игровых видеокарт бытовой сферы применения. Модели чувствительны в первую очередь к объему видеопамяти (или оперативной, если у вас ее достаточно много и вы терпеливы). Но уже объема в 4Гб будет хватать, чтобы запускать оптимизированные версии 7b и меньших моделей полностью на GPU, т.е. с терпимой производительностью. Такие модели уже могут стать пригодными в качестве ассистентов при использовании дополнительных инструментов, таких как MCP и RAG.

Квантизация

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

Наиболее распространенным форматом моделей на сегодня является GGUF от проекта llama.cpp. Он стал практически стандартом благодаря Ollama разработке на основе llama.cpp от партнеров из OpenAI, которая широко используется и имеет значительное сообщество и всевозможные дружественные продукты. 

Обычно модель можно скачать сразу в нескольких вариантах квантизации основанных на 8bit, 4bit типах данных и различных оптимизациях. 

Достаточно оптимальными вариантами по соотношению цена/качество является квантизация Q4. 

Считается, что размер gguf-файла соответствует требованиям к виртуальной памяти (GPU) для модели, но у меня некоторые модели показывали меньшее потребление, видимо, из-за архитектурных оптимизаций. Посмотреть статистику использования видеопамяти можно командой:

nvidia-smi

Локальный запуск модели

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

Дистрибутив для установки можно найти по ссылке на сайт производителя: https://ollama.com/download 

Правда, на тот момент у меня уже стоял фирменный драйвер Nvidia, и различные инструменты и библиотеки к нему как те, что идут в комплекте с CUDA. 

На Ubuntu это как минимум пакеты nvidia-driver-xxx и nvidia-cuda-toolkit.  

Запуск модели выглядел уже вот так:

ollama run gpt-oss:20b

Ollama основана на библиотеке llama.cpp, и, если вы хотите большей гибкости, можно использовать ее. 

Команда запуска для llama.cpp тоже достаточно проста:

llama-cli -m MODEL_NAME.gguf -q "query prompt for model"

где с параметром -m указывается имя модели или файла или путь к файлу, который вы скачали с huggingface.com или другого ресурса. 

А -p - это промт, т. е. запрос к нейросети простым текстовым предложением или в поддерживаемом формате.

Для себя я собирал llama.cpp из исходников.  

git clone git@github.com:ggml-org/llama.cpp.git

После чекаута репозитория исходных кодов и установки сборочных инструментов Linux-дистрибутива (скорее всего, потребуются как минимум build-essential и libcurl4-openssl-dev) команды компиляции и оформления в пакет выглядели следующим образом:

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES="XX" -DCMAKE_INSTALL_PREFIX=/usr 
cmake --build build --config Release  
sudo checkinstall cmake --install build/ 

Последняя команда позволяет создать по установленным файлам deb-пакет, который потом можно безопасно удалить из системы или перенести на другую такую же.  

при сборке пришлось учитывать модель моего GPU ускорителя в параметре CMAKE_CUDE_ARCHITECTURES. Значение, подходящее для вашей видеокарты или архитектуры, можно прочитать в документации к исходникам, но я, кажется, спросил у ИИ, скармливая ему сообщения об ошибках, выбрасываемые сборочными командами. 

Если вы хотите использовать сервер, работающий без графического ускорителя или использующего какую-то отличную от CUDA технологию, это также надо указывать в параметрах к cmake.

После установки бинарников в систему и перелогина стали доступны команды с префиксом llama-.

Самостоятельная квантизация

Если имеющаяся модель не подходит под ваши ресурсные возможности, ее можно квантизировать самостоятельно. В llama.cpp включен функционал конвертации. 

Выполняется она утилитой llama-quantize. Если запустить команду без параметров, то вам будет показан спектр доступных параметров. 

Я пользовался конвертором из stable-diffusion.cpp, и у меня команда квантизации выглядела вот так:

sd -M convert -m MODEL_NAME.safetensors -o ~/models/MODEL_NAME_q4_0.gguf -v --type q4_0

API-cервер

Сервер запускается примерно так же как и запрос из cli, но другим бинарником, собираемым или поставляемым вместе с llama.cpp. Например:

llama-server -m Kodify_Nano_q8_0.gguf --host 0.0.0.0

Запуск покажет вам небольшую инструкцию

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

Использование с плагином среды разработки

Для вайбкодинга подойдет любая среда разработки с плагином, совместимым с протоколами с llama.cpp. Для IntelliJ IDEA и OpenIDE это может быть плагин DevoxxGenie, который умеет работать и с облачными и с опенсорсными LLM, подключать RAD, MCP и многое другое. 

Чтобы получать более релевантные ответы и предложения лучше настроить под себя хотя бы системный промт, обозначив там требования к используемой технологии. Например, указав что модель - ассистент разработчика на Java веб-фреймворке Jmix.

От качества составления системного и пользовательского запроса сильно зависит релевантность результатов работы модели. Часто, если вам не удается добиться какого-то результата, надо просто объяснить модели нюансы и определить границы. Благо на локальной модели вы можете более смело экспериментировать ограничиваясь только аппаратными возможностями вашего железа. Также разные модели обучаются и файнтюняся(дообучаются) на разных данных и какие-то могут подойти под ваши задачи лучше, а другие возможно придется доводить до ума.  

Очень существенно качество результатов улучшается с использованием RAG, именно с его использованием мы делаем нашего Jmix AI ассистента https://ai-assistant.jmix.io более полезным. 

После этого можно добавлять файлы в контекст и получать релевантные решения по своим вопросам. Например, добавить поля для сущности или создать для нее экраны используя дескриптор в качестве образца, также конечно мы можем ставить общие и прикладные задачи кодирования и забирать решения себе в код.

Запуск в Docker 

Достаточно хорошо подходящей для генерации кода является модель Qwen Coder 2.5. Она оказалась настолько удачной, что многие отечественные вендоры построили свои модели на ее основе.   

Чтобы запускать контейнеры, использующие видеокарту, вам понадобится установить пакет интеграции, на Ubuntu он называется nvidia-container-toolkit.  

После этого можно выполнить запуск, указав каталог с моделями в качестве volume, путь до файла модели, номер порта, на котором будет отвечать сервер, и параметры работы с видеокартой.

docker run --gpus all -v=/home/syncro/models/:/models -p 8000:8000 ghcr.io/ggerganov/llama.cpp:server-cuda -m /models/qwen2.5-coder-7b-instruct-q3_k_m.gguf --port 8000 --host 0.0.0.0 -n 512 --n-gpu-layers 1 

Запуск в Kubernetes

Для запуска мы будем использовать специальный дистрибутив от разработчика Ubuntu, который, впрочем, работает и на других дистрибутивах операционных систем. Он достаточно прост в обращении и хорошо подходит для не очень масштабных инфраструктур. Также у него есть расширение для работы с видеокартами, которое надо включить при помощи такой команды: 

microk8s enable gpu

При этом от вас может потребоваться установка пакетов Nvidia, CUDA и их интеграции с Docker. 

Создайте каталог llama-cpp-k8s где-нибудь в проектах и в нем два файла: 

llama-cpp-server.json

{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "llama-cpp-server",
    "labels": {
      "app": "llama-cpp-server"
    }
  },
  "spec": {
    "containers": [
      {
        "name": "llama-cpp-server",
        "image": "ghcr.io/ggerganov/llama.cpp:server-cuda",
        "args": [
          "-m", "/models/qwen2.5-coder-7b-instruct-q3_k_m.gguf",
          "--port", "8000",
          "--host", "0.0.0.0",
          "-n", "512",
          "--n-gpu-layers", "1"
        ],
        "ports": [
          {
            "containerPort": 8000
          }
        ],
        "volumeMounts": [
          {
            "name": "models-volume",
            "mountPath": "/models"
          }
        ],
        "resources": {
          "limits": {
            "nvidia.com/gpu": "1"
          }
        }
      }
    ],
    "volumes": [
      {
        "name": "models-volume",
        "hostPath": {
          "path": "/home/syncro/models/",
          "type": "Directory"
        }
      }
    ]
  }
}

Эта конфиурация будет запускать Docker-контейнер с llama-cpp сервером работающим с моделью Qwen2.5 Coder из файла в /home/syncro/models. Это мой домашний каталог с моделями подключается тут как hostpath хранилище, возможно не самый оптимальный вариант для K8s с точки зрения простоты кластеризации, но, допустим, это наш подкроватный кластер из одной ноды. 

А также сервис, привязывающий порт 30080 к порту 8000 этого контейнера:

llama-cpp-service.json

{
  "apiVersion": "v1",
  "kind": "Service",
  "metadata": {
    "name": "llama-cpp-service-nodeport",
    "labels": {
      "app": "llama-cpp-server"
    }
  },
  "spec": {
    "type": "NodePort",
    "selector": {
      "app": "llama-cpp-server"
    },
    "ports": [
      {
        "port": 8000,
        "targetPort": 8000,
        "nodePort": 30080,  # Optional: Manually specify (30000-32767)
        "protocol": "TCP"
      }
    ]
  }
}

Применять конфигурации надо, как обычно, при помощи kubectl:

kubectl apply –f lama-cpp-k8s/

После запуска модель остается загруженной в видео память. Pod с Qwen Coder 2.5 занял у меня порядка гигабайта видеопамяти, что, в общем-то, немного. 

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

kubectl delete –f lama-cpp-k8s/

Итого

Таким образом, MicroK8s кластер, предоставляя возможность реализовать на нем платформу с подходом Infrastructure-as-Code, кажется вполне удобным способом управлять моделями даже в персональных целях, т. е. позволяет хранить и все параметры их запуска, а также, например, переиспользовать их, комбинируя с адаптерными слоями файнтюна. Также, конечно, его использование дает нам возможность построить универсально масштабируемую горизонтально систему.