Почему мы хотим запретить виртуализацию:
Манифест архитектуры «голого металла»

В истории развития облачных вычислений за последние десять лет виртуальная машина (VM) и гипервизор были непоколебимым фундаментом любой облачной инфраструктуры. Будь то EC2 от AWS или Compute Engine от Google Cloud, почти все гиганты публичного облака полагаются на технологию виртуализации. Виртуализация позволяет поставщикам облачных услуг разрезать огромный физический сервер на десятки или даже сотни небольших экземпляров, позволяя нескольким изолированным арендаторам использовать один и тот же кремниевый кристалл, одну и ту же шину и один и тот же набор физических источников питания. Этот механизм экстремального сокращения ресурсов и «переподписки» принёс астрономическую коммерческую прибыль поставщикам облачных услуг и создал процветающую экосистему SaaS.

Однако, когда мы стоим на перепутье радикальных изменений в базовой аппаратной архитектуре — особенно когда Apple Silicon (чипы серии M) полностью переопределила стандарты вычислительной мощности на уровне настольных компьютеров и рабочих станций своей революционной ARM-архитектурой — попытка применить старую раздутую облачную архитектуру x86 к вычислительным узлам Mac обнажила жёсткий инженерный факт: виртуализация необратимо уничтожает то, что делает чипы Apple такими быстрыми.

Сегодня инженерная команда НОВАКВМ выпускает этот архитектурный манифест. Начиная с чрезвычайно глубоких основополагающих принципов, мы предоставим вам подробный анализ того, почему виртуализация является ядом, от которого необходимо отказаться в конвейере компиляции, и в сценариях высокоинтенсивного вывода локальной модели большого языка (LLM), которые преследуют экстремальную производительность; и как мы создали первую в мире чистую, без потерь и 100% нативную плоскость управления планированием Apple Silicon (Bare Metal) посредством полной реконструкции.

Чтобы понять, почему виртуализация так сильно снижает производительность, нужно начать с ключевого конструктивного преимущества Apple: унифицированной архитектуры памяти (UMA). На классических рабочих станциях x86 системная RAM и GPU VRAM физически разделены. Для перемещения больших объёмов данных — текстур, весов больших моделей — между CPU и GPU всё передаётся через медленную, узкую шину PCIe. Этот стоимостной предел переноса данных инженеры называют «стеной PCIe».

M4 и M4 Pro разрушают эту стену. Производительные ядра CPU, эффективные ядра, многоядерный GPU и Neural Engine находятся на одном кристалле и напрямую подключены к единому пулу памяти с очень высокой пропускной способностью — до 64 ГБ или 128 ГБ. При параллельных сборках Xcode или рабочем процессе MLX с моделью 70B данные остаются на месте: никаких копирований через PCIe, нулевые накладные расходы.

Однако когда мы представили гипервизор, произошла катастрофа низкого уровня.

«Уровень виртуализации принудительно вставляет чрезвычайно толстый слой программных агентов между физическими инструкциями ЦП и базовой аппаратной периферией. Любая высокоскоростная адресация памяти и каждое чтение и запись в файловой системе с высокой степенью параллелизма должны перехватываться, транслироваться и моделироваться этим слоем агентов. В мире компиляции, где миллисекунды имеют значение, это медленное самоубийство».

В нашей внутренней лаборатории сравнительного анализа мы используем реальный крупномасштабный проект корпоративного приложения для iOS с более чем 2 миллионами строк смешанного кода Swift/Objective-C. Результаты испытаний были шокирующими:

  • 100% bare-metal M4 Pro (14 ядер / 64 ГБ): инкрементальная сборка и полная индексация заняли 4 минуты 15 секунд. Системная нагрузка стабильна, очередь NVMe не перегружена.
  • VM с тем же профилем M4 Pro (14 vCPU / 64 ГБ): инкрементальное время сборки возрастает до 12 минут 40 секунд. Вентиляторы хоста на полной мощности; данные ядра показывают высокую долю sys time в обходах вложенных таблиц страниц и заблокированных путях виртуализации ввода-вывода.
BENCHMARK_EXECUTION.LOG
root@mg-lab-01:~$ xcodebuild -project Core_Enterprise.xcodeproj -benchmark
> Initiating Build Sequence...
> Allocating parallel compilation threads: 14

[VM Environment Detected - KVM/Hypervisor Hooked]
> Translation overhead: SEVERE
> I/O wait time spiking: > 4200ms
> Result: Build finished in 760.5s. (12m 40s)

root@mg-lab-02:~$ xcodebuild -project Core_Enterprise.xcodeproj -benchmark
> Initiating Build Sequence...

[Bare Metal Environment Detected - Direct Hardware Access]
> Native Metal framework hooked. Zero-copy memory mapped.
> Direct NVMe PCIe lanes confirmed.
> Result: Build finished in 255.0s. (4m 15s)

Помимо чрезвычайно высоких потерь ввода-вывода и трансляции инструкций, механизмы виртуализации и совместного использования физических машин также вызывают печально известные проблемы в индустрии облачных вычислений: «эффект шумного соседа». Что означает запуск нескольких виртуальных машин на одном хосте? Это означает, что когда другой арендатор, использующий с вами один и тот же чип M4, безумно занимает ЦП, производительность вашей виртуальной машины неизбежно будет испытывать непредсказуемые и серьезные колебания. Базовые кэши уровня 2 ЦП (L2) и системного уровня (SLC) безжалостно очищаются и вытесняются (Cache Thrashing) соседними процессами. Эта чрезвычайно нестабильная выходная вычислительная мощность наносит сокрушительный удар по конвейерам непрерывной интеграции (CI/CD) уровня предприятия, которые стремятся к максимальной стабильности.

Что ещё больше беспокоит — это периметр защиты на аппаратном уровне. Исследователи безопасности бесчисленное количество раз доказывали, что физические атаки по побочным каналам на виртуальные машины (такие как Spectre, Meltdown и их ARM-варианты) всё ещё имеют возможности для использования в теории и на практике.

В NOVAKVM мы устраняем эту проблему радикально: через полную физическую изоляцию. Вы арендуете не абстрактные «вычислительные единицы» — вы получаете настоящий Mac mini с собственной материнской платой и алюминиевым корпусом. По окончании аренды плоскость управления активирует путь максимальной безопасности на чипе Apple к Secure Enclave, уничтожает аппаратно-привязанный ключевой материал и выполняет глубокую физическую перезапись всего диска NVMe в соответствии со стандартом DoD 5220.22-M.

Поняв различные недостатки виртуализации, команда столкнулась с чрезвычайно трудным выбором: следует ли им следовать этой тенденции и использовать зрелые решения для виртуальных машин, чтобы перепродавать машины и комфортно получать высокую прибыль; или им следует выбрать тернистую дорогу, по которой никогда раньше не ходили и полную инженерных глубоких вод? Мы решительно выбрали последнее.

«Мы не можем допустить, чтобы люди-операторы стали узким местом облачных вычислений. В NOVAKVM каждая операция должна управляться кодом».

Наши сетевые и платформенные инженеры после долгого цикла проектирования и ввода в эксплуатацию использовали корпоративный фреймворк Apple MDM (Mobile Device Management) и с нуля разработали на Go высококонкурентный демон оркестрации Mac bare-metal.

Когда вы нажимаете DEPLOY INSTANCE в консоли, следующая последовательность выполняется автоматически и быстро в тихом дата-центре:

  1. Планирование и выделение ресурсов: планировщик резервирует физическую машину в выключенном состоянии из пула ресурсов.
  2. Аппаратный сброс и сетевая загрузка: умный PDU подаёт питание на устройство; коммутатор переводит порт в изолированную VLAN восстановления.
  3. Развёртывание нативного образа: сервер развёртывания через внутренний канал 10 Гбит/с передаёт чистый образ macOS; типичное время — менее 90 секунд.
  4. Передача доступа: MDM настраивает статическую публичную маршрутизацию IPv4 и записывает ваш SSH-публичный ключ в путь доверия authorized_keys системы.

Bare metal — это не только для Xcode. Главная рабочая нагрузка сегодня — локальные LLM-исследования и инференс непосредственно на устройстве.

Благодаря унифицированной памяти физический M4 Pro с 64 ГБ или более позволяет GPU использовать системную RAM как VRAM на полной ширине. С открытым проектом Apple MLX вы загружаете очень большие модели прямо на bare-metal хосте — без шардинга памяти и межустройственного обмена данными.

MLX_INFERENCE_TEST.LOG
# Загрузка незначительно выхолощенных моделей на голые металлические узлы NOVAKVM 64 ГБ
root@mlx-engine:~$ python -m mlx_lm.generate \
    --model meta-llama/Meta-Llama-3-70B-Instruct \
    --prompt "Explain quantum entanglement."

> Allocating unified memory buffer...
[OK] 48.2 GB mapped to GPU address space directly.
> Bootstrapping Neural Engine...

> Generation completed.
> Profiling: Token generation speed: 18.5 tokens/sec
> VRAM Overflow: FALSE (100% Native UMA Support)

Мы твёрдо убеждены, что путь развития современной вычислительной инфраструктуры не должен заключаться в постоянном наложении тяжёлых программных абстракций поверх железа. Правильное направление — обратное: сверху — плавная автоматизация и качественные API; снизу — прямой доступ к кремнию, чтобы ни один вычислительный ресурс не тратился впустую.

В NOVAKVM мы применяем «инфраструктуру как код» к физическому уровню. Долгосрочный план включает провайдеры в стиле Terraform: несколькими строками вы объявляете флот реальных Mac-машин в нескольких регионах — по духу как EC2, но исключительно на физическом железе.

Эпоха маржи на виртуализации не бесконечна. Налог на производительность реален, и инженерные команды не должны принимать его как данность. Сегодня NOVAKVM отвергает эту модель и переопределяет границы понятия «вычисления» для Mac в облаке.

Не позволяйте медленным и нестабильным сборкам разрушать ваш инженерный поток. Добро пожаловать в эпоху bare metal — чистого, прямого и полностью вашего.