⚡️ Prefill-as-a-Service предлагает пересобрать инференс
В статье (авторы Kimi.ai) разбирают, почему держать Prefill и Decode в одном процессе невыгодно, и как это разнести без потерь.
Любой ответ модели начинается с Prefill. Модель читает весь вход и строит внутреннее состояние. Дальше идёт Decode. Пошаговая генерация токенов.
Эти этапы ведут себя по-разному. Prefill короткий, но тяжёлый по вычислениям. Decode долгий и чувствительный к задержкам. Когда они сидят на одном GPU, часть ресурсов простаивает.
В статье предлагают вынести Prefill в отдельный сервис. Его можно крутить на других узлах или в другом дата-центре. Decode оставить ближе к пользователю, где важна задержка на токен.
Авторы упирались в KV cache. Он слишком большой, чтобы гонять его по сети без ощутимых накладных расходов. Но в статье показывают, что при оптимизации представления KV это становится практичным.
На практике это даёт более быстрый первый токен и лучший throughput. Появляется возможность подбирать железо под конкретный этап, а не под весь пайплайн сразу.
Инференс перестаёт быть привязанным к одному месту. Его можно разнести, как обычный сервис. И дальше оптимизировать уже не только модель, но и архитектуру вокруг неё.
Проверено на модели Kimi Linear, увеличенной в 20 раз:
• пропускная способность модели выросла в 1.54 раза
• P90 TTFT ниже на 64%.
• На выходе это напрямую конвертируется в более дешёвый токен.
https://arxiv.org/html/2604.15039v1
В статье (авторы Kimi.ai) разбирают, почему держать Prefill и Decode в одном процессе невыгодно, и как это разнести без потерь.
Любой ответ модели начинается с Prefill. Модель читает весь вход и строит внутреннее состояние. Дальше идёт Decode. Пошаговая генерация токенов.
Эти этапы ведут себя по-разному. Prefill короткий, но тяжёлый по вычислениям. Decode долгий и чувствительный к задержкам. Когда они сидят на одном GPU, часть ресурсов простаивает.
В статье предлагают вынести Prefill в отдельный сервис. Его можно крутить на других узлах или в другом дата-центре. Decode оставить ближе к пользователю, где важна задержка на токен.
Авторы упирались в KV cache. Он слишком большой, чтобы гонять его по сети без ощутимых накладных расходов. Но в статье показывают, что при оптимизации представления KV это становится практичным.
На практике это даёт более быстрый первый токен и лучший throughput. Появляется возможность подбирать железо под конкретный этап, а не под весь пайплайн сразу.
Инференс перестаёт быть привязанным к одному месту. Его можно разнести, как обычный сервис. И дальше оптимизировать уже не только модель, но и архитектуру вокруг неё.
Проверено на модели Kimi Linear, увеличенной в 20 раз:
• пропускная способность модели выросла в 1.54 раза
• P90 TTFT ниже на 64%.
• На выходе это напрямую конвертируется в более дешёвый токен.
https://arxiv.org/html/2604.15039v1