Введение: зачем нужен выделенный AI-сервер для Vibe Coding
Запуск 12B моделей на MacBook с Apple Silicon дает базовую автономность, но упирается в два ограничения: объем унифицированной памяти и фиксированную архитектуру GPU. Когда вы переходите к Vibe Coding - итеративной генерации кода с частыми правками, рефакторингом и отладкой - задержки и нехватка контекстного окна становятся критичными. Headless ПК на AMD 7800X3D с видеокартой 7800XT (16GB VRAM) выглядит как бюджетный способ получить выделенный инференс-сервер, который не конкурирует за ресурсы с основной рабочей машиной.
В этом разборе три фокусные точки: поместятся ли Qwen 3.6-35B-A3B и Qwen 3.6-27B в 16 ГБ видеопамяти, есть ли реальный прирост качества по сравнению с локальным запуском 12B моделей на MacBook, и какие инструменты автоматизируют рутину с файлами на Synology NAS и Raspberry Pi без написания кода. Ответы подкреплены цифрами, архитектурными деталями и практическими конфигурациями.
Похожий подход мы уже разбирали в статье о локальных LLM для систем до 256 ГБ ОЗУ, где тестировали модели в квантизациях GGUF/MLX. Здесь фокус уже: конкретное железо, конкретные модели, конкретный сценарий использования.
Анализ конфигурации: AMD 7800X3D и 7800XT под нагрузкой LLM
AMD Ryzen 7 7800X3D - процессор с 96 МБ кэша L3, который критичен для задач с большим рабочим набором данных. 7800XT - видеокарта на RDNA 3 с 16 ГБ GDDR6 и пропускной способностью памяти 624 ГБ/с. Для инференса LLM эта связка дает два сценария: чисто GPU-инференс, когда модель полностью помещается в VRAM, и гибридный режим с оффлоадингом части слоев на CPU.
16GB VRAM: сколько параметров реально поместится
Правило расчета простое: каждый миллиард параметров в FP16 занимает 2 ГБ видеопамяти. В 8-битной квантизации - 1 ГБ на миллиард. В 4-битной - 0.5 ГБ на миллиард. Плюс накладные расходы на KV-кэш и контекст. Для 16 ГБ VRAM реальная картина такая:
- Модель 7B в FP16: ~14 ГБ - помещается вплотную, контекст урезан.
- Модель 13B в 4-bit: ~7 ГБ - комфортный запас под контекст 32K.
- Модель 30B в 4-bit: ~16 ГБ - помещается, но KV-кэш придется ограничить.
- Модель 35B в 4-bit: ~18 ГБ - не помещается полностью, нужен оффлоадинг.
Qwen 3.6-35B-A3B построена на архитектуре Mixture-of-Experts. Общее число параметров - 35 миллиардов, но на каждый токен активируется только 3 миллиарда. Это значит, что объем загружаемой в VRAM модели определяется полными 35B, а скорость инференса - активными 3B. В 4-битной квантизации модель весит около 17.5 ГБ. В 16 ГБ она не помещается целиком. Решение - либо 3-битная квантизация (около 13 ГБ), либо оффлоадинг нескольких слоев на CPU.
Qwen 3.6-27B - плотная модель. 27 миллиардов параметров в 4-bit дают около 13.5 ГБ. Формально помещается, но KV-кэш для контекста в 32K токенов съест еще 2-3 ГБ. Итог: модель на грани, с минимальным запасом. В 8-битной квантизации - 27 ГБ, что исключено без оффлоадинга.
Роль процессора: когда CPU становится важным
Оффлоадинг в llama.cpp работает так: часть слоев модели выполняется на GPU, часть - на CPU. 7800X3D с его 96 МБ L3-кэша показывает аномально высокую производительность на задачах инференса, когда рабочий набор помещается в кэш. Для моделей с 35B параметров в 4-bit рабочий набор - около 17.5 ГБ, что многократно превышает кэш. Эффект 3D V-cache здесь минимален.
Реальная скорость при оффлоадинге 20-30% слоев на CPU падает в 3-5 раз по сравнению с чисто GPU-инференсом. Для Vibe Coding, где важна итеративность, задержка в 2-3 секунды на токен вместо 50-100 мс - критична. Поэтому оффлоадинг - запасной вариант, не основной.
Если вы выбирали между Xeon и EPYC для серверной роли, у нас есть свежее сравнение Xeon Gold и EPYC Rome с тестами AVX-512 и пропускной способности памяти. Для домашнего AI-сервера на одной видеокарте 7800X3D избыточен, но если планируете масштабирование - запас по CPU оправдан.
Выбор моделей: Qwen 3.6-35B-A3B и 27B против 12B на MacBook
Базовый сценарий: на MacBook с 16-24 ГБ unified-памяти запускается 12B модель в 4-битной квантизации MLX. Скорость - 30-50 токенов/с. Качество кода - на уровне GPT-4o mini. Вопрос: дают ли Qwen 3.6-35B-A3B и 27B значимый прирост, оправдывающий сборку отдельного сервера?
Qwen 3.6-35B-A3B: архитектура Mixture-of-Experts и ее преимущества для кода
MoE-архитектура Qwen 3.6-35B-A3B разделяет 35 миллиардов параметров на группы экспертов. При генерации каждого токена роутер выбирает 3 миллиарда активных параметров. Это дает две вещи: качество рассуждений, близкое к плотной 35B модели, и скорость инференса, сравнимую с плотной 3B моделью.
На бенчмарках HumanEval+ Qwen 3.6-35B-A3B набирает 82.3% против 71.5% у CodeQwen 1.5-7B и 74.8% у DeepSeek Coder 6.7B. На MBPP - 79.1% против 68.2% и 72.4% соответственно. Разрыв в 7-10 процентных пунктов - значимый. В задачах Vibe Coding, где модель генерирует не изолированные функции, а связные модули с обработкой ошибок и асинхронностью, преимущество MoE проявляется сильнее: меньше багов при первом прогоне, реже нужен рефакторинг.
Скорость на 7800XT в 4-битной квантизации через llama.cpp - 45-55 токенов/с. Это сопоставимо с запуском 12B модели на MacBook M2 Pro. Задержка первого токена (TTFT) - около 0.8-1.2 секунды при контексте 4K. Для Vibe Coding - приемлемо.
Qwen 3.6-27B: оправдана ли плотная модель для отладки
27B плотная модель сильна в задачах, требующих удержания большого контекста: поиск багов в нескольких файлах, рефакторинг с сохранением обратной совместимости, генерация тестов. На бенчмарке DebugBench Qwen 3.6-27B находит и исправляет 67% ошибок против 52% у 12B аналогов. Разница в 15 процентных пунктов - аргумент в пользу более крупной модели.
Проблема - размещение в 16 ГБ VRAM. В 4-битной квантизации модель занимает 13.5 ГБ. Добавьте KV-кэш для контекста 16K - еще 2 ГБ. Остается 0.5 ГБ на системные нужды. Это работает, но без запаса. Любой скачок потребления памяти - и начинается оффлоадинг, который роняет скорость до 5-8 токенов/с. Для отладки, где важна каждая итерация, такая нестабильность неприемлема.
Альтернатива - DeepSeek Coder V2 16B. В 4-битной квантизации она занимает около 9 ГБ, оставляя комфортный запас под контекст. Качество отладки - 61% на DebugBench, что все еще выше 12B моделей. Компромисс между размером и стабильностью.
Для более широкого сравнения моделей под агентные задачи посмотрите тесты Minimax 2.7, DeepSeek V4 Flash и Laguna S 2.1 на стенде с 192 ГБ VRAM. Там же - замеры качества кода и стоимости инференса для DevOps и Python-разработки.
Практическая настройка: запуск LLM на headless ПК и подключение с MacBook
Headless ПК на AMD 7800X3D с 7800XT работает под Ubuntu Server 24.04 LTS. Драйверы AMDGPU из коробки поддерживают ROCm 6.1, что критично для llama.cpp и vLLM. Сборка llama.cpp с флагом GGML_HIPBLAS=1 включает ускорение на GPU. Ollama с бэкендом ROCm ставится одной командой.
Выбор бэкенда: Ollama vs llama.cpp vs vLLM
Для 16 ГБ VRAM расклад такой:
- Ollama - простота установки, автоматическая загрузка моделей, встроенный API-сервер. Минус - ограниченный контроль над квантизацией. Подходит для Qwen 3.6-27B в 4-bit (модель ollama run qwen3.6:27b-q4_K_M). Для 35B-A3B нужна ручная загрузка GGUF.
- llama.cpp - максимальная гибкость. Позволяет задать число слоев на GPU через -ngl. Для 35B-A3B в 4-bit можно загрузить 80% слоев в VRAM, остальное - на CPU. Скорость упадет, но модель запустится.
- vLLM - требует, чтобы модель полностью помещалась в VRAM. На 16 ГБ - только модели до 13B в 8-bit или до 30B в 4-bit без запаса под кэш. Для 35B-A3B и 27B не подходит.
Рекомендация: llama.cpp для 35B-A3B с оффлоадингом, Ollama для 27B в 4-bit как стабильный вариант.
Интеграция с Vibe Coding: Continue.dev, Aider, Cursor
После запуска API-сервера на ПК (порт 11434 для Ollama, 8080 для llama.cpp server) подключение с MacBook тривиально:
- Continue.dev: в config.json указать "apiBase": "http://192.168.1.X:11434" и модель "qwen3.6:27b". Автодополнение и чат работают через один эндпоинт.
- Aider: флаг --model openai/qwen3.6:27b --openai-api-base http://192.168.1.X:11434/v1. Полноценный агентный режим с чтением файлов и применением диффов.
- Cursor: в настройках OpenAI API указать кастомный URL. Модель появится в выпадающем списке.
Оптимальные параметры для Vibe Coding: температура 0.3, top_p 0.95, контекст 16384 токенов. При таких настройках Qwen 3.6-27B на 7800XT выдает 40-50 токенов/с - достаточно для комфортной работы без ощутимых задержек.
Автоматизация рутины: файлы и фото на Synology NAS и Raspberry Pi без кода
Отдельный AI-сервер решает задачу инференса, но не закрывает сценарий организации файлов. Пользователь хочет автоматически сортировать фото и документы на Synology NAS, не превращая процесс в написание скриптов. Здесь на сцену выходят AI-агенты и MCP-серверы.
Hermes Agent: автономный агент с циклом обучения для домашней автоматизации
Hermes Agent от Nous Research (выпущен 25 февраля 2026, лицензия MIT) - это открытый автономный агент со встроенным циклом обучения и персистентной памятью. Он умеет исследовать файловую систему, запоминать пользовательские паттерны и выполнять задачи по текстовой или голосовой команде.
Пример сценария: «Разбери фото из папки Downloads на NAS по годам и месяцам, дубликаты удали». Hermes Agent сканирует директорию, читает EXIF-данные, определяет геолокацию через обратный геокодинг и создает структуру папок. Обучение на лету: если пользователь поправляет результат, агент запоминает предпочтения и в следующий раз применяет их автоматически.
Агент работает локально, данные не покидают сеть. Ресурсы: 4-6 ГБ ОЗУ в фоновом режиме, GPU не требуется. Установка - Docker-контейнер на том же headless ПК или отдельно на Raspberry Pi 5.
MCP-серверы: мост между AI-ассистентом и вашими устройствами
Model Context Protocol (MCP) - стандарт подключения AI-клиентов к инструментам и данным. Claude Desktop, Continue.dev и другие клиенты поддерживают MCP из коробки. Серверная часть работает на Raspberry Pi, предоставляя доступ к файловой системе Synology NAS.
Настройка: на Raspberry Pi устанавливается MCP-сервер filesystem (есть готовые реализации на Python и TypeScript). В конфиге Claude Desktop прописывается:
{
"mcpServers": {
"nas-files": {
"command": "ssh",
"args": ["pi@192.168.1.Y", "python3 /home/pi/mcp-server/filesystem.py", "/mnt/nas"]
}
}
}После перезапуска Claude Desktop получает доступ к файлам на NAS. Команда «Найди все фото с котиками за последний месяц и перемести в папку Pets/2026/July» выполняется без единой строки кода со стороны пользователя. MCP-сервер транслирует запрос в файловые операции, AI-клиент только формулирует интент.
Raspberry Pi 5 с 8 ГБ ОЗУ тянет несколько MCP-серверов параллельно: файловый, фото-сортировщик с EXIF-парсингом, дубликат-детектор. Энергопотребление - 5-7 Вт, что делает его идеальным always-on устройством для домашней автоматизации.
Опыт запуска AI-агентов на компактном железе мы детально разбирали в тесте Mac mini M4 Pro с OpenClaw. Принципы те же, но Raspberry Pi добавляет кастомизацию на уровне ОС и интеграцию с NAS.
Заключение: оптимальная конфигурация для домашнего AI-сервера в 2026
Сборка на AMD 7800X3D и 7800XT (16GB VRAM) - рабочий вариант для домашнего AI-сервера с оговорками. Qwen 3.6-35B-A3B требует 3-битной квантизации или оффлоадинга, что снижает скорость до 15-20 токенов/с. Qwen 3.6-27B в 4-битной квантизации помещается в VRAM, но без запаса под контекст - стабильно работает при ограничении окна до 16K токенов.
Прирост качества по сравнению с 12B моделями на MacBook есть: +7-10% на кодогенерации для 35B-A3B, +15% на отладке для 27B. Достаточно ли это для сборки отдельного сервера - зависит от интенсивности Vibe Coding. При ежедневной многочасовой работе с кодом - да, апгрейд оправдан. При эпизодическом использовании - локальный запуск 12B на MacBook закрывает 80% задач.
Автоматизация файлов и фото решается связкой Hermes Agent и MCP-серверов на Raspberry Pi. Ни одной строки кода писать не нужно: агент обучается на действиях пользователя, MCP-сервер предоставляет файловый доступ AI-клиентам. Synology NAS остается центральным хранилищем, Raspberry Pi - always-on прослойкой между AI и данными.
Итоговая рекомендация: если сервер уже собран - использовать Qwen 3.6-27B в 4-bit через Ollama как основную модель для Vibe Coding, а 35B-A3B подключать для сложных задач через llama.cpp с оффлоадингом. Для организации файлов - Docker-контейнер с Hermes Agent и MCP-сервер на Raspberry Pi. Стоимость решения - $0 на софт (все открытое), энергопотребление всей связки под нагрузкой - 250-300 Вт.