Блочный драфтер быстро предлагает несколько токенов, но проверка длинного продолжения и ограничения движка могут поглотить весь выигрыш.
Совместить параллельную генерацию кандидатов с выбором выгодной длины проверки, подготовкой памяти для всего блока и учётом фактической стоимости графов исполнения.
В измерении V1 при батче 256 DSpark дал 3120 токенов/с с динамическим бюджетом против 2614 при фиксированном K=9 и 2411 у основной модели. Асинхронную V2 на момент доклада ещё не измеряли.
Последовательную модель нужно было встроить в живую ленту с быстро меняющимися публикациями, социальными связями и ограничением задержки; дорогой текстовый LLM-ранкер не улучшил онлайн-результат.
Чередовать представления публикаций и действий, добавлять числовой контекст после трансформера и оценивать множество кандидатов с общей историей за один проход.
В таблице 5 авторы сообщают о +2,10% времени в продукте относительно прежнего ранжировщика. Для новых участников эффект статистически незначим; результаты A/B не включают инкрементальное обучение.
Начните здесь, если хотите связать модель, данные, A/B-тест и систему обслуживания в одном промышленном кейсе.
Прежние модули взаимодействия признаков плохо загружали GPU; увеличение модели повышало стоимость и не давало соразмерного улучшения качества.
Сгруппировать признаки в небольшое число смысловых токенов, смешивать части их представлений и обрабатывать токены независимыми FFN; затем оптимизировать точность вычислений и GPU-операции.
Таблица 6: 15,8 млн → 1,1 млрд плотных параметров при задержке 14,5 → 14,3 мс. Таблица 4: Douyin overall +0,2908% активных дней и +1,0836% времени по обновлённому длительному A/B-наблюдению.
Читайте после Feed SR: здесь главный вопрос — не устройство истории, а взаимодействия разнородных признаков и реальная стоимость крупного ранжировщика.
История порядка 100 событий ограничивает память о пользователе, а прямое добавление десятков тысяч событий делает хранение, передачу и инференс слишком дорогими.
Найти релевантные события в нескольких историях, гарантированно сохранить самые свежие, обучать дополнительное предсказание действия и убрать повторную передачу общей истории между кандидатами.
Против TransAct в онлайн-тесте: +6,35% сохранений, −12,80% скрытий, +0,45% разнообразия и +1,41% времени. Офлайн +13,31% HIT@3/repin имеет другую базу — модель без последовательностей.
Читайте после исходного TransAct: здесь особенно хорошо разобраны негативные показы, общая история запроса и влияние очередей на хвост задержки.
Разнородные ручные признаки и повторная обработка истории затрудняют масштабирование модели на постоянно меняющемся словаре и огромном потоке взаимодействий.
Объединить признаки в последовательность, использовать специализированные блоки HSTU, учить много целевых позиций совместно и обслуживать кандидатов микропакетами с общими вычислениями.
Таблица 7: +12,4% по неназванной engagement-задаче E-Task и +4,4% по C-Task в онлайн-ранжировании. +65,8% NDCG относится к Books, а множители скорости — к отдельным стендам.
Читайте в связке с Feed SR: HSTU объясняет исходную формулировку, а LinkedIn показывает, какие решения оказались полезными или неудачными в другой ленте.
Пакетный профиль интересов обновляется недостаточно быстро, но независимая подробная обработка истории для каждого кандидата резко увеличивает стоимость ранжирования.
Объединить долгосрочный пакетный профиль с короткой историей действий, рано добавить в историю представление кандидата и сжать выход трансформера перед общей сетью ранжирования.
В таблице 5: +11% сохранений в Homefeed, −10% скрытий и +2% общего времени в продукте. Контроль — Pinnability без realtime-последовательности; по 1,5% посетителей в группе.
Начните с этой главы перед TransAct V2: она объясняет исходную гибридную модель и проблемы, которые следующая версия развивает дальше.
Длинные входные запросы прерывают потоковую генерацию других запросов на общем GPU. Дополнительную CPU-работу по токенизации и разбору ответов приходится выполнять на узлах с ускорителями, а разделение стадий приносит собственную задержку при передаче KV-кеша.
Независимо отделить вычисление контекста (prefill) от генерации (decode) с передачей KV-кеша через коннектор и вынести подготовку запроса `/render` и восстановление ответа `/derender` на CPU-сервер. Сравнивать схемы по TTFT, ITL и полезной пропускной способности при порогах задержки.
На синтетическом сравнении Qwen2.5-7B-Instruct на двух L40S P/D уменьшил p99 ITL с 169 до 29 мс при 0,4 запроса/с и с 263 до 50 мс при 2 запросах/с. Но без NVLink и прямого обмена GPU перенос примерно 470 МБ KV занимал около 1,3 с: при 0,2 запроса/с медианный TTFT был 2,2 с против 0,7 с у DP=2, поэтому P/D не выдерживал двухсекундный порог TTFT. Это контролируемый эксперимент, не подтверждённый эффект внедрения.
Длинные повторяющиеся контексты, паузы и всплески агентных запросов делают наивное распределение нагрузки дорогим и мешают соблюдать TTFT.
Измерять prefill и decode, моделировать очередь и всплески, маршрутизировать запросы к сохранённому KV-cache и уменьшать его дублирование через Context Parallelism, LayerSplit и общий L3.
Для 16 GPU и P95 TTFT ≤ 5 с базовый вариант не проходил SLO даже на одной сессии; KV-aware routing дал около 3,4 RPS, неудачный 3P1D — 2,27 RPS, а после дальнейших оптимизаций добавление 1 ТБ DRAM дало 9,79 RPS. В рабочей системе доля закешированных входных токенов выросла примерно с 55% до 80% после L3 и затем до 90% после LayerSplit.
Число вычислительных ядер растёт вместе с аппаратными платформами, архитектурами моделей и наборами операций. Экспертная ручная настройка не успевает покрывать специализированные рекламные нагрузки и новые поколения ускорителей.
KernelEvolve рассматривает оптимизацию ядра как многошаговый поиск. LLM предлагает код, job harness компилирует и измеряет варианты, дерево поиска использует диагностику и историю ветвей, а база знаний поставляет аппаратные документы и сохранённые навыки.
По данным Meta, система прошла все 250 задач KernelBench и подтвердила корректность 480 конфигураций ATen; в отдельных рабочих нагрузках сообщается о приросте пропускной способности инференса Andromeda более 60% на NVIDIA и обучения рекламной модели более 25% на MTIA.
Более сложное ранжирование рекламы требовало всё больше вычислений и памяти, но ответ оставался ограничен долями секунды, а стоимость обслуживания не должна была расти пропорционально масштабу модели.
Распределять запросы между моделями разной сложности, рассчитывать общие пользовательские сигналы один раз на запрос и совместно оптимизировать архитектуру, GPU-вычисления, хранение эмбеддингов и систему обслуживания.
После запуска на Instagram в IV квартале 2025 года Meta заявила о +3% рекламных конверсий и +5% CTR для targeted users. Отдельно авторы называют задержку порядка O(100 мс), MFU 35% на нескольких типах оборудования и масштаб O(1T) параметров; эти показатели имеют другие условия и не являются бизнес-эффектом.