В этом материале
Проверяйте сумму входа и выхода, фактическую токенизацию и параллельность, а не размер текстового файла.
Если LLM загружается и отвечает на короткий вопрос, но выдаёт CUDA out of memory на длинном документе, проверьте память контекста и временные буферы обработки входа. Размер весов при этом обычно не меняется. Проверять следует число токенов после шаблона диалога, резерв ответа и количество одновременно выполняемых запросов.
Измерьте вход после токенизации
Длина файла в килобайтах не равна числу токенов. Код, кириллица, таблицы и служебные сообщения разбиваются по-разному. Шаблон чата добавляет собственные элементы, а история переписки увеличивает каждый следующий запрос. Используйте токенизатор именно выбранной модели и сохраните получившееся число рядом с примером.
Для проверки подготовьте три обезличенных документа одной структуры, но разной длины. Не сравнивайте короткий русский абзац с длинным английским кодом: одновременно изменятся слишком многие свойства нагрузки. Так проще определить, действительно ли проблема следует за размером входа.
Оставьте место для генерируемого ответа
Лимит контекста обычно включает вход и выход. Например, при выбранной границе 8192 токена запрос с входом 7600 и разрешённым ответом 1200 требует отдельного пересмотра. Это арифметический пример, а не характеристика конкретной модели или обещание, что такая граница поместится на вашей карте.
Приложение может отклонить превышение лимита до вычислений; это отличается от CUDA OOM во время выполнения. В первом случае исправляют бюджет запроса, во втором изучают фактическую память. Подробности настройки приведены в руководстве max-model-len.
Разделите кеш и обработку длинного входа
KV-кеш сохраняет промежуточные данные внимания. Его объём зависит от архитектуры, точности, числа последовательностей и токенов. Дополнительно обработка длинного входа создаёт рабочую нагрузку prefill; кратковременный пик способен отличаться от расхода при последовательной генерации.
Поэтому тест должен фиксировать фазу ошибки. Если сбой возникает до первого токена, отдельно рассмотрите обработку входа. Если после длинного ответа — рост накопленного контекста. Отличия фаз объясняет статья prefill и decode, а способы ограничения ресурсов — официальная оптимизация vLLM.
Найдите рабочую границу последовательным тестом
Запустите один запрос с небольшим выходом, затем увеличивайте только вход. После каждого успешного уровня повторите проверку несколько раз. Далее оставьте вход постоянным и увеличьте выход. Последним отдельным этапом добавьте параллельные обращения: успешный одиночный тест не доказывает вместимость нескольких сессий.
В журнал заносите число входных и выходных токенов, пиковую VRAM, время до первого токена и причину остановки. Указывайте, использовался ли прогретый префикс. Одинаковый длинный текст может повторно обрабатываться иначе из-за кеширования, поэтому нужны также независимые документы.
Полезно сохранить также окончательную причину остановки ответа. Достижение заданного предела выхода отличается от нормального завершения, и эти случаи нельзя одинаково учитывать при проверке полезности длинного контекста.
Выберите ограничение, полезное пользователю оборудования
Иногда разумнее принять короткие документы и стабильную очередь, чем рекламировать максимально длинный контекст. В другом сценарии нужен более ёмкий GPU или поддерживаемое изменение точности кеша. Разницу между хранением весов и кешем описывает руководство Transformers.
Для владельца результатом становится конкретный профиль: модель, проверенный вход, резерв ответа, допустимое число сессий. Для обсуждения финансирования важна связь дополнительной памяти с реальной длиной документов.