DevOps-инженер или iOS-разработчик арендует Mac mini для CI, Xcode или локального LLM — и через неделю обнаруживает: SSH обрывается ночью, VNC показывает чёрный экран, а support отвечает «перезагрузите сами». В 2026 году проблема редко в вашем коде: чаще в архитектуре провайдера. Ниже — три системных причины offline, матрица типов аренды, шесть шагов проверки до оплаты и как Mac mini M4 на LlmMac даёт предсказуемый uptime для production-задач.

Навигация: три причины offline · матрица провайдеров · диагностика SSH · шесть шагов проверки · цифры для RFC · выбор и покупка.

Три причины, почему арендованный Mac mini «всегда offline»

1. Oversubscription вместо dedicated hardware. Некоторые «облачные Mac» — это time-slicing одного физического узла между десятками клиентов. Когда соседний tenant запускает Xcode archive или MLX inference, ваш SSH-сессия теряет приоритет CPU и выглядит как «сервер упал». Технически Mac жив, но для вас — offline. Признак: serial number меняется после «перезагрузки» или system_profiler показывает конфигурацию, не совпадающую с тарифом.

2. Sleep-политики macOS без явного отключения. macOS по умолчанию уходит в sleep при простое дисплея — даже без монитора. Провайдер, не настроивший pmset -a sleep 0 disablesleep 1, теряет SSH-сессии каждую ночь. Дополнительный риск: автоматический logout через 10–30 минут без GUI-активности, что ломает long-running CI job.

3. NAT и «jump-host only» доступ. Если SSH доступен только через прокси провайдера, а не по публичному IP, любой рестарт jump-host = массовый offline для всех клиентов. Плюс: macOS Security Update без предупреждения перезагружает машину — и без documented maintenance window вы узнаёте об этом только по failed pipeline.

Матрица типов аренды Mac mini (2026)

Используйте таблицу при выборе провайдера. Цифры uptime — типичные значения по отзывам инженерных команд, не маркетинговые SLA.

Тип аренды Реальный uptime SSH стабильность Риск offline Когда подходит
Dedicated Mac mini M4 99,5–99,9% Прямой IP, keepalive Низкий CI/CD, Xcode, LLM inference
Shared / time-slice 85–95% Через jump-host Высокий Краткие demo, не prod
Virtualized Mac 90–97% Зависит от гипервизора Средний Unit-тесты без Simulator
Colocation + remote hands 99%+ Ваш VPN Низкий, но CAPEX Enterprise, свой дата-центр
LlmMac dedicated M4 99,7%+ SSH + VNC, pmset настроен Минимальный Production CI, iOS, AI

Вывод: если pipeline должен работать 24/7 — только dedicated physical Mac mini с документированным SLA. Shared и virtualized экономят 30–50% бюджета, но скрытая стоимость простоя CI часто превышает разницу за один failed release.

Диагностика: offline или «мёртвый» SSH?

Перед сменой провайдера разделите симптомы. Connection refused на порту 22 — Mac выключен или firewall блокирует; Connection timed out — проблема NAT или jump-host; Broken pipe после idle — sleep или NAT timeout без keepalive. Запустите параллельно ping, nc -zv host 22 и VNC — если ping жив, а SSH мёртв, проблема в sshd или sleep, а не в «упавшем сервере».

На dedicated Mac mini M4 LlmMac sshd слушает 0.0.0.0:22, pmset отключает sleep, а в консоли виден uptime и последняя перезагрузка — вы диагностируете за минуты, а не через тикет support.

Шесть шагов проверки провайдера до оплаты

  1. Health probe 24 часа. До оплаты запустите cron: ssh mac 'uptime' каждые 60 секунд. Запишите количество failed ping за 24 ч — целевой порог для prod: менее 3 пропусков.
  2. Проверка dedicated. Выполните system_profiler SPHardwareDataType — serial number и модель должны совпадать с тарифом и не меняться между сессиями.
  3. Sleep policy audit. Проверьте pmset -g: sleep должен быть 0, disablesleep — 1. Запросите у support скриншот настроек Energy Saver.
  4. Прямой сетевой путь. SSH должен работать по публичному IP или вашему VPN, а не только через web-консоль провайдера. Проверьте ServerAliveInterval 60 в ~/.ssh/config.
  5. Maintenance window. Запросите письменную политику macOS updates: день недели, время UTC, уведомление за 24 ч. Без этого — гарантированный offline раз в месяц.
  6. SLA и компенсация. Зафиксируйте uptime SLA (минимум 99,5%), время реакции support (≤4 ч) и кредит за простой свыше 30 минут. Verbal promise без SLA = offline без recourse.

Цифры и тезисы для внутренней wiki

  • 99,5% uptime — минимальный порог для production CI; это допускает ~3,6 часа простоя в месяц — учитывайте при планировании release window.
  • До 40% «offline» на shared Mac — следствие neighbor noise, а не сбоя сети; dedicated M4 устраняет этот класс проблем полностью.
  • ServerAliveInterval 60 + TCPKeepAlive yes в SSH config снижают ложные disconnect на 70% при NAT timeout провайдера.
  • 16 GB RAM — минимум M4 для Xcode CI; при параллельном Simulator + LLM нужны 24 GB, иначе thermal throttle вызывает «зависание», похожее на offline.
  • Стоимость одного failed release в среднем $800–2 000 для команды из 5 человек — dedicated аренда за $50–80/мес окупается после первого предотвращённого простоя.
  • VNC fallback обязателен: при SSH offline GUI-доступ через VNC показывает, спит ли Mac или завис sshd — без VNC вы слепы при диагностике.

Итог: стабильный Mac mini — это архитектура, а не удача

«Сервер всегда offline» — симптом неправильного типа аренды, а не «Mac плохо работает в облаке». Dedicated Mac mini M4 с отключённым sleep, прямым SSH и documented maintenance window даёт предсказуемый uptime для CI, Xcode и AI inference.

На LlmMac вы получаете dedicated Mac mini M4 с настроенным pmset, SSH/VNC доступом и SLA 99,7%+. Пройдите шесть шагов проверки на trial-неделе, зафиксируйте uptime, затем масштабируйте на production pipeline. Оформление — на странице аренды; сравнение тарифов — в калькуляторе. Не платите за shared «облачный Mac», пока не доказали uptime dedicated узлом.

Итог: oversubscription, sleep macOS и NAT без SLA — три главных врага uptime. Dedicated Mac mini M4 на LlmMac решает все три. См. также: гид по конфигурации M4, аренда для iOS, опыт фрилансера.