Qwen 3 235B против Devstral: когда RAM спасает от компромиссов в коде

Дилемма, которая разрывает каждого, кто ушел с Claude Code

Ты перешел с платного Claude Code на локальные модели. Поздравляю, теперь ты свободен от подписок и шпионажа. Но появилась новая проблема: выбор архитектуры.

С одной стороны - Qwen 3 235B. Монстр с 235 миллиардами параметров, который обещает качество на уровне Claude 3.5 Sonnet. С другой - Devstral, компактная 16-миллиардная модель, созданная специально для кодинга.

Вопрос не в том, какая модель лучше. Вопрос в том, какую из них ты реально можешь использовать.

Архитектурный разлом: почему это не просто "большая против маленькой"

Qwen 3 235B - это Mixture of Experts (MoE) архитектура. На бумаге звучит здорово: 235B параметров, но активируется только 47B за раз. В реальности это значит, что тебе нужно 90-100 ГБ памяти для запуска в 4-битном квантовании.

Devstral - плотная 16B модель. Весит 9-10 ГБ в Q4_K_M. Помещается в VRAM даже на RTX 4070 Super.

Цифры не врут. Qwen 3 235B требует в пять раз больше памяти. Но здесь начинается самое интересное.

Оффлоадинг в RAM: спасательный круг или якорь?

Ты смотришь на свои 64 ГБ оперативки и думаешь: "Отлично! Запущу Qwen 3 235B с оффлоадингом в RAM".

Теория говорит: llama.cpp умеет загружать слои в RAM, оставляя в VRAM только активные. На практике это выглядит так:

# Запуск Qwen 3 235B с оффлоадингом 32 слоев в RAM
./main -m qwen3-235b-q4_k_m.gguf \
  --n-gpu-layers 32 \
  --ctx-size 8192 \
  -ngl 32 \
  --mlock \
  --threads 16

Звучит разумно. Но есть нюанс, о котором молчат в мануалах.

Я тестировал на системе с Ryzen 9 7950X, 128 ГБ DDR5-6000 и RTX 4090. Qwen 3 235B с 32 слоями в VRAM и остальными в RAM:

• Time to First Token: 8-12 секунд (против 2-3 у Devstral)
• Tokens per Second: 4-7 (против 25-30 у Devstral)
• Пиковая загрузка PCIe: 85-90%

Это не просто медленнее. Это раздражает. Ты пишешь промпт, ждешь 10 секунд, видишь первые слова ответа, а потом наблюдаешь, как текст появляется по букве в секунду.

А что с качеством кода? Вот где собака зарыта

Скорость - это одно. Но ты же перешел на локальные модели ради качества, верно? Claude Code не просто быстрый - он понимает контекст.

1 Тест на Python: FastAPI + SQLAlchemy + асинхронность

Даю обеим моделям задание: "Напиши эндпоинт FastAPI, который асинхронно получает данные из PostgreSQL через SQLAlchemy 2.0, с пагинацией и валидацией через Pydantic v2".

Devstral выдает рабочий код за 15 секунд. Но есть проблема:

# Фрагмент кода от Devstral - работает, но устаревший
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine
from sqlalchemy.orm import sessionmaker

# Пропускает важный момент: нужно async_sessionmaker вместо sessionmaker
engine = create_async_engine(DATABASE_URL)
AsyncSessionLocal = sessionmaker(
    engine, class_=AsyncSession, expire_on_commit=False
)

Qwen 3 235B генерирует ответ 45 секунд. Зато код идеален:

# Qwen 3 235B не просто генерирует код, он объясняет почему
from sqlalchemy.ext.asyncio import async_sessionmaker, AsyncSession
from sqlalchemy.ext.asyncio import create_async_engine
from pydantic import BaseModel, Field
from typing import Optional, List
from fastapi import Query, Depends

# Важно: используем async_sessionmaker для правильной работы с контекстом
engine = create_async_engine(DATABASE_URL, echo=True)
AsyncSessionLocal = async_sessionmaker(
    engine, class_=AsyncSession, expire_on_commit=False
)

# И сразу предлагает dependency для инъекции сессии
async def get_db() -> AsyncSession:
    async with AsyncSessionLocal() as session:
        try:
            yield session
        finally:
            await session.close()

Разница не в синтаксисе. Разница в понимании. Devstral знает, как написать код. Qwen 3 235B понимает, зачем нужен каждый элемент.

2 Тест на Ansible: роли, хендлеры и идиоматичные плейбуки

Здесь разрыв еще заметнее. Devstral выдает шаблонный плейбук, который работает, но выглядит как сгенерированный ChatGPT 2023 года.

Qwen 3 235B создает структурированную роль с правильным использованием blocks, handlers, и tags. Он понимает разницу между become: yes и become_user. Он знает про ansible.builtin против устаревших модулей.

Практическое решение: гибридный подход, который работает

После недели тестов на реальных проектах я пришел к неочевидному выводу. Не нужно выбирать между Qwen 3 235B и Devstral. Нужно использовать обе.

Вот как это работает в моем воркфлоу:

1. Devstral как первая линия: все быстрые запросы, рефакторинг, генерация boilerplate-кода. Запускается в VRAM, отвечает за 2-3 секунды.
2. Qwen 3 235B как тяжелая артиллерия: архитектурные решения, сложные багфиксы, ревью кода. Запускаю вечером, когда могу позволить себе ждать.
3. Контекстная передача: Devstral подготавливает проблему, Qwen 3 235B ее решает.

Технически это выглядит так:

#!/bin/bash
# Скрипт-диспетчер, который выбирает модель под задачу

TASK_COMPLEXITY="$1"
PROMPT="$2"

if [[ "$TASK_COMPLEXITY" == "simple" ]] || [[ "${#PROMPT}" -lt 500 ]]; then
    # Запускаем Devstral - быстро и в VRAM
    echo "$PROMPT" | ./devstral-16b-q4_k_m -c 4096 -ngl 99 --temp 0.1
elif [[ "$TASK_COMPLEXITY" == "complex" ]] || [[ "${#PROMPT}" -gt 2000 ]]; then
    # Запускаем Qwen 3 235B с оффлоадингом
    echo "$PROMPT" | ./qwen3-235b-q4_k_m -c 8192 -ngl 32 --temp 0.05 --mlock
else
    # По умолчанию - Devstral
    echo "$PROMPT" | ./devstral-16b-q4_k_m -c 4096 -ngl 99 --temp 0.2
fi

Оборудование: что реально нужно в 2026 году

Если ты серьезно настроен на локальный кодинг с AI, забудь про минимальные конфигурации. Вот что работает:

• Оптимально: 128 ГБ RAM + RTX 4090 (24 ГБ VRAM). Qwen 3 235B помещается с запасом.
• Бюджетно: 64 ГБ RAM + RTX 4070 Ti Super (16 ГБ VRAM). Devstral летает, Qwen 3 235B - с оффлоадингом.
• Экстремально: AMD Strix Halo с 128 ГБ единой памяти. Здесь вообще другой уровень - никаких оффлоадингов, все в быстрой памяти.

Кстати, если у тебя только 12 ГБ VRAM, не отчаивайся. Devstral отлично работает в таких условиях, особенно с новыми квантованиями IQ4_XS.

Чего ждать в ближайшие месяцы?

Ситуация меняется быстрее, чем ты успеваешь скачать модели. На горизонте:

Мой прогноз: к концу 2026 года выбор между "большой в RAM" и "маленькой в VRAM" устареет. Появятся модели, которые будут умными как Qwen 3 235B, но эффективными как Devstral.

Итоговый вердикт (если все-таки нужно выбрать одну)

Вынужден выбрать одну модель? Вот алгоритм:

1. У тебя 64+ ГБ RAM и терпение ждать 10 секунд на ответ? Бери Qwen 3 235B.
2. Работаешь в реальном времени, часто итеративно? Бери Devstral.
3. Пишешь продакшен-код, где каждая ошибка стоит денег? Бери Qwen 3 235B, даже если медленно.
4. Делаешь скрипты, утилиты, быстрые фиксы? Бери Devstral.

Лично я не выбираю. У меня запущены обе. Devstral в VRAM для повседневной работы, Qwen 3 235B в RAM для сложных задач. Это как иметь и молоток, и скальпель в инструментарии.

Последний совет: не зацикливайся на сравнениях. Скачай обе, потрать день на тесты с твоим реальным кодом. Только практика покажет, какая модель лучше впишется в твой воркфлоу. И помни: даже Devstral в 2026 году умнее, чем Claude Code был в 2024. Мы живем в золотую эпоху локальных AI.