Выбор локальной LLM как код-тьютора: модели, требования к RAM/VRAM и борьба с галлюцинациями

Зачем вообще локальный код-тьютор? Платить за ChatGPT или рисковать данными?

Вы сидите с ошибкой в коде, гуглите, перебираете Stack Overflow, час тратится впустую. ChatGPT мог бы помочь за минуту, но вы не хотите загружать куски проприетарного кода в облако OpenAI. Или у вас просто нет интернета в самолете. Или бюджет ограничен.

Локальная LLM-модель решает все это сразу. Она работает офлайн, не шпионит, не требует подписки. Но вот незадача: большинство моделей галлюцинируют как сумасшедшие, когда дело доходит до программирования. Они выдумывают несуществующие функции, путают синтаксис и предлагают решения, которые просто не работают.

Что нам нужно от идеального локального код-тьютора?

Давайте сразу отбросим абстракции. Нам нужна модель, которая:

• Понимает контекст в 10-20 тысяч токенов — чтобы можно было загрузить несколько файлов проекта и попросить объяснить архитектуру
• Минимум галлюцинаций — когда модель говорит "используй функцию numpy.quantile_sort()", а такой функции не существует, это раздражает больше, чем отсутствие ответа
• Работает на доступном железе
• Поддерживает основные языки программирования — Python, JavaScript, Go, Rust, SQL как минимум
• Умеет объяснять, а не только генерировать код — разница между "вот исправленный код" и "вот исправленный код, потому что ты использовал mutable default argument, что в Python приводит к..."

Три претендента: кто реально умеет в код?

После тестирования десятков моделей на реальных задачах (от дебага Python до оптимизации SQL-запросов) я выделил трех фаворитов. Каждый со своими тараканами.

1DeepSeek-Coder: китайский снайпер в мире код-тьюторов

Если бы мне пришлось выбрать одну модель для ежедневного использования — это был бы DeepSeek-Coder. Не потому что она идеальна, а потому что она предсказуема. Когда она не знает ответа, она так и говорит, а не выдумывает ерунду.

Вот реальный тест. Я дал ей кусок Django-кода с багом в сериализаторе:

class UserSerializer(serializers.ModelSerializer):
    groups = serializers.PrimaryKeyRelatedField(many=True, read_only=True)
    
    class Meta:
        model = User
        fields = ['id', 'username', 'email', 'groups']
        extra_kwargs = {'email': {'required': True}}

И спросил: "Почему при создании пользователя через этот сериализатор падает ошибка, если не передать email, хотя в модели User email не обязателен?"

DeepSeek-Coder ответил за 12 секунд: "Потому что extra_kwargs устанавливает required=True для поля email на уровне сериализатора, переопределяя настройки модели. Убери extra_kwargs или измени модель." Точно. Никаких выдумок про "может быть, проблема в миграциях" или "попробуй переустановить Django".

2Codestral: французский аристократ с ограничениями

Mistral AI сделали Codestral специально для программирования. Она быстрая, точная, но... Лицензия. Вы не можете использовать ее в коммерческих проектах без договора. Для личного обучения — пожалуйста. Для компании — проблемы.

Технически Codestral впечатляет. На тесте с асинхронным Python:

async def fetch_data(urls):
    results = []
    for url in urls:
        async with aiohttp.ClientSession() as session:
            async with session.get(url) as response:
                results.append(await response.text())
    return results

Codestral сразу заметила: "Ты создаешь новую ClientSession для каждого URL, это неэффективно. Вынеси создание сессии за цикл. И используй asyncio.gather для параллельных запросов." Умно. Но контекст всего 8k токенов — для больших проектов маловато.

3Llama 3.2 Coder: демократичный выбор с оговорками

Meta выпустила специализированную код-модель на базе Llama 3.2. Она легче (11B параметров), открытая, но... Галлюцинирует. Чаще, чем хотелось бы.

В том же тесте с Django она предложила: "Добавь в модель User поле email_verified и установи default=False. Тогда сериализатор будет работать." Это решение вообще не по делу. Проблема была в required=True, а не в верификации email.

Но если нужно что-то простое и быстрое на слабом железе — Llama 3.2 Coder в Q4_K_S займет всего 6-7 GB RAM и будет работать даже на интегрированной графике.

Аппаратная математика: сколько реально нужно памяти?

Все говорят "возьми модель поменьше", но никто не объясняет, как именно она помещается в память. Давайте разберем на примере вашего железа: 24 GB RAM и 16 GB VRAM.

Формула простая, но ее все игнорируют:

Общая память = размер модели + контекст * 0.5 + накладные расходы

Для DeepSeek-Coder 33B в Q4_K_M:

• Размер модели: ~20 GB
• Контекст 20k токенов: ~10 GB (0.5 MB на 1k токенов — реальная цифра из llama.cpp)
• Накладные расходы (кэш, система): 2-3 GB
• Итого: 32-33 GB

Не влезает? Правильно. Поэтому нужно распределять между RAM и VRAM.

Пример команды для DeepSeek-Coder:

./main -m ./models/deepseek-coder-33b-q4_k_m.gguf \
  -c 20000 --temp 0.1 --top-p 0.95 \
  --ngl 45 -t 8 --mlock --verbose-prompt

Что здесь важно:

• -c 20000 — наш целевой контекст
• --temp 0.1 — низкая температура уменьшает креативность (и галлюцинации)
• --ngl 45 — 45 слоев на GPU, остальные в RAM
• --mlock — фиксирует модель в RAM, предотвращает свопинг

Если у вас меньше RAM, прочитайте мой гайд про минимальные требования VRAM для домашнего сервера, там подробно про оптимизацию памяти.

Борьба с галлюцинациями: три техники, которые реально работают

Галлюцинации — это не баг, а фича. Модель обучена "додумывать" информацию. Но в программировании это смертельно. Вот как заставить модель быть точной.

Техника 1: Температурный шок

Не используйте температуру выше 0.3 для код-тьютора. Да, ответы будут менее "креативными", но зато точными. Лучше получить "не знаю", чем неправильный ответ.

# ПЛОХО: модель будет выдумывать
./main --temp 0.8 --top-p 0.9

# ХОРОШО: модель будет консервативной
./main --temp 0.1 --top-p 0.95

Техника 2: Контекстный якорь

Всегда давайте модели точные технические данные. Не "напиши функцию для работы с БД", а "напиши функцию на Python с использованием SQLAlchemy 2.0, которая принимает session и user_id, возвращает объект User или None".

Чем конкретнее промпт, тем меньше места для фантазии.

Техника 3: Последовательный допрос

Не просите объяснить сложную концепцию одним запросом. Разбивайте:

1. "Объясни, что такое async/await в Python"
2. "Приведи три реальных примера использования"
3. "Какие ошибки чаще всего возникают при работе с asyncio?"
4. "Как отладить deadlock в асинхронном коде?"

Каждый следующий вопрос строится на ответе предыдущего. Модель "входит в тему" и галлюцинирует меньше.

Практическая настройка: от загрузки модели до первого вопроса

Давайте пройдем весь путь с DeepSeek-Coder 33B. Предположим, у вас Ubuntu или WSL2.

Шаг 1: Качаем правильную версию

Не берите первую попавшуюся квантованную модель. Ищите конкретно Q4_K_M — лучший баланс качества и размера.

# Скачиваем через huggingface-hub
pip install huggingface-hub
huggingface-cli download deepseek-ai/deepseek-coder-33b-instruct-GGUF deepseek-coder-33b-instruct.Q4_K_M.gguf --local-dir ./models

Шаг 2: Собираем llama.cpp с поддержкой CUDA

Если у вас NVIDIA карта, это обязательно:

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make clean && make LLAMA_CUBLAS=1 -j$(nproc)

Шаг 3: Тестовый запуск с мониторингом памяти

# В одном терминале следим за памятью
watch -n 1 "nvidia-smi | grep -A1 GPU"

# В другом запускаем модель
./main -m ../models/deepseek-coder-33b-instruct.Q4_K_M.gguf \
  -p "Напиши функцию на Python, которая проверяет валидность email с помощью regex" \
  -c 4096 --temp 0.1 --ngl 40 -t 6 -n 256

Смотрите на использование VRAM и RAM. Если VRAM заполняется полностью, уменьшайте --ngl. Если RAM подходит к 90%, уменьшайте -c (контекст).

Подробнее про тонкую настройку llama.cpp читайте в моей статье Аргументы llama.cpp: от слепого копирования команд к осознанной настройке.

Чего ждать от локальных код-тьюторов через год?

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

• Модели станут меньше и умнее — архитектуры MoE (Mixture of Experts) вроде Granite 4 Small уже показывают, что можно иметь качество 30B модели при размере 8B
• Специализация дойдет до абсурда — будут отдельные модели для Python, отдельные для frontend, отдельные для DevOps
• Контекст перестанет быть проблемой — 100k токенов станут стандартом, модели научатся работать с целыми репозиториями

Но главное — исчезнет необходимость выбирать между "работает на моем железе" и "дает точные ответы". Уже сейчас Granite 4 Small показывает, что можно запускать 30B MoE-модель на ноутбуке с 8 ГБ VRAM. Это будущее.

FAQ: вопросы, которые вы постеснялись спросить

А если у меня только 16 GB RAM без видеокарты?

Берите Llama 3.2 Coder 11B в Q4_K_S. Она займет 6-7 GB RAM и будет работать на CPU со скоростью 5-7 токенов в секунду. Медленно, но для обучения сойдет. Или читайте мой гайд про запуск LLM на старом железе.

Можно ли дообучить модель на своем коде?

Технически да, но не стоит. Fine-tuning 33B модели требует нескольких A100 на неделю. Лучше использовать RAG (Retrieval-Augmented Generation) — загружайте свою документацию в векторную базу, и модель будет искать ответы там. Это проще и эффективнее.

Почему модель иногда "тупит" на простых вопросах?

Потому что вы дали ей слишком общий промпт. LLM — это не поисковик по документации. Она не "знает" ответ, она его генерирует на основе паттернов. Чем конкретнее вопрос, тем точнее ответ. Вместо "как работает Django ORM" спросите "как в Django ORM сделать LEFT JOIN между моделями User и Profile".

Стоит ли использовать несколько моделей одновременно?

Да, если есть ресурсы. Запустите DeepSeek-Coder для сложных задач и Llama 3.2 Coder для быстрых подсказок. Разные модели ошибаются по-разному, и сравнение их ответов помогает найти истину. Просто не делайте это на одном железе — памяти не хватит.

Последний совет: начните с DeepSeek-Coder 33B в Q4_K_M. Скачайте, запустите, попробуйте решить реальную проблему из вашего кода. Первые ответы могут разочаровать — модель нужно "настроить" правильными промптами. Но через неделю использования вы поймете, почему локальные код-тьюторы — это не будущее, а настоящее. Просто настоящее с особенностями.