Для LLM-инференса вблизи пользователя редко есть готовые «тяжёлые» серверы. Обычно это mix из Edge-устройств, шлюзов и fog-нод с разным объёмом памяти и вычислительной мощностью. Разворачивать модель так, будто она всегда умещается на одном устройстве, значит закрывать глаза на реальность: модель либо не влезает, либо работает с неприемлемыми задержками, либо простаивает дорогие ресурсы. Фреймворк E2LLM предлагает для этого более прагматичный путь.
Почему классический сценарий не подходит
Традиционные подходы к обслуживанию LLM часто исходят из того, что вся модель живёт на одной машине. В облаке это обычно работает, но в Edge/Fog-среде узлы слабее и разнороднее. Часть устройств может иметь достаточно памяти для весов, но не тянуть вычисления; другие — наоборот, быстрые, но с ограниченным объёмом. Если пытаться просто «раскидать» модель по всем доступным устройствам, начинаются проблемы с координацией, связью и утилизацией.
При этом на практике нужны три вещи одновременно:
- предсказуемая низкая задержка,
- экономное использование ресурсов,
- разумная стоимость развёртывания.
Они конфликтуют между собой, поэтому нужен компромисс, а не однобокая оптимизация. E2LLM строится вокруг этого компромисса.
Реплики и роли: как E2LLM обходит ограничения
Ключевая идея E2LLM — не дробить одну модель между всеми узлами, а собирать устройства в реплики. Внутри каждой реплики хранится полная копия модели, а уже затем она распределяется по участникам группы с помощью модельного параллелизма. Звучит как лишняя трата памяти, но на деле такое дублирование повышает отказоустойчивость и позволяет обслуживать несколько запросов параллельно.
Дальше вступает в дело знание об устройстве LLM-инференса. У него две фазы с разными профилями нагрузки: prefill, когда модель активно обрабатывает входные токены и строит кэш внимания, и decode, когда она генерирует выходные токены. Для этих фаз нужны разные ресурсы: prefill чувствителен к пиковой вычислительной мощности, decode — к пропускной способности памяти и латентности передачи данных.
Вместо того чтобы заставлять каждую группу делать и то и другое, E2LLM назначает репликам специализированные роли. Одни становятся prefill-репликами и быстрее обрабатывают входящие запросы, другие — decoder-репликами и отвечают за плавную генерацию. Такое разделение позволяет не тратить ресурсы на «неудобную» для конкретного железа фазу.
Как формируются группы устройств
Просто взять первые попавшиеся устройства и назвать их репликой нельзя. E2LLM сначала решает, какие узлы вообще стоит объединять. Для этого используется генетический алгоритм: он перебирает варианты кластеров и постепенно улучшает их, ориентируясь на итоговую производительность системы.
Когда кластер определён, внутри него нужно понять, как именно разрезать модель между участниками. Здесь уже работает динамическое программирование: оно ищет такую стратегию разбиения, при которой «узкие места» при передаче данных между устройствами минимальны. Иными словами, верхний уровень занимается подбором состава реплик, а нижний — оптимальной нарезкой модели под конкретный состав железа.
Что это даёт на практике
Авторы проверили подход в сравнении с базовым решением Splitwise, которое тоже разделяет prefill и decode, но менее гибко работает с разнородными средами. Эксперименты показали, что E2LLM хорошо адаптируется к изменениям рабочей нагрузки. Особенно это заметно, когда длины входных и выходных токенов сильно различаются: например, приходят короткие запросы, но требуются длинные ответы, а затем нагрузка резко меняется.
При высокой нагрузке новый подход снижает среднее время ожидания более чем на 50% по сравнению со Splitwise. Это значит, что пользователи реже стоят в очереди к генерации, а сами Edge/Fog-устройства работают более осмысленно, а не пытаются одинаково обслуживать обе фазы инференса.
Итог
E2LLM показывает, что для эффективного запуска LLM на периферии важна не только мощность отдельного устройства, но и то, как устройства объединены и распределены по ролям. Дублирование полной модели на уровне реплик в сочетании с разделением prefill и decode — это осознанный trade-off: где-то приходится жертвовать памятью, но взамен система получает стабильную производительность и меньшие задержки.
Главный вывод для прикладных сценариев: в разнородной среде не нужно пытаться втиснуть всю модель в один узел или равномерно размазать её по всем. Нужно собирать из доступного железа специализированные группы и уже внутри них решать, как распределить вычисления. Именно так LLM-инференс становится по-настоящему практичным за пределами больших облачных кластеров.
