Обновить

Отчёт по виртуальным машинам Proxmox

К сожалению в бесплатной версии Proxmox VE нет отчётов и привычной для меня в Vmware Vsphere выгрузки данных по ВМ в CSV с выборкой нужных столбцов поэтому я написал небольшой и как мне кажется универсальный плейбук Ansible.

Пример отчёта
Пример отчёта

Ссылка: https://github.com/Leonid-Kanareykin/proxmox-vm-report

Описание:

Этот плейбук подключается ко всем кластерам и нодам Proxmox и получает подробную информацию о ВМ: группы Ansible со всеми дочерними группами (обычно: группа, DC, кластер), имя узла Proxmox, VMID, имя ВМ, статус питания, CPU (ядра), выделенная RAM (ГБ), используемая RAM (ГБ), размер всех дисков (ГБ), тип ОС, версия ОС (агент), пул, теги (включая тип ОС из конфига, версию ОС из агента QEMU, пул, теги), и формирует CSV-отчет с временной меткой. Скорость работы для 90 хостов и 3000 ВМ примерно 15 минут.

!!! Тестировалось с примером файла инвентаря в формате yaml:

 https://github.com/Leonid-Kanareykin/proxmox-vm-report/blob/main/inventory-example.yml

Ключевые возможности:

  • подключение по SSH к одному или нескольким хостам и кластерам из файла инвентаря yaml

  • генерация CSV-файла с группами Ansible, Узел, VMID, Имя ВМ, Статус, CPU (ядра), RAM выделено (ГБ), RAM использовано (ГБ), Размер всех дисков (ГБ), Тип ОС, Версия ОС (агент), Пул, Теги

  • получение информации из нескольких кластеров и хостов

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

  • команды командной строки вроде pvesh, которые на самом деле используют API-

  • параллельная обработка по ВМ на каждом узле (используя xargs -P)

  • на случай если агент QEMU недоступен и мы не можем получить версию ОС то происходит получение 'ostype' из конфига ВМ что бы понимать тип ОС

  • - конвертация значений памяти/дисков из байт в гигабайты (2 знака после запятой)

  • добавление строки заголовка с удобными для пользователя названиями колонок
    отсутствие временных файлов на управляющем узле – все собирается в памяти

Запуск по всему инвентарю:
ansible-playbook -i inventory-example.yml /playbooks/pve-vm-report-latest.yml

Запуск по некоторым кластерам или одному кластеру:
ansible-playbook -i inventory-example.yml /playbooks/pve-vm-report-latest.yml --limit proxmox_dc1_cluster1,cluster2_pve_dc2

Теги:
Всего голосов 8: ↑8 и ↓0+11
Комментарии0

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Наш проект называется ExVRAM Lab. Это открытая исследовательская лаборатория, в которой мы проверяем, насколько большие локальные LLM можно запускать на обычных видеокартах с ограниченным объёмом VRAM, если использовать ultra‑low‑bit quantization, полное размещение весов на GPU и существующие open‑source inference‑технологии.

ExVRAM расшифровывается как Exchange Compute for VRAM. Основная идея проекта — в ряде сценариев выгоднее потратить часть свободной вычислительной мощности GPU на работу с более компактным представлением весов, чем хранить часть модели в оперативной памяти и постоянно передавать данные через PCIe.

Когда мы начинали проект, исходный вопрос был достаточно простой: можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM так, чтобы она не просто «запустилась», а работала полностью на GPU, поддерживала длинный контекст и обеспечивала нормальную интерактивную скорость генерации.

В качестве основной тестовой системы мы используем NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. Основная модель в текущих экспериментах — Qwen3.8–27B.

Сначала результат выглядел не слишком впечатляюще. Модель запускалась, но значительная часть весов оставалась в системной памяти. Около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB — на CPU. Скорость генерации составляла порядка 3,8–5,5 токена в секунду.

При этом сама видеокарта была загружена далеко не полностью.

Это стало одним из первых важных наблюдений проекта. Проблема заключалась не столько в нехватке вычислительной мощности RTX 5060, сколько в том, что часть decoder weights находилась в RAM. Во время autoregressive generation данные приходилось постоянно передавать между CPU и GPU через PCIe.

Как мы запустили Qwen3.8–27B целиком на RTX 5060 8 GB и получили ~30 токенов/с

Публикации