Урок 2: Локальный деплой SOTA open-LLM — Qwen 3.8, DeepSeek V4, T-Pro 2.1

Чему вы научитесь

• Выбирать open-LLM под конкретный контур: edge, on-prem, частное облако или кластерный inference
• Отличать модели, которые реально можно поднять локально, от моделей, которые формально open, но практически требуют кластера
• Разбираться в квантизации: GGUF Q4/Q5, AWQ, GPTQ, EXL2 — без маркетинговой мистики
• Поднимать локальный API через Ollama и vLLM и понимать, когда какой способ уместен
• Не путать «русская модель» с «модель, которая действительно готова к production на русском корпусе»

Open-weight модель — это ещё не локальный production. Вопрос не в том, открыты ли веса. Вопрос в том, можно ли их запустить в вашем контуре, на вашем железе, с вашим TCO и без санкционного сюрприза. Именно поэтому этот урок стоит читать вместе с уроком p.2/03 про железо, уроком p.3/05 про санкционный контур и уроком p.4/01 про ROI.

Сначала семейства моделей, потом конкретный checkpoint

После первой таблицы полезно сразу отрезать лишние ветки. Ниже — грубое дерево выбора, которое помогает не путать «русский контур», reasoning и multimodal-задачи.

flowchart TD
    A{Основной язык — русский?}
    A -->|Да| B{Нужен reasoning?}
    B -->|Да| C[T-Pro 2.1 / DeepSeek V4-Flash]
    B -->|Нет| D{Нужна мультимодальность?}
    D -->|Да| I[Qwen2.5-VL / Qwen3-VL]
    D -->|Нет| E{Приоритет — RU-корпус?}
    E -->|Да| F[T-Pro 2.1]
    E -->|Нет| G[Vikhr / Saiga]
    A -->|Нет| H{Нужен reasoning?}
    H -->|Да| C
    H -->|Нет| J{Нужна мультимодальность?}
    J -->|Да| I
    J -->|Нет| K{Только чат?}
    K -->|Да| L[Qwen 3.8 27B]
    K -->|Нет| M[Qwen 3.8 / DeepSeek V4-Flash]

Что из этого реально запускать локально

Практическое правило жёсткое.

• Если у вас одна рабочая машина, берите семейства до 14B или компактные MoE/quant-варианты.
• Если у вас один серьёзный сервер, тогда появляются 27–33B-класс и отдельные русские модели уровня T-Pro 2.1 в квантованном виде.
• Если у вас нет нескольких дорогих GPU, не стройте план вокруг полной DeepSeek V4-Pro или GLM-5.2.

Официальная модельная карта Qwen3-235B-A22B прямо указывает 235B total и 22B activated, поддержку thinking / non-thinking mode и рекомендации по deployment через vllm>=0.8.5 или sglang>=0.4.6.post1 (Qwen/Qwen3-235B-A22B). Это хороший пример того, как надо читать open-model card: не по headline, а по реальным inference requirements.

У DeepSeek-V3 модельная карта прямо говорит про 671B total, 37B active и перечисляет локальные пути запуска через SGLang, TensorRT-LLM, vLLM и даже Huawei Ascend (deepseek-ai/DeepSeek-V3). То есть модель действительно открыта. Но «локально» в данном случае означает не ноутбук, а серьёзный кластерный контур.

Русский контур: на что смотреть в 2026 году

Для русскоязычного enterprise-open стека сегодня надо различать четыре класса.

1. T-Pro 2.1 — лучший прямой кандидат под RU RAG и ассистентов

Модельная карта t-tech/T-pro-it-2.1 публикует лицензию apache-2.0, базу на Qwen 3 и прирост к 2.0: instruction following +9 п.п., Ru Arena Hard 93,8, сильнее tool calling (t-tech/T-pro-it-2.1). Для корпоративной базы знаний, регламентов и техподдержки это сейчас понятный стартовый checkpoint. 2.0 с MERA 0.660 можно не сносить, если уже в проде.

2. Vikhr — сильная community-семья, но проверяйте конкретный checkpoint

У VikhrModels есть активная open ecosystem и собственные papers/leaderboards, однако в production надо смотреть не на бренд «Vikhr», а на конкретную модель и её card: какая база, какая лицензия, что можно делать коммерчески (VikhrModels org).

3. Saiga — не одна модель, а семейство fine-tune’ов

С Saiga нельзя писать в архитектурном документе просто «ставим Saiga». Это семейство разных чекпойнтов на разных базовых моделях. У одних карт встречается cc-by-4.0, у других лицензия наследуется от базовой модели, поэтому для commercial deploy лицензию нужно смотреть на уровне конкретного checkpoint — нужна проверка (IlyaGusev org).

4. GigaChat open family — уже не только «Lite»

В research-паке фигурирует ярлык GigaChat Lite, но open-контур Сбера уже другое поколение: репозиторий gigachat3, веса Lightning / Ultra (в том числе линейка 3.5 Ultra как открытый MoE). Платный API юрлиц при этом всё ещё GigaChat 2. Для локального деплоя смотрите конкретный checkpoint, не ярлык Lite (salute-developers/gigachat3).

Квантизация: что реально использовать

Квантизация — это не магия. Она всегда торгует качеством, скоростью, памятью и удобством эксплуатации. Поэтому правило простое: сначала выбрать модель, потом runtime, потом тип квантизации. Не наоборот.

Минимальный путь 1: локально через Ollama

Ollama хорош, когда вы хотите быстро проверить модель в on-prem среде без общего трафика.

ollama pull qwen3:14b
ollama run qwen3:14b

Дальше у вас сразу есть локальный REST API:

curl http://localhost:11434/api/chat   -d '{
    "model": "qwen3:14b",
    "messages": [{"role": "user", "content": "Суммируй регламент пуска насоса"}],
    "stream": false
  }'

Такой режим годится для инженерного рабочего места, автономного помощника технолога, офлайн-проверки русской документации и edge-сценариев. Он плох как shared endpoint на десятки пользователей — это мы уже разбирали в уроке p.9/01.

Минимальный путь 2: серверно через vLLM

Когда нужен общий сервис, vLLM обычно становится базовым вариантом.

vllm serve Qwen/Qwen3-14B   --dtype auto   --max-model-len 32768

Для модели вроде Qwen3-235B-A22B официальная модельная карта уже сама даёт пример:

vllm serve Qwen/Qwen3-235B-A22B   --enable-reasoning   --reasoning-parser deepseek_r1

Для T-Pro 2.1 есть GGUF и FP8 checkpoints; у предшественника 2.0 отдельно лежат AWQ/GGUF/FP8 — тот же стек SGLang / vLLM (t-tech/T-pro-it-2.1, t-tech/T-pro-it-2.1-GGUF). Это хороший сигнал зрелости: не только paper, но и готовые артефакты под разные режимы inference.

Как собирать локальный production-контур

1. Выберите не «лучшую модель», а класс задачи. RU RAG, reasoning, coding, классификация, tool use, document Q&A — это разные профили.

2. Проверьте лицензию на уровне конкретного checkpoint. Особенно для community fine-tune’ов и семейств типа Saiga.

3. Подберите runtime. Ollama — для локального пользователя и edge. vLLM — для общего сервиса. llama.cpp — для GGUF и CPU/Apple.

4. Только после этого выбирайте quant. Для CPU и laptop чаще GGUF, для shared GPU чаще AWQ/GPTQ/FP8.

5. Сразу ставьте gateway и логирование. Даже open-source стек надо эксплуатировать как сервис, а не как набор команд в bash-history.

Главный управленческий вывод

Локальный open-LLM проект проваливается не потому, что модель «хуже GPT». Он проваливается, когда команда берёт слишком большую модель, не считает VRAM, не проверяет лицензию, не понимает русский корпус и не отличает пилотный runtime от production сервера.