Когда 512k токенов — это не хвастовство, а боль: как правильно бенчмаркать длинные контексты LLM

Зачем вообще это нужно? (Спойлер: не для хвастовства)

Каждый месяц появляется новая модель, которая "поддерживает 512k контекст". Разработчики хлопают в ладоши, маркетологи пишут пресс-релизы, а вы запускаете её на своих данных — и получаете ответы уровня семиклассника, который не читал задание.

Проблема в том, что "поддерживать длинный контекст" и "эффективно работать с ним" — это разные вещи. Модель может технически проглотить 500 тысяч токенов, но вспомнить факт из первых 50 тысяч уже не сможет. Или начнёт путать имена. Или просто замедлится до 1 токена в секунду.

Что ломается при длинных контекстах? (Всё)

Давайте сразу к сути. Когда вы насильно пихаете в LLM 200 тысяч токенов, происходит три катастрофы:

• Деградация внимания — модель забывает начало. В архитектуре attention есть ограничения, и даже с clever positional encoding информация из первых 10% контекста растворяется.
• Артефакты генерации — модель начинает повторять фразы, зацикливаться, генерировать бессмыслицу после определённой точки.
• Падение производительности — не только по времени, но и по потреблению памяти. Ваш GPU с 24 ГБ VRAM может просто сдаться на 300k токенах.

И самое неприятное: стандартные бенчмарки вроде MMLU или HellaSwag здесь бесполезны. Они тестируют знание, а не способность работать с длинным контекстом.

Инструменты: от простого к сложному

lm-eval — базовый, но с приколами

Да, это стандарт. Но не тот, который вы думаете. lm-eval от EleutherAI хорош для коротких контекстов, но для длинных нужно танцевать с бубном.

# Установка — стандартная
pip install lm-eval

# Но для длинных контекстов нужно больше памяти
export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512

Основная проблема lm-eval — он не умеет измерять позиционную точность. То есть, насколько хорошо модель помнит информацию из начала, середины и конца контекста. Придётся дописывать свои метрики.

Runer-QA-Hotpot — специалист по длинным QA

Этот датасет специально создан для тестирования длинных контекстов. Суть: вам дают несколько документов (до 20), перемешанных в случайном порядке, и вопрос, ответ на который требует синтеза информации из разных частей.

Проблема в том, что оригинальный Runer-QA-Hotpot рассчитан на ~128k токенов. Для тестирования 512k нужно либо генерировать свои датасеты, либо использовать расширенные версии вроде LongBench.

LongBench и аналоги — промышленные решения

Если вам нужно протестировать действительно длинные контексты (от 256k), смотрите в сторону:

• LongBench — набор из 10+ задач специально для длинных контекстов
• L-Eval — фокусируется на реальных сценариях (длинные документы, код)
• SCROLLS — для задач summarization и QA на длинных текстах

У всех есть общая проблема: они требуют тонны вычислительных ресурсов. Запуск на одной карте может занять сутки.

Методика: как не обмануть себя

1Начните с реалистичных объёмов

Не гонитесь за 512k, если ваше приложение работает с 50k. Тестируйте с запасом: если нужно 50k, тестируйте на 100k. Это покажет, где модель начинает ломаться.

# Пример: тестируем на разных длинах контекста
context_lengths = [32_000, 64_000, 128_000, 256_000, 512_000]
# Для каждой длины создаём свой тестовый датасет
# И измеряем accuracy на QA задачах

2Измеряйте позиционную точность

Это самый важный метрик. Создайте тест, где ответ нужно найти:

• В первых 10% контекста
• В середине
• В последних 10%
• Распределённый по всему контексту

Сравните accuracy для каждой позиции. Если для начала контекста точность 85%, а для конца — 45%, у вас проблема.

3Тестируйте скорость и память

Токенов в секунду — это хорошо. Но что с латентностью первого токена? А с пиковым потреблением VRAM?

import torch
import time

# Измеряем время первого токена
start = time.time()
first_token = model.generate(input_ids, max_new_tokens=1)
first_token_latency = time.time() - start

# Измеряем пиковую память
peak_memory = torch.cuda.max_memory_allocated() / 1024**3  # в ГБ

Для production критична не только скорость генерации, но и то, сколько времени модель "думает" перед ответом.

4Добавьте шум и distractors

Реальный контекст — это не чистый текст. Это смесь релевантной информации, шума, повторов, противоречий. Добавьте в тестовые данные:

• Повторяющиеся абзацы
• Противоречивую информацию
• Не относящиеся к делу факты
• Опечатки и formatting errors

Хорошая модель должна фильтровать шум. Плохая — начнёт цитировать distractors или запутается в противоречиях.

Практический пример: тестируем модель на 256k

Допустим, у нас есть модель, которая заявлена как "поддерживающая 256k контекст". Вот наш план атаки:

# 1. Готовим датасет
import datasets
from lm_eval import tasks

# Берём LongBench или создаём свой
# Для каждой длины контекста (64k, 128k, 256k) создаём подвыборку

# 2. Запускаем lm-eval с кастомными метриками
evaluator = lm_eval.evaluator.Evaluator(
    tasks=["longbench_qasper", "longbench_multifieldqa_en"],
    model_args="pretrained=our-model",
    position_accuracy=True  # наша кастомная метрика
)

# 3. Измеряем производительность
results = evaluator.evaluate(
    max_length=256_000,
    batch_size=1,  # для длинных контекстов batch_size обычно 1
    device="cuda:0"
)

Ключевые метрики, которые мы собираем:

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

Что делать, если ресурсов мало?

Не у всех есть кластер из A100. Но бенчмаркать всё равно нужно. Ваши варианты:

• Тестируйте на подвыборках — возьмите не весь датасет, а 10-20 примеров для каждой длины контекста. Это даст приблизительную картину.
• Используйте квантование — запускайте модель в 4-bit или 8-bit режиме. Точность упадёт, но относительная разница между моделями сохранится.
• Фокусируйтесь на критичных метриках — определите, что важно именно для вашего случая. Если latency критична — измеряйте только её и positional accuracy.

Кстати, если вы работаете на старом железе, у меня есть гайд по запуску LLM на старом железе — там есть трюки и для бенчмаркинга.

Специальный случай: MoE-модели

MoE (Mixture of Experts) архитектуры вроде Granite 4 Small ведут себя с длинными контекстами особенно интересно. Они могут:

• Активировать разных экспертов для разных частей контекста
• Иметь проблемы с consistency между экспертами
• Показывать нелинейную деградацию качества

При бенчмаркинге MoE обязательно тестируйте:

# 1. Как часто переключаются эксперты
expert_switches = count_expert_changes(model, long_context)

# 2. Не противоречат ли друг другу разные эксперты
consistency_score = check_expert_agreement(model, context_with_contradictions)

# 3. Распределяется ли нагрузка равномерно
load_balance = calculate_expert_load_balance(model, long_context)

Финальный совет: бенчмарк — это не соревнование

Не гонитесь за максимальными цифрами. Модель с accuracy 75% на 512k может быть лучше для production, чем модель с 85% на 256k, если:

• Она стабильнее (меньше variance между запусками)
• Потребляет меньше памяти
• Имеет предсказуемую latency
• Не "сходит с ума" на edge cases

Создайте свой чеклист требований. Приоритезируйте метрики. И тестируйте на данных, максимально близких к реальным. Потому что в production вас не спасут красивые цифры из бенчмарка — спасёт только стабильная работа.

И последнее: не верьте маркетингу. "Поддерживает 512k" часто значит "технически может принять 512k токенов на вход, но что будет на выходе — большой вопрос". Проверяйте. Тестируйте. Сомневайтесь. Ваш production от этого только выиграет.