Заставь пользователя ждать — и он уйдёт
Вы запускаете RAG-систему. Клиент задаёт вопрос, система идёт в векторную базу, вытаскивает три статьи по 4 тысячи токенов каждая, склеивает в один гигантский контекст — и только потом начинает генерацию. И вот тут происходит магия: пользователь видит, как курсор дёргается, а текст появляется со скоростью улитки.
Проблема не в декодинге (генерации ответа). Проблема в prefilling — этапе, когда модель переваривает весь ваш контекст и строит для себя внутреннее представление. Если prefill медленный — RAG мёртв. Никому не нужен ассистент, который думает 20 секунд, прежде чем начать писать ответ. А в 2026 году, когда контексты уже перевалили за 128K, эта проблема стала системной.
Prefill vs Decode: почему один из них важнее для RAG
Грубо говоря, генерация текста делится на две фазы: prefill (обработка всех входных токенов за один проход) и decode (генерация одного токена за раз). Для обычного чата prefill почти незаметен — 50 токенов промпта обрабатываются за миллисекунды. Но в RAG контекст легко вырастает до десятков тысяч токенов.
Что происходит на prefill? GPU выполняет один массивный матричный мультипликативный прогон для всех токенов промпта. Это требует высокой пропускной способности памяти — нужно быстро подгружать веса модели и вычислять attention. Если шина памяти узкая (как у Strix Halo), prefill превращается в ад.
В интерактивном RAG время до первого токена (TTFT) напрямую зависит от скорости prefilling. Пользователь не простит задержку больше 2-3 секунд. А ведь контекст может содержать 10-20 документов по 2K токенов каждый.
Strix Halo: зверь с медленными ногами
AMD Strix Halo — это APU с 128 ГБ унифицированной памяти LPDDR5X. Звучит круто: одна железка, не надо думать про PCIe, можно загрузить Llama-3-70B в полном качестве. Да, память дешёвая, ёмкая... но шина — 256 бит, и частота — около 6 ГГц. Итоговая пропускная способность — примерно 120-130 ГБ/с.
Сравните с серверным GPU: H100 выдаёт 2 ТБ/с, даже RTX 4090 — около 1 ТБ/с. А у Strix Halo — в 8-10 раз меньше. Теперь представьте prefill для контекста в 32K токенов на модели 70B. На H100 это займёт ~0.3 секунды. На Strix Halo — 3-4 секунды. И это не считая времени на извлечение документов!
Но самое смешное — когда вы запускаете RAG с интерактивным пользователем. Каждый новый запрос требует prefilling заново (если не используете кэширование KV на уровне контекста). То есть каждое сообщение пользователя снова переваривает 32K токенов. И пользователь ждёт. И уходит.
Эффект масштаба: больше контекста — больше боли
В 2026 году RAG-системы всё чаще используют LLM с длинным контекстом (128K, 256K), чтобы не резать документы. Это увеличивает время prefilling линейно. На Strix Halo контекст в 128K будет обслуживаться 12-15 секунд — полностью убивая UX.
Конечно, есть хаки: спекулятивный декодинг, MTP (multi-token prediction), о которых мы писали в статье MTP в llama.cpp: как ускорить генерацию до 111% на Strix Halo. Но эти методы ускоряют decode, а не prefill. Prefill — это узкое место, которое не обойти простым увеличением числа токенов за шаг.
Как не надо: типичная ошибка при выборе GPU для RAG
Самый популярный аргумент в пользу Strix Halo: «У меня 128 ГБ, я загружу целую 120B модель без квантизации!». И это правда — модель помещается. Но как только вы добавляете RAG-пайплайн, весь выигрыш в качестве от full-precision съедается падением скорости.
В интерактивном режиме пользователь ждёт ответ. Если TTFT больше 5 секунд — система проигрывает конкуренту, который выдаёт менее умный, но быстрый ответ на основе 8B модели с RAG. Парадокс: меньшая модель на быстром GPU (RTX 4090 с 24 ГБ) часто даёт лучший UX, чем огромная модель на медленной памяти Strix Halo.
Важно: скорость prefilling scale'ируется с пропускной способностью памяти. На Strix Halo вы заплатите за 128 ГБ не деньгами, а временем пользователя.
Решения: как всё-таки заставить RAG летать
Первый вариант — разгрузить prefill на отдельный GPU, а Strix Halo оставить только для декодинга. Об этом мы писали в статье Гибридный кластер для LLM: разгрузка prefill на eGPU и декодирование на Strix Halo. Например, eGPU с RTX 4090 берёт на себя prefill, а Strix Halo с огромной памятью хранит модель и генерирует токены. Это работает, но усложняет архитектуру.
Второй вариант — использовать современные фреймворки вроде SGLang, которые умеют кэшировать KV-кэш на уровне контекста и повторно использовать его между запросами. Мы рассматривали этот подход в статье Современный стек RAG 2025: отказ от энкодеров в пользу LLM и переход на SGLang. Если запросы перекрываются по контексту, prefill можно пропустить частично.
Но самый честный путь — взять GPU с HBM: RTX PRO 6000 (там 96 ГБ на карте, но пропускная способность — 2 ТБ/с), или объединить две такие. Мы протестировали подобную конфигурацию в статье Две RTX PRO 6000 и терабайт памяти: выдержит ли эта станция 20 одновременных пользователей?. Результат: 20 пользователей, контекст по 8K каждому, TTFT < 1 секунды. Strix Halo в таком сценарии просто упал бы.
Агентные сценарии — ещё один крест на Strix Halo
Агентные LLM требуют многошаговых рассуждений, где каждый шаг генерирует новый запрос к RAG. То есть prefilling повторяется многократно. На Strix Halo это превращается в кошмар: агент думает по минуте, прежде чем ответить. В статье AMD Strix Halo и агентные AI: как выжать 128GB оперативки до последнего токена мы пытались это оптимизировать — но фундаментальная проблема пропускной способности памяти остаётся.
Итог: кому Strix Halo всё-таки нужен
Не будем поливать грязью железку полностью. Strix Halo — отличный зверь для batch-обработки и офлайн RAG, где время не критично. Например, индексация документов, суммирование большого корпуса, генерация эмбеддингов. Там вам не нужна скорость prefilling, а нужна большая память. Но как только в игру вступает человек с секундомером — Strix Halo проигрывает.
Совет: не ведитесь на гигабайты унифицированной памяти. Для интерактивного RAG смотрите на bandwidth памяти и поддержку оптимизированных фреймворков (vLLM, SGLang). Ваши пользователи скажут спасибо.
