Локальный LLM на сервере клиента: Ollama vs llama.cpp, выигрыш в 3 раза

В ITFresh частенько приходят с необычными задачами, и этот случай — не исключение. Обратилась к нам торговая компания из самого центра Москвы (ЦАО), у них 28 рабочих мест. Ребята занимаются промышленной химией. В штате: юрист, пара менеджеров-аналитиков и финдир, который, прямо скажем, очень любил кидать все важные документы — в том числе договоры с контрагентами — в ChatGPT. Пока не пришёл новый аудитор. Он мигом прикрыл эту лавочку, сославшись на 152-ФЗ: слишком уж много ценных персональных данных улетало к американцам. И что же? Мы, ITFresh, за каких-то пять рабочих дней смогли собрать им свой собственный «ChatGPT» — прямо на их офисном сервере! А пока переключались с Ollama на llama.cpp, умудрились разогнать его производительность аж в 3,1 раза. Этот кейс — наш подробный отчёт: расскажем, как мы это провернули и, конечно, на какие грабли наступили.

С чем пришёл клиент и почему запретили облачный AI

Представьте: наш финдир, человек прогрессивный, два года беззаботно пользовался ChatGPT Plus. Каждый месяц по $20 улетали в карман OpenAI, а взамен — куча удобств. Он, не задумываясь, сливал туда буквально всё: договоры, черновики писем для контрагентов, даже какие-то тестовые скрипты для 1С. Ну, очень удобно же! И вот однажды — классика жанра — наш юрист случайно заглянул ему через плечо. Что он увидел? Полный набор персональных данных: ФИО, паспортные данные учредителей контрагента, банковские реквизиты. Все это, конечно, тут же полетело в американское облако. Результат? Юрист, бледный от ужаса, схватил распечатку 152-ФЗ и прямиком отправился к гендиректору. Мы ведь, по закону, не имеем права передавать такие данные в иностранные системы. И уж тем более без личного согласия каждого, чьи данные там прописаны! А такого согласия, естественно, никто не давал.

Что было дальше? Конечно, последовал короткий, но жутко серьёзный разговор. Решение оказалось однозначным, как приговор: «AI нам нужен, но исключительно свой, родной!» Аудитор, ответственный за 152-ФЗ, не стал ходить вокруг да около, выразившись кристально ясно: «Ребята, если вы сможете вот прямо здесь, в этом здании, показать мне сервер, который будет обрабатывать все ваши запросы, и при этом докажете, что наружу из него точно ни единого бита не улетает – вот тогда я без вопросов подпишу своё заключение». Никаких полумер, никаких компромиссов. И именно после этого разговора финдир поднял трубку и набрал мой номер.

К счастью, я к этому моменту уже не новичок в локальных LLM. До этого случая я успел развернуть подобные системы трижды: одна для юрфирмы с 35 рабочими местами, вторая — для медцентра неподалёку от Курского вокзала, и третья — для проектного бюро прямо на Чистых Прудах. Так что план действий у меня был готов, можно сказать, ещё до того, как мы успели пожать руки. На первой же встрече я чётко обрисовал нашу стратегию: неделя на всё про всё, установка мощной GPU-станции прямо в их серверной, доступ к веб-интерфейсу исключительно через внутренний порт, и главное — ни единого байта outbound-трафика в интернет с этой машины. Всё прозрачно и безопасно.

Подбор железа: почему RTX 4090, а не A100 и не «облако»

Знаете, любая статья в интернете о локальных LLM почти всегда начинается с одной и той же фразы: «Приготовьтесь, вам понадобится видеокарта H100, а это восемь миллионов рублей». Что я могу сказать? Это откровенная неправда, причём рассчитанная, скорее, на корпорации-гиганты. Для малого и среднего бизнеса такой подход просто не сработает. Наша философия другая: мы ищем идеальный баланс между по-настоящему толковой моделью, разумными затратами на железо и, конечно же, быстрой окупаемостью — в идеале, за год.

Что я взял у этого клиента

Так что же в итоге мы выбрали? В качестве платформы взяли Supermicro SYS-740GP-TNRT — это такой 4U корпус. Внутри, как говорится, «мозги» системы: один процессор Xeon Gold 6354 с 18 ядрами, работающий на частоте 3,0 GHz. Оперативной памяти мы не пожалели — 128 GB DDR4 ECC. Для быстрой работы системы и, конечно, хранения весов всех моделей установили NVMe-накопитель Samsung PM9A3 на 1.92 TB. Но главная «рабочая лошадка» всей этой станции — это, безусловно, видеокарта Nvidia GeForce RTX 4090 с 24 GB памяти, да ещё и Founders Edition. И, разумеется, чтобы всё это прокормить, поставили мощный блок питания на 1600 W, да ещё и титанового класса. А вот вам приятный бонус: этот корпус специально сделан так, что при необходимости мы сможем без проблем добавить вторую такую же карту. Это наш задел на будущее, мало ли, вдруг понадобится масштабироваться!

Теперь о деньгах. Сама платформа со всей памятью и дисками обошлась в 612 000 ₽. К этому добавили 268 000 ₽ за мощную видеокарту (GPU) и ещё 18 000 ₽ за надёжный ИБП APC Smart-UPS 1500. Не забываем про НДС, само собой. В сумме, под ключ, со всей нашей настройкой, вышло примерно 950 тысяч рублей. И самое интересное — окупаемость. Если посчитать только чистую экономию на подписках ChatGPT, Claude или GigaChat для команды из 14 человек, то вся эта инвестиция окупится примерно за 11 месяцев. Неплохо, правда?

Почему не A100 и не RTX 6000 Ada

Хочу быть с вами абсолютно честным: на вторичном рынке сейчас можно найти A100 80 GB где-то за 1,4-1,8 миллиона, а RTX 6000 Ada 48 GB — за 750-900 тысяч рублей. Да, такие монстры действительно необходимы, если, например, вы собираетесь запихнуть в одну карту Llama 70B или Qwen 72B без всякого квантования, или если вам нужно обрабатывать сотни параллельных запросов одновременно. Но давайте посмотрим на нашего клиента. Как я уже не раз говорил, даже в самый пик, в обеденный перерыв, с LLM одновременно работают от силы четыре человека. Так что нашей RTX 4090 хватает с головой — даже с двукратным запасом по памяти! Мы же не какой-нибудь огромный банк, в конце концов, с тысячами сотрудников.

Почему не облако GPU вроде Yandex DataSphere

Аргумент, поверьте, был предельно простой: главная цель всего проекта — забрать наши данные из чужих, по сути, рук. Ведь что такое Yandex DataSphere? Юридически это тот же самый «облачный API», просто находится он на территории РФ. Но наш аудитор, человек въедливый, тут же задал бы логичный вопрос: «А кто вам гарантирует, что Yandex не сделает какую-нибудь резервную копию вашего запроса для отладки своей модели?» И тут крыть нечем. А вот свой, физический сервер, стоящий прямо в офисе — он закрывает этот вопрос раз и навсегда. Один аргумент, и все сомнения прочь.

Первая итерация: Ollama, 19 токенов в секунду и разочарование

Первые три дня я сделал «как все»: Ubuntu Server 24.04, драйвер Nvidia 555, Docker, контейнер с Ollama, веб-интерфейс Open WebUI. Десять команд, два часа работы, всё взлетает. Финдир заходит в браузер по адресу http://llm.local:8080, видит знакомый чат и улыбается.

Но, увы, моя победная улыбка длилась ровно три минуты. Мы попросили систему: «Вычитай этот договор и предложи правки в раздел 5». И тут началось... Ollama начала выдавать ответ с черепашьей скоростью — всего 19 токенов в секунду. Можете себе представить? Чтобы обработать договор, который еле-еле умещался на двух экранах, ей потребовалась целая 1 минута 47 секунд! Конечно же, финдир тут же, с видом победителя, выдал коронную фразу, которую я, признаться, слышу от каждого клиента в подобной ситуации: «Ну вот, а ChatGPT мне отвечал всего за 8 секунд!» Что тут возразишь, когда факты налицо...

Что внутри Ollama притормаживает

Итак, в чём же загвоздка? Ollama, по сути, это такая очень удобная «обёртка» над llama.cpp, написанная на языке Go. В ней есть и менеджер моделей, и полноценный сетевой API. Казалось бы, всё отлично! Но вот беда: по умолчанию, она запускает движок с уж слишком консервативными параметрами. И это серьёзно замедляет работу.

• Не использует флаг --flash-attn — а на RTX 4090 это +30% к скорости.
• Знаете, какая особенность у Ollama? По умолчанию её контекст — 2048 токенов. Это не проблема. Но если вы вдруг подкидываете ей длиннющий промпт, вся эта история с контекстом обнуляется, и системе приходится пересчитывать всё с нуля. Согласитесь, не очень удобно?
• Layers offloaded to GPU считается автоматически и часто ставит ngl=999, но при этом резервирует слишком мало под KV-cache.
• Параллелизм запросов через OLLAMA_NUM_PARALLEL=1 по умолчанию — то есть второй пользователь ждёт, пока закончится первый.

Я, конечно, не мог сидеть сложа руки. Сразу же взялся за дело и «докрутил» Ollama по максимуму, как только мог! Настроил все переменные окружения, создал свой кастомный Modelfile, увеличил размер контекста аж до 8192. В результате, да, скорость подросла: я добился уже 26 токенов в секунду. Стало, безусловно, получше. Но, как говорится, всё равно «не торт».

Переход на llama.cpp напрямую: 58 токенов в секунду

На третий день вечером я снёс Ollama и поставил голый llama.cpp. Скомпилировал из исходников с CUDA-поддержкой, чтобы не тащить чужие сборки и точно знать, какие флаги активны.

# Ставим зависимости
apt-get install -y build-essential cmake git pkg-config \
    libcurl4-openssl-dev nvidia-cuda-toolkit

# Клонируем и собираем с CUDA
git clone https://github.com/ggerganov/llama.cpp.git /opt/llama.cpp
cd /opt/llama.cpp
cmake -B build -DGGML_CUDA=ON -DLLAMA_CURL=ON
cmake --build build --config Release -j 18

# Проверяем, что собралось
./build/bin/llama-cli --version
./build/bin/llama-server --help | head -40

Дальше — модель. Я взял Qwen 2.5 32B Instruct в кванте Q4_K_M от unsloth, на тот момент это был лучший русскоязычный open-source вариант для технических и юридических задач. Размер файла — 19,8 GB, отлично укладывается в 24 GB видеопамяти RTX 4090 вместе с KV-cache.

# Скачиваем веса прямо из HuggingFace через llama-cli
mkdir -p /var/lib/llm/models
cd /var/lib/llm/models

# Q4_K_M от unsloth — 19,8 GB
wget https://huggingface.co/unsloth/Qwen2.5-32B-Instruct-GGUF/resolve/main/Qwen2.5-32B-Instruct-Q4_K_M.gguf

# Контрольная сумма обязательно
sha256sum Qwen2.5-32B-Instruct-Q4_K_M.gguf

И вот тут начинается самое интересное: правильный запуск llama-server с грамотно подобранными параметрами. Именно эта формула позволила мне получить заветные 58 токенов в секунду. Смотрите:

/opt/llama.cpp/build/bin/llama-server \
  --model /var/lib/llm/models/Qwen2.5-32B-Instruct-Q4_K_M.gguf \
  --host 0.0.0.0 \
  --port 8081 \
  --ctx-size 16384 \
  --n-gpu-layers 65 \
  --batch-size 2048 \
  --ubatch-size 512 \
  --flash-attn \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 12 \
  --threads-batch 18 \
  --parallel 4 \
  --cont-batching \
  --metrics \
  --log-format json \
  --api-key 7c4a0f...очень_длинный_ключ

Что делает каждый флаг

--n-gpu-layers 65 — выгрузить все 65 слоёв Qwen 2.5 32B в видеопамять, включая embedding. Если поставить 64 — один слой останется на CPU и скорость упадёт втрое.

--flash-attn — Flash Attention v2, экономит память KV-cache и ускоряет генерацию на 25-35% на Ada Lovelace.

--cache-type-k q8_0 --cache-type-v q8_0 — квантование KV-cache в 8 бит. Сама модель в Q4, кэш в Q8 — оптимум по памяти и точности. С таким кэшем у меня в 24 GB лезет контекст до 24K токенов с запасом.

--parallel 4 и --cont-batching — четыре одновременных запроса батчатся непрерывно, без ожидания. Это критично для офиса с несколькими пользователями.

После старта проверяю замер:

# Тест скорости
curl -X POST http://127.0.0.1:8081/v1/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer 7c4a0f..." \
  -d '{
    "model": "qwen-32b",
    "prompt": "Перепиши пункт договора простым языком: ...",
    "max_tokens": 800,
    "temperature": 0.3
  }' | jq '.usage, .timings'

Ответ: predicted_per_second: 58.4. Тот самый трёхкратный выигрыш по сравнению с Ollama на той же модели. Прогон договора, который раньше ждал 1:47, теперь идёт 34 секунды. Финдир прислал в Telegram три «огонь»-эмодзи и попросил «то же самое для бухгалтера».

Обвязка вокруг llama.cpp: веб-интерфейс, авторизация, журнал

Чистый llama-server даёт OpenAI-совместимый HTTP API, но людям нужен интерфейс. Я поставил перед ним Open WebUI в Docker, чтобы юристу и финдиру было привычно, как ChatGPT.

# Docker Compose файл /etc/llm/docker-compose.yml
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: webui
    network_mode: host
    environment:
      - OPENAI_API_BASE_URL=http://127.0.0.1:8081/v1
      - OPENAI_API_KEY=7c4a0f...
      - WEBUI_AUTH=true
      - DEFAULT_MODELS=qwen-32b
      - DEFAULT_USER_ROLE=user
      - ENABLE_SIGNUP=false
      - ENABLE_OPENAI_API=true
      - ENABLE_OLLAMA_API=false
      - WEBUI_NAME=ITfresh AI
      - WEBUI_URL=https://llm.client-corp.local
    volumes:
      - /var/lib/open-webui:/app/backend/data
    restart: always

Авторизация через Active Directory

Кстати, у клиента уже был настроен Active Directory на Windows Server 2022 — это мы им сами и развернули, примерно год назад. Поэтому дальше я просто «прикрутил» LDAP-аутентификацию к Open WebUI.

# Дополнительные переменные в docker-compose
- ENABLE_LDAP=true
- LDAP_SERVER_LABEL=corp
- LDAP_SERVER_HOST=dc01.corp.client.local
- LDAP_SERVER_PORT=389
- LDAP_USE_TLS=false
- LDAP_APP_DN=CN=svc-llm,OU=ServiceAccounts,DC=corp,DC=client,DC=local
- LDAP_APP_PASSWORD=...
- LDAP_SEARCH_BASE=OU=Sotrudniki,DC=corp,DC=client,DC=local
- LDAP_SEARCH_FILTER=(&(sAMAccountName={username})(memberOf=CN=GG_AI_Users,OU=Groups,DC=corp,DC=client,DC=local))

Доступ к системе получают строго ограниченные пользователи — только те, кто является участником группы GG_AI_Users. Эту группу наполняет сам администратор клиента, мы туда, конечно, не вмешиваемся. В чём плюс? Финдир в любой момент может отозвать доступ к корпоративной LLM у уволенного сотрудника. Причём сделает он это той же самой командой, которой обычно отключает доступ к 1С. Удобно, не правда ли?

Аудит и журналирование

Представьте: аудитор спрашивает — а есть ли у вас доказательства, что никакие данные не уходят наружу? Что ж, мы решили этот вопрос радикально. На уровне сети я просто закрыл весь outbound на сервере с помощью iptables-правила. Теперь он может общаться только с локальной сетью и официальным зеркалом пакетов Ubuntu; всё остальное сразу ловит DROP.

# /etc/iptables/rules.v4 — выписка
-A OUTPUT -d 192.168.0.0/16 -j ACCEPT
-A OUTPUT -d 10.0.0.0/8 -j ACCEPT
-A OUTPUT -d 91.189.91.0/24 -p tcp --dport 80 -j ACCEPT
-A OUTPUT -d 91.189.91.0/24 -p tcp --dport 443 -j ACCEPT
-A OUTPUT -p udp --dport 53 -d 192.168.20.10 -j ACCEPT
-A OUTPUT -p udp --dport 53 -d 192.168.20.11 -j ACCEPT
-A OUTPUT -p udp --dport 123 -j ACCEPT
-A OUTPUT -j REJECT --reject-with icmp-host-prohibited

На уровне приложения llama-server пишет логи в JSON-формате в /var/log/llm/, плюс Open WebUI хранит все диалоги в SQLite. Я настроил Filebeat → Wazuh-аггрегатор у клиента, чтобы каждый запрос с user-id попадал в централизованный журнал. Если когда-то всплывёт вопрос «а что такого попадало в LLM», можно будет показать.

Тонкости квантования: почему Q4_K_M, а не Q5 или Q8

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

Что я тестировал

Чтобы не быть голословными, мы взяли и погоняли прямо на том же сервере три разных кванта модели Qwen 2.5 32B. Для чистоты эксперимента использовали 30 абсолютно одинаковых запросов. Результаты, скажем прямо, весьма показательны.

• Q8_0 — 34,8 GB. Не лезет в 24 GB, часть на CPU, скорость 11 ток/сек. Качество ответа эталонное, но сервер ползает. Не подходит.
• Q5_K_M — 23,3 GB. Впритык влезает в видеопамять, но кэшу остаётся 0,7 GB и контекст обрезается до 4K. Скорость 41 ток/сек. Подходит, если нужны короткие диалоги.
• Q4_K_M — 19,8 GB. Остаётся 4,2 GB под KV-cache, контекст 16K, скорость 58 ток/сек. На моих тестах разница в качестве с Q8 — 1-2% по бенчмаркам и не заметна на реальных задачах перевода/правки/SQL.
• Q3_K_S — 14,4 GB. Скорость 71 ток/сек, но качество заметно проседает на длинных рассуждениях. Не пускаю в прод.

Вот что показывает моя практика: если у вас небольшой офис, человек на 30–50, и одна единственная RTX 4090, то Q4_K_M — это чистой воды золотое сечение. Идеальный баланс, поверьте. А что, если у вас две такие карты? Или, например, есть RTX 6000 Ada? Тогда смело забирайте Q5 или Q6. Но если бюджет подвёл и хватило только на 4070 Ti Super 16 GB, то, увы, придётся выбирать: либо довольствоваться Q3, либо, как вариант, взять модель поменьше. Скажем, Qwen 2.5 14B Q5_K_M туда точно влезет.

Imatrix-квантованные веса от unsloth

Я принципиально использую кванты от unsloth, а не «обычные» от bartowski или TheBloke. У unsloth кванты сделаны через imatrix-калибровку на лучшем датасете, и в результате Q4_K_M от unsloth даёт качество как Q5 от других сборщиков. Реальная разница на юридических текстах — два-три балла из ста по моему слепому A/B-тесту с финдиром.

Сравнение скорости: цифры со стенда

Мы не любим пустых слов, поэтому вот вам честные замеры. Делали их прямо на сервере у клиента: там стояла RTX 4090, работала модель Qwen 2.5 32B, и мы использовали один и тот же промпт-договор. Входные данные были на 4500 токенов, а выходные — на 800.

Ollama 0.5.4, Q4_K_M, дефолт                  19 ток/сек,  ответ 58 сек
Ollama 0.5.4, Q4_K_M, тюнинг env-vars         26 ток/сек,  ответ 41 сек
llama.cpp build 4127, Q4_K_M, голый           48 ток/сек,  ответ 22 сек
llama.cpp build 4127, Q4_K_M, +flash-attn     58 ток/сек,  ответ 18 сек
llama.cpp build 4127, Q4_K_M, +cache q8_0     58 ток/сек,  ответ 18 сек, контекст 16K
vLLM 0.6.4, AWQ, GPTQ                         52 ток/сек,  ответ 20 сек, +1 час настройки

Я пробовал и vLLM, но, честно говоря, он оказался капризнее. Во-первых, ему нужны AWQ/GPTQ-квантованные веса, а их у unsloth, к сожалению, нет. Во-вторых, в нашей конфигурации он оказался примерно на 10% медленнее. Конечно, для большой серверной фермы с четырьмя GPU vLLM объективно выигрывает за счёт PagedAttention. Но для одной-единственной видеокарты llama.cpp оказался просто проще и быстрее. Зачем усложнять?

Что мы получили в итоге

Через пять рабочих дней у клиента стоит сервер в их же серверной (этаж минус один, в районе Курского вокзала), который доступен по адресу https://llm.client-corp.local через корпоративный SSL-сертификат от внутреннего CA. Заходят 14 сотрудников с компьютеров в домене, авторизуются доменными учётками, никакой регистрации.

Две недели пролетели быстро, и аудитор снова в гостях — на этот раз уже с полноценной проверкой. Мы показали ему всё: от серверной комнаты до подробнейшей диаграммы потоков данных, выписки из iptables-правил и даже журнал Wazuh за все эти 14 дней. Что в итоге? Он без единого колебания поставил подпись под заключением, где чёрным по белому было сказано: «обработка персональных данных не вышла за периметр». Победа, не иначе!

А теперь поговорим о том, что волнует многих — о деньгах. Раньше наш клиент каждый месяц выкладывал за ChatGPT Plus, GigaChat и разные API-доступы внушительную сумму — около 92 000 рублей. Сейчас же переменные расходы у них… ноль рублей! Только электричество на сервер — это примерно 1 800 ₽ в месяц. Как вам такой расклад? Окупаемость железа получается всего за 11 месяцев. А дальше? Дальше каждый месяц — чистая экономия. И это, согласитесь, очень здорово!

По производительности: 14 пользователей пользуются комфортно, в пиковые часы (10:00-12:00 и 14:00-17:00) одновременно сидят 4-5 человек, очередь не возникает за счёт --parallel 4 --cont-batching. Если станет тесно — у меня в плане докупить вторую RTX 4090 за 270 тысяч и перейти на tensor parallelism через vLLM.

Грабли, на которые я наступил

Свежий драйвер Nvidia 565 ронял CUDA

Первый день я поставил самую свежую версию драйвера на тот момент — 565. Через десять минут работы llama-server вылетал с ошибкой CUDA error: out of memory при заведомо свободной памяти. Откатился на 555.42 — стабильно как часы. Урок: на проде не ставлю последний драйвер, беру предыдущий major-релиз.

Open WebUI пытался ходить во внешний интернет

По умолчанию Open WebUI пингует api.openai.com и hub HuggingFace для проверки обновлений. У меня iptables всё резал, и интерфейс открывался 40 секунд. Решение: переменная окружения HF_HUB_OFFLINE=1 и WEBUI_AUTH_DOMAIN=disable.

Длинные контексты — KV-cache в нативном FP16 не вмещался

Без флага --cache-type-k q8_0 при контексте 16K карта забивалась под пробку и рестартила процесс. Квантование KV-cache в Q8 уменьшает занимаемую память почти вдвое без видимой потери качества — это главный трюк для длинных диалогов.

Финдир добавил в группу всех бухгалтеров — пошли тормоза

На вторую неделю клиент сам добавил в GG_AI_Users всю бухгалтерию (восемь человек) и два менеджера. Утром пришло восемь параллельных запросов, llama-server поставил их в очередь по 4. Я докрутил --parallel 8, но скорость на одного просела до 22 ток/сек. Договорились с клиентом, что когда народу станет 25+ — берём вторую карту.

FAQ: что чаще всего спрашивают клиенты

Сколько стоит развернуть локальный LLM для офиса 30 человек?

Если у заказчика уже есть подходящий сервер с GPU, то наши инженерные работы «под ключ» займут, как правило, около недели, и стоить это будет 80-120 тысяч рублей. Но вот если железо приходится собирать с нуля, тут, конечно, самая большая статья расходов — видеокарта. Одна RTX 4090 24 GB обойдется где-то в 240-280 тысяч. А серверная платформа на Xeon с 64 GB RAM и NVMe? Это еще 350-400 тысяч. В итоге, весь комплект под Qwen 2.5 32B Q4 выйдет в 600-700 тысяч рублей разово. Сравните эти цифры с 90-120 тысячами, которые вам придётся отдавать каждый месяц за API OpenAI или Anthropic при аналогичной нагрузке. Разница, по-моему, просто очевидна, не правда ли?

Какую модель выбрать: Qwen, Llama, GPT-OSS или что-то ещё?

Вот, например, на май 2026 года для большинства русскоязычных задач я обычно ставлю Qwen 2.5 32B Instruct в кванте Q4_K_M. Считаю его лучшим выбором по балансу размера, скорости и, конечно же, качества. Для английских технических текстов с ним вполне конкурирует Llama 3.3 70B, но есть один важный нюанс: она не поместится в 24 GB видеопамяти и требует CPU-offload. А это, к сожалению, моментально роняет скорость в 4-5 раз. Не наш вариант, согласитесь. GPT-OSS 20B от OpenAI тоже неплохая, но русский язык у неё заметно слабее. Qwen 3 пока, на наш взгляд, ещё сыроват; мы ждём стабильных весов в кванте, чтобы наконец-то протестировать его как следует.

Чем llama.cpp лучше Ollama, если Ollama проще?

Как я уже говорил, Ollama — это по сути просто удобная обёртка над llama.cpp. У неё есть сетевой API и приятный менеджер моделей. Но вот вам один огромный минус: по умолчанию она запускается с чересчур консервативными настройками. И это, к сожалению, очень сильно бьёт по скорости. Представьте себе: на RTX 4090 у моего клиента llama.cpp выдавал стабильные 58 токенов в секунду, а Ollama… всего 19! Какая разница, да? В три раза, и это при той же самой модели и тех же весах! Если вы просто экспериментируете на Mac Studio для прототипа, то Ollama ещё сойдёт. Но для серьёзного продакшна, где каждая миллисекунда на счету, всегда лучше использовать llama.cpp напрямую. Конечно, с правильно подобранными параметрами. Это мой железный принцип.

Безопасно ли держать LLM на своём сервере вместо облачного API?

Именно поэтому наши клиенты и приходят к нам. Ведь давайте будем честны: юристы и бухгалтеры просто не имеют права отправлять договоры с персональными данными контрагентов в публичные OpenAI или GigaChat. Это же прямая утечка по 152-ФЗ, а там такие штрафы, что голова закружится! Наш локальный LLM? Он работает полностью без интернета. Все его веса лежат прямо на NVMe сервера, и, поверьте, ни один, я подчеркиваю, ни один токен не покидает корпоративную сеть. Это стопроцентная безопасность. Когда приходит аудитор, мы просто показываем ему сетевую диаграмму, где чётко видно, что исходящий трафик на 443 порту у GPU-ноды заблокирован. И что? Никаких вопросов! Все довольны.

Какая нагрузка реально вытягивается одной RTX 4090 на офис?

С моделью Qwen 2.5 32B Q4_K_M, которую мы запускаем через llama.cpp, одна наша RTX 4090 спокойно тянет 4-6 одновременных диалогов. И при этом время ответа даже на сложный запрос не превышает восьми секунд. Согласитесь, это очень достойный результат! Для офиса, где работает 28-35 человек, и где 12-15 сотрудников пользуются LLM лишь время от времени, такой производительности хватает с огромным запасом. Мы даже не чувствуем, что сервер загружен. Но если вдруг вам понадобятся 20+ параллельных запросов в режиме реального времени, или, скажем, вы захотите запустить Llama 70B, тогда, конечно, придётся раскошелиться. Тут уже или две карты в SLI, или сразу RTX 6000 Ada с 48 GB памяти. Это уже совсем другие масштабы.

Итог

Поверьте мне, друзья: локальный LLM в 2026 году — это уже давно не какая-то научная фантастика. И уж точно это не значит, что вам придётся строить целый дата-центр. На самом деле, всё куда проще! Это всего лишь одна неделя работы нашего инженера, одна RTX 4090, грамотно настроенные параметры llama.cpp и удобный веб-интерфейс с доменной авторизацией. Вот и всё, правда! Для малого бизнеса такое решение полностью закрывает все требования 152-ФЗ, а главное — экономит вам 90 000 ₽ каждый месяц, которые вы бы тратили на подписки облачных сервисов. И помните, ребята: ни в коем случае не запускайте через Ollama в дефолтном режиме! Лучше соберите llama.cpp из исходников и тщательно подберите кванты конкретно под вашу видеокарту. Вот тогда всё будет просто летать!