Мой сетап: MacBook + собственное облако на мини-ПК
Хочу рассказать, как работаю с MacBook и домашним сервером: что вынес в отдельные ВМ, как подключаюсь удалённо и какие сервисы использую. А ещё — как нейросети помогли мне перевести сервер с Windows и Hyper-V на Proxmox, запустить локальные модели и автоматизировать повседневные задачи. Интересно узнать, как это устроено у вас.
В статье — общая схема моего сетапа и опыт его использования, без пошаговых инструкций по установке и настройке. Бенчмарки и скорость генерации в токенах в секунду здесь не привожу: подобные данные можно найти в интернете, а эта статья — о моём опыте использования сервера.
Содержание
- Когда одного MacBook стало мало
- Сначала Windows, потом Proxmox
- Что сейчас работает на сервере
- Локальные модели и задачи для Hermes
- Как подключаюсь из дома и в поездках
- Как управляю самим сервером
- Что получилось
Мой сервер — мини-ПК Minisforum MS-S1 Max на AMD Ryzen AI Max+ 395 (Strix Halo) со 128 ГБ оперативной памяти. На нём работают виртуалки, сервисы и локальные нейросети, а MacBook остаётся основным компьютером.
Я покупал мини-ПК на Ozon в августе 2025 года. С доставкой он обошёлся примерно в 190 тысяч рублей. На момент написания статьи такая конфигурация стоит заметно дороже.
Когда одного MacBook стало мало
Раньше я обходился одним MacBook. Для локальной работы с 1С использовал VMware Fusion с Windows 11 ARM. Со временем ресурсов ноутбука на виртуалки и сервисы стало не хватать, и я начал думать, что с этим делать. Рассматривал переход на облачный сервер, более мощный MacBook, Mac mini и отдельный x86-мини-ПК.
От облака отказался, потому что хотелось самому контролировать инфраструктуру. Среди MacBook и Mac mini не нашёл подходящего варианта с памятью больше 32 ГБ — не устраивали цена или наличие.
В итоге выбрал отдельный x86-мини-ПК: меня устроило соотношение цены и возможностей, а 1С на нём можно было запускать без эмуляции. Привычный способ работы почти не менялся — MacBook оставался основным компьютером, а Windows и рабочие окружения переезжали на домашний сервер. Подключаться к ним можно удалённо, как к облаку.
К Minisforum присмотрелся после того, как увидел у знакомого X1 Pro. Он мне понравился, но для себя хотелось больше мощности и памяти. Поэтому остановился на Minisforum MS-S1 Max: мощный x86-процессор, 128 ГБ RAM и возможность запускать локальные LLM в компактном корпусе. Поставил его на шкаф в коридоре и подключил к источнику бесперебойного питания. Получился небольшой домашний сервер, которым пользуюсь удалённо.
Сначала Windows, потом Proxmox
Мини-ПК приехал с предустановленной Windows — привычной для меня системой. Hyper-V я без особых трудностей настроил сам: поднял ВМ с Windows Server 2022 для сервера 1С и ещё одну с Windows 11 Pro для разработки и тестирования.
Мне нравилась сама идея: в отдельной ВМ можно ставить что угодно и экспериментировать с настройками. Если что-то сломал — вернулся к заранее сделанному снимку. Основной рабочий компьютер эти эксперименты не затрагивают.
Постепенно захотелось так же отделить от хоста остальные программы и сервисы. Но с оборудованием были неудобства. USB-ключ в ВМ получилось пробросить только через USB-over-network: пришлось поставить дополнительную программу и на хост, и в гостевую систему.
Движки для запуска локальных LLM я хотел запускать в Docker с доступом к GPU, чтобы не ставить весь этот софт на хост. Но наладить такую схему с Radeon 8060S под Windows у меня тогда не получилось (Сейчас это уже можно). Поэтому движки приходилось устанавливать прямо на хост.
Получалось, что рабочие задачи я разделил по виртуалкам, а сам хост всё равно обрастал программами. Хотелось довести эту идею до конца: оставить на нём только виртуализацию, а весь остальной софт разнести по ВМ и контейнерам. Тогда я и задумался о смене системы на сервере.
С обычным Linux всё упиралось в отсутствие опыта: самостоятельно установить его и собрать на нём нужную систему было для меня слишком сложно. Поэтому искал готовые инструменты для управления виртуалками и контейнерами. А решиться на переход помогли нейросети: с ними стало проще разобраться в незнакомых настройках и исправлять ошибки. Без этой помощи я вряд ли стал бы уходить с привычной Windows.
Так я пришёл к Proxmox. Получил чистый хост и больше свободы в организации ВМ и контейнеров: всё управляется из одной панели, USB с хоста можно пробросить в нужную ВМ, а GPU — использовать в нескольких контейнерах. Для моего сценария это оказалось удобно.
С переходом всё равно пришлось повозиться. Пару раз после моих действий хост зависал, но удавалось зайти по SSH, аварийно перезагрузить его и восстановить работу.
Что сейчас работает на сервере
Сейчас мой сетап выглядит так:
Для рабочих задач у меня четыре виртуальные машины:
- Разработка 1С — Windows 11 Pro с подключением по RDP. Вести разработку под Windows мне удобно и привычно.
- Сервер 1С — Ubuntu с PostgreSQL и сервером 1С. Объём RAM для этой ВМ зафиксировал, чтобы избежать проблем с привязкой программной лицензии 1С.
- Удалённая работа — отдельная ВМ со всеми нужными для неё настройками. Мне так удобно.
- Бухгалтерия — ВМ со всем нужным софтом. С хоста проброшен USB-ключ для налоговой и работы с ЭДО.
Пробовал использовать Ubuntu для разработки и удалённой работы. Но удобного удалённого подключения к графическому интерфейсу так и не добился: при использовании xrdp интерфейс работал с огрехами и не подходил мне для повседневной работы. Поэтому от Ubuntu как рабочей ВМ отказался
Сервер 1С и машина для разработки могут работать круглосуточно. MacBook можно закрыть и забрать с собой — виртуалки продолжат работать, как в облаке.
Файлы тоже храню на сервере: дома открываю их через сетевой диск, извне — через Nextcloud.
Нашлось применение и для игр. На сервере работает контейнер со Steam Headless, к которому подключаюсь через Moonlight. Сейчас, например, играю так в Silent Hill 2 Remake на максимальных настройках.
Это не серверное железо, а оперативная память здесь без ECC. Но для моих задач такой конфигурации хватает. Раз в неделю через cron на хосте Proxmox запускается резервное копирование на внешний жёсткий диск. В копии входят только данные виртуальных машин.
Сервер подключён к ИБП. Через NUT я настроил автоматическое завершение работы: если пропадает электричество и заряд аккумулятора ИБП падает до 10%, NUT инициирует штатное выключение Proxmox-хоста.
Локальные модели и задачи для Hermes
Ryzen AI Max+ 395 я выбрал в том числе ради локальных LLM. Для их запуска у меня два отдельных контейнера:
- llama.cpp запускает Qwen3.6-35B-A3B. Это моя основная локальная модель на каждый день.
- Halogen Flash Server запускает Qwen3.8-Flash-Next. Её включаю для локальной разработки, экспериментов и просто когда хочется попробовать возможности большой модели.
Обычно эти модели не работают одновременно. После запуска Halogen остаётся около 30 ГБ свободной оперативной памяти — этого хватает ещё на одну-две ВМ. Контейнеры совместно используют Radeon 8060S через GPU sharing: оба получают доступ к видеокарте без GPU passthrough и эксклюзивного закрепления за одним из них. По моим замерам, пиковое общее энергопотребление в режиме Balanced составляет около 150–160 Вт во время инференса.
Что поручаю Hermes
Hermes Agent связывает модели с моими задачами и инструментами. Для общих запросов и разработки его модель по умолчанию — облачная DeepSeek V4.1 Flash через OpenRouter. Она устраивает меня по стоимости и качеству для повседневных задач. Локальные модели подключаю, когда хочу обрабатывать данные на своём сервере, а также для тестов и экспериментов. Если облачные сервисы временно недоступны, могу переключиться на локальную модель.
Например, почту Hermes анализирует только с помощью локальной Qwen3.6-35B-A3B: письма из разных ящиков он группирует, выделяет важное и готовит краткую сводку. Для этого сценария облачную модель не использую. Локальные модели также применяю для работы с мессенджерами, с агентами внутри 1С и для тестирования действий в 1С через VA MCP. При этом для самой разработки в 1С я всегда использую облачные модели.
По моим наблюдениям, Qwen3.6 лучше показывает себя, когда задача описана чётко и для неё уже подготовлены инструменты. Qwen3.8 чаще справляется с более свободной постановкой задачи. Пробовал и Gemma 4, но в моих задачах она заметно менее надёжно вызывала инструменты (tool calling), поэтому от неё отказался. Для работы с локальными моделями, на мой взгляд, оптимальная схема — сначала с помощью облачной модели подготовить нужные инструменты, а затем использовать их с локальной моделью.
Если интернет однажды массово отключится, я хотя бы смогу попросить локальную Qwen3.8 придумать план действий. Главное — чтобы электричество осталось 😂
Часть задач Hermes выполняет по расписанию, остальные я запускаю через чат по мере необходимости. Помимо почты, он напоминает о предстоящих встречах, подбирает новости по интересующим меня темам и проверяет обновления нужных программ.
Для разработки я обычно использую pi: мне нравится, что в нём нет ничего лишнего. В моей конфигурации стартовый контекст Hermes — системные инструкции и описания инструментов — занимает около 15 тысяч токенов. Для задач разработки большая часть этого контекста обычно избыточна, поэтому pi мне удобнее. Иногда для разработки использую и Hermes.
Управление приложениями через Android MCP
Для работы с мобильными приложениями на сервере запущен отдельный контейнер с Android x86. С помощью Claude я сделал для него MCP-интерфейс: он предоставляет инструменты, через которые агент взаимодействует с приложениями. В основном использую его для мессенджеров, Ozon и Avito — приложений, которые другим способом автоматизировать у меня не получилось.
Как подключаюсь из дома и в поездках
Работаю по-прежнему с MacBook. К рабочим ВМ подключаюсь по RDP, к серверу и сервисам — по SSH и через браузер. Мне важно, чтобы всё это было доступно и вне дома.
Одно время использовал Tailscale: удобно, и выделенный публичный IP не нужен. Но однажды во время поездки он посчитал, что я нарушаю санкции и перестал работать, и я остался без удалённого доступа. После этого пришлось искать другой вариант.
В итоге подключил выделенный публичный IP и настроил доступ по SSH. На роутере установил нестандартный порт для доступа SSH извне. Вход по паролю отключил — оставил только авторизацию по ключу. В RDP-клиенте настроил шлюз (gateway), поэтому для подключения к ВМ использую те же внутренние адреса, что и дома. Отдельные адреса для работы извне прописывать не нужно.
Если нужен какой-то сервис, пробрасываю его порт через SSH на localhost своего компьютера или организую доступ через VPS. Так я могу пользоваться нужными мне ВМ и сервисами почти как в домашней сети, без VPN. SSH-туннели шифруют трафик, а на MacBook для них хватает встроенного клиента.
Как управляю самим сервером
Для доступа к самому хосту есть GL.iNet Comet Pro — аппаратный KVM. Через него можно увидеть экран сервера при загрузке и зайти в BIOS.
На Comet Pro я запустил дополнительный сервис — dashboard для Proxmox. Он работает на самом Comet Pro, поэтому доступен, даже когда сервер выключен. Через dashboard я включаю сервер с помощью Wake-on-LAN. Когда Proxmox запущен, могу управлять ВМ и контейнерами, а также штатно выключить хост: для этого dashboard обращается к Proxmox с токеном доступа.
Что получилось
Так у меня и получилось своё облако: виртуалки, файлы и сервисы доступны с MacBook, но работают на отдельной машине. Когда нужно новое окружение, создаю его на сервере, выделяю ресурсы и оставляю работать. MacBook при этом остаётся привычным рабочим компьютером.
Без нейросетей я бы всё это не собрал. Продолжал бы использовать на сервере Windows 11 Pro с Hyper-V и даже не задумывался бы о Proxmox и многих сервисах, которыми сейчас пользуюсь.
А как у вас устроена инфраструктура? Насколько нейросети помогли вам её изменить?
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
