Код на Macbook Pro 24GB: Qwen 2.5 Coder против Devstral — кто выживет на твоём железе?

Почему 24GB на Mac — это не 24GB на PC, и почему это важно

Ты купил Macbook Pro с 24GB памяти. Думал, что теперь можешь запускать любые модели. Открываешь Hugging Face, видишь модель на 34B параметров и... упс. Она не влезает. Потому что Unified Memory на Apple Silicon — это не просто RAM. Это общая память для CPU и GPU. И система тоже хочет кусочек. И браузер с сотней вкладок. И Docker. В реальности для моделей у тебя свободно 16-18GB. И это меняет всё.

Два претендента на твой SSD: кто они?

За последние полгода выстрелили две модели, которые не требуют RTX 4090, но при этом умеют писать код. Не просто дополнять — понимать контекст, исправлять баги, генерировать целые функции.

Обе — 7B. Обе — кодеры. Но Devstral создали французские разработчики с упором на практические задачи, а Qwen 2.5 — это эволюция алибабовской модели с улучшенной математикой и поддержкой 92 языков программирования. На бумаге они похожи. На практике — два разных зверя.

Установка: не делай эту ошибку с Ollama

Все советуют Ollama. И правильно советуют — это самый простой способ. Но 90% людей с Macbook Pro наступают на одни и те же грабли.

1 Сначала ставим Ollama (очевидно, да?)

# НЕ качай с официального сайта через .dmg — будет работать медленнее
# Вместо этого:
brew install ollama

Версия через Homebrew использует нативные бинарные зависимости для Apple Silicon. Версия из .dmg иногда тащит за собой Rosetta 2, даже если не должна. Разница в скорости — до 15%.

2 Запускаем и настраиваем лимиты

# Запускаем сервис
brew services start ollama

# Проверяем, что работает
ollama --version

Теперь важное: по умолчанию Ollama пытается занять всю доступную память. На Macbook Pro с 24GB это плохая идея. Нужно создать конфиг.

# Создаём конфигурационный файл
mkdir -p ~/.ollama
cat > ~/.ollama/config.json << EOF
{
  "num_keep": 5,
  "num_predict": 2048,
  "num_thread": 8,
  "num_gpu": 1,
  "main_gpu": 0,
  "low_vram": false,
  "mmap": true,
  "mlock": false
}
EOF

3 Качаем модели с правильным квантованием

# Qwen 2.5 Coder в Q4_K_M — лучший баланс качество/скорость
ollama pull qwen2.5-coder:7b-q4_K_M

# Devstral в Q5_K_M — здесь можно позволить 5 бит
ollama pull devstral:7b-q5_K_M

Почему разные квантования? Qwen 2.5 Coder изначально лучше сжата — в Q4_K_M теряет меньше качества. Devstral чувствительнее к квантованию — Q5_K_M сохраняет больше логики. Если попробовать наоборот — получишь либо тормозной Qwen, либо туповатый Devstral.

Тест-драйв: заставляем их решать реальные задачи

Я взял три типовых сценария, которые встречаются каждый день:

1. Написать функцию на Python, которая парсит JSON, фильтрует данные и сохраняет в CSV
2. Найти баг в React-компоненте с неправильным обновлением состояния
3. Сгенерировать SQL-запрос с JOIN трёх таблиц и агрегацией

Результаты удивили даже меня.

Python-задача: Qwen 2.5 Coder побеждает, но...

# Запрос к Qwen 2.5 Coder:
# "Write a Python function that reads a JSON file, filters entries where 'status' == 'active', and saves to CSV"

# Ответ Qwen 2.5 Coder (сокращённо):
import json
import csv

def filter_json_to_csv(input_file, output_file):
    with open(input_file, 'r') as f:
        data = json.load(f)
    
    if isinstance(data, list):
        filtered = [item for item in data if item.get('status') == 'active']
    elif isinstance(data, dict):
        filtered = {k: v for k, v in data.items() if v.get('status') == 'active'}
    else:
        raise ValueError("Unsupported JSON structure")
    
    with open(output_file, 'w', newline='') as f:
        writer = csv.writer(f)
        # ... правильно определяет заголовки и записывает строки

Qwen выдала код, который работает с разными структурами JSON (список или словарь). Devstral сделала функцию только для списка. Но! Devstral добавила обработку ошибок и логирование, которых не было у Qwen. Вывод: Qwen лучше понимает спецификацию, Devstral думает о production-качестве.

React-баг: здесь Devstral в своей стихии

// Исходный код с багом:
function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    fetchUsers();
  }, []);

  const fetchUsers = async () => {
    setLoading(true);
    const response = await fetch('/api/users');
    const data = await response.json();
    setUsers(data);
    // Забыли setLoading(false)!
  };

  return (
    

      {loading ?  : (
        

          {users.map(user => (
            
{user.name}
          ))}
        
      )}
    
  );
}

Qwen 2.5 Coder нашла отсутствие setLoading(false). Devstral нашла это И предложила добавить обработку ошибок в fetch, иначе при падении API loading останется true навсегда. Devstral думает на шаг вперёд.

SQL: ничья с привкусом Qwen

Обе модели сгенерировали рабочий SQL. Но Qwen добавила комментарии с объяснением каждого JOIN — полезно для junior-разработчиков. Devstral сгенерировала более оптимизированный запрос с EXISTS вместо IN, но без пояснений.

Скорость: цифры, которые имеют значение

Я замерил на Macbook Pro M2 Pro с 24GB:

Разница в 4 токена в секунду — это примерно 10%. На практике: генерация функции из 200 токенов займёт у Qwen ~4.7 секунды, у Devstral ~5.2 секунды. Полсекунды разницы. Стоит ли гоняться за скоростью? Если пишешь код целый день — да, набегает. Если используешь эпизодически — нет.

Интеграция в рабочий процесс: не только чат

Ollama — это не только командная строка. Есть три способа встроить модели в твой редактор:

• Continue.dev — расширение для VS Code и JetBrains. Подключается к локальному Ollama, работает как Copilot, но с твоими моделями. Бесплатно.
• Cursor — редактор со встроенным AI. В настройках можно указать локальную модель через Ollama API.
• Свой скрипт — Ollama предоставляет REST API на localhost:11434. Пишешь простой Python-скрипт — и получаешь код-генератор для конкретных задач.

# Пример: простой клиент для Ollama API
import requests
import json

def generate_code(prompt, model="qwen2.5-coder:7b-q4_K_M"):
    response = requests.post(
        'http://localhost:11434/api/generate',
        json={
            "model": model,
            "prompt": prompt,
            "stream": False,
            "options": {"temperature": 0.2}
        }
    )
    return response.json()['response']

# Генерируем функцию для парсинга URL
code = generate_code(
    "Write a Python function that parses a URL and returns domain, path, and query parameters"
)
print(code)

Что насчёт других моделей? Они умерли?

CodeLlama 7B? Устарела. DeepSeek Coder 6.7B? Хороша, но проигрывает в понимании контекста. StarCoder 2 7B? Быстрая, но часто галлюцинирует. MiniMax M2 интересна, но её 15B версия уже не влезет в 24GB с комфортом.

Есть ещё один игрок — выбор сообщества Reddit часто падает на Magicoder 7B. Я тестировал. Она хороша для соревновательного программирования, но для повседневных задач слишком академична.

Мой вердикт: когда какую модель запускать

Утром, когда нужно быстро набросать прототип — Qwen 2.5 Coder. Она быстрее, поддерживает больше языков, не задумывается над «идеальным» кодом.

Днём, когда пишешь production-код — Devstral. Она заметит edge cases, предложит обработку ошибок, сгенерирует более безопасный код.

Вечером, когда Macbook уже горячий и хочется сохранить батарею — ни одну. Или переходи на llama.cpp с меньшим количеством потоков.

А если устал от текстовых моделей и хошь картинок — посмотри как заставить Apple Silicon понимать изображения. Но это уже другая история.

Что будет через полгода?

Модели 7B достигли плато. Следующий прорыв — не в размере, а в архитектуре. Уже сейчас появляются модели с 3B параметрами, которые работают как 7B за счёт better training. На Macbook Pro 24GB можно будет запускать эквивалент сегодняшних 14B моделей. Или держать две 7B модели одновременно, переключаясь между ними без перезагрузки.

Пока же — качай обе. Тестируй. Qwen для скорости, Devstral для качества. И помни: лучшая модель — та, которая решает твои задачи, а не та, у которой больше звёзд на GitHub.