Hugging Face опубликовал разбор того, как оценивать стоимость массового инференса энкодерных моделей. Материал рассчитан на сценарии, где через систему проходят более 1 млрд запросов в сутки: классификация документов, фильтрация писем, детекция токсичности и построение эмбеддингов для RAG.
Автор публикации — инженер, выступающий под ником datavistics. Он рассматривает задачу не как выбор «самой быстрой» модели, а как поиск конфигурации с приемлемым соотношением стоимости, пропускной способности и задержки. В качестве масштаба приводится сравнение: 1 млрд классификаций сопоставим с обработкой английской Википедии примерно 144 раза.
Почему стандартные настройки быстро становятся дорогими
Энкодерные модели обычно компактнее современных больших языковых моделей. Однако при миллиарде вызовов в сутки даже небольшая разница в производительности одного GPU заметно влияет на итоговый счёт за облачную инфраструктуру.
Поэтому автор предлагает сначала получить базовые показатели для одной GPU-конфигурации, а затем масштабировать систему горизонтально — добавлением реплик. Такой подход позволяет отделить две задачи: оптимизацию отдельного экземпляра и расчёт необходимого количества экземпляров для заданного потока запросов.
Универсального результата для всех моделей при этом нет. На итоговую стоимость влияют длина входных данных, размер батча, тип задачи, используемое оборудование и требования к задержке. Показатели из публикации нельзя напрямую переносить на другой датасет или другой облачный тариф без повторного тестирования.
Из чего состоит предложенная методика
В экспериментальном контуре используются четыре компонента:
- Hugging Face Inference Endpoints — для запуска моделей на выбранном оборудовании;
- библиотека Hugging Face Hub — для программного развёртывания;
- Infinity — сервер инференса для энкодерных и мультимодальных моделей;
- k6 от Grafana — инструмент генерации нагрузки.
Автор отмечает, что Inference Endpoints в данном случае выступают лишь удобной площадкой для сравнения аппаратных конфигураций. Ту же логику можно применить к собственным GPU или инфраструктуре другого провайдера.
Для сервера инференса выбран Infinity. В публикации отдельно упоминаются его поддержка оборудования AMD, Nvidia, CPU и Inferentia, а также работа с моделями, использующими remote code и ещё не интегрированными в Transformers. При этом материал не является сравнительным тестом Infinity и TEI: TEI упоминается как возможная альтернатива, но отдельного сопоставления результатов автор не проводит.
Как устроены нагрузочные тесты
Для каждого сценария меняются два ключевых параметра — размер батча и количество предварительно выделенных виртуальных пользователей. Батч определяет, сколько запросов обрабатывается совместно, а VU помогают поддерживать достаточную загрузку сервера во время теста.
В базовом варианте используется исполнитель k6 shared-iterations: тест отправляет 10 000 запросов и ограничен одной минутой. Если система не успевает обработать весь объём за это время, эксперимент завершается по тайм-ауту. Для мультимодальных эмбеддингов применяется меньший объём запросов, поскольку изображения тяжелее текстовых входов, а скорость обработки ниже.
Автор собирает несколько групп показателей:
- среднюю задержку и P95 — время, за которое завершается 95% запросов;
- throughput, то есть пропускную способность;
- число успешно обработанных запросов;
- проверку формата ответа;
- accuracy для задач классификации;
- длительность эксперимента.
Такой набор нужен, чтобы не принять высокий throughput за успешную оптимизацию. Конфигурация может обрабатывать больше запросов в секунду, но при этом чаще завершаться с ошибками, нарушать формат ответа или давать неприемлемую задержку.
Три сценария: классификация, текстовые и мультимодальные эмбеддинги
В блоге разбираются три типа нагрузки. Первый — текстовая классификация. Среди возможных применений названы фильтрация электронной почты и проверка наборов данных на токсичный контент. Для таких моделей важна не только скорость, но и сохранение качества классификации после выбора конкретной конфигурации.
Второй сценарий — создание текстовых эмбеддингов для систем поиска и RAG. Здесь вместо accuracy обычно важнее пропускная способность, стабильность задержки и стоимость обработки большого корпуса.
Третий сценарий — мультимодальные эмбеддинги, где система работает с изображениями и текстом. Такой тест выделен отдельно из-за более высокой нагрузки на передачу и обработку данных. Результаты для него нельзя механически сравнивать с текстовой классификацией: у задач разные входы, ограничения и целевая производительность.
В качестве класса моделей автор рассматривает распространённые энкодерные архитектуры, включая BERT, ModernBERT, RoBERTa, DeBERTa и XLM-RoBERTa. При этом классификационные модели требуют дообучения под конкретную задачу. Само наличие архитектуры в списке не означает, что готовая модель без дополнительной настройки будет пригодна для нужного набора данных.
Что можно проверить до расчёта бюджета
Главный практический результат публикации — не фиксированная цена миллиарда запросов, а процедура, которую можно повторить на своей инфраструктуре. Код и три ноутбука для экспериментов размещены в репозитории datavistics/encoder-analysis.
Перед запуском крупного пайплайна команде стоит проверить как минимум четыре параметра:
Как меняется throughput при увеличении батча.
В какой момент рост батча перестаёт давать прирост из-за ограничений пропускной способности памяти или вычислительных блоков GPU.
3. Как число VU влияет на загрузку оборудования и P95.
4. Сохраняется ли качество классификации при переходе на более дешёвую конфигурацию.
Отдельно нужно зафиксировать входные данные: среднюю длину текста, размер изображений, долю ошибок и допустимую задержку. Без этого сравнение стоимости будет условным. Например, результат для коротких сообщений нельзя считать оценкой для длинных документов, даже если используется та же модель.
Документация по используемому нагрузочному сценарию доступна в материалах Grafana k6 о shared-iterations. Дополнительную проверку стоит провести на том сервере инференса, который планируется использовать в эксплуатации: результаты для Infinity не следует автоматически считать результатами для TEI или другого сервера.
Методика Hugging Face полезна прежде всего как основа для собственного измерения. Публикация показывает, какие показатели собирать и почему настройки по умолчанию могут быть невыгодны, но не заменяет расчёт для конкретной модели, оборудования, тарифа и набора данных. Полный разбор опубликован в блоге Hugging Face.