Claude Code против Llama-4 Scout: когда 1М токенов — это иллюзия, а LiteLLM — единственный путь

Миллион токенов? Скорее миллион проблем

Каждый второй пост в AI-сообществе кричит про "революцию сверхдлинного контекста". Llama-4 Scout заявляет 1М+ токенов. Claude Code хвастается интеллектуальным анализом целых репозиториев. Звучит как мечта инженера: загрузи весь проект, задай вопрос, получи ответ.

Пока не попробуешь.

Потому что между "поддерживает 1М токенов" и "эффективно работает с 1М токенов" — пропасть размером с весь ваш RAM. И я сейчас не про память.

Что на самом деле происходит в голове у LLM

Представьте библиотеку на миллион книг. Вам говорят: "Найди цитату про синий закат на странице 784502 в книге 329". Вы технически можете пройтись по всем полкам (у вас есть ноги!). Но вы не помните, где какая книга. И не можете одновременно смотреть на все полки.

Так работает attention механизм. Даже с sliding window и другими ухищрениями, эффективность падает экспоненциально с ростом контекста. В моих тестах Llama-4 Scout начинала "терять" детали уже после 64К токенов.

1 Собираем тестовый стенд: железо против математики

Для чистоты эксперимента я взял:

• 2x RTX 4090 (24GB каждая) — потому что меньше просто смешно
• 128GB RAM DDR5 — иначе даже загрузка модели проблематична
• Ubuntu 22.04 LTS — Linux всё ещё быстрее, и точка
• vLLM 0.4.2 с поддержкой sliding window attention
• Llama-4 Scout 14B в GGUF формате (quantized до Q4_K_M)

Зачем квантование? Потому что в полном размере модель съедала бы 28GB на GPU, оставляя 20GB на сам контекст. А нам нужно место для этих пресловутых миллиона токенов.

2 Настройка vLLM: где спрятаны все чёртовы флаги

Стандартный запуск vLLM — это как сесть в Ferrari с ручником. Модель работает, но не так, как могла бы.

Вот конфигурация, которая реально работает со сверхдлинным контекстом:

#!/bin/bash
# Запускаем vLLM сервер с правильными параметрами
export CUDA_VISIBLE_DEVICES=0,1  # Используем обе карты

python -m vllm.entrypoints.openai.api_server \
  --model /path/to/llama-4-scout-14b-Q4_K_M.gguf \
  --served-model-name llama-4-scout \
  --max-model-len 1048576  # Вот он, заветный 1М токенов \
  --gpu-memory-utilization 0.95  # Жмём до последнего байта \
  --enforce-eager  # Избегаем graph capture для длинных последовательностей \
  --swap-space 64  # GB свопа на диске (да, это нужно) \
  --block-size 32  # Размер блока для paged attention \
  --tensor-parallel-size 2  # Распределяем между двумя GPU \
  --port 8000 \
  --host 0.0.0.0

Ключевые моменты:

• --max-model-len 1048576: без этого флага vLLM обрежет контекст до 16К по умолчанию. Тихий саботаж.
• --swap-space 64: когда GPU память заканчивается, vLLM сбрасывает KV-кэш на диск. Медленно? Чёрт возьми, да. Но работает.
• --enforce-eager: CUDA graphs плохо дружат с динамически меняющимся контекстом. Отключаем.

LiteLLM: мост между мирами (и API)

vLLM запущен. Теперь нужен способ подружить его с Claude Code. Потому что Anthropic не планирует добавлять поддержку локальных моделей в своё IDE.

Входит LiteLLM — прокси, который превращает любой OpenAI-совместимый эндпоинт во что угодно: Anthropic Messages API, Google Vertex, даже Azure.

Установка проста:

pip install litellm

А вот конфигурация — нет. Потому что документация LiteLLM написана так, будто её автор ненавидит людей, которые будут это читать.

3 Конфиг LiteLLM: где спрятаны все слёзы

Создаём config.yaml:

model_list:
  - model_name: llama-4-scout
    litellm_params:
      model: openai/llama-4-scout
      api_base: http://localhost:8000/v1
      api_key: dummy-key  # vLLM не проверяет ключи, но LiteLLM требует
      max_tokens: 8192
      temperature: 0.1  # Для анализа кода нужна минимальная креативность
      timeout: 600  # 10 минут на генерацию

litellm_settings:
  drop_params: true  # Игнорируем неподдерживаемые параметры
  set_verbose: true  # Логируем всё для отладки
  caching: false  # Кэширование ломает сверхдлинный контекст
  max_budget: 0.0  # Бесплатно, потому что локально

router_settings:
  routing_strategy: "simple"
  num_retries: 3
  retry_after: 30

general_settings:
  master_key: "your-secret-key-here"  # Меняйте обязательно!
  database_url: "sqlite:///litellm.db"

Запускаем прокси:

litellm --config ./config.yaml --port 4000

Теперь у нас есть эндпоинт http://localhost:4000, который говорит на языке Anthropic Messages API. Claude Code подключается к нему, думая, что общается с родным Claude.

Тестирование: когда миллион токенов становится обузой

Я взял три тестовых кейса:

1. Анализ кодовой базы Django (450 файлов, ~85К токенов)
2. Поиск security issues в Express.js приложении (120 файлов, ~40К токенов)
3. Рефакторинг монолита на микросервисы (полный проект, ~220К токенов)

И один контрольный — загрузка полного Linux kernel (да, все ~30М строк кода, сжатых до ~1.2М токенов).

Видите проблему? С ростом контекста качество не просто ухудшается — оно обваливается. При 1.2М токенов модель вела себя так, будто видела только первые 100К.

Коллапс эффективного контекста: почему это происходит

Технически, sliding window attention в Llama-4 Scout работает. Математически — тоже. Практически? Есть три убийцы эффективности:

1. KV-кэш взрывается: 1М токенов → ~20GB KV-кэша в FP16. Даже с квантованием это 8-10GB. vLLM вынужден свапать на диск, latency растёт экспоненциально.
2. Attention dilution: каждый новый токен "видит" всё меньше предыдущих. К концу последовательности модель фактически работает с локальным контекстом в 4-8К токенов.
3. Проблема needle-in-haystack: если нужная информация в конце — модель её не найдёт. Проверено: спрятал секретный ключ в конце файла на 800К токенов. Scout его не заметил.

Это не баг. Это фундаментальное ограничение transformer архитектуры. И все модели, которые обещают "понимание" сверхдлинного контекста, просто лучше маскируют эту проблему.

Claude Code vs локальная альтернатива: счёт

Давайте посчитаем:

• Claude Code (через API): $0.03 за 1К токенов ввода, $0.15 за вывод. Анализ проекта на 200К токенов → $6 + $30 за ответ = $36 за запрос. В месяц легко набегает $1000+.
• Llama-4 Scout локально: $0 за токены. $3000 за две RTX 4090 (разовые). Электричество ~$50/месяц. Окупаемость — 3 месяца.

Но! Качество у Claude 3.5 Sonnet всё ещё выше. Особенно для сложного рефакторинга. Мой тест показал: для рутинного анализа кода Scout справляется на 85% уровня Claude. Для архитектурных решений — на 60-70%.

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

Ошибки, которые сломают вам день

Из моего списка "как не надо":

1. Не экономьте на swap: без --swap-space vLLM упадёт при первом же длинном контексте с OOM.
2. Не используйте tensor parallelism на разнородных GPU: если одна карта медленнее, она затормозит всю систему.
3. Не доверяйте заявленному max context: всегда тестируйте реальную эффективность. Модель может "поддерживать" 1М токенов, но работать только с 10% из них.
4. Не забывайте про cooling: две RTX 4090 под 95% нагрузкой греются как печь. Без хорошего охлаждения будут троттлиться уже через 10 минут.

Что в итоге? Гибрид

После недели тестов я пришёл к гибридной архитектуре:

• Локальный Llama-4 Scout через LiteLLM для рутинного анализа, поиска багов, документации
• Claude API через тот же LiteLLM прокси для сложных архитектурных задач
• Автоматический роутинг на основе сложности запроса и бюджета

LiteLLM позволяет настроить fallback: если локальная модель не справляется (низкая confidence), запрос автоматически идёт в Claude. И наоборот — простые запросы всегда остаются локальными.

Это не идеально. Но это работает. И экономит $700-800 в месяц при сравнимом качестве.

Сверхдлинный контекст — это как гиперлуп: красивая идея, которая ещё не готова к ежедневному использованию. Но инструменты вокруг него (vLLM, LiteLLM) уже сегодня позволяют строить системы, которые год назад были научной фантастикой.

Просто не верьте маркетингу. Тестируйте. Считайте токены. И помните: иногда 32К хорошо подобранных токенов работают лучше, чем 1М случайных.