ainews
Почему бенчмарки LLM-инференса врут вам в глаза
Синтетические бенчмарки LLM-фреймворков (с фиксированными промптами и ровной нагрузкой) плохо предсказывают реальную производительность. В продакшене трафик неравномерный, промпты разной длины, и «победитель» рейтинга может проседать под реальной нагрузкой. Статья объясняет, как правильно выбирать фреймворк для инференса, не полагаясь только на tokens/sec в таблице лидеров.
Если выбираешь фреймворк для инференса LLM по цифрам из бенчмарков, рискуешь получить неожиданно низкую производительность в продакшене и потратить время на миграцию. Статья даёт практический фреймворк для оценки, который экономит деньги и нервы.
Синтетика vs. реальность
Большинство сравнений фреймворков для инференса LLM начинается с лидерборда: один фреймворк показывает максимальные tokens/sec на стандартном бенчмарке — и это число тихо становится причиной его внедрения в компании.
Проблема в том, что условия чистого бенчмарка редко похожи на то, что модель видит в продакшене. Синтетические тесты обычно используют: - фиксированную длину промптов, - равномерный поток запросов, - одну модель на знакомом железе.
Реальный трафик не делает ничего из этого.
Почему «победитель» может проседать
В продакшене запросы приходят пачками и пустотами, длина промптов скачет, пользователи генерируют тексты разной сложности. Фреймворк, оптимизированный под стабильную синтетику, может не справляться с всплесками или тратить ресурсы впустую в паузах.
Три оси компромиссов, которые реально решают исход: 1. Пропускная способность vs. латентность — высокий throughput в бенчмарке может означать задержки для отдельных запросов. 2. Эффективность батчинга — как фреймворк группирует запросы разной длины. 3. Управление ресурсами — как он справляется с переменной нагрузкой (автоскейлинг, очереди, приоритезация).
Что делать
Статья предлагает практический процесс оценки: - тестировать на реалистичных распределениях запросов (длина, частота, всплески), - мерить не только среднее, но и перцентили латентности (p95, p99), - запускать нагрузочные тесты с переменным трафиком перед выбором.
Вывод: не доверяйте headline numbers. Выбирайте фреймворк, который ведёт себя предсказуемо под вашей реальной нагрузкой, а не под синтетикой.
Ключевые выводы
- Синтетические бенчмарки LLM (фиксированные промпты, ровная нагрузка) плохо предсказывают поведение в продакшене
- «Победитель» по tokens/sec может проседать под реальным трафиком из-за неравномерности запросов и длины промптов
- Три ключевых компромисса: throughput vs. латентность, эффективность батчинга, управление переменной нагрузкой
- Перед выбором фреймворка нужно тестировать на реалистичных распределениях запросов и мерить перцентили латентности, а не только среднее
- Headline numbers в лидербордах — плохой критерий выбора инфраструктуры для инференса
Автор: Павел Заславский · Источник: reddit.com
**Эта статья — антидот против «магии цифр».** Каждый, кто выбирал инфраструктуру для AI, знает соблазн ткнуть пальцем в топ лидерборда и на этом успокоиться. Автор объясняет, почему это ловушка: синтетика — это спортзал с идеальными условиями, продакшен — драка на улице. Неравномерный трафик, скачущая длина промптов, всплески нагрузки — всё это убивает красивые tokens/sec из таблички.
**Что ценно:** не просто критика, а конкретный чек-лист для оценки. Тестируй на реальных распределениях, меряй не среднее, а p95/p99, смотри, как фреймворк справляется со всплесками. Это особенно важно сейчас, когда рынок inference-фреймворков бурлит (vLLM, TensorRT-LLM, TGI) и каждый кричит о своих рекордах. Выбирай по поведению под *твоей* нагрузкой, а не по headline numbers — иначе через месяц будешь мигрировать и объяснять боссу, почему «самый быстрый» фреймворк тормозит.
Комментарии