Модуль p.9 · Урок 2
Урок 2: Локальный деплой SOTA open-LLM — Qwen 3, DeepSeek V3, T-Pro 2.0
Содержание
- Чему вы научитесь
- Сначала семейства моделей, потом конкретный checkpoint
- Что из этого реально запускать локально
- Русский контур: на что смотреть в 2026 году
- 1. T-Pro 2.0 — лучший прямой кандидат под RU RAG и ассистентов
- 2. Vikhr — сильная community-семья, но проверяйте конкретный checkpoint
- 3. Saiga — не одна модель, а семейство fine-tune’ов
- 4. GigaChat open family — уже не только «Lite»
- Квантизация: что реально использовать
- Минимальный путь 1: локально через Ollama
- Минимальный путь 2: серверно через vLLM
- Как собирать локальный production-контур
- Главный управленческий вывод
Чему вы научитесь
- Выбирать 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
| Модель / семейство | Официальный URL | Лицензия | Зрелость AIStudy | Язык | Где уместна | Ориентир по VRAM в Q4 |
|---|---|---|---|---|---|---|
| Qwen 3 14B | Qwen/Qwen3-14B | Apache-2.0 | production | multilingual, русский адекватный | on-prem чат, RAG, tool use | ≈9–14 GB в Q4 с учётом KV cache и production-нагрузки |
| Qwen 3 235B-A22B | Qwen/Qwen3-235B-A22B | Apache-2.0 | production, но кластерный класс | multilingual | сложный reasoning, high-end agent stack | не consumer-класс; нужен кластер, точная конфигурация зависит от режима |
| DeepSeek V3 | deepseek-ai/DeepSeek-V3 | MIT + model license | production | EN/ZH, русский терпимо | reasoning, code, сложные аналитические задачи | полная модель — кластер; distill и quant — отдельный расчёт |
| DeepSeek R1 | deepseek-ai/DeepSeek-R1 | MIT + model license | production | reasoning-heavy | сложная аналитика, разбор инцидентов, инженерный reasoning | зависит от distill/full; нужна проверка под конкретный checkpoint |
| GLM-4.5 | zai-org/GLM-4.5 | MIT | stable / production-candidate | EN/ZH, частично multilingual | coding, agentic сценарии, tool use | полный checkpoint кластерный |
| T-pro-it-2.0 | t-tech/T-pro-it-2.0 | Apache-2.0 | production | русский + bilingual | корпоративный RAG, инструкции, документы | ≈19.8 GB для Q4_K_M GGUF; 22–27 GB для Q5/Q6 |
| Phi-4 | microsoft/phi-4 | MIT | stable | в основном EN | компактный reasoning-слой, классификация, локальный ассистент | ≈10–12 GB, нужна проверка |
| Llama 3.3 70B | открытые веса Meta, лицензия сообщества | Llama Community License | production | multilingual | крупный on-prem inference | ≈40–48 GB в Q4, нужна проверка |
| GigaChat open family | salute-developers/gigachat3 | MIT | stable / production-candidate | RU/EN | русскоязычный локальный inference и high-load use | GigaChat3-10B-A1.8B — компактный класс, точная память зависит от формата |
После первой таблицы полезно сразу отрезать лишние ветки. Ниже — грубое дерево выбора, которое помогает не путать «русский контур», reasoning и multimodal-задачи.
flowchart TD
A{Основной язык — русский?}
A -->|Да| B{Нужен reasoning?}
B -->|Да| C[DeepSeek R1]
B -->|Нет| D{Нужна мультимодальность?}
D -->|Да| I[Qwen2-VL]
D -->|Нет| E{Приоритет — RU-корпус?}
E -->|Да| F[T-Pro 2.0]
E -->|Нет| G[Vikhr / Saiga]
A -->|Нет| H{Нужен reasoning?}
H -->|Да| C
H -->|Нет| J{Нужна мультимодальность?}
J -->|Да| I
J -->|Нет| K{Только чат?}
K -->|Да| L[Qwen 3 14B]
K -->|Нет| M[Qwen / DeepSeek V3]Что из этого реально запускать локально
Практическое правило жёсткое.
- Если у вас одна рабочая машина, берите семейства до
14Bили компактные MoE/quant-варианты. - Если у вас один серьёзный сервер, тогда появляются
32B-класс и отдельные русские модели уровняT-Pro 2.0в квантованном виде. - Если у вас нет нескольких дорогих GPU, не стройте план вокруг полной
DeepSeek V3илиQwen 3 235B-A22B.
Официальная модельная карта 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.0 — лучший прямой кандидат под RU RAG и ассистентов
Модельная карта t-tech/T-pro-it-2.0 прямо публикует лицензию apache-2.0, базу на Qwen 3 и собственные бенчмарки: MERA 0.660, ruMMLU 0.790, Ru Arena Hard 0.876 (t-tech/T-pro-it-2.0). Для корпоративной базы знаний, внутренней документации, регламентов и техподдержки это сейчас один из самых понятных вариантов.
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, но на 20 апреля 2026 года у Salute Developers опубликован уже более свежий open контур: репозиторий gigachat3 и открытые веса GigaChat3 Ultra Preview и GigaChat3 Lightning, а также ранее открытые линейки GigaChat family под MIT (salute-developers/gigachat3, ai-sage/GigaChat-20B-A3B-instruct). Поэтому в локальном deployment надо смотреть уже не на старый маркетинговый ярлык Lite, а на актуальный checkpoint и его требования.
Квантизация: что реально использовать
| Формат / подход | Где работает | Когда брать | Сильная сторона | Ограничение |
|---|---|---|---|---|
| GGUF Q4_K_M | llama.cpp, Ollama, CPU/Apple/edge | Когда нужен компактный локальный inference | Лучший бытовой компромисс по памяти и скорости | Обычно сохраняет 97–99% качества по perplexity относительно FP16 при ≈4x сжатии; итог всё равно зависит от модели |
| GGUF Q5_K_M | llama.cpp, Ollama | Когда Q4 уже заметно портит ответ | Лучше держит качество | Требует больше памяти |
| AWQ | vLLM, SGLang, HF | Когда нужен GPU-serving и 4-bit | Хорошо подходит для server inference | Не все модели и backend’ы одинаково зрелы |
| GPTQ | vLLM, HF, exllama-стек | Когда нужен агрессивный GPU-quant | Большая экосистема | На части моделей проигрывает AWQ по удобству и качеству |
| EXL2 | ExLlama-экосистема | Когда нужен максимум скорости на одной GPU | Очень быстрый локальный inference | Меньше универсальности, чем у GGUF |
Квантизация — это не магия. Она всегда торгует качеством, скоростью, памятью и удобством эксплуатации. Поэтому правило простое: сначала выбрать модель, потом 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.0 сама модельная карта рекомендует и SGLang, и vLLM, а также публикует отдельные AWQ, GGUF и FP8 checkpoints (t-tech/T-pro-it-2.0, t-tech/T-pro-it-2.0-AWQ). Это очень хороший сигнал зрелости: у модели есть не только paper, но и готовые артефакты под разные режимы inference.
Как собирать локальный production-контур
Выберите не «лучшую модель», а класс задачи. RU RAG, reasoning, coding, классификация, tool use, document Q&A — это разные профили.
Проверьте лицензию на уровне конкретного checkpoint. Особенно для community fine-tune’ов и семейств типа Saiga.
Подберите runtime. Ollama — для локального пользователя и edge. vLLM — для общего сервиса. llama.cpp — для GGUF и CPU/Apple.
Только после этого выбирайте quant. Для CPU и laptop чаще GGUF, для shared GPU чаще AWQ/GPTQ/FP8.
Сразу ставьте gateway и логирование. Даже open-source стек надо эксплуатировать как сервис, а не как набор команд в bash-history.
Главный управленческий вывод
Локальный open-LLM проект проваливается не потому, что модель «хуже GPT». Он проваливается, когда команда берёт слишком большую модель, не считает VRAM, не проверяет лицензию, не понимает русский корпус и не отличает пилотный runtime от production сервера.