oMLX на GitHub — https://github.com/jundot/omlx

Это сервер для запуска локальных языковых моделей (LLM) и не только, который решает самую неприятную боль: он не заставляет тебя каждый раз ждать, пока модель прогрузит весь длинный диалог с нуля. Он умеет хранить «контекст» разговора — тот самый KV-cache — как в оперативке, так и сбрасывать его на SSD, когда память заканчивается. В итоге, если ты вернулся к старому диалогу или попросил продолжить длинный код, модель не начинает думать заново. Всё это обёрнуто в удобное меню в строке состояния мака и веб-интерфейс.

Если просто

Представь, что у тебя на маке крутится несколько моделей: одна для кода, другая для общения, третья умеет с картинками работать. Обычно они пожирают всю оперативку, и если ты переключаешься между ними, то каждая загружается с чистого листа, тратя твоё время и нервы.

oMLX делает из этого хаоса швейцарскую гостиницу. Он управляет памятью: часто используемые модели держит «в прихожей» (в RAM), а те, к которым редко обращаешься, аккуратно складывает «в камеру хранения» (на SSD). Более того, сам контекст ваших с моделью разговоров он тоже может сохранять на диск. Всё это работает в фоне как служба, а управлять можно через иконку вверху экрана или через браузер.

Что это решает

Главная боль — непрактичность. Запускать модели через скрипты в терминале неудобно, а «тяжёлые» серверные решения вроде vLLM на маке — это стресс. Ты хочешь просто работать: открыть свой редактор с плагином типа Claude Code, чтобы он использовал локальную модель, и не думать о том, что через полчаса диалог упрётся в потолок контекста и всё начнётся сначала.

oMLX решает это тихой, умной работой в фоне. Он предоставляет тот же API, что и OpenAI, поэтому твои привычные инструменты (OpenClaw, Cursor, Codeium) подключаются к localhost:8000 и даже не замечают подмены. А ты получаешь контроль: можешь закрепить любимую модель в памяти, выгрузить ту, что не нужна, и всё это — парой кликов.

Как попробовать

Самый простой путь для большинства — скачать .dmg файл из раздела Releases и перетащить приложение в папку «Программы». Запускаешь — и видишь welcome-гайд из трёх шагов: указать папку с моделями, запустить сервер и скачать свою первую модель. Всё.

Если ты живешь в терминале, то через Homebrew:

brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx
brew services start omlx

Сервис запустится в фоне и будет автоматически перезапускаться при падении. Модели по умолчанию ищет в ~/.omlx/models. Дальше можешь открыть http://localhost:8000/admin и увидеть панель управления.

Важное ограничение: проект требует macOS 15.0 (Sequoia) или новее и чип Apple Silicon (M1/M2/M3/M4). Если у тебя Intel или старая система — увы, не взлетит.

3 сценария с примерами

Вот где oMLX перестаёт быть просто технологией и становится реальным помощником.

1. Работа с кодом в Claude Code или Cursor.

  • Задача: Ты пишешь фичу, постоянно консультируясь с ИИ. Диалог растёт, контекст переполняется, и модель «забывает» то, что было в начале.
  • Как применить: Настраиваешь свой редактор на API http://localhost:8000/v1. В панели oMLX загружаешь модель для кода (например, Qwen2.5-Coder-7B-Instruct). В настройках модели включаешь «Claude Code Optimization».
  • Что получится: Сервер будет «обманывать» клиент, масштабируя отчёты о токенах, чтобы триггер авто-компакта срабатывал правильно. А главное — KV-cache диалога будет сохраняться между сессиями. Прервал работу, выключил мак, утром продолжил — модель «помнит» вчерашний контекст, загружая его с SSD.

2. Быстрое переключение между задачами: текст, картинки, поиск.

  • Задача: Нужно описать скриншот, потом задать вопрос по документу, потом подобрать синонимы для текста. Запускать каждый раз новую модель вручную — долго.
  • Как применить: В папку с моделями скачиваешь VLM (например, llava-llama-3.2), модель для эмбеддингов (например, bge-m3) и обычную чат-модель. В веб-панели oMLX они все появятся в списке.
  • Что получится: Ты можешь через встроенный чат-интерфейс (/admin/chat) загрузить картинку и спросить о ней. Потом, не закрывая вкладку, переключиться на другую модель для текстового диалога. Сервер сам выгрузит из RAM неактивную модель, если память на исходе, и подгрузит её обратно, когда она снова понадобится.

3. Создание персонального «ассистента» с инструментами.

  • Задача: Хочется, чтобы модель могла работать с твоими файлами, календарём или БД через MCP (Model Context Protocol).
  • Как применить: Ставишь oMLX с поддержкой MCP (pip install -e ".[mcp]" или через Homebrew-команду из README). Настраиваешь MCP-серверы (например, для файловой системы).
  • Что получится: Модели, которые поддерживают tool calling (Llama, Qwen и т.д.), смогут через единый API oMLX получать доступ к твоим инструментам. Ты сможешь попросить: «Найди в моих документах всё про квартальный отчёт» — и модель через MCP получит доступ к файлам, проанализирует и ответит.

Где можно застрять

Проект сыроват, и это видно по цифрам: 322 открытых issue при 13k звёзд. Люди жалуются на сложность первоначальной настройки, проблемы с установкой через pip из-за зависимостей вроде mlx, на то, что меню-бар иногда не отвечает. Огромный список поддерживаемых форматов tool calling выглядит впечатляюще, но на практике можно нарваться на модель, которая «почти, но не совсем» подходит, и parsing сломается.

Самая большая ловушка — модели в формате MLX. oMLX не конвертирует модели из Hugging Face автоматически. Ему нужны уже сконвертированные веса в формате .safetensors для фреймворка MLX. То есть сначала тебе нужно найти или конвертировать модель с помощью mlx-lm, а уже потом положить её в папку. Встроенный загрузчик в админке качает только MLX-модели с Hub’a, что сужает выбор.

Кому это нужно

  • Разработчикам на macOS, которые устали от лагов и перезагрузок контекста при работе с локальными моделями в IDE.
  • Любителям всё держать под контролем, которые хотят гибко управлять памятью: пинить модели, ставить TTL, менять параметры генерации на лету.
  • Тем, кто экспериментирует с мультимодальностью и RAG, но не хочет разворачивать тяжёлый стэк. Единый сервер для LLM, VLM и эмбеддингов — это мощно.
  • Пользователям, которые ценят удобство нативного меню-бара и веб-интерфейса с поддержкой русского языка.

Кому это не нужно

  • Владельцам маков на Intel или с macOS старше 15.0. Система просто не запустится.
  • Тем, кто ищет «установил и сразу GPT-4». Придётся разбираться с конвертацией/поиском моделей под MLX.
  • Если тебе нужна одна модель на разок. Для простого чата через mlx-lm проще использовать прямые скрипты без всего этого серверного оверхеда.
  • Хардкорным исследователям, которым нужен полный контроль над каждым циклом GPU и кастомными оптимизациями. Это всё же продукт для практического использования, а не исследовательский фреймворк.

Вердикт Веры

oMLX — это, пожалуй, самая зрелая попытка сделать из локального ИИ на маке не хобби, а рабочий инструмент. Идея с двухуровневым кешем (RAM + SSD) — гениальная в своей практичности. Она решает реальную проблему, а не просто добавляет ещё одну анимацию в интерфейс.

Но меня, честно, настораживает этот разрыв между громкой заявкой «удобство и контроль» и текущей сыростью. Триста с лишним открытых issue — это не баги, это очередь в поликлинику. Проект явно страдает от собственной популярности: люди хотят волшебства, а получают инструмент, который требует технической подкованности и терпения.

Тем не менее, если ты сидишь на свежем маке с Apple Silicon и готов потратить час на настройку, oMLX может стать тем самым мостом между «поигрался с локальной моделькой» и «работаю с ней каждый день». Он не идеален, но он указывает направление, в котором всё должно развиваться: тихо, умно и прямо под рукой. А вы готовы мириться с сыростью ради таких перспектив?

Материалы

Похожие материалы