Triton ensemble: как проверить связку tokenizer, inference и postprocessing

Triton ensemble нужно проверять как граф передачи tensors между preprocessing, inference и postprocessing. Ошибка tokenizer output может выглядеть как ошибка модели, если имена или формы не совпадают на границе. Сначала зафиксируйте mappings и версии компонентов, затем тестируйте полный путь. Ensemble сам по себе не является дополнительной вычислительной моделью и не делает все стадии одним общим scheduler с одинаковыми настройками batch и concurrency.

Нарисуйте dataflow

Руководство ensemble models описывает шаги и отображение input/output tensors. Для каждого ребра укажите исходное имя, внутреннее имя и имя получателя. Одинаковый читаемый смысл не гарантирует одинаковые key. Если tokenizer выдает token IDs и lengths, backend должен получать именно предусмотренную пару. Не исправляйте ошибку переименованием public API модели: это другой уровень идентификации. Сохраните схему рядом с config, чтобы порядок обработки можно было проверить без чтения всей программы и предположений о неявных преобразованиях между стадиями.

Проверьте dtype и shape

Model configuration определяет типы и dimensions входов и выходов. На каждом соединении сравнивайте обе стороны, включая batch dimension. Данные могут быть корректны по содержанию, но непригодны по типу либо layout. Для строк и token tensors это особенно важно: внешнее текстовое представление не описывает внутреннюю структуру. Укажите, какие формы переменные и где применяется padding. Не позволяйте postprocessing случайно скрывать несоответствие, возвращая правдоподобный текст из неполного или неправильно сопоставленного результата модели.

Пример контракта трех стадий

Для учебного pipeline создайте таблицу tokenizer, inference и detokenizer с входами, выходами и model versions. Добавьте короткий текст, ожидаемые token IDs на первой границе и форму результата на второй. Это диагностический fixture, не измерение качества LLM. Проверьте каждую стадию отдельно, затем весь ensemble. Если изолированные части проходят, а связка нет, исследуйте mappings и request metadata. Такая развилка сокращает поиск, не заставляя переустанавливать все компоненты после первой ошибки общего endpoint.

Учитывайте независимое scheduling

Внутренние модели могут иметь собственные batchers и instance settings. Ensemble управляет dataflow, но его наличие не доказывает одинаковую конкурентность всех стадий. Если tokenizer или postprocessing образует очередь, увеличение GPU instances не обязано помочь. Сохраните количество экземпляров и наблюдения по каждому шагу. При version mapping на latest проверьте, не изменился ли один компонент отдельно от остальных. Несогласованный релиз tokenizer и inference способен нарушить контракт, хотя обе модели по отдельности показывают ready и успешно проходят свои сетевые health проверки.

Приемка согласованного pipeline

В пакет включите ensemble config, configs компонентов, явные версии и промежуточные fixtures. Отдельно проверьте неверный dtype, отсутствующий tensor и отказ внутреннего шага, чтобы общий клиент получал понятный результат. Не обещайте атомарного обновления всего графа только по факту замены одного каталога repository. Согласуйте процедуру reload с model control mode. Полезный итог показывает, кто создает каждый tensor, кто его читает и какая версия обеспечивает контракт. После любого изменения повторите границы и end-to-end запрос. Это позволяет локализовать ошибку до конкретного ребра или стадии, а не сводить все случаи к общей «несовместимости tokenizer» и не выводить пропускную способность полного pipeline исключительно из benchmark самой GPU модели.

Связанные материалы

Гибридная CPU/GPU-архитектура: как разделить AI-сервис по задачам; Воспроизводимый стек инференса: как сохранить результат GPU-пилота.