«Я рассматриваю это как точку на кривой Парето-оптимальности LLM в режиме, где существовал большой выявленный скрытый спрос (никаких размышлений, один токен, приемлемый интеллект с низкой задержкой), в который недостаточно инвестировали из-за гонки за более высоким интеллектом». — Карпати-сан, о Jev
В то время как все и каждый громко создают агентов для написания кода и чат-ботов, на бэкенде происходит более тихая революция в области вывода (inference). Простые преобразования данных с помощью LLM могут быть невероятно мощными, если соотношение цена-производительность достаточно хорошее — просто пролистайте социальные сети и посмотрите на несколько потрясающих, вдохновляющих демо-версий модели TypeSafe AI’ Jev.
Jev реализует эти преобразования на том, что можно назвать «JSON-слоем», — интерфейсах в веб-стиле между клиентами и сервисами.
AI-SQL реализует это на аналитическом SQL-слое, на стыке бизнес-аналитики и базы данных:
Различные приложения для вывода создают разные рабочие нагрузки, и AI-SQL не исключение. Запрос, подобный приведенному выше, может генерировать миллионы последовательностей из тысяч токенов — прощайте, ваш бюджет токенов. Эти запросы часто требуют гораздо меньшего интеллекта, чем передовые модели, поэтому небольшие модели с открытыми весами могут справиться с задачей. Но наивная подача этих последовательностей напрямую в движок вывода, оптимизированный для агентного вывода через интерфейсы для произвольных запросов, контролируемых пользователем, по своей сути является крайне неэффективной.
Поэтому мы создали движок вывода, чтобы исправить это: QUery-Aware Inference Layer (Quail). В одном запросе с множественными соединениями (multi-join), где планирование особенно важно, Quail достигает более миллиарда обработанных токенов в минуту на один GPU H100 (TPM/GPU), что более чем в 10 раз быстрее, чем наш базовый vLLM на том же оборудовании. На Modal это обходится менее чем в 6 центов за миллиард токенов.
В нашем недавно выпущенном бенчмарке для AI-SQL запросов Quail работает в 1,84 раза быстрее, чем vLLM, при геометрическом усреднении по задачам — включая два запроса, которые мы разработали, чтобы продемонстрировать области для будущего улучшения вывода в AI-SQL.
Вы можете попробовать это на Modal прямо сейчас:
В этом блоге мы дадим краткий обзор проблемы, которую мы решаем, и того, как работает Quail сегодня. Спойлер: главное преимущество заключается в том, что, имея на руках структурированный запрос, вы можете упорядочивать запросы для лучшего кэширования (и вытеснения) KV-кэша. Это требует небольшой доработки Hydragen-стиля каскадного внимания. Большое количество мелких запросов для небольших моделей также может привести к большим накладным расходам на хост, то есть к низкой загрузке GPU, чего можно избежать, если заранее знать структуру запросов.
Это была совместная работа исследователей вывода из Modal и исследователей баз данных из Full Stack Data Lab университета Карнеги-Меллона — назовите это «смесью экспертов» (mixture of experts). Мы делимся тем, что сделали, потому что хотели бы сделать эту работу более «экспертно-параллельной», если можно так выразиться. Мы считаем, что это только начало для инженерных решений по производительности с открытым исходным кодом на стыке вывода и баз данных — двух важнейших областей применения вычислений.
В этом посте мы сосредоточимся на соображениях для инженеров по выводу. Вы можете прочитать больше с точки зрения инженера баз данных в блоге Full Stack Data Lab. Вы также можете ознакомиться с кодом Quail или документацией here. И если вы запускаете AI-SQL запросы в масштабе и заинтересованы в повышении производительности и сокращении затрат, свяжитесь с нами.
Что такое AI-функции и AI-SQL?
Сначала немного предыстории о рабочей нагрузке.
Это решительно не промптинг AI-систем для создания SQL на основе ввода на естественном языке — это NL2SQL. Это очень похоже на традиционную рабочую нагрузку чат-бота или агента по написанию кода, поэтому существующие движки вывода работают хорошо.
На самом деле все наоборот! В AI-SQL мы используем расширение SQL для программного создания (и потребления) промптов для AI-систем. Промпты создаются из записей базы данных и формируют таблицы.
Например, вот так:
AI-SQL в основном используется внутри платформ бизнес-аналитики (BI), чтобы помочь специалистам по данным и заинтересованным сторонам задавать более «нечеткие» вопросы к своим полуструктурированным данным, таким как документы и поля со свободным текстом.
Стандарта пока нет, но крупные управляемые платформы аналитических баз данных имеют свои собственные варианты: Snowflake Cortex AI-SQL, Databricks AI Functions, BigQuery AI functions.
В отличие от остального SQL, эта задача действительно требует GPU.
Рассмотрим следующий план запроса к набору данных BioDEX, который выбирает отчеты о серьезных нежелательных явлениях в ответ на прием лекарств, включающих как неврологический, так и сердечно-сосудистый компоненты:
Если бы это были обычные фильтры и соединения, скажем, основанные на сопоставлении строк и логическом равенстве, не было бы веских причин использовать высокопроизводительный численный ускоритель, такой как GPU, даже несмотря на то, что это аналитический запрос, который кажется «пропускным». Возможно, для кого-то это очевидно, но давайте все равно разберем логику.
Каждый байт, загружаемый из постоянного хранилища в память (или из памяти в регистры), требует не более нескольких арифметических/логических операций для выполнения сравнений. GPU разработаны для рабочих нагрузок с высокой арифметической интенсивностью — множеством операций на загруженный байт. А новейшие GPU имеют большую часть своей арифметической пропускной способности в специализированном оборудовании для больших матричных умножений, то есть тензорных ядрах. Обычная фильтрация/соединение не требует больших матричных умножений.
Но этот план запроса использует AI_FILTER и AI_JOIN, которые вместо этого пропускают входные данные через большую языковую модель. LLM — это последовательность численных операций, узким местом для которых являются большие матричные умножения. Каждый байт, загруженный из постоянного хранилища, подвергнется порядку миллиардов операций, прежде чем байт будет записан в хранилище.
Почему это интересно инженерам по выводу?
Большая часть инженерных работ по выводу в наши дни сосредоточена на одной конкретной форме рабочей нагрузки: итеративном создании длинных входных последовательностей пользователями и вызовами инструментов, внешними по отношению к сервису вывода. Это форма рабочих нагрузок чат-ботов и агентов, а также «развертываемого» вывода во время запусков обучения с подкреплением, которые донастраивают модели, чтобы они стали чат-ботами или агентами.
Не поймите нас неправильно, это очень важная работа! Мы писали о нашем подходе к ней здесь. Но для хардкорного инженера по выводу это, честно говоря, начинает казаться немного… избитым.
Существует также работа над выводом с ультранизкой задержкой, где скорость важна не меньше, чем интеллект. Мы писали о наших методах для этого здесь. В целом, эти рабочие нагрузки используют структурированные выводы/вызовы инструментов. Они в конечном итоге становятся чем-то вроде «OLTP» вывода, легче встраиваясь в другие компьютерные приложения, чем агенты с открытым финалом. Недавняя популярность Jev демонстрирует важность этих рабочих нагрузок — и то, что мы все еще находимся на самом раннем этапе!
Рабочие нагрузки AI-SQL пока не получили большого внимания, но мы считаем их интересными для инженеров по выводу моделей (inference engineers) по ряду фундаментальных причин, выходящих далеко за рамки их важности для приложений. Самое любопытное, что они невероятно хорошо подходят для трансформеров (поскольку позволяют «идеально» использовать KV-кэш) и для трансформеров на GPU (поскольку не требуют декодирования).
Управляйте KV-кэшем без лишних сожалений.
При обычном выводе запросы контролируются клиентом и являются произвольными. Это доставляет массу проблем. Но при выводе AI-SQL клиенты управляют только SQL-запросами, которые создают множество подзапросов, а объединенный планировщик запросов и движок вывода имеют существенный контроль над обработкой этих запросов.
Это значительно упрощает работу кэша, который амортизирует больше работы. Например, мы точно знаем, когда запись в кэше больше не нужна, поэтому можем смело ее удалять. Мы также довольно много знаем о том, как будет выглядеть спрос на кэш, поскольку получаем все запросы плана выполнения целиком заранее.
И нам крайне необходимо кэширование для трансформеров, потому что их проходы вперед (forward passes) по своей сути квадратичны относительно длины последовательности. Мы можем заменить это на линейное время и линейное хранилище с помощью KV-кэширования.
KV-кэшами может быть сложно управлять для агентских рабочих нагрузок, потому что время между доступами совершенно неизвестно. Но для AI-SQL запроса мы контролируем запросы движка вывода и поэтому можем предвидеть будущие доступы и применять оптимизации, такие как предварительная выборка (prefetching). Более того, поскольку мы ориентированы на пропускную способность токенов, нас меньше волнует задержка при извлечении записей KV. Это делает, например, работу многоуровневого KV-кэша гораздо более осуществимой.
Смотри, мама, без декодирования!
Вывод моделей последовательностей делится на две фазы: «prefill» (предварительное заполнение), когда генерируется большая часть KV-кэша, и фаза «decode» (декодирование), когда генерируется большинство выходных токенов.
Декодирование — это своего рода боль. GPU не особенно хороши в этом. У декодирования низкая арифметическая интенсивность, поэтому, даже несмотря на то, что GPU обеспечивают большую пропускную способность памяти, сложно поддерживать насыщенность арифметической пропускной способности.
Агентские приложения сильно смещены в сторону декодирования — даже если входных токенов больше, чем выходных, декодирование настолько медленнее, что занимает большую часть времени. Эта проблема настолько серьезна, что развертывания сервисов вывода часто вынуждены использовать сложные решения, такие как дезагрегация prefill-decode между узлами, просто чтобы получить приемлемую производительность.
Но не все токены генерируются во время декодирования. Финальный проход «prefill» во время обработки входной последовательности выдает предсказание для одного токена.
А для логической классификации последовательности, также известной как AI.IF, одного токена — это буквально все, что вам нужно.
Это важно, потому что AI.IF — не второстепенная задача. Именно так реализованы соединения (joins) в AI-SQL (JOIN ON AI.IF). При небольшой изобретательности в построении промптов, AI.CLASSIFY также может быть отображен на один токен для количества классов вплоть до размера словаря (мы оставили это на будущее!).
В настоящее время мы не особо пользуемся этим, за исключением того, что мы не реализуем:
- Раздельные фазы prefill и decode (не говоря уже о дезагрегации), потому что нет декодирования
- Сэмплирование, потому что нет сгенерированных токенов, только вероятности
- Захват графов CUDA, потому что длительность prefill достаточно велика, чтобы накладные расходы на запуск были пренебрежимо малы, даже для небольших моделей на больших GPU
- Спекулятивное декодирование, потому что оно ускоряет декодирование более чем одного токена
Но мы предвидим более глубокие возможности для оптимизации вывода только с prefill!
Quail совместно оптимизирует SQL-запрос и рабочую нагрузку вывода.
Имея представление о структуре SQL-задачи и задачи вывода, давайте теперь быстро пройдемся по архитектуре Quail, сосредоточившись на планировщике запросов и движке выполнения.
Обзор архитектуры
Возможно, вы еще не заметили, но создавать базы данных сейчас легко (см. Stonebraker & Pavlo, 2024 или этот доклад об Apache DataFusion от Эндрю Лэмба). В частности, аналитические базы данных создавать гораздо проще, поскольку многие ключевые компоненты стандартизированы с помощью расширяемых реализаций с открытым исходным кодом. А компоновка компонентов с открытым исходным кодом теперь стала безумно простой благодаря агентам кодирования.
Ключевыми компонентами, в порядке от внешнего интерфейса до внутренних деталей реализации, являются SQL-парсер, планировщик запросов, движок выполнения и движок хранения.
- SQL-парсер. Мы используем the Python sqlglot library by @tobymao, который поддерживает диалекты snowflake и bigquery. AI-SQL обрабатывается через «анонимные» выражения, то есть передается планировщику запросов.
- Планировщик запросов. Эта часть в значительной степени является кастомной, так как это основная часть работы. Мы опишем ее ниже. Мы используем Substrait для сериализации планов запросов для бенчмаркинга.
- Движок выполнения. Мы сделали форк реализации vLLM для проходов моделей вперед, а затем изменили ядра, как описано ниже (в основном написав на Triton для получения слияния ядер). Мы еще не добавили полную поддержку выполнения SQL, но это довольно простое дополнение с помощью DataFusion.
- Движок хранения. Мы используем pyarrow для управления колоночным форматом Arrow. Это аналитическая рабочая нагрузка, которая записывается один раз и читается многократно, то есть «файловые системы в упрощенном режиме». Мы предполагаем, что данные заранее извлекаются из объектного хранилища, такого как S3, или распределенной файловой системы, такой как Modal Volumes.
Проектирование планировщика запросов для движка вывода
Планировщик запросов берет логический план, основанный на разборе SQL-запроса, и преобразует этот план — как между эквивалентными логическими планами, так и в «физические» планы с конкретными операциями. Пространство проектирования для планировщиков запросов огромно. В конце концов, они по сути являются компиляторами!
Но наш набор задач ограничен фильтрами и соединениями, и в рамках этого мы смогли в основном использовать хорошо известные методы. Мы используем проталкивание предикатов (predicate push-down) за соединения, упорядочивание фильтров на основе селективности в стиле Хеллерштейна и Стоунбрейкера, и упорядочивание соединений с помощью динамического программирования на глубоких деревьях, как в the classic 1976 System R paper. Это очень краткий обзор — больше подробностей о стороне баз данных в блоге Full Stack Data Lab !
Здесь мы кратко коснемся вкладов в вывод трансформеров/GPU-центричность в модели затрат и алгоритме упорядочивания соединений. В частности, Quail добавляет оценку «скорости света» (speed-of-light) в модель затрат и осведомленность о KV в поиск порядка соединений.
Поиск порядка соединений с учетом KV
Упорядочивание соединений классически основано на динамическом программировании «разделяй и властвуй». На высоком уровне: выберите оптимальный вариант на одном шаге, затем ищите оптимальный подплан с зафиксированным выбором.
Наш случай не так прост, как обычное упорядочивание соединений. Мы дополнительно отслеживаем состояние KV из предыдущих планов на случай, если то, что поначалу казалось плохим вариантом, окажется полезным для более позднего соединения, которое сможет повторно использовать свой KV.
Во время поиска мы поддерживаем несколько кандидатов. Мы исключаем планы только в том случае, если новый план-кандидат имеет меньше токенов, меньше пар внимания и меньше кэшированных токенов — он был «доминирован» в смысле Парето. Затем мы выбираем финальный план, применяя оценку затрат «скорости света», описанную ниже.
Упорядочивание соединений — это сложная задача! Мы ожидаем значительных улучшений в этой технике и будем рады поработать над ними вместе с вами.
Пессимистичная оценка скорости света
Как и в большинстве баз данных, наши аппаратные оценки стоимости довольно грубы. Мы используем «roofline-модель» Уильямса, Уотермана и Паттерсона для аппаратуры, ориентированной на пропускную способность, чтобы оценить «скорость света» на основе пиковых аппаратных показателей, что имеет свои ограничения (см. последний абзац в нашем глоссарии производительности GPU о «узких местах» производительности).
Но грубо — не значит неэффективно! Во-первых, модель SoL была критически важным инструментом для проверки работоспособности результатов во время итераций. Во-вторых, она скорее склонна к завышению пиковой производительности, чем к случайным пропускам или занижению. Сравните это с путеводной звездой: вы никогда не сможете достичь её, но она всё равно помогает вам двигаться на север.
Подробный код находится here, но модель стоимости выглядит примерно так:
Расчет основан только на подмножестве модулей, которые являются наиболее «узкими местами» для целевых рабочих нагрузок: проекции внимания для каждого токена, слои MLP/MoE и вычисления внимания между токенами.
В принципе, это должно делаться один раз для каждой модели, но на практике модели используют много общих операторов. Мы обнаружили, что современные агенты кодирования довольно хорошо справляются с чтением конфигурации Hugging Face и созданием разумной модели стоимости в этой настройке — хотя их вывод часто требует проверки на «ощущения». Для другого применения моделирования стоимости на основе roofline-SoL см. наш оценщик ускорения спекулятивного декодирования.
Механизм вывода как механизм выполнения
После того как выбран окончательный физический план, он должен быть реализован механизмом выполнения.
Но прежде чем слишком много думать о стороне GPU, важно убрать с пути CPU. Любой, кто работал с высокопроизводительными хранилищами или сетями, знаком с основными принципами здесь.
В данном случае у нас много последовательностей (миллионы) и небольшая модель (миллиарды параметров) на большом GPU (H100), что выходит за рамки проектного пространства для большинства бэкендов токенизаторов. Мы использовали Gigatoken от нашего друга Марселя Рода из Стэнфорда. Примечание: эта работа происходит в планировщике запросов, но затем повторно используется во время выполнения. Мы храним ID токенов в отображаемых в память файлах Arrow — это та же базовая технология, что и в нашем движке хранения.
Переходя к уровню GPU: мы начали с реализаций прямого прохода модели в vLLM, а затем переписали их с помощью нескольких пользовательских оптимизаций. Мы очень благодарны за возможность строить работу на базе достижений сообщества!
Ядра, которые мы используем для основных операций матричного умножения и внимания, являются стандартными: DeepGEMM от DeepSeek и Dao et al.’s Flash Attention 3. Эти ядра довольно хороши для вывода с высокой пропускной способностью и только с предварительным заполнением (prefill).
Модель стоимости «скорости света» учитывает только эти операции, но в прямом проходе есть много других. Их время выполнения в принципе незначительно, но их много, и они суммируются, включая накладные расходы хоста на запуск этих ядер.
Стандартная техника здесь — объединение нескольких небольших ядер в одно, так называемое слияние ядер (kernel fusion). К счастью, сейчас довольно легко создать пользовательское ядро на Triton от OpenAI — особенно с помощью агента кодирования и эталонной реализации! Мы объединяем add-RMSNorm с квантованием fp8, а также объединяем RMSNorm запроса/ключа для каждой головы с роторными эмбеддингами.
Нам действительно нужно «обернуть» FlashAttention в некоторую пользовательскую логику. При соединении A и B многие суффиксные документы из B обращаются к одному и тому же якорю из A. При наивном отображении на FlashAttention это приводит к множественным репликациям якоря во время выполнения.
Мы избегаем этого, выполняя «рекурсивное» вычисление внимания или «комбинацию частичных результатов» для соединений.
Сначала мы выполняем внимание от всех суффиксных запросов к якорю, своего рода «перекрестное внимание». Затем суффиксы обращаются к самим себе, и результаты окончательно объединяются с LSE-масштабированием, как в Dao et al.’s flash decoding. KV-значения суффиксов не записываются в кэш — мы выполняем нулевое декодирование и никогда не делаем (N>2)-сторонние соединения, поэтому они нам не нужны!
Это очень похоже на каскадное внимание Flash Infer или . Это также похоже на древовидное внимание, но для частного случая дерева глубиной один. У нас та же мотивация, что и в этих методах: совместное повторное использование префиксов. Но поскольку мы знаем общие префиксы заранее, мы можем избежать большой сложности.
Кроме того, мы делаем одну оптимизацию на уровне модели. Поскольку мы выполняем только фильтры и соединения, нам нужно, чтобы модель выводила вероятности только для истинных и ложных токенов. Это означает, что наш словарь имеет только 8 вариантов — экстремальный случай структурированных выводов. Это известно во время загрузки движка, поэтому мы просто полностью удаляем эти столбцы из головы языкового моделирования модели, сокращая конечное матричное умножение деэмбеддинга с размера словаря x размер скрытого состояния до 8 x размер скрытого состояния.
Каково будущее механизмов вывода?
Наконец, если вы запускаете AI-SQL запросы и заинтересованы в повышении производительности и снижении затрат, свяжитесь с нами.
Мы worked много работали над SGLang и создали свои собственные движки, включая Quail, и это привело к тому, что у нас сложилось мнение о том, куда движется эта область. Это критическое время как для работы над механизмами вывода, потому что эти системы новы (им годы, а не десятилетия), так и для разработки программного обеспечения в целом, потому что агенты кодирования меняют ограничения в исследованиях и разработках. Несколько заметок об этом ниже.
Это только начало для оптимизированного AI-SQL вывода.
Существует множество очевидных дополнительных оптимизаций для Quail и рабочих нагрузок AI-SQL. Мы могли бы создавать лучшие планы, и мы всё ещё не достигли «скорости света» для планов, которые выполняем.
Вот краткий список задач, чтобы мы могли «Шмидхуберизировать» любого, кто их реализует — список вещей, над которыми мы хотели бы видеть больше работы:
1. Добавьте больше уровней в KV-кэш.
Мы кэшируем KV-значения только в HBM GPU. Но существует больше уровней хранения, и отличные кэши всегда многоуровневые. Такие системы, как HiCache от LMSYS Org, помогают управлять многоуровневыми кэшами. Мы использовали его для класса рабочих нагрузок, для которого он предназначен — вывода чат-ботов/агентов, но не применяли его здесь.
Поскольку эта рабочая нагрузка сильно отличается, мы ожидаем, что есть возможности для улучшения существующих систем кэширования. В частности, мы больше знаем о порядке запросов и имеем больше контроля над ним, поэтому можем более непосредственно управлять кэшем, и мы существенно нечувствительны к задержкам, поэтому получаем выгоду от ещё более высоких и медленных уровней хранения, особенно со страйпингом. Возможно, мы могли бы подавать данные в нашу LLM с ленточных накопителей?
2. Оптимизируйте между запросами.
Мы также кэшируем KV-значения только в течение времени жизни запроса. Мы не выбрасываем фильтры Блума или карты зон в мусор, так почему мы делаем это с KV-кэшем? HBM GPU слишком ценен для этого, но более высокие уровни кэша намного дешевле.
3. Поддержка наборов данных, превышающих объем памяти.
Как доказывает успех Redis от antirez и DuckDB от Mühleisen и Raasveldt, можно создать полезную систему баз данных без постоянного хранилища. А инференс настолько интенсивен с точки зрения вычислений, что объемы наборов данных зачастую оказываются меньше.
Но это не повод останавливаться на обработке в оперативной памяти! Поскольку представление KV намного больше, чем хранимое представление, применение этого метода также выиграет от многоуровневого кэширования KV.
4. Радикальный индекс для лучшего совместного использования.
В нашем наборе тестов мы отстаем от vLLM в одном случае: при обработке набора данных трассировок агентов. Мы добавили этот бенчмарк специально, чтобы показать, что наша система в том виде, в котором мы ее изначально построили, идет на компромисс, а не является универсально лучшей по сравнению с существующими движками, в которые вложено гораздо больше инженерных усилий.
В частности, бенчмарк агентов можно отобразить на обслуживание агентов — просто сохраните все истории сеансов в базе данных, затем выберите (SELECT) эти истории с помощью нового входящего сообщения и запустите AI_COMPLETE. Это создает множество случаев совместного использования префиксов между документами, которые наша текущая система не может моделировать или использовать.
Но мы все равно могли бы улучшить производительность Quail в этом аспекте! Например, мы могли бы построить индекс на основе дерева radix для документов, а затем искать возможности для повторного использования KV-кэша.
5. Лучшее перекрытие между ядрами.
Мы придерживались относительно простых методов на уровне ядер, таких как слияние в Triton, и мы знаем, что нам все еще далеко до предельной скорости. Частой причиной отставания здесь являются накладные расходы или недостаточное повторное использование ресурсов между ядрами. Мегаядро, ориентированное на пропускную способность, в стиле Hazy Research или даже просто программный зависимый запуск CUDA улучшили бы перекрытие и могли бы повысить производительность.
6. Тонкая настройка «на лету».
И последнее, нечто гораздо более спекулятивное. В современных аналитических базах данных операторы часто оптимизируются в процессе выполнения, например, с помощью специализации и JIT-компиляции — см. компилятор «Flying Start» от Umbra. Эти оптимизированные модули затем подменяются в запросе прямо во время выполнения.
Мы могли бы аналогичным образом «компилировать» более быстрые модели с помощью квантования, прунинга, дистилляции и аналогичных методов, запускать их параллельно с запросом, а затем подменять их, как только точность достигнет приемлемого уровня. И обучение ML действительно можно довести до такой степени операционализации! См. Anil et al.’s “On the Factory Floor” paper.
Инференс-движки, созданные «по наитию», с общим ядром.
Мы проделали большую часть этой работы, подсказывая кодирующим агентам. Самое сложное заключалось уже не в реализации идей, а в постановке задачи и измерении результатов — вкусе и обеспечении качества.
К этому ли движется разработка программного обеспечения и системные исследования? Мы не знаем, но нам это кажется вероятным! Что бы ни случилось, это будет странно, и потребует вдумчивого внимания к рабочим привычкам, структуре сообщества и стимулам that has been recently admirably demonstrated by the mathematics community.
Более узко, мы прекрасно осознаем, что в последнее время наблюдается расцвет специализированных инференс-движков, где движок разрабатывается с учетом более узкой рабочей нагрузки или набора нагрузок. Система агентской разработки VibeServe из лаборатории SyFI демонстрирует, что этот процесс создания может быть даже обобщен при условии наличия четко определенных базовых показателей и целей.
Вместо этого мы считаем, что мир инференса скоро станет немного больше похож на базы данных после DataFusion: переиспользуемое «ядро», которое достаточно выразительно, чтобы впитывать новые методы, но достаточно контролируемо, чтобы предоставлять гарантии. Для доказательства концепции см. твит ekzhang об агентно-расширяемом инференс-движке.
Существующие инференс-движки, такие как vLLM и SGLang, также могут быть адаптированы, чтобы лучше служить в качестве такого ядра — см. проекты nano-vllm и mini-sglang.
