LM Studio или Ollama: что выбрать для локальных LLM

LM Studio - настольное приложение с графическим интерфейсом для запуска языковых моделей на своём компьютере. Оно ищет и скачивает модели с Hugging Face, запускает их на llama.cpp (GGUF) и MLX (Apple Silicon), поднимает OpenAI- и Anthropic-совместимый сервер на порту 1234 и управляется из CLI lms. Само приложение закрытое, но бесплатное, в том числе для работы, а CLI и SDK открыты под MIT. Ollama - open-source программа под MIT, у которой главный интерфейс CLI, а сервер слушает порт 11434.

На 19 октября 2026 года актуальны LM Studio 0.4.26 от 13 октября и Ollama v0.40.7 от 18 октября. На уровне «скачать модель и поднять локальный API» программы делают одно и то же, поэтому выбор решают другие вещи: лицензия, нужен ли GUI, как программа работает на сервере без экрана и как к ней подключаются агенты для кода. Довод «MLX на Mac есть только в LM Studio» устарел: с версии 0.40.0 Ollama сама запускает поддерживаемые модели на MLX.

Статья о том, чем LM Studio и Ollama отличаются по лицензии, движкам, API, headless-режиму, MCP и подключению Claude Code, Codex и OpenCode и что выбрать под конкретную задачу. Установка, Modelfile и настройки Ollama подробно разобраны в гайде по Ollama, здесь они не повторяются. Скорость и память сравниваются замером одной модели в четырёх комбинациях «приложение × формат» на Mac с Apple M4 Max.

Коротко: что выбрать

• Нужен GUI с каталогом моделей, чат и ручной выбор квантов - LM Studio.
• Нужен фоновый сервер для скриптов, Docker, Linux без экрана или открытая лицензия - Ollama.
• Агент для кода работает с обоими: оба отдают Anthropic /v1/messages и OpenAI /v1/responses. Результат сильнее зависит от модели и контекста.
• На Mac MLX есть у обоих, так что спор «GGUF против MLX» не равен выбору приложения.

Что такое LM Studio и Ollama

LM Studio

LM Studio работает на macOS 14 и новее (только Apple Silicon, Intel-Маки не поддерживаются), на Windows x64 и ARM и на Linux x64 и ARM64, где распространяется как AppImage (системные требования). Документация рекомендует от 16 ГБ памяти. В приложении есть поиск и загрузка моделей с Hugging Face, чат, настройки загрузки модели (контекст, выгрузка слоёв на GPU) и вкладка разработчика с локальным сервером.

Вместе с приложением ставится CLI lms, без GUI работает демон llmster. Версия 0.4.26 от 13 октября 2026 года обновила llama.cpp, добавила CUDA 13 на Windows ARM и эндпоинты /v1/decisions и /v1/systemone (changelog).

Bionic с того же сайта lmstudio.ai - отдельное приложение-агент для открытых моделей со своим changelog, в этом сравнении он не участвует.

Ollama

Ollama - репозиторий ollama/ollama под лицензией MIT. Основной интерфейс - CLI (ollama pull, ollama run, ollama ps), сервер по умолчанию слушает 127.0.0.1:11434. Для macOS и Windows есть приложение с окном чата и настройками. Модели берутся из библиотеки ollama.com или импортируются из GGUF и safetensors через Modelfile.

Релизы выходят часто: v0.40.0 вышла 25 сентября 2026 года, а 18 октября - уже v0.40.7. Номер версии в любом сравнении поэтому устаревает быстро, ориентир - дата.

Таблица сравнения LM Studio и Ollama

Лицензия LM Studio и Ollama для работы

Ollama распространяется под MIT. Код можно читать, менять, встраивать и распространять с сохранением уведомления о лицензии.

LM Studio устроена иначе. Само приложение проприетарное: исходников в организации lmstudio-ai на GitHub нет, репозиторий lmstudio-bug-tracker служит только трекером ошибок. С 8 июля 2025 года приложение бесплатно и дома, и на работе: форму и отдельную коммерческую лицензию больше не требуют.

Условия задают Terms в редакции от 23 августа 2026 года. Лицензия неисключительная и непередаваемая, на использование «for Your personal and / or internal business purposes». Запрещено:

• модифицировать приложение и создавать производные работы;
• декомпилировать и реверс-инжинирить его, кроме случаев, которые прямо разрешает закон;
• использовать его как service bureau, application service provider или SaaS для третьих лиц.

Запустить LM Studio на рабочем ноутбуке и подключить к ней свой агент условия разрешают. Перепродавать доступ к ней как к сервису условия запрещают. Для команд есть платный Enterprise: SSO, ограничения доступных моделей и MCP-серверов, приватная совместная работа.

Открытые части LM Studio лежат в организации lmstudio-ai под MIT:

Лицензию headless-демона llmster ни на странице headless-режима, ни в Terms найти не удалось. Называть его открытым оснований нет. Модели в обоих приложениях лицензируются отдельно, по соглашению автора каждой модели. Это описание условий, а не юридическая консультация: для компании решающий текст - актуальная редакция Terms.

Движки и MLX на Mac

Оба приложения запускают GGUF через llama.cpp и MLX-модели на Apple Silicon. Разница в том, кто выбирает движок.

В LM Studio формат выбирают при загрузке: в каталоге у модели есть GGUF- и MLX-варианты, и движок определяется скачанным файлом. MLX-поддержку LM Studio реализует собственным открытым mlx-engine.

Ollama выбирает сама. Превью MLX она анонсировала 30 марта 2026 года, с требованием больше 32 ГБ общей памяти и поддержкой формата NVFP4. С v0.40.0 модели архитектур, которые поддерживает MLX-рантайм, на Apple Silicon запускаются на MLX по умолчанию.

На Ollama 0.40.14 с M4 Max тег qwen3.8:27b скачивает MLX-сборку: веса в safetensors, квантизация nvfp4, runner mlx. GGUF Q4_K_M той же модели ставится только явным тегом:

ollama pull qwen3.8:27b            # на Apple Silicon: MLX, nvfp4
ollama pull qwen3.8:27b-q4_K_M     # GGUF для llama.cpp
ollama ps                          # колонка RUNNER: какой движок работает

ollama ps для MLX-сборки с контекстом 32768 показал 100% GPU и RUNNER mlx, а память в нём выросла с 18 ГБ сразу после загрузки до 25 ГБ после прогонов с длинным промптом. Рамка «GGUF в Ollama против MLX в LM Studio» некорректна: в каждом приложении есть оба формата.

Под словом «4 бита» скрываются разные схемы:

Параметры MLX-схем описаны в документации mlx.core.quantize. У модели lmstudio-community/Qwen3.8-27B-MLX-4bit в config.json записано bits: 4, group_size: 64, mode: affine. Сравнение «MLX в Ollama против MLX в LM Studio» затрагивает сразу и приложение, и квантизацию.

Параллельные запросы тоже зависят от движка. В LM Studio они работают только на llama.cpp, по умолчанию до четырёх одновременно, а для MLX документация пишет «coming soon» (parallel requests). В Ollama число параллельных запросов на модель задаёт OLLAMA_NUM_PARALLEL, по умолчанию 1.

В changelog LM Studio с версии 0.4.25 упоминается ещё один движок для Mac, Splash (чипы M3 и новее, macOS 26.4+). Описания движка в документации найти не удалось, в сравнении он не участвует.

Установка и первый запуск

LM Studio

Установщик скачивают с lmstudio.ai, на macOS приложение есть и в Homebrew как cask lm-studio. CLI lms лежит внутри приложения и не работает, пока приложение ни разу не запускалось: команда отвечает «No running LM Studio or Bionic app, and no valid installation was found». После первого запуска появляется каталог ~/.lmstudio, и CLI начинает работать. lms bootstrap добавляет его в PATH, дописывая строку в профиль оболочки.

brew install --cask lm-studio
open -a "LM Studio"                # первый запуск обязателен
"/Applications/LM Studio.app/Contents/Resources/app/.webpack/lms" bootstrap   # lms в PATH
lms get https://huggingface.co/lmstudio-community/Qwen3.8-27B-MLX-4bit --mlx -y
lms ls                             # ключи скачанных моделей
lms load <model-key> --context-length 32768
lms ps

Модели по умолчанию хранятся в ~/.lmstudio/models/ в структуре «издатель/модель/файл». lms get в проверке завершился раньше, чем докачалась модель, а приложение продолжало загружать .part-файлы. Перед lms load стоит убедиться через lms ls или вкладку загрузок, что файл скачан целиком.

Ollama

Установка Ollama на все платформы разобрана в гайде по Ollama. Для сравнения достаточно двух команд:

ollama run qwen3.8:27b --verbose   # скачает модель и покажет скорость
ollama ps                          # память, контекст, процессор, runner

Одна и та же модель в обоих приложениях

Общего хранилища моделей у приложений нет. Ollama хранит веса в ~/.ollama/models/blobs под именами по хешу, LM Studio - в своём каталоге. GGUF-файл можно подключить в LM Studio без второй копии: у lms import есть флаги --hard-link и --symbolic-link (документация).

ollama show --modelfile qwen3.8:27b-q4_K_M | grep '^FROM'   # путь к blob-файлу
lms import --hard-link <путь-к-blob>

Флаг обязателен. Без него lms import по умолчанию перемещает файл, и модель пропадёт из Ollama. Жёсткая ссылка работает только в пределах одного тома. Для MLX-сборок такой способ не проверялся: Ollama хранит их в своём хранилище блобов, а LM Studio ждёт папку модели в формате Hugging Face. MLX-модель для LM Studio в замере скачивалась отдельно.

Сервер и API

OpenAI-совместимый API

Оба сервера принимают запросы в формате OpenAI, поэтому клиент переключается сменой base_url:

curl http://localhost:1234/v1/models     # LM Studio
curl http://localhost:11434/v1/models    # Ollama

from openai import OpenAI

client = OpenAI(base_url="http://localhost:1234/v1", api_key="lm-studio")
# для Ollama: base_url="http://localhost:11434/v1", api_key="ollama"
resp = client.chat.completions.create(
    model="<model-key>",
    messages=[{"role": "user", "content": "Привет"}],
)
print(resp.choices[0].message.content)

При выключенной аутентификации ключ сервер не проверяет, но SDK требует его указать. Список эндпоинтов совпадает почти полностью: /v1/models, /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/responses (LM Studio, Ollama). Ollama поддерживает /v1/responses только без состояния, без previous_response_id.

Anthropic-совместимый /v1/messages

Оба сервера принимают формат Anthropic Messages API на POST /v1/messages, через него работает Claude Code. В Ollama эндпоинт появился в v0.14.0. Для LM Studio точную версию появления найти не удалось, но в changelog эндпоинт упоминается начиная с 0.4.22 от 28 августа 2026 года. При включённой аутентификации LM Studio принимает токен и в x-api-key, и в Authorization: Bearer (документация).

Нативные API

У LM Studio это POST /api/v1/chat: диалог с сохранением состояния через previous_response_id, вызов MCP-серверов и управление моделями. У Ollama - /api/* с generate, chat, pull, create, ps и метриками скорости в ответе. Нативные API несовместимы между собой, переносимый код пишут под /v1.

Обе программы умеют загружать модель по первому запросу. В LM Studio это JIT-загрузка (настройка Just in Time Model Loading): модель без ручного lms load поднимается при запросе и по умолчанию выгружается через 60 минут простоя (TTL и auto-evict). TTL меняют флагом lms load --ttl или полем ttl в запросе. Ollama по умолчанию выгружает модель через 5 минут, это меняют OLLAMA_KEEP_ALIVE или keep_alive в запросе.

Аутентификация и безопасность

Ollama слушает только 127.0.0.1, а локальный API работает без ключа. OLLAMA_HOST=0.0.0.0:11434 открывает сервер в сеть, и тогда любой, кто достучится до порта, сможет запускать, скачивать и удалять модели. Снаружи Ollama закрывают reverse proxy с аутентификацией, VPN или SSH-туннелем.

У LM Studio аутентификация тоже выключена по умолчанию (authentication). Её включают переключателем Require Authentication в Server Settings, токены создают в Manage Tokens с выбором разрешений. Доступ с других устройств включает отдельный переключатель Serve on Local Network (server settings). В LM Studio встроенная авторизация есть, в Ollama её делают внешним прокси.

Headless-режим и CI

На сервере без экрана LM Studio работает через llmster. Документация описывает Linux:

curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get <модель>
lms load <model-key>
lms server start --port 1234
curl http://localhost:1234/v1/models

Для автозапуска документация предлагает systemd-юнит типа oneshot, который вызывает lms daemon up, загружает модель и стартует сервер. Скрипт установки при подготовке статьи не запускался, лицензия llmster не указана.

У Ollama на Linux скрипт install.sh сам создаёт пользователя ollama и systemd-сервис, есть официальный Docker-образ ollama/ollama для CPU, NVIDIA и AMD. В Docker Desktop на macOS GPU-ускорения нет, там модели идут на CPU. Для CI и контейнеров у Ollama путь короче и полностью открытый.

Агенты для кода: Claude Code, Codex, OpenCode

Claude Code

# LM Studio (по docs/integrations/claude-code)
lms server start --port 1234
export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_AUTH_TOKEN=lmstudio
export CLAUDE_CODE_ATTRIBUTION_HEADER=0
claude --model <model-key>

# Ollama
ollama launch claude --model qwen3.8:27b
# или вручную
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3.8:27b

Если в LM Studio включена аутентификация, в ANTHROPIC_AUTH_TOKEN передают созданный токен. Рекомендации по контексту расходятся: LM Studio советует модель и настройки «with more than ~25k context length», Ollama - не меньше 64k. Системный промпт агента с описаниями инструментов легко занимает десятки тысяч токенов, поэтому ориентироваться разумнее на 64k, если модель и память это позволяют.

Anthropic не поддерживает работу Claude Code с моделями, отличными от Claude, через любой шлюз. Локальная модель вместо Opus 5.5 или Sonnet 5.5 работает на ваш риск. Ограничения такой схемы разобраны в статье Claude Code в России.

Codex

Codex работает с LM Studio через OpenAI-совместимый POST /v1/responses, это прямо указано в документации LM Studio. В CLI Codex для локальных серверов есть флаг --oss и выбор провайдера --local-provider со значениями lmstudio и ollama:

codex --oss --local-provider lmstudio -m <model-key>
codex --oss --local-provider ollama -m qwen3.8:27b
ollama launch codex                 # Ollama настроит профиль сама

Для Codex документация Ollama тоже требует контекст от 64k. Чем Codex отличается от Claude Code как агент, разобрано в сравнении Claude Code и Codex.

OpenCode

В документации OpenCode у LM Studio есть встроенное обнаружение локальных моделей на http://127.0.0.1:1234/v1. Ollama подключается командой ollama launch opencode или через конфиг провайдера. Конфиг, проверка tool calls и результаты локальных моделей собраны в гайде по OpenCode.

Выбор сервера влияет на агента меньше, чем выбор модели. В тестах из гайдов по Ollama и OpenCode 7-8B модели либо печатали вызовы инструментов текстом, либо правили лишнее. Хорошая модель для кода в чате не обязательно стабильно работает в агентном цикле, и это не зависит от того, LM Studio её запускает или Ollama. Место локального стека среди платных инструментов показано в обзоре нейросетей для кода.

MCP и интеграции

LM Studio с версии 0.3.17 работает как MCP-хост: модель в чате приложения вызывает инструменты MCP-серверов (документация). Серверы описывают в mcp.json в нотации Cursor (вкладка Program, Install, Edit mcp.json), поддерживаются локальные и удалённые серверы. Документация предупреждает, что MCP-сервер может выполнять произвольный код, читать локальные файлы и ходить в сеть. Серверы из недоверенных источников ставить нельзя. Что такое MCP и как устроены серверы, объясняет статья MCP-серверы простыми словами.

У Ollama своего MCP-хоста нет. MCP-серверы подключают в клиенте, который ходит к Ollama: в Claude Code, Codex, OpenCode. В документации Ollama есть пример MCP-сервера на Python для её веб-поиска, его подключают в клиент, сама Ollama инструменты не вызывает.

Для своего кода у обоих есть SDK. У LM Studio это @lmstudio/sdk для TypeScript и lmstudio для Python, у Ollama - библиотеки ollama для Python и JavaScript. Если локальная модель нужна рядом с облачными, оба сервера встают провайдерами за шлюзом LiteLLM, а облачную альтернативу с одним счётом на сотни моделей разбирает гайд по OpenRouter. Железо, форматы и квантование для локального запуска в целом собраны в гайде по локальным LLM.

Замер на M4 Max 36 ГБ

Проверено: 7 ноября 2026 года, Mac с Apple M4 Max (14-ядерный CPU, 32-ядерный GPU) и 36 ГБ общей памяти, macOS 27.2, питание от сети. Ollama 0.40.14 из Homebrew и LM Studio 0.4.28 из Homebrew cask с движками llama.cpp 2.71.0 и MLX 1.14.0: версии новее, чем на дату статьи. Перед замером тяжёлые приложения закрыты, открытыми остались Claude и системные процессы, около 17 ГБ памяти без модели. Swap к началу был занят на 7 ГБ из 8 после предыдущих прогонов.

Модель одна - Qwen3.8 27B, в четырёх ячейках:

Условия во всех ячейках: контекст 32768, temperature 0, до 400 токенов ответа. Промптов два: короткий (около 55 токенов) и длинный (около 8,9 тысяч токенов; в LM Studio он на ~40 токенов длиннее из-за шаблона чата). На промпт по 5 прогонов, в таблице медиана, в скобках минимум и максимум. У каждого прогона уникальный префикс, чтобы сервер не взял промпт из кэша. Между ячейками все модели выгружались, а прирост Pageouts + Swapouts в vm_stat за время замера показывал, ушла ли система в swap.

Метрики снимались по-разному. В Ollama запросы шли в POST /api/generate со стримом и think: false, скорость генерации бралась из полей сервера eval_count и eval_duration. В LM Studio запросы шли в OpenAI-совместимый POST /v1/chat/completions со стримом, модель загружалась командой lms load <key> -c 32768 --no-speculative-draft-mtp, а скорость генерации считалась по времени между первым и последним токеном стрима. TTFT - время до первого токена.

В Ollama такого флага нет: MLX-раннер включает MTP (multi-token prediction) для qwen3.8:27b сам. Это видно в логе сервера по строкам speculative decode stats, а раннер llama.cpp в том же логе пишет no implementations specified for speculative decoding. Из четырёх основных ячеек MTP работал только в A.

Выключить размышления Qwen3.8 в LM Studio через API не удалось. Не подействовали reasoning_effort: "none", reasoning: {effort: "none"}, chat_template_kwargs: {enable_thinking: false} и /no_think в системном промпте: на запрос «Say ok» модель всё равно генерировала 22 токена рассуждения. В Ollama размышления выключены. Токены рассуждения тоже генерируются и входят в decode, поэтому скорость генерации между приложениями сравнима, а число выходных токенов и TTFT нет. Скорость обработки промпта Ollama отдаёт сама, у LM Studio её можно оценить только через TTFT. Из-за этого prefill в таблицу не вынесен, и выводы ниже опираются на decode.

Результаты

Строка C + MTP - досъёмка ячейки C с включённым MTP: 5 прогонов короткого промпта и один прогон длинного, после чего досъёмку остановили. TTFT в таблице дан для ориентира: размышления в LM Studio не выключились, и между приложениями он несравним.

Память приложения показывают по-своему, поэтому рядом с их цифрами стоит footprint процесса:

Как читать таблицы:

• B и D - самое чистое сравнение приложений: один и тот же GGUF-файл, один движок llama.cpp. Разница между ними - это сборки llama.cpp внутри приложений и их настройки по умолчанию.
• A и C отличаются сразу тремя вещами: движком внутри приложения, квантизацией и MTP. nvfp4 и MLX 4bit (affine) - разные 4-битные схемы с разным размером группы и разным представлением чисел, а MTP в A включён по умолчанию, в C выключен. Строка C + MTP убирает только третье различие.
• A против B и C против D показывают, что даёт MLX против GGUF внутри одного приложения.
• У GGUF-ячеек процесс меньше файла: llama.cpp отображает веса из файла в память (mmap), и эти страницы в footprint процесса не входят. MLX держит веса внутри процесса.

Что показал замер

На одном и том же GGUF-файле приложения почти равны: 10,6 и 12,4 tok/s на коротком промпте, 10,1 и 10,2 на длинном. На скорость GGUF выбор приложения почти не влияет, и решают лицензия, GUI и интеграции.

MLX быстрее GGUF в обоих приложениях: в Ollama в 3,1 раза (32,4 против 10,6 tok/s, у MLX-ячейки с MTP), в LM Studio в 1,6 раза (20,3 против 12,4) на коротком промпте. На Mac сначала выбирают формат, приложение вторично.

Между MLX-ячейками разрыв заметный: 32,4 tok/s у nvfp4 в Ollama против 20,3 у affine 4bit в LM Studio. При этом 32,4 выше оценки сверху по пропускной способности памяти: около 23 tok/s для файла 18 ГБ на 410 ГБ/с у этой конфигурации M4 Max. Оценка считает один токен на одно чтение весов, а MTP за одно чтение принимает больше. По логу сервера Ollama за прогон ячейки A медиана acceptance 0,67, а avg_accepted 1,29: столько токенов в среднем принимается за итерацию сверх основного.

Весь разрыв MTP не объясняет. Досъёмка ячейки C с --speculative-draft-mtp дала 21,1 tok/s (20,0-21,6) на коротком промпте против 20,3 без него, на этой машине MTP в LM Studio почти ничего не добавил. Длинный промпт с MTP прогнали один раз (13,4 tok/s) и досъёмку остановили. Разница A и C складывается из схемы nvfp4, движка MLX-раннера Ollama и MTP, и разделить их вклад в этом замере нельзя. Вывода «Ollama быстрее» отсюда нет, а сравнение MLX в Ollama и LM Studio без оговорки про MTP некорректно: в Ollama он включён по умолчанию для поддерживаемых моделей, в LM Studio его задают при загрузке.

На 36 ГБ обе MLX-ячейки на длинном промпте упираются в память: разброс 14,2-19,7 tok/s у A и 7,9-14,4 у C. У A за замер в swap ушло около 11 ГБ, а ollama ps вырос с 18 до 25 ГБ. GGUF-ячейки на длинном промпте держатся ровно, 10,1 и 10,2 tok/s при узком разбросе. Для 27B на 36 ГБ запас по памяти важнее формата.

Жёсткая ссылка работает: после lms import --hard-link у GGUF-файла две ссылки, и лишних 16,8 ГБ на диске нет. Параллельность в LM Studio 0.4.28 по умолчанию 4 (колонка PARALLEL в lms ps), параллельные запросы в замер не входили.

Замер привязан к версиям, одной модели и одной машине на 36 ГБ с открытыми приложениями. На Mac с 64 ГБ и больше, на другой архитектуре модели или на Windows с NVIDIA расклад может быть другим, это не проверялось. Не проверялись также параллельные запросы, скорость при контексте 64K и работа агентов с этими моделями.

Когда выбирать LM Studio, а когда Ollama

LM Studio, если:

• вы только начинаете и хотите выбирать модели в интерфейсе, видеть размер файла и настройки загрузки;
• нужно сравнивать кванты и форматы одной модели: GGUF разной разрядности и MLX лежат в одном каталоге;
• нужен чат с MCP-инструментами прямо в приложении;
• в компании нужны SSO и централизованный контроль моделей и MCP: это LM Studio Enterprise.

Ollama, если:

• нужен фоновый сервер для своего кода, скриптов и агентов, который запускается вместе с системой;
• сервер работает на Linux без экрана, в Docker или в CI;
• политика компании требует открытую лицензию для всего стека;
• нужна быстрая настройка агентов одной командой ollama launch;
• иногда нужна большая облачная модель через тот же API: у Ollama есть облачные модели, а локальный режим от них не зависит.

Оба вместе - рабочий вариант. LM Studio удобна, чтобы найти модель и подобрать квант, Ollama - чтобы держать её фоновым сервером. Порты разные (1234 и 11434), GGUF подключается из Ollama в LM Studio жёсткой ссылкой. Ограничение одно - память: загруженные модели обоих серверов занимают её одновременно.

Ограничения и подводные камни

lms import по умолчанию перемещает файл

Без --copy, --hard-link или --symbolic-link команда переносит файл в каталог LM Studio. Для blob-файла Ollama это значит, что модель в Ollama сломается. Флаги взаимоисключающие, указать можно только один.

CLI LM Studio зависит от приложения

lms не работает до первого запуска приложения, а lms get может завершиться раньше загрузки. В скриптах после lms get проверяют lms ls, а на сервере ставят llmster вместо GUI-приложения.

Две копии моделей и бэкапы Ollama

GGUF можно разделить жёсткой ссылкой, а MLX-модели приходится скачивать в каждое приложение отдельно. В замере GGUF Qwen3.8 27B, подключённый в LM Studio через --hard-link, не занял лишних 16,8 ГБ, а MLX 4bit-сборка той же модели заняла в LM Studio ещё 16,1 ГБ рядом с nvfp4-сборкой Ollama на ~18 ГБ. В Ollama с v0.40.2 старые модели при первом запуске обновляются в фоне, а оригинал остаётся бэкапом, так что место на диске временно занято вдвое. Бэкапы удаляет скрипт из релизных заметок.

Память делят оба сервера

Модель, загруженная в LM Studio через JIT, держится в памяти до 60 минут простоя, в Ollama - 5 минут. На 36 ГБ MLX-сборка 27B, которая в Ollama дорастает до 25 ГБ, не оставляет места для такой же модели во втором сервере. Перед переключением выгружают модель (lms unload, ollama stop <модель>) или сокращают TTL.

MLX в Ollama не для всех моделей

MLX включается только для архитектур, которые поддерживает MLX-рантайм Ollama, остальные идут через llama.cpp. Превью требовало больше 32 ГБ общей памяти. Какой движок реально работает, показывает ollama ps, по названию тега этого не видно.

Параллельность на MLX в LM Studio

Continuous batching в LM Studio работает только на llama.cpp. Для MLX документация пишет «coming soon», так что параллельной обработки запросов нескольких клиентов к MLX-модели пока нет.

Размышления Qwen3.8 в LM Studio через API не выключаются

В LM Studio 0.4.28 ни reasoning_effort: "none", ни chat_template_kwargs: {enable_thinking: false}, ни /no_think в системном промпте не отключили рассуждение у Qwen3.8 27B: модель тратит токены на размышления даже на короткий запрос. Это удлиняет ответ и время до первого видимого токена, а при сравнении с Ollama, где think: false работает, сопоставима только скорость генерации.

Контекст по умолчанию разный

Ollama подбирает контекст по объёму видеопамяти (на 36 ГБ это 32768), LM Studio берёт значение из настроек загрузки модели. Для честного сравнения и для агентов контекст задают явно в обоих.

Версии меняются каждую неделю

С 25 сентября по 18 октября 2026 года у Ollama вышло восемь версий 0.40.x, у LM Studio с начала сентября - три. Поведение по умолчанию между ними меняется, поэтому любые цифры, включая замер в этой статье, привязаны к версии и дате.

С чего начать

1. Определите главную задачу: GUI и подбор моделей - LM Studio, фоновый сервер и открытая лицензия - Ollama.
2. Поставьте выбранное приложение. Для LM Studio запустите приложение один раз, затем lms bootstrap. Для Ollama проверьте curl http://localhost:11434/api/version.
3. Выберите формат: на Apple Silicon попробуйте MLX и GGUF одной модели и сравните скорость на своих задачах.
4. Проверьте, где работает модель: ollama ps (RUNNER, PROCESSOR, CONTEXT) или lms ps.
5. Подключите код через /v1 с OpenAI SDK, агент - через /v1/messages или /v1/responses, с контекстом от 64k.
6. Перед открытием сервера в сеть включите Require Authentication в LM Studio или поставьте прокси с аутентификацией перед Ollama.