Гайд · TNWS AI

Как группировать запросы к ML-модели через batch=True в Gradio Interface

4 мин—

Сверяем сигнатуру пакетной функции, tuple of lists и max_batch_size на детерминированном тесте.

Задача и применимость

Русскоязычный вопрос: «как включить пакетную обработку gradio interface batch для нейросети». Для gr.Interface и модели, которая действительно поддерживает пакетный инференс; здесь использован быстрый детерминированный обработчик строк вместо весов. Документация Interface и руководство по производительности сверены 20 сентября 2026 года. Экономию GPU и пропускную способность надо измерять на своём оборудовании.

Что подтверждено производителем

При batch=True Gradio передаёт каждому параметру список входов одинаковой длины не больше max_batch_size. Функция должна возвращать кортеж списков даже при единственном выходном компоненте. Пакетирование относится к запросам в очереди; max_batch_size по умолчанию документирован как 4.

Порядок действий

  1. Напишите пакетную функцию, принимающую список строк и возвращающую кортеж из одного списка.
  2. Проверьте её напрямую на двух значениях до запуска UI.
  3. Создайте Interface(batch=True,max_batch_size=4) и включите очередь.
  4. Отправьте несколько запросов из разных вкладок близко по времени.
  5. Сравните throughput и p95 с одиночной функцией на реальной модели.

Готовый шаблон

Сохраните пример в отдельном файле Python. В коде нет реального секрета или скрытого вызова модели: если подключён внешний API, его адрес и параметры указаны явно. Установите gradio в отдельном окружении; дополнительные пакеты требуются только там, где они импортированы в примере.

import gradio as gr

def batch_label(texts):
    labels = ["СРОК" if "дней" in t.lower() else "ДРУГОЕ"
              for t in texts]
    return (labels,)

assert batch_label(["Возврат 14 дней", "Доставка завтра"]) == (
    ["СРОК", "ДРУГОЕ"],)

demo = gr.Interface(batch_label, inputs=gr.Textbox(),
    outputs=gr.Textbox(), batch=True, max_batch_size=4,
    title="Пакетный контракт")
demo.queue().launch(server_name="127.0.0.1")

Вход и ожидаемый результат

Список входов [«Возврат 14 дней», «Доставка завтра»] должен дать кортеж с одним списком [«СРОК», «ДРУГОЕ»]. В самом UI каждый пользователь вводит отдельную строку; очередь может объединить заявки в пакет, но это зависит от одновременной нагрузки. Не обещайте, что два ручных последовательных клика обязательно попадут в один batch.

Проверка контракта

Ускорение зависит от природы модели. GPU-инференс нескольких коротких входов может лучше использовать устройство, чем отдельные вызовы, но при длинных текстах возрастает расход памяти и задержка медленной заявки внутри общего пакета. Запустите контроль на входах разной длины и сравните p50/p95 и число завершённых запросов за минуту. Если максимальный пакет приводит к OOM, уменьшайте max_batch_size; настройка по умолчанию — не рекомендация для конкретного checkpoint.

Работа с данными пользователя

Порядок результатов должен совпадать с порядком входных строк. Нельзя пересортировать embeddings или метки, а затем раздать их исходным пользователям по прежним индексам. В тесте кроме текста добавьте уникальные искусственные ID и проверьте сопоставление после возврата. Для многоарендного сервиса не используйте пакет как разрешение смешивать данные клиентов: сама обработка на GPU не должна открывать каждому чужие результаты.

Что проверить перед развёртыванием

Ошибка формы ответа часто маскируется: разработчик возвращает простой список labels вместо (labels,), и Gradio не может сопоставить его с ожидаемыми выходными компонентами. Проверка прямого вызова выше ловит этот случай без GPU. При нескольких выходах возвращайте столько списков в кортеже, сколько выходных компонентов объявлено. Пакетирование не заменяет контролируемую очередь, дедлайны и валидатор размера каждого входа.

Шаблон тестового корпуса для будущего классификатора: «Возврат 14 дней» → СРОК; «Доставка завтра» → ДРУГОЕ; «Вернуть в течение семи дней» → СРОК после подключения модели, понимающей смысл. Текущий учебный обработчик распознаёт лишь буквальное «дней», поэтому третий тест намеренно выявит его ограничение. Не представляйте эту логику как нейросетевое понимание русского языка.

Если функция распознаёт документы с разным временем обработки, группировка может увеличить ожидание коротких документов. Решайте вопрос по продуктовой цели: throughput сервера против индивидуальной задержки. Для приёмки представьте не только среднюю скорость, но и разброс p95, частоту ошибок и объём памяти на коротких и длинных входах. При обновлении GPU-драйвера либо самой модели повторите измерение; старое число не переносится автоматически. Документируйте и число фактически сформированных пакетов: конфигурация batch=True без одновременной нагрузки не доказывает, что пакетирование вообще произошло.

Критерии приёмки

  1. Прямой тест возвращает кортеж списков правильной длины.
  2. Ответы сохраняют порядок входов.
  3. Для реальной модели измерены throughput и память.

Типичные ошибки и чего не делать

  • Не возвращать плоский список при одном output.
  • Не рассчитывать на пакетирование последовательных кликов.
  • Не повышать размер пакета без замера памяти.

FAQ

Какой вход получает функция?

Список значений для каждого параметра.

Какой выход нужен при одном поле?

Кортеж, содержащий один список.

Всегда ли batch ускоряет?

Нет, зависит от модели, входов и памяти.

Официальные источники

Частые вопросы

Какой вход получает функция?

Список значений для каждого параметра.

Какой выход нужен при одном поле?

Кортеж, содержащий один список.

Всегда ли batch ускоряет?

Нет, зависит от модели, входов и памяти.

Читайте также

Комментарии

Пока тихо. Скажите первое слово