Разработка на 1С-Битрикс
Михаил Базаров
Да, я в курсе про vibe coding. Нет, я так не работаю. Модель - это инструмент для рутины, а не замена головы. Всё перепроверяю, а она помогает не лазить каждые 30 секунд в dev.1c-bitrix.ru за сигнатурой метода или не вспоминать синтаксис очередного D7-запроса.
Кстати, для этого я сделал свой MCP-сервер для 1С-Битрикс - он даёт модели доступ к реальному API ядра: классы, методы, константы, события, ORM-поля. Всё в реальном времени, без датасетов и fine-tune-ов. Модель не гадает, а реально смотрит в код Битрикса и выдаёт точный ответ. Работает с любым AI-агентом.
Железо
MacBook Pro, M5 Pro, 48 ГБ unified memory. macOS 27.
| Параметр | Значение |
|---|---|
| Процессор | Apple M5 Pro |
| Память | 48 ГБ unified |
| Диск | 1 ТБ (плюс внешний SSD) |
| ОС | macOS 27 |
48 ГБ - хорошая конфигурация для локальных LLM. Не густо, но и не пусто. Можно таскать модели до 30-35 ГБ с квантованием, остаётся запас под систему и прочие приложения (PhpStorm, браузер с кучей вкладок, Telegram, etc.).
Почему Ornith-1.0-35B-6bit
Перебрал несколько моделей. Вот что было:
- Qwen3.6-35B-A3B-MLX-6bit (MoE, ~7.5 ГБ активных) - шустрая, умная, но MoE-архитектура даёт странные лаги на переключение экспертов. Для кода норм, но не хватало «глубины» на сложных архитектурных вопросах.
- Qwen3.6-27B-MLX-6bit (~22 ГБ) - хороша, но 27B не всегда хватало контекста для больших компонентов Битрикса.
- gemma-4-26B-A4B-it-MLX-8bit - интересная, но Google упорно не доучивает Gemma для кода. Для общих вопросов ок, для PHP/Битрикс - так себе.
- GLM-4.7-Flash-6bit - неожиданно приятная, но мало fine-tune-ов под код.
- Ornith-1.0-9B-8bit - быстрая, но маловата.
Остановился на Ornith-1.0-35B-6bit. Почему:
- 35B параметров в 6-битном квантовании - ~27-28 ГБ веса. Влезает в 48 ГБ с запасом.
- Ornith делали на базе Qwen3.5, который отлично заточен под код (CodeQwen в основе).
- Tool calling - умеет вызывать функции, что важно для работы через MCP/Kilo.
- Длинный контекст - до 32K токенов (а с burst-режимом и больше). Для больших компонентов Битрикса самое то.
- Скорость - на M5 Pro выдаёт ~55-70 токенов/с на простых запросах, на длинном контексте ~30-40 токенов/с. Комфортно.
Единственный минус - 6-битное квантование. Оно экономит память (28 ГБ вместо 36+), но на специфическом коде иногда проскакивают микрогаллюцинации. Поэтому не отключаем голову - всё перепроверяем. Рутина - ок, вайбкодинг - нет.
OMLX - что это и почему не LM Studio / Ollama
Коротко: OMLX - это сервер для MLX-моделей, который делал один чувак Jundot под свои нужды, но получилось годно. Версия 0.5.2rc2.
Чем отличается:
| LM Studio | Ollama | OMLX |
|---|---|---|
| GUI-ориентирован, жрёт память на свой интерфейс | GGUF (llama.cpp) или MLX, но без тонких настроек кеша | Чистый MLX - нативный Metal фреймворк Apple. Максимальная скорость на Mac. |
| Нет горячего кеша на SSD | Есть кеш, но без гибких настроек | Paged SSD cache + hot cache - можно тонко настроить сколько RAM под кеш, остальное на SSD |
| Нет раздельного prefill/decode | Есть continuous batching | Chunked prefill + adaptive throttling - не даёт уронить Mac в своп |
| Одна модель за раз | Мульти-модели | Multi-model serving - можно держать несколько моделей загруженными и переключаться по мере надобности |
| OpenAI API - да | OpenAI API - да | OpenAI API + admin API + MCP - можно управлять моделью удалённо |
| Memory guard - нет | Memory guard - нет | Process memory enforcer - следит за памятью и не даёт macOS уйти в жесткий своп |
Ollama - хороший зверёк, и он умеет и GGUF, и MLX. Но у него нет главного - paged SSD cache и memory enforcer. На длинных контекстах он просто забивает всю RAM и Mac уходит в своп, пока всё не ляжет. У меня такое было не раз.
LM Studio - удобна, но интерфейс жрёт память (на MacBook это критично), и нет тонких настроек кеша. Плюс я не люблю GUI для серверных процессов мне нужен headless режим.
OMLX - это консоль. Запустил, забыл. Всё управление через API или веб-интерфейс на localhost:8000. Минимум оверхэда.
Настройка OMLX под Ornith-35B: грабли и решение
Настраивал методом научного тыка. Сначала выставил всё по-максимуму и получил Prefill capacity rejected на каждом втором запросе. Пришлось разбираться.
Важная особенность OMLX - он не держит весь контекст в RAM. Когда модель обрабатывает длинный диалог, paged SSD cache автоматически скидывает старые блоки контекста на диск. В памяти остаётся только hot cache - самые свежие блоки (у меня 1 ГБ). Остальное - на SSD.
Это принципиально отличает OMLX от Ollama и LM Studio - те при длинном контексте просто забивают всю память и Mac уходит в жесткий своп, пока всё не ляжет. OMLX же сбрасывает контекст на диск ещё до того, как память закончится.
По умолчанию кеш пишется на системный диск - в ~/.omlx/cache. Если не хочется нагружать системный SSD (особенно на MacBook с распаянным диском), можно перенести на внешний. Я пробовал внешний USB-C SSD со скоростью ~500 МБ/с чтение/запись - работает стабильно, скорость генерации падает примерно до 25 токенов/с вместо 60 на RAM-кеше. Для длинных контекстов вполне терпимо.
Главное - внешний диск должен быть быстрым (USB 3.2 или Thunderbolt). Дешёвая флешка с 50 МБ/с превратит генерацию в слайд-шоу.
TurboQuant KV: сжимаем кеш перед записью на диск
В OMLX есть ещё одна полезная штука - TurboQuant KV. Это квантование KV-кеша перед тем, как сбросить его на SSD.
Что это даёт: без TurboQuant каждый блок кеша пишется на диск в fp16 (16 бит). С TurboQuant можно сжать до 8 или даже 4 бит. Меньше данных - быстрее чтение/запись, меньше износ SSD, меньше места на диске.
| Режим | Размер блока | Скорость на внешнем SSD | Качество |
|---|---|---|---|
| Выключено (fp16) | 16 бит | ~25 токенов/с | Полное |
| 8-bit | 8 бит | ~35-40 токенов/с | Почти неотличимо |
| 4-bit | 4 бита | ~45-50 токенов/с | Заметно на специфичных задачах |
Я выставил 8-bit на всех моделях - данные на диск пишутся в 2 раза компактнее, а разницы в ответах я не заметил. Для Ornith-35B это было выключено по умолчанию, пришлось включить руками.
Настраивается в ~/.omlx/model_settings.json для каждой модели отдельно:
"turboquant_kv_enabled": true, "turboquant_kv_bits": 8.0
hot_cache_only: истина где-то посередине
Вторая грабля - hot_cache_only: true. Сначала пробовал 3 ГБ горячего кеша в RAM - не хватило. Потом уменьшил до 1 ГБ, а остальное пусть само как-то. Не хватило. При длинных контекстах (25K+ токенов) вылетали ошибки:
[guard:external] context too large at progress=1024
kv_len=70656: predicted peak would exceed prefill safety capПотому что с hot_cache_only: true OMLX пытается весь контекст держать в RAM. Ты даёшь ему 1 ГБ кеша, но модель уже заняла 28 ГБ, а система - ещё 10-12 ГБ.
Решение - выключить hot_cache_only:
"hot_cache_only": falseТеперь работает так:
- 1 ГБ hot cache в RAM - для свежих блоков контекста (быстрый доступ)
- Всё, что не влезло - уходит на SSD (
/Users/mb/.omlx/cache) - Когда память поджимает - процесс memory enforcer сам чистит hot cache и сбрасывает на SSD
Да, холодные блоки читаются с SSD - это чуть медленнее. Но лучше читать с SSD, чем не читать вообще, получая ошибки.
Итоговые настройки
| Параметр | Значение | Почему |
|---|---|---|
| hot_cache_max_size | 1GB | Минимум в RAM, остальное на SSD — больше памяти под модель и систему |
| hot_cache_only | false | Сбрасывать на SSD при нехватке RAM |
| ssd_cache_dir | ~/.omlx/cache (или внешний SSD) | Можно перенести на внешний быстрый SSD, чтобы не нагружать системный |
| memory_guard_tier | balanced | Не даёт сожрать всю память, но и не душит модель |
| max_context_window | 32768 | 32K контекста - больше редко нужно, а память жрётся зря |
| chunked_prefill | true | Дообучать контекст частями, а не целиком - меньше пик памяти |
Как это выглядит в работе
Запускаю OMLX, загружаю Ornith-35B-6bit, подключаю к Kilo Code через MCP-сервер bxmcp.camouf.ru.
Типовой сценарий:
- Пишу компонент каталога - модель подсвечивает D7-запросы, подсказывает правильные события для OnBeforeProductAdd, проверяет сигнатуры вызовов.
- Нужно вспомнить как работает \Bitrix\Main\ORM\Query\Filter\ConditionTree - не лезу в документацию, просто спрашиваю модель.
- Рефакторинг старого кода - модель переписывает CIBlockElement::GetList на D7 getList с правильными селектами и фильтрами.
Всё перепроверяю. Но скорость разработки выросла - не надо отвлекаться на гуглёж и документацию каждые 5 минут.
Что в итоге
OMLX + Ornith-35B-6bit на MacBook M5 Pro 48GB - годная связка для Битрикс-разработчика. Не серебряная пуля, но инструмент, который реально ускоряет рутину.
Главное - не заигрываться. Модель ошибается. Я ошибаюсь. Но вместе мы ошибаемся реже, чем я один без модели. Особенно когда речь идёт о сигнатурах методов и правильных событиях Битрикса.