Тест облачного кластера Mac mini: каково это — Thunderbolt 5 при 80 Гбит/с?

Что такое объединение Thunderbolt 5?

На странице конфигурации ZilCloud среди дополнительных опций есть пункт «Сервис объединения Thunderbolt 5»: +$1.4 в день или +$8.9 в месяц. Моя первая реакция была предсказуемой: зачем это вообще нужно?

Кратко: Thunderbolt 5 (далее TB5) — новый стандарт интерфейса на Mac mini M4. Теоретическая пропускная способность по каналу PCIe — 120 Гбит/с, а при прямом соединении двух устройств доступно 80 Гбит/с в обе стороны, то есть около 10 ГБ/с — вдвое больше, чем у TB4 (40 Гбит/с). Сервис TB5 от ZilCloud физически соединяет два или более облачных Mac mini M4 кабелем Thunderbolt, формируя для macOS прозрачную высокоскоростную локальную сеть.

С инженерной точки зрения это не просто «две машины в одной сети». TB5 идёт по шине PCIe, задержка на порядки ниже, чем у Ethernet. Теоретически возможен межмашинный доступ к памяти с пропускной способностью, близкой к локальному NVMe (через механизмы Remote Direct Memory Access). Для кластеров сборки, инференса ИИ и пулов рендеринга видео это не маркетинговая цифра, а рабочий инструмент.

Настройка: активация и распознавание TB5

После выбора двух узлов и включения дополнения TB5 в консоли ZilCloud оба сервера перешли в статус «готов» примерно за 3 минуты. По SSH на первом узле выполните проверку интерфейса:

system_profiler SPThunderboltDataType

В выводе оба порта TB5 отображаются как распознанные; в состоянии «Connected» видно удалённое устройство — второй Mac mini. В сетевых настройках macOS связь по TB5 появляется как интерфейс «Thunderbolt Bridge» с адресом 169.254.x.x (APIPA), без ручной настройки.

Статический IP (рекомендуется)

Автоматический APIPA-адрес работает, но для стабильности скриптов и сборок лучше задать статику на интерфейсе Thunderbolt Bridge на обеих машинах:

# Узел A
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.1 255.255.255.0

# Узел B
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.2 255.255.255.0

После настройки команда ping -c 4 192.168.100.2 даёт средний RTT около 0,08 мс — ниже, чем у 10-гигабитного Ethernet в том же дата-центре.

Отдельный момент: публичный SSH и VNC к каждому узлу остаются независимыми — TB5 создаёт только внутренний линк между машинами. Сборочные скрипты и distcc обращаются к адресам 192.168.100.x, а администрирование по-прежнему идёт через консоль ZilCloud. Так проще разделить «внешний» доступ команды и «внутренний» трафик кластера без лишних правил файрвола на публичном интерфейсе.

Замеры пропускной способности: iperf3 и fio

Сеть поднята — первый шаг: прогнать iperf3.

TCP-тест iperf3

# Узел B — сервер
iperf3 -s

# Узел A — клиент, 8 параллельных потоков
iperf3 -c 192.168.100.2 -P 8 -t 30

Результаты:

Один UDP-поток даёт 79,1 Гбит/с — почти номинальные 80 Гбит/с. TCP при 8 потоках — 72,4 Гбит/с, для реальных задач с запасом. При одновременной передаче в обе стороны каждое направление стабильно держит 60+ Гбит/с, суммарно свыше 120 Гбит/с — в линию с теорией PCIe у TB5.

Разрыв между однопоточным TCP (38,2 Гбит/с) и UDP (79,1 Гбит/с) ожидаем: стек TCP на macOS добавляет контроль перегрузки и подтверждения. В продакшене почти всегда используют несколько параллельных соединений — distcc, NFS, RPC llama.cpp как раз так и работают. Поэтому для оценки «реальной» пропускной способности ориентируйтесь на многопоточный TCP и UDP, а не на один поток.

Межмашинная передача файлов (fio)

iperf3 меряет сеть; на практике важнее скорость на уровне файловой системы. Тестировали встроенный SMB и NFS:

NFS v4.2 при последовательном чтении достигает 6,2 ГБ/с — быстрее, чем локальное чтение с одного NVMe SSD: у M4 выше пропускная способность памяти, и через TB5 можно напрямую обращаться к буферам унифицированной памяти на удалённом узле.

Распределённая сборка Xcode

Для разработчиков iOS и macOS главный вопрос: насколько быстрее станет сборка в Xcode на кластере TB5?

Тестовый объект — реальный iOS-проект: крупное SwiftUI-приложение (~180 модулей), холодная сборка на одной машине ~14 минут. Использовали distcc в режиме pump для распределения задач между двумя узлами:

# Установка distcc
brew install distcc

# Узел B — сервер distccd
distccd --allow 192.168.100.0/24 --log-stderr --verbose

# Узел A — список хостов
export DISTCC_HOSTS="192.168.100.2/8 localhost/4"

# Сборка в режиме pump
pump xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release build

Холодная сборка сократилась с 14 минут до 8 мин 47 с — ускорение около 1,62×. До идеальных 2× не дошли: фронтенд Swift (семантический анализ) пока не распределяется и остаётся на локальном узле — это ~35% общего времени. Для чистого C/C++/Objective-C при distcc получали до 1,9×.

Инкрементальная сборка выигрывает сильнее: промежуточные артефакты между машинами передаются по TB5 быстрее ожидания I/O по сети. Цикл «изменил код — собрал» сократился с ~3 мин 46 с до 1 мин 38 с — заметная экономия в ежедневной разработке.

Инференс LLM: llama.cpp на двух машинах

Кроме сборки, кластер TB5 полезен для ИИ. Apple Neural Engine на M4 даёт 38 TOPS — для одного потока достаточно; для сервиса с несколькими параллельными запросами два узла заметно повышают пропускную способность.

Тестировали RPC-бэкенд llama.cpp (с build 0.1.x поддерживается балансировка нагрузки) на Llama 3.1 8B (квантизация Q4_K_M):

# Узел B — llama-rpc-server
./llama-rpc-server --host 192.168.100.2 --port 50052 -ngl 99

# Узел A — главный, оба хоста
./llama-cli \
  --rpc 192.168.100.2:50052 \
  -m ./Llama-3.1-8B-Q4_K_M.gguf \
  -ngl 99 --parallel 8 -p "Write a detailed technical analysis of..."

Для 8B-модели пропускная способность выросла с 48,2 до 89,7 ток/с — почти линейное масштабирование. Низкая задержка TB5 делает синхронизацию KV-Cache между узлами пренебрежимо малой — типичный Ethernet так не тянет.

Два узла открывают задачу, недоступную на одной машине с 16 ГБ: Llama 3.1 70B в Q4 требует ~40 ГБ. Через RPC слои распределяются по двум Mac mini; локальный инференс ~22 ток/с без GPU — для многих сценариев вполне рабочий вариант.

Задержка и стабильность: 72 часа под нагрузкой

Красивые бенчмарки — полдела; для продакшена важна стабильность облачного узла. Два сервера гоняли 72 часа под смешанной нагрузкой: цикл инкрементальной сборки Xcode каждые 5 минут, параллельный инференс llama.cpp и непрерывное чтение/запись крупных файлов между узлами.

За 72 часа линк TB5 ни разу не оборвался, SSH на обоих узлах был доступен постоянно. При пиковой нагрузке из-за троттлинга M4 пропускная способность иногда падала, но среднее 69,8 Гбит/с — для CI/CD и постоянного AI-сервиса приемлемо.

Троттлинг проявлялся не как «падение до нуля», а как кратковременное снижение с ~72 до ~61 Гбит/с на 30–90 секунд, после чего канал возвращался к норме. Температура корпуса при этом не превышала 42°C — пассивное охлаждение Mac mini в стойке дата-центра ведёт себя предсказуемо. Для ночных полных пересборок и дневных инкрементальных циклов такой профиль нагрузки мы считаем безопасным для постоянной эксплуатации.

Кому подойдёт кластер TB5

По итогам тестов оптимальны такие сценарии:

1. Распределённая сборка iOS / macOS (Xcode + distcc): холодная сборка ~1,6× быстрее, инкрементальная — более 2×; время пайплайна CI сокращается заметно.

2. Локальный инференс крупных моделей (llama.cpp RPC): объединение 32 ГБ унифицированной памяти двух узлов позволяет запускать квантизованные модели уровня 70B; параллельный инференс масштабируется почти линейно.

3. Массовый рендеринг видео и медиа: чтение файлов по NFS через TB5 — до 6,2 ГБ/с, выше обычной ЛВС; с протоколами кластерного рендеринга Final Cut Pro теоретически можно уполовинить время рендера.

4. Потоковая обработка данных в реальном времени: 80 Гбит/с и 0,08 мс задержки делают межмашинный обмен состоянием практичным — бэктесты, агрегация потоков, низколатентные пайплайны.

Почему не собрать такой же кластер в обычном облаке?

Логичный вопрос после цифр: разве AWS, Yandex Cloud или другие HPC-инстансы с «100 Гбит/с Ethernet» не закрывают ту же задачу?

Разница в деталях, которые редко попадают в маркетинговые таблицы.

macOS нельзя заменить Linux-ВМ. Сборка в Xcode, подпись iOS, TestFlight, инференс на Apple Neural Engine — на Linux или Windows это либо невозможно, либо запрещено лицензией. AWS Graviton — ARM, но не macOS. EC2 Mac — официальное железо Apple, но от ~$1,08/час и минимум 24 часа аренды (~$25,9/день), дороже $20,9/день у ZilCloud, плюс нет объединения TB5 между инстансами.

Виртуализация и overselling. У большинства облаков за «10 vCPU» может стоять общий пул физических ядер; «10 Гбит/с» часто burst, а не гарантия. Сосед по гипервизору в часы пика бьёт по времени сборки и задержке инференса. ZilCloud отдаёт выделенный физический Mac mini M4 без слоя виртуализации: 10 ядер CPU — это 10 реальных ядер на вашей машине.

Качество межузловой сети. Cluster Placement Group в AWS снижает задержку, но RTT между узлами обычно 0,5–2 мс; даже EFA для HPC — микросекунды, не наносекунды. 0,08 мс RTT у TB5 — прямое PCIe-соединение без маршрутизации через стек TCP/IP. Для нагрузок с тяжёлым обменом состоянием (шардирование KV-Cache при инференсе) это принципиально другой класс.

Традиционное облако сильно там, где нужны Linux, GPU NVIDIA и посекундная эластичность. Если же нужны нативный macOS + быстрый кластерный линк + аренда по дням, на рынке по сути только TB5-сервис ZilCloud. Базовый узел от $20,9/день, дополнение TB5 +$1,4/день — итого $22,3/день за физический Mac mini M4 в 80-гигабитном кластере. Двухнедельный проект: арендовали две машины, отработали, отключили — без платы за простаивающие ресурсы.