Эта статья написана в июне 2026 года. Момент знаковый. Если сегодня взглянуть на рабочее место разработчика, практически неизбежно увидишь на экране AI-ассистент программирования — будь то Cursor, Claude Code или Gemini CLI. Локально запущенные процессы больших моделей конкурируют с Xcode или Webpack за пропускную способность памяти. Рабочие процессы AI-кодинга больше не являются экспериментальными функциями — это жёсткая потребность на уровне инфраструктуры.
В этом контексте мы считаем необходимым открыто поговорить об одном из ключевых инженерных решений ZUKCLOUD: с первого дня мы полностью отвергли виртуализацию и выбрали прямую, безущербную поставку нативных физических серверов Apple Silicon пользователям. Это не коммерческий приём, а болезненный и трезвый технический выбор, подкреплённый огромным массивом внутренних данных.
01 2026 год: рабочие процессы AI-кодинга стали инфраструктурой
Три года назад «запустить локально модель с 70B параметрами» считалось роскошью для большинства инженеров. Тогда основным способом потребления вычислительной мощности были API-вызовы к удалённым серверам OpenAI или Anthropic. Пропасть между скоростью, качеством локальных моделей и облаком была практически непреодолима.
Сегодня эта пропасть стремительно сужается и даже переворачивается. Зрелость фреймворка Apple MLX, скачок в качестве следования инструкциям у открытых моделей серий Llama и Gemma, а также растущее осознание разработчиками суверенитета данных совместно движут неотвратимым трендом: всё больше инженерных команд запускают свои ключевые рабочие процессы AI-кодинга на локальном или частном физическом оборудовании — от автодополнения кода и код-ревью до генерации автотестов.
Этот тренд ставит перед нами острый инженерный вопрос: подходят ли эти новые гибридные нагрузки, одновременно выполняющие тяжёлые задачи компиляции и LLM-инференс, для работы на виртуальных машинах, урезанных Hypervisor? Наш ответ: категорически нет.
02 Скрытый налог виртуализации: каждая I/O-операция незаметно списывает средства
Проблема виртуальных машин не в том, что они «не работают», а в том, что потери крайне скрыты. Ваш код выполняется, ваша модель производит инференс, но каждое обращение к памяти, каждая операция чтения/записи диска, каждая команда вычисления на GPU проходит через многоуровневый перехват и программную эмуляцию Hypervisor. Эти потери мы называем налогом виртуализации.
«Налог виртуализации — это не единовременный крупный платёж, это НДС, взимаемый с каждой операции. При высоконагруженных вычислительных задачах он незаметно поглощает от 30% до 60% нативной вычислительной мощности.»
Мы провели сравнительный эксперимент на внутреннем тестовом стенде ZUKCLOUD, используя одинаковый M4 Pro (12-ядерный CPU / 18-ядерный GPU / 64 ГБ унифицированной памяти). Тестовым проектом стал реальный крупный iOS-проект платформы промежуточного слоя, содержащий около 1,8 млн строк кода на Swift:
| Среда | Время полной сборки | Скорость LLM-инференса | Утилизация пропускной способности памяти |
|---|---|---|---|
| Bare metal (прямой доступ к железу) | 3 мин 52 сек | 22.4 tokens/s | 89% |
| Виртуальная машина (все vCPU/vRAM выделены) | 11 мин 18 сек | 9.1 tokens/s | 38% |
| Разница в производительности | В 2.9× быстрее | В 2.5× быстрее | +51pp |
Ещё более тревожным является джиттер производительности в среде виртуальных машин. После 10 последовательных запусков одной и той же задачи сборки стандартное отклонение времени выполнения в виртуальной машине достигло ±43 секунды, тогда как в среде bare metal — всего ±6 секунд. Для команд, которые полагаются на стабильный CI/CD-конвейер для прогнозирования ритма выпусков, такая непредсказуемость губительна.
03 Физические границы UMA: почему обещание Zero-Copy работает только на bare metal
Чтобы понять на принципиальном уровне, почему виртуализация так разрушительна для Apple Silicon, нужно сначала разобраться в ключевом ценностном предложении Unified Memory Architecture (UMA).
В чипе M4 Pro высокопроизводительные и энергоэффективные ядра CPU, многоядерный GPU и Neural Engine — все физически напрямую подключены к единому пулу памяти со сверхвысокой пропускной способностью. Когда MLX выполняет инференс на GPU, а линкер Xcode одновременно работает на CPU, они обращаются к одной физической памяти — данные остаются на месте, а разные вычислительные блоки просто получают указатели на эту память. Это и есть так называемое «Zero-Copy» — оно устраняет дорогостоящие накладные расходы на перемещение данных по PCIe между CPU и GPU в традиционных архитектурах.
# Среда bare metal: CPU и GPU совместно используют единый физический пул памяти
zukcloud@node-sg-01:~$ sudo instruments -t "Metal System Trace" mlx_inference.py
> GPU Compute Encoder: allocating 48.3 GB
[OK] Direct UMA pointer mapped — zero PCIe copy
> CPU linker (Xcode): accessing same pool
[OK] Cache coherency maintained — no flush required
> Combined memory bandwidth: 276.8 GB/s
# Среда VM: Hypervisor разрывает путь Zero-Copy
vm-guest@kvm-mac-01:~$ sudo instruments -t "Metal System Trace" mlx_inference.py
[WARN] Metal GPU access intercepted by hypervisor emulation layer
> Emulated VRAM region allocated (shadow page tables)
[WARN] PCIe emulation overhead detected: +18ms per allocation
> Effective memory bandwidth: 91.2 GB/s
[DEGRADED] UMA zero-copy path unavailable in guest contextСуть проблемы в том, что гостевая ОС виртуальной машины не может напрямую воспринимать и использовать физическую топологию унифицированной памяти базового оборудования. Hypervisor вынужден поддерживать посреднические «теневые таблицы страниц» (Shadow Page Tables), транслируя виртуальное адресное пространство гостя в физические адреса хоста. Каждое выделение GPU-памяти запускает этот дорогостоящий механизм программной трансляции. Ключевое обещание UMA — Zero-Copy — в этот момент полностью разрушается.
04 Инженерный выбор ZUKCLOUD: MDM-оркестровка вместо Hypervisor
Понимая всё вышесказанное, команда ZUKCLOUD столкнулась с очень ясным, но крайне сложным в исполнении выбором: нам нужно найти способ, позволяющий пользователям получать физические серверы так же удобно, как облачные сервисы — но при этом абсолютно без введения каких-либо уровней виртуализации.
Наше решение — полностью обойти Hypervisor и вместо этого глубоко задействовать стек протоколов MDM (Mobile Device Management), разработанный Apple для управления корпоративными устройствами. Мы самостоятельно разработали высококонкурентную систему оркестровки bare metal на базе Golang.
После оформления заказа в консоли ZUKCLOUD в нашем дата-центре автоматически выполняется следующий процесс:
- Планирование узла: движок планировщика захватывает из ресурсного пула свободный физический Mac mini в выключенном состоянии и выполняет маркировку сетевой изоляции.
- Включение железа и сетевая загрузка: интеллектуальный PDU подаёт питание на целевое устройство, базовый коммутатор переключает его Ethernet-порт в выделенный VLAN восстановления, подготавливаясь к получению образа ОС.
- Нативная прошивка macOS: сервис развёртывания пушит прошедший верификацию безопасности чистый образ macOS по внутренней 10G-сети — без каких-либо сторонних Hypervisor или контейнерных слоёв.
- Выдача идентификатора и прав: протокол MDM автоматически настраивает статический публичный IPv4, записывает SSH-публичный ключ пользователя в цепочку доверия системы и завершает передачу прав.
"Мы продаём не нарезанный кусочек вычислительной мощности. Мы продаём полноценный физический Mac, который принадлежит тебе — просто он находится в далёком дата-центре Tier-3 и доставляется тебе полностью автоматически через код."
Ещё одним ключевым преимуществом этой архитектуры является абсолютность границ безопасности данных. По истечении срока аренды система MDM немедленно запускает уничтожение аппаратных ключей шифрования через Apple Secure Enclave и выполняет физическую глубокую перезапись NVMe-носителей по стандарту DoD 5220.22-M. Никаких остаточных снапшотов, никаких утечек памяти, никаких «соседей» — потому что совместного использования попросту не существует.
05 Следующее десятилетие принадлежит локальным физическим вычислениям
Мы находимся на раннем этапе трансформации вычислительной парадигмы. AI-агенты эволюционируют от «инструментов, которыми пользуются изредка» к «базовым процессам, требующим круглосуточной работы». Сценарий, когда разработчик локально одновременно запускает ассистент кодирования, генератор автотестов и локальный поиск по базе знаний, в сегодняшних корпоративных командах уже не является исключением.
В свете этого тренда мы считаем, что локальные, физические вычисления переживут свой исторический момент. Ключевым преимуществом облачных сервисов никогда не была сама «виртуализация» — им были «эластичность» и «отсутствие необходимости строить самостоятельно». ZUKCLOUD стремится объединить плотность производительности bare metal с эластичным опытом облачных сервисов — через управляемую кодом оркестровку физических серверов, создавая бескомпромиссный вычислительный фундамент.
Виртуализация была строительным материалом первых двадцати лет облачных вычислений. Но для сегодняшних рабочих нагрузок Apple Silicon она уже является тяжёлым старым кирпичом, тянущим всё здание вниз. Мы выбрали вынуть его из фундамента.
Если ваша команда страдает от долгого ожидания компиляции, нестабильных задержек инференса или необъяснимого джиттера CI — попробуйте настоящий bare metal узел лично. Цифры скажут сами за себя.