Разработчик с почти 20-летним опытом два года переносил работу с AI на собственное железо. К ноябрю 2026 он выполняет около 95% задач локально через Lamplight, самодельный харнесс из двух компьютеров: SFF-ПК Jade на RTX 5090 FE и MacBook Pro Slate на M5 Max. Харнесс целиком не опубликован, но часть специфических модулей автор расцепляет для публикации и описал устройство системы в посте на r/LocalLLaMA.
Логика объединения простая. Задачи ставятся в общую очередь, а исполнителя выбирает система: одна машина быстрее на плотной генерации, вторая даёт большой объём объединённой памяти под тяжёлые контексты. До этого, примерно два месяца назад, автор работал на двух компьютерах по отдельности.
Практическая ценность кейса не в 95% как таковых. Полезнее три вещи: конфигурация подбирается по агентным тестам под свои процессы, а не по одному публичному бенчмарку; качество агентных задач упирается в настройки харнесса не меньше, чем в модель; код после локальной модели всё равно проходит ручное ревью. Ниже архитектура, движки, метрики и ограничения.
Что такое Lamplight и почему две машины объединили в один харнесс
Lamplight это персональная обвязка для агентной разработки, а не продукт. Внутри Pi-Bolt, прекомпилированная сборка Pi, поверх неё набор кастомных расширений и инструментов, которые автор настраивал сам, вместе с локальным харнессом и Claude. Задача конструкции: держать как можно больше работы на своём железе и обращаться к внешним моделям только осознанно.
Две машины в этой схеме не дублируют друг друга.
| Машина | Железо | Платформа | Что даёт |
|---|---|---|---|
| Jade | RTX 5090 FE, Ryzen 7 9800X3D, 64 ГБ RAM, корпус Fractal Terra | Fedora | Быстрый инференс на дискретной видеокарте, но фиксированный объём VRAM |
| Slate | MacBook Pro, M5 Max, 128 ГБ объединённой памяти | macOS | Много общей памяти под модель и длинный контекст, плюс мобильность |
Jade и Slate: две машины с разными сильными сторонами
Jade собрана в прошлом году в корпусе Fractal Terra: RTX 5090 Founders Edition, Ryzen 7 9800X3D, 64 ГБ оперативной памяти, Fedora. Компактная сборка даёт CUDA-путь с быстрой видеопамятью, но у неё жёсткий лимит по объёму VRAM и по охлаждению.
Slate это MacBook Pro на M5 Max со 128 ГБ объединённой памяти и macOS. Разница принципиальная: на Mac модель может занять десятки гигабайт общей памяти, тогда как на дискретной карте приходится укладываться в фиксированный объём VRAM. Платой идёт пиковая вычислительная мощность и пропускная способность памяти, которые у настольной карты выше.
Как именно автор распределяет задачи между машинами по типам нагрузки, в доступном фрагменте поста не раскрыто. Известно, что обе машины запускают одну и ту же модель, а координирует их харнесс. Тем, кто рассматривает Apple Silicon как основную машину под локальные LLM, полезен отдельный разбор Mac Studio M5 Ultra с 256 ГБ памяти: объём памяти решает задачу «модель помещается», но не гарантирует скорость.
Pi-Bolt как основа и координация через git worktrees
git worktrees это механизм Git, который создаёт несколько рабочих каталогов из одного репозитория. У каждого каталога своя ветка и свой набор файлов, а объектная база общая. Для агентных задач это удобно: каждому параллельному заданию выдаётся отдельный checkout, агенты не перезаписывают файлы друг друга, а слияние идёт привычными средствами Git.
Вторая часть координации, событийная система задач. Задание не привязано к конкретной машине жёстко: оно появляется как событие, харнесс решает, кто его возьмёт, и передаёт исполнителю. Так одна очередь обслуживает и Jade, и Slate.
Собрать копию Lamplight по этому описанию нельзя: сам харнесс не опубликован, а кастомные расширения заточены под процессы автора. Воспроизводить стоит принципы: изоляция задач по worktrees, очередь вместо ручного переключения, одна модель на обеих машинах.
Модели и движки: почему Qwen 3.8 Flash-Next и два разных рантайма
Обе машины запускают Qwen 3.8 Flash-Next с контекстом до 262K токенов. Модель крупная и построена на MoE-архитектуре: на каждом токене работает только часть экспертов, поэтому она быстрее, чем можно ожидать от полного размера. Запустить такую модель дома реально, если распределять нагрузку между VRAM, RAM и SSD, о чём разбирается отдельный материал про Qwen 3.8 Flash-Next и Strata.
Рантаймы на двух платформах разные, и это ожидаемо: CUDA и Metal требуют разных движков, а кванты под них готовят по-разному. В разборе кейса фигурируют Basalt IQ3_S на Fedora и mlx-serve с квантом около 4.7 бита на MLX в macOS. В доступном фрагменте первоисточника эти названия не подтверждены, поэтому воспринимать их стоит как заявленную конфигурацию автора, а не как проверенный факт. Общее правило выбора остаётся: движок должен поддерживать нужный квант и давать приемлемую скорость на вашей длине контекста.
Какие движки и модели автор пробовал и отбросил
Перебор был широким. На Jade тестировались Strata, NInfer, Maya и llama.cpp, на Mac MTPLX и Kapitsa. Итоговые движки выбраны не потому, что остальные плохие, а по совокупности скорости, стабильности и удобства на конкретном железе.
С моделями та же история. Qwen 3.8 27B и GLM-5.3-Flash показали хорошие результаты, но итоговая конфигурация оказалась стабильнее и точнее на задачах автора. Критерий субъективный: «стабильнее» здесь значит меньше сорванных шагов и меньше повторов, а не абсолютное лидерство в таблице.
Выбор делался по двум наборам тестов: публичные бенчмарки плюс собственные агентные прогоны, имитирующие нормальные рабочие процессы. Такой подход дороже по времени, чем чтение лидерборда, и лучше предсказывает поведение в ежедневной работе. Альтернативный взгляд на оценку моделей, с агентными тестами вместо LLM-as-judge, разобран в материале про открытый бенчмарк локальных LLM locallm.top.
Отдельная ветка оптимизации, специализированные сборки движка под одну модель, тоже существует: кастомная сборка llama.cpp под одну модель обещает кратный прирост, но подтверждённых замеров там пока нет.
Квантование и агентные характеристики: на что смотреть
Квант влияет на память и на скорость, а в агентных задачах ещё и на способность держать формат вызова инструментов. Unsloth Dynamic 3.1 позиционируется как метод, который уменьшает размер модели, сохраняя агентные характеристики. В тесте на YouTube это проверялось на реальной задаче со скрытой проверкой pass/fail через Pi Coding Agent, от 1 до 4 бит. Результаты этого теста мы не воспроизводили, поэтому обещание производителя квантования остаётся обещанием до вашей собственной проверки.
Практический критерий простой. Гоняйте квант на своей задаче с машинной проверкой: тесты, typecheck, парсинг ответа инструмента. Если после сжатия агент начинает ломать JSON вызовов или терять шаги плана, экономия памяти не окупается.
Замеры: скорость декодирования, TTFT и результаты бенчмарков
В посте автор приводит замеры скорости декодирования, времени до первого токена и результаты HumanEval, LiveCodeBench v6 и MMLU-Pro для двух конфигураций. В доступном фрагменте таблица обрывается на заголовках Jade/Fedora и Slate/macOS, конкретных значений в нём нет. Сравнить машины по цифрам мы не можем и выдумывать их не станем: ниже расшифровка метрик, чтобы вы читали такие таблицы осмысленно, когда доберётесь до полного поста.
| Метрика | Что показывает | Как читать |
|---|---|---|
| Decode, ток/с | Скорость генерации после первого токена | Определяет комфорт в цикле «правка-запуск». Для агента важна так же, как для чата: длинные ответы читаются минутами. |
| TTFT | Время до первого токена | Зависит от длины промпта и скорости prefill. На контексте в сотни тысяч токенов именно TTFT, а не decode, съедает основную паузу. |
| HumanEval | Генерация функций по описанию, метрика pass@1 | Проверяет базовую способность писать корректный код в изоляции. Реальный проект сложнее: контекст, зависимости, стиль. |
| LiveCodeBench v6 | Задачи с соревнований, собранные после выхода модели | Меньше риск контаминации обучающих данных. Полезнее как индикатор обобщения. |
| MMLU-Pro | Общие знания, расширенный набор вариантов ответа | Показывает эрудицию и устойчивость рассуждения, но слабо связан с качеством агентной разработки. |
Главная оговорка: ни один из этих бенчмарков не отвечает на вопрос «справится ли модель с моим репозиторием». Ответ даёт прогон на своих задачах, желательно с проверкой результата кодом, а не глазами.
Тюнинг железа: андервольт RTX 5090 и ограничение частоты Ryzen 7 9800X3D
В описании кейса указано, что андервольт RTX 5090 и ограничение частоты Ryzen 7 9800X3D снизили температуры и потребление ценой нескольких процентов скорости. Конкретных значений напряжения, частот, ватт и температур в доступном фрагменте поста нет, поэтому подставлять цифры наугад бессмысленно.
Логика тюнинга при этом понятна. Агентная сессия длится часами, карта почти постоянно занята, а корпус Fractal Terra не рассчитан отводить сотни ватт так же легко, как башня. Андервольт по кривой напряжение-частота снижает напряжение на заданной частоте, и карта перестаёт упираться в температурный лимит. Ограничение частоты процессора работает похоже: меньше пиковых герц, заметно меньше тепла в тесном объёме.
Плата измеряется процентами производительности, выигрыш даёт тишину, стабильный буст и меньший троттлинг на длинной дистанции. Результат не переносится один в один: у каждого экземпляра свой запас по напряжению, а в SFF всё дополнительно упирается в высоту радиатора и продув корпуса. Начинать стоит с малых шагов и проверять стабильность под реальной нагрузкой, а не в коротком стресс-тесте.
Настройка харнесса: thinking, компакция контекста и агентные задачи
По описанию кейса настройка уровня thinking и компакции контекста заметно улучшила качество агентных задач. Конкретные значения автор не приводит, зато понятна механика обеих ручек.
Уровень thinking задаёт, сколько модель рассуждает перед действием. На планировании и разборе ошибок дополнительный бюджет окупается: меньше неверных шагов, меньше откатов. На рутине он тратит время и контекст, а агент делает те же правки вдвое дольше. Разумная схема: высокий уровень на планировании и диагностике, низкий на механических изменениях.
Компакция контекста решает другую проблему. Контекст в 262K выглядит огромным, но агентная сессия съедает его быстро: вывод тестов, диффы, повторные попытки. Компакция сжимает историю, оставляя решения, пути к файлам и результаты проверок. Ошибка здесь дороже, чем кажется: если из сжатой истории выпало условие задачи, агент уверенно пойдёт не туда. Полезный приём из смежного опыта, ночного марафона по кодингу на локальной 27B: держать состояние задачи в файле, а не только в контексте, и резать работу на фазы с машинной проверкой.
Параллельные задачи усложняют картину. Каждый job на своей worktree расходует собственный контекст, поэтому десять одновременных агентов дают десятикратный расход, а не десятикратную скорость: узкое место переезжает на память и на верификацию. Событийная очередь помогает тем, что задача берётся тогда, когда есть свободный исполнитель.
UI с 3D-окружением: зачем харнессу собственный интерфейс
Интерфейс Lamplight автор нарисовал и смоделировал сам. 3D-сцена повторяет его реальное рабочее место, а лампа в ней мигает, когда харнессу нужно участие человека. Это единственная функция с прямой пользой: сигнал о том, что агент упёрся в решение, которое нельзя принять автоматически.
При нескольких параллельных задачах такой индикатор экономит внимание. Без него человек либо проверяет всё подряд, либо пропускает момент, когда процесс встал. Эстетика сцены на производительность не влияет никак, и приписывать ей ускорение не стоит.
Что это значит на практике: 95% локально, но с ручной проверкой
Автор программирует почти 20 лет и формулирует вывод осторожно: при правильном подходе (SOLID, паттерны проектирования), инструментах и тюнинге локальный AI пишет код, который его устраивает. Ревью он не отменял. Изменение в другом: ошибок становится меньше, и по ощущениям он проверяет работу старшего разработчика, а не джуниора. Lamplight он использует ежедневно для работы, хобби и исследований, около 95% задач выполняется локально.
Границы честно видны. Харнесс не опубликован, конфигурация привязана к задачам одного человека, а 95% остаются самоотчётом без независимой проверки. Ручное ревью обязательно: локальная модель ошибается реже, но ошибается.
Стоит ли повторять такой сетап: выводы для читателя
Связка из RTX 5090-класса и Mac с большим объёмом объединённой памяти имеет смысл в одном случае: вы много работаете с агентными задачами, готовы тюнинговать железо и харнесс и понимаете, зачем вам две платформы. Тогда распределение нагрузки, разные движки и общая очередь дают то, чего одна машина не даст.
Для большинства путь короче. Начните с одной машины и одной модели, настройте её на своей задаче, измерьте decode и TTFT на реальной длине контекста, введите машинную проверку результата. После этого станет видно, упираетесь вы в память, в скорость или в качество модели, и только тогда имеет смысл добавлять вторую машину.
Стоковые настройки и железа, и харнесса далеки от оптимальных. Это главный вывод кейса и самая дорогая его часть: андервольт, лимиты частот, уровень thinking, компакция контекста и перебор движков заняли месяцы. Повторять их слепо не нужно, но проверить каждую ручку на своих задачах стоит.