Почему локальные модели для программирования не работают с Cursor: тест производительности на Mac и обходные пути

Проблема, которая бесит всех: локальные модели в Cursor - это иллюзия

Вы скачали Qwen2.5-Coder-32B, запустили через Ollama, подключили к Cursor и... ничего. Ну, не совсем ничего - курсор мигает, модель думает, вы ждете. Через 15 секунд получаете первую строку кода. Еще через 20 - вторую. Это не разработка, это медитация на тему "как я трачу свое время".

Почему так происходит? Потому что Cursor - не просто текстовый редактор с автодополнением. Это IDE, которая постоянно анализирует контекст: открытые файлы, структуру проекта, документацию. И каждый раз, когда вы нажимаете Ctrl+K ("Ask AI"), она отправляет в модель не только ваш вопрос, но и весь этот контекст. А это сотни, иногда тысячи токенов префилла.

Тест на Mac M4 Pro: цифры, которые заставят вас плакать

Я взял MacBook Pro M4 Pro с 64GB RAM - железо, которое должно "жевать" любые модели. Запустил тесты с разными конфигурациями. Результаты - ниже. Готовьтесь к разочарованию.

Видите разницу? 14 секунд на префилл против 3. Это значит: каждый раз, когда вы задаете вопрос в Cursor, вы ждете 14 секунд, прежде чем модель начнет генерировать ответ. А потом еще ждете сам ответ со скоростью 8 токенов в секунду. Для сравнения: GPT-4 в облаке делает то же самое за 1-2 секунды.

Почему стандартный Ollama так медленный? (И почему вы не можете это исправить)

Ollama по умолчанию использует llama.cpp под капотом, но с неоптимальными настройками для Mac. Проблема в том, что Cursor отправляет контекст через OpenAI-совместимый API, а Ollama обрабатывает его последовательно. Каждый токен префилла проходит через всю модель.

Но главная проблема - кэширование внимания (KV cache). В стандартной конфигурации Ollama не кэширует ключи и значения для префилла между запросами. Каждый новый запрос в Cursor - это полная переработка всего контекста с нуля.

В статье "Почему Cursor IDE блокирует локальные LLM и как это обойти" я уже писал о проблемах с CORS и конфигурацией, но производительность - отдельная история.

Решение 1: Переходим на MLX - нативная оптимизация для Apple Silicon

MLX от Apple - это не просто еще один фреймворк. Это нативная оптимизация для M-чипов, которая использует Unified Memory Architecture. Результат: модели работают в 3-5 раз быстрее, чем через llama.cpp.

1 Устанавливаем MLX и vLLM-MLX

# Клонируем репозиторий vLLM-MLX
git clone https://github.com/ml-explore/vllm-mlx
cd vllm-mlx

# Устанавливаем зависимости
pip install -e .

# Скачиваем модель (например, DeepSeek-Coder-33B)
python -m vllm.mlx.download --repo mlx-community/DeepSeek-Coder-33B-Instruct-mlx

2 Запускаем сервер с оптимизациями

# Запускаем сервер с кэшированием KV cache
python -m vllm.mlx.serve \
  --model mlx-community/DeepSeek-Coder-33B-Instruct-mlx \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9 \
  --enable-chunked-prefill \
  --kv-cache-dtype auto \
  --port 8000

Ключевые флаги здесь:

• --enable-chunked-prefill - разбивает префилл на чанки, обрабатывает параллельно
• --kv-cache-dtype auto - автоматически выбирает оптимальный тип данных для кэша
• --gpu-memory-utilization 0.9 - использует 90% памяти GPU, максимизируя производительность

В статье "vLLM-MLX: настройка нативного LLM-инференса на Apple Silicon" есть подробный гайд по тонкой настройке.

Решение 2: Меньше контекста - больше скорости

Cursor по умолчанию отправляет слишком много контекста. Настройте его:

1. Откройте настройки Cursor (Cmd+,)
2. Найдите "AI Settings"
3. Установите "Max Context Length" на 2000-3000 токенов вместо 8000
4. Отключите "Include All Open Files" - оставьте только текущий файл
5. Отключите "Include Project Documentation" если она не нужна

Это сократит префилл в 2-3 раза. Да, модель будет знать меньше о проекте, но зато ответит в 3 раза быстрее. Иногда это разумный компромисс.

Решение 3: Кэшируйте ответы локально

Самый радикальный, но эффективный способ - кэшировать частые запросы. Например, если вы часто спрашиваете "напиши функцию для валидации email", зачем каждый раз спрашивать модель?

Установите Continue - open-source альтернативу Cursor с встроенным кэшированием. Или напишите простой middleware для Ollama:

from fastapi import FastAPI, Request
import hashlib
import json
from redis import Redis

app = FastAPI()
redis = Redis(host='localhost', port=6379)

@app.post("/v1/chat/completions")
async def chat_completion(request: Request):
    data = await request.json()
    
    # Создаем хэш запроса для кэширования
    request_hash = hashlib.md5(
        json.dumps(data, sort_keys=True).encode()
    ).hexdigest()
    
    # Проверяем кэш
    cached = redis.get(request_hash)
    if cached:
        return json.loads(cached)
    
    # Если нет в кэше - идем к модели
    # ... проксируем запрос к Ollama/MLX
    
    # Кэшируем ответ на 1 час
    redis.setex(request_hash, 3600, json.dumps(response))
    return response

Какие модели реально работают в 2026 году?

После месяцев тестов могу сказать: не все модели одинаково полезны для программирования в Cursor. Вот мой топ на январь 2026:

• DeepSeek-Coder-33B-Instruct - лучший баланс качества и скорости с MLX
• Qwen2.5-Coder-14B - быстрее 32B версии, почти так же умна для повседневных задач
• Codestral-22B - специализирована на коде, но требует больше памяти
• IQuest-Coder-V1-40B-Instruct - мощная, но медленная даже на M4 Pro (читайте мой разбор в статье "IQuest-Coder-V1-40B-Instruct: как 40 миллиардов параметров превратились в цифровую пыль")

Ошибки, которые совершают все (и как их избежать)

Ошибка 1: Использовать 32B+ модели на MacBook Air или MacBook Pro с 16GB RAM. Результат - своппинг на диск и скорость 1-2 ток/с.

Решение: Берите 14B модели или используйте quantization (4-битное квантование). Qwen2.5-Coder-14B в 4-битном формате работает почти так же хорошо, как 32B в FP16, но в 3 раза быстрее.

Ошибка 2: Не настраивать параметры инференса. По умолчанию temperature=0.8, top_p=0.95 - это для чата, а не для кода.

Решение: Установите temperature=0.1, top_p=0.9 для детерминированного кода. И добавьте repetition_penalty=1.1 чтобы избежать зацикливания.

Ошибка 3: Пытаться заменить Claude Code или GitHub Copilot локальной моделью один-в-один. Не получится.

Решение: Используйте локальные модели для конкретных задач: рефакторинг, документация, дебаггинг. Для генерации нового кода с нуля лучше использовать облачные модели или специализированные инструменты вроде Claude Code.

Будущее локальных моделей в IDE: что нас ждет в 2026-2027?

Проблема не в железе и не в моделях. Проблема в архитектуре. Cursor и другие IDE проектировались для облачных моделей с мгновенным откликом. Локальные модели требуют другого подхода:

• Асинхронная генерация: Модель начинает отвечать до завершения префилла
• Инкрементальный контекст: Не пересылать весь проект каждый раз
• Специализированные маленькие модели: 3-7B параметров, заточенные под конкретные языки

Уже сейчас появляются инструменты вроде нового автопарсера для llama.cpp, который оптимизирует обработку кода.

Мой прогноз: к концу 2026 мы увидим IDE, которые изначально проектировались для локальных LLM. С кэшированием контекста, инкрементальной загрузкой и специализированными моделями для разных задач.

А пока что - настраивайте MLX, берите 14B модели и не ожидайте чудес. Локальные модели в Cursor работают, но требуют терпения и правильных ожиданий. Они не заменят GPT-4 для сложных задач, но отлично справляются с рутиной.

И последний совет: иногда проще написать код самому, чем ждать 30 секунд ответа от модели. AI - инструмент, а не замена мышлению.