Навигация: три причины 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.
Шесть шагов проверки провайдера до оплаты
- Health probe 24 часа. До оплаты запустите cron:
ssh mac 'uptime'каждые 60 секунд. Запишите количество failed ping за 24 ч — целевой порог для prod: менее 3 пропусков. - Проверка dedicated. Выполните
system_profiler SPHardwareDataType— serial number и модель должны совпадать с тарифом и не меняться между сессиями. - Sleep policy audit. Проверьте
pmset -g: sleep должен быть 0, disablesleep — 1. Запросите у support скриншот настроек Energy Saver. - Прямой сетевой путь. SSH должен работать по публичному IP или вашему VPN, а не только через web-консоль провайдера. Проверьте
ServerAliveInterval 60в ~/.ssh/config. - Maintenance window. Запросите письменную политику macOS updates: день недели, время UTC, уведомление за 24 ч. Без этого — гарантированный offline раз в месяц.
- 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, опыт фрилансера.