Moore Threads представила Prefill-as-a-Service: prefill и decode предлагается развести по разным пулам оборудования, чтобы не оплачивать универсальность, которой обе фазы инференса не могут воспользоваться одновременно. Схема выглядит разумно для агентов, генерации кода и анализа длинных документов, но её ценность определит не архитектурная красота, а экономика на реальных запросах.
Что предлагает Moore Threads
Как пишет IT Home, 24 августа Moore Threads выпустила технический документ о Prefill-as-a-Service на базе флагманской карты MTT S5000. Компания адресует подход сценариям с длинным контекстом: AI-агентам, генерации кода и анализу сверхдлинных документов.
Отправная точка документа проста. По мере роста входного контекста до сотен K и 1M увеличиваются вычислительная нагрузка и задержка до первого токена. Moore Threads считает это ограничением для эффективности корпоративного инференса и совокупной стоимости владения инфраструктурой.
Проблема, по версии компании, находится в устройстве самого инференса. Prefill является вычислительно интенсивной фазой и упирается в производительность операций с плавающей точкой. Decode сильнее зависит от доступа к памяти и пропускной способности видеопамяти. Если выполнять обе фазы в одном однородном пуле, часть ресурсов неизбежно простаивает.
При выборе оборудования под decode ёмкая память недостаточно эффективно используется во время prefill. При выборе под prefill вычислительные блоки простаивают во время decode. Поэтому Moore Threads предлагает полностью разделить фазы: пул prefill оптимизировать под высокую загрузку вычислительных мощностей и низкую задержку до первого токена, пул decode под высокую конкурентность запросов и стабильную задержку на токен.
Компания утверждает, что такое распределение оборудования позволяет снизить инфраструктурную стоимость токена при соблюдении требований к качеству сервиса. В сообщении IT Home, однако, нет абсолютных показателей стоимости, профилей запросов или результатов на нагрузках сторонних команд. Поэтому перед нами пока тезис об экономике, а не воспроизводимое доказательство.
Покупать нужно не карту, а разделение счетов
Для оператора AI-сервиса главное в анонсе не MTT S5000. Главное, что привычная метрика общей загрузки GPU может скрывать два разных вида неэффективности. Средняя загрузка выглядит прилично, пока не разделишь трассировку на prefill и decode и не увидишь, какие ресурсы простаивают на каждой фазе.
Отсюда практический вывод: длинный запрос стоит считать не как единый прогон модели, а как минимум как две инфраструктурные операции. Отдельно нужны стоимость и задержка prefill, отдельно стоимость и задержка decode. Иначе команда рискует оптимизировать среднюю температуру по кластеру, а затем удивляться счёту.
Разделение пулов особенно убедительно выглядит там, где вход велик, а выход относительно предсказуем. Но это уже гипотеза, которую каждой команде придётся проверять на собственном распределении запросов. Чем сильнее меняются длина контекста, объём генерации и требования к задержке, тем меньше пользы от усреднённого рекламного результата.
Поэтому Prefill-as-a-Service стоит воспринимать как предложение изменить единицу планирования инфраструктуры. Не «сколько GPU нужно модели», а «какой пул нужен каждому этапу». Если такой расчёт сходится, бизнесу не придётся покупать одинаковые ускорители для всего цикла инференса. Если нет, раздельные пулы останутся более сложным способом получить тот же счёт.
Что проверять дальше
Первый маркер жизнеспособности схемы конкретен: сторонняя нагрузка должна показать снижение стоимости токена при тех же ограничениях на задержку до первого токена и задержку каждого следующего токена. В расчёт должна попасть загрузка обоих пулов.
Пока этих данных нет, Moore Threads доказала структурную проблему однородного кластера, но не универсальность своего решения. Инфраструктурным командам сейчас полезнее не ждать консенсуса, а прогнать собственные трассировки через раздельную модель затрат. Именно там выяснится, является ли длинный контекст отдельным сервисом или просто ещё одной дорогой очередью на тех же GPU.