Qwen 3 против DeepSeek: что выбрать для русского языка

MAATRIX

Вы разворачиваете локальную LLM для работы с русским текстом и упёрлись в выбор между Qwen 3 и DeepSeek — оба семейства открытые, оба регулярно занимают верхние строчки в общих рейтингах, и по обоим в рунете гуляют статьи с готовыми вердиктами «эта модель лучше пишет по-русски». Проблема в том, что большинство таких вердиктов либо устарели ко времени публикации, либо вообще не измерялись — их пересказывают друг у друга. Дальше — честная методика, как получить ответ, который будет верен именно для вашей задачи, а не для чужого бенчмарка.

Что на самом деле стоит проверять

Вместо вопроса «какая модель лучше по-русски вообще» задайте себе более узкий и полезный: «какая модель лучше справляется с *моими* текстами на русском». Это два разных вопроса с разными ответами. Модель может быть сильнее в художественном стиле и слабее в структурированных JSON-ответах на русском, или наоборот — держать техническую терминологию, но проваливаться в неформальном тоне. Универсального победителя для всех задач сразу, скорее всего, не существует.

Из практики держания серверов с локальными LLM для клиентов с русскоязычными задачами: типичные слабости моделей, для которых русский — не основной язык обучения, повторяются из версии в версию (хотя острота проблемы у новых поколений обычно снижается):

• Неестественные кальки с английского/китайского синтаксиса — порядок слов, который формально грамматически верен, но так не говорят;
• Смешение регистров — официально-деловой оборот посреди разговорной фразы или наоборот;
• Ошибки согласования — падежи, роды, числительные с существительными (особенно на длинных предложениях);
• Затухание качества на длинном контексте — первые абзацы русского текста ровные, к концу генерации проскальзывают англицизмы или структура рассыпается;
• Транслитерация вместо перевода терминов там, где в русском уже есть устоявшийся эквивалент.

Ни один из этих пунктов не гарантированно проявится именно в вашем случае — это список того, на что стоит целенаправленно смотреть при проверке, а не диагноз.

Методика самостоятельной проверки: пошагово

Это ядро статьи — если сделаете только это, остальное не так важно.

Шаг 1. Соберите 15–30 реальных примеров вашей задачи. Не абстрактные тесты вроде «переведи предложение» — а именно то, что модель должна будет делать в проде. Если это бот поддержки — реальные (обезличенные) вопросы клиентов. Если генерация статей — три-четыре типовых брифа с вашими требованиями к стилю. Если извлечение данных из документов — реальные, а не выдуманные документы. Разнообразие важнее объёма: 20 разных кейсов дадут больше информации, чем 100 вариаций одного и того же.

Шаг 2. Зафиксируйте промпт и параметры генерации. Один и тот же системный промпт, одна и та же температура (для сравнения качества текста разумно брать низкую — 0.2–0.4, чтобы убрать случайность и сравнивать именно способности модели, а не удачные семплы), одинаковый формат ожидаемого ответа. Если параметры будут отличаться между прогонами двух моделей, вы будете сравнивать не модели, а настройки.

Шаг 3. Прогоните одинаковые примеры через обе модели. Проще всего — через Ollama на одном сервере, переключая модель между прогонами. Если хотите гонять оба семейства параллельно и сравнивать через единый API — удобно поднять LiteLLM как прокси-шлюз перед обеими моделями, тогда переключение — это смена одного параметра в запросе, а не смена окружения.

Шаг 4. Оценивайте по заранее определённым критериям, а не «на глаз». Перед прогоном решите, что для вас важно: грамматическая правильность, естественность оборотов, точность фактов, соблюдение формата, длина ответа, скорость генерации. Пройдитесь по каждому примеру и отметьте, где какая модель хуже — а не просто общее впечатление «эта как будто получше». Субъективная оценка нормальна (это и есть цель — оценить то, что важно именно вам), но структурированная субъективная оценка надёжнее, чем интуитивное «чувство».

Шаг 5. Проверьте устойчивость, а не одну попытку. Прогоните хотя бы часть примеров по два-три раза с разными сидами (или чуть более высокой температурой). Модель, которая один раз выдала отличный ответ, может на соседнем похожем запросе просесть — это тоже часть картины.

Шаг 6. Если возможно, привлеките живого носителя языка со стороны для слепой оценки. Покажите ответы двух моделей без указания, где чья, и попросите отметить, какой ответ лучше и почему. Это убирает вашу собственную предвзятость (если вы заранее ожидали, что одна модель лучше) и даёт более честную картину.

Весь цикл шагов 1–5 на 20 примерах занимает обычно несколько часов работы, а не дни — и именно этих нескольких часов чаще всего не хватает, когда решение принимается «по статье из интернета» вместо реальной проверки.

Как быстро развернуть обе модели рядом для сравнения

Практически для теста не обязательно поднимать сложную инфраструктуру. Минимальный рабочий вариант на одном сервере:

# устанавливаем Ollama
curl -fsSL https://ollama.com/install.sh | sh

# скачиваем нужные размеры обеих моделей
ollama pull qwen3:8b
ollama pull deepseek-r1:8b

# прогон одного и того же промпта через обе модели
ollama run qwen3:8b "Ваш тестовый промпт на русском"
ollama run deepseek-r1:8b "Ваш тестовый промпт на русском"

Точные названия тегов моделей в реестре Ollama могут отличаться на момент вашего запуска — всегда сверяйтесь со списком через ollama list после pull и с актуальным реестром на сайте Ollama, чтобы не ориентироваться на устаревшее имя тега из старой инструкции.

Если хотите автоматизировать прогон списка примеров через обе модели скриптом (а не вручную копировать в консоль), простой вариант — обратиться к локальному REST API Ollama:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "Ваш тестовый промпт",
  "stream": false
}'

Меняете model на второй вариант — и сравниваете JSON-ответы по одному и тому же полю response. Для десятков примеров такой скрипт на Python или bash с циклом по файлу с промптами экономит время по сравнению с ручным копированием.

Отдельный практический момент — если задача предполагает не разовую генерацию, а диалог с памятью или работу с базой знаний (RAG), тестировать модели стоит именно в этом контуре, а не изолированными репликами: качество финального ответа сильно зависит от того, как модель работает с подставленным контекстом, а не только от «чистой» генерации.

Размер модели тоже часть выбора, а не только семейство

И у Qwen, и у DeepSeek модели выпускаются в нескольких размерах — от компактных вариантов, которые можно гонять на CPU или скромной видеокарте, до крупных, которым нужен полноценный GPU-сервер с существенным объёмом видеопамяти. Это отдельная ось выбора, ортогональная вопросу «какое семейство лучше по-русски»: младшая модель одного семейства и старшая модель другого будут вести себя на русском по-разному не столько из-за архитектурных различий компаний, сколько из-за разницы в размере и, соответственно, в общей «мощности» модели.

Практический вывод: сравнивать имеет смысл модели сопоставимого размера (условно — младшую с младшей, среднюю со средней), иначе результат теста будет отражать разницу в размерах, а не разницу в качестве работы с русским языком между семействами. И наоборот — если для вашей задачи хватает компактной модели, есть смысл сразу тестировать именно компактные варианты обеих линеек, а не топовые (которые могут не влезть в доступное железо или обойдутся кардинально дороже в эксплуатации).

Какой размер вообще потребуется под ваше железо и сколько памяти нужно на каждый вариант — отдельный вопрос, который лучше проработать заранее, до теста: смотрите разбор в статье про требования к железу для машинного обучения, а под конкретные модели — материалы сколько RAM нужно для Qwen и сколько RAM нужно для DeepSeek. Отдельный фактор — квантование: степень сжатия модели тоже влияет на качество русского текста, и её стоит держать одинаковой при сравнении моделей, иначе разница в результатах может объясняться не семейством, а степенью сжатия, а не выбором между Qwen и DeepSeek.

Частые вопросы