Пользователь выложил в r/LocalLLaMA отчёт по Liquid LFM3-1.7B в Q8_0 GGUF, запущенной через llama.cpp на ROCm. На iGPU Strix Halo модель выдала около 4,1 тыс. токенов/с на prefill и примерно 78 токенов/с на decode. В конфигурации с tensor-split между 7900 XTX и XT (вторую карту автор обозначает просто как XT) те же задачи дали около 7,1 тыс. токенов/с prefill и примерно 151 токен/с decode.
Для модели на 1,7 млрд параметров это много. 78 токенов/с хватает, чтобы читать ответ быстрее, чем успеваешь пролистать, а 151 токен/с уже упирается в интерфейс и в готовность пользователя ждать. Prefill в 4,1 тыс. токенов/с означает, что промпт на 32 тыс. токенов обрабатывается примерно за 8 секунд, и только потом начинается генерация.
Оговорка, без которой эти цифры нельзя переносить на своё железо: это замеры одного пользователя на двух его конфигурациях. Версии llama.cpp, ROCm и драйверов, параметры запуска и методика измерения в отчёте не раскрыты. Дальше разбор того, что числа значат, где проходят границы их применимости и как проверить похожий сценарий у себя.
Что именно измеряли: LFM3-1.7B, Q8_0 GGUF и llama.cpp на ROCm
Модель тестировали как кандидата для сжатия и суммаризации текста. В таких задачах важны две вещи: аккуратная работа с длинным входом и скорость, потому что суммаризация одного документа редко бывает единственным запросом за сессию. Эрудиция на уровне флагманских моделей здесь вторична.
Стек простой: веса в GGUF с квантованием Q8_0, движок llama.cpp, бэкенд ROCm. Первая конфигурация - iGPU Strix Halo, то есть APU, который берёт память из общего с CPU пула. Вторая - две дискретные видеокарты, 7900 XTX и XT, между которыми модель разделена через tensor-split. Набор задач один и тот же, поэтому сравнение выглядит наглядным, хотя условия в нём разные по определению.
Что из отчёта не следует: это не независимый бенчмарк. Один прогон на одном железе, без опубликованных версий софта и флагов запуска, не даёт права говорить о поведении LFM3-1.7B «в целом» или о преимуществе одной платформы над другой. Ценность здесь в порядке величин и в самом факте, что компактная модель на AMD-железе работает с длинным контекстом.
Почему Q8_0, а не int4: что это меняет для 1,7B
Квантование задаёт, сколько байт занимает один параметр: fp16 - 2 байта, int8 - 1 байт, int4 - 0,5 байта плюс накладные расходы на масштабы (разбор квантования в курсе LLM Inference Systems). Q8_0 хранит веса в 8 битах блоками с отдельными масштабами, поэтому реальный расход чуть выше байта на параметр.
Для 1,7B параметров Q8_0 даёт примерно 1,8 ГБ весов, int4-вариант - порядка 1 ГБ. Разница меньше гигабайта. На 24 ГБ у 7900 XTX и на общей памяти Strix Halo вопрос «влезет или нет» не стоит, поэтому выбор Q8_0 логичен: он снижает деградацию качества на суммаризации, где искажения формулировок и потерянные детали заметны сразу.
Платить за это приходится скоростью. При генерации одного токена веса читаются из памяти целиком, и чем больше байт на параметр, тем больше трафик. По общей теории int4 на decode обычно быстрее Q8_0. В отчёте пользователя такого сравнения нет, поэтому это ожидание по формуле, а не измеренный факт.
Prefill и decode: два разных этапа, и цифры 4,1k/78 против 7,1k/151 это подтверждают
Prefill обрабатывает промпт: модель прогоняет все входные токены, считает активации и наполняет KV-кэш. Decode генерирует ответ по одному токену за шаг. Нагрузка на железо у этапов разная, отсюда и разрыв в цифрах: prefill считает тысячи токенов в секунду, decode - десятки.
| Метрика | Strix Halo, iGPU | 7900 XTX + XT, tensor-split | Отношение |
|---|---|---|---|
| Prefill | ~4,1 тыс. токенов/с | ~7,1 тыс. токенов/с | ~1,7x |
| Decode | ~78 токенов/с | ~151 токен/с | ~1,9x |
| Prefill промпта 32k | ~8 с | ~4,6 с | ~1,7x |
| Prefill промпта 64k | ~16 с | ~9 с | ~1,7x |
Время в таблице посчитано по указанным пользователем скоростям prefill, это арифметика, а не отдельные замеры. Реальная задержка до первого токена будет выше: сюда добавляются токенизация, работа сервера и сетевой слой, если запрос идёт через API llama-server.
Почему decode упирается в память, а не в арифметику
На декоде при батче 1 узкое место - не вычисления, а трафик весов: каждый новый токен требует прочитать все параметры модели примерно один раз (та же глава про квантование). Отсюда рабочая оценка: tok/s ≈ пропускная способность памяти / (байт на параметр × число параметров).
Логику видно на постороннем примере: у M2 Pro с пропускной способностью памяти 200 ГБ/с 8B-модель в fp16 теоретически даёт 200 / 16,1 ≈ 12,4 ток/с, а в int4 - около 47 ток/с. К LFM3-1.7B это отношения не имеет, это иллюстрация модели roofline.
Прикинуть эффективный трафик для замеров пользователя можно так: 78 ток/с × 1,8 ГБ ≈ 140 ГБ/с на Strix Halo, а 151 ток/с × 1,8 ГБ ≈ 272 ГБ/с суммарно на двух картах. Оценка грубая: она предполагает, что все веса читаются на каждом токене и что объём модели ровно 1,8 ГБ. Но она объясняет, почему связка двух GPU почти удвоила decode: в работу включились две подсистемы памяти.
Почему prefill чувствителен к вычислениям и батчу
Prefill обрабатывает токены промпта параллельно, пачками, поэтому ему важны вычислительные блоки и размер батча, а не только память. Прирост в замерах получился меньше, чем на decode: с 4,1 тыс. до 7,1 тыс. токенов/с, примерно в 1,7 раза против 1,9 раза.
Объяснять эту разницу только железом нельзя. Размер батча и ubatch, число слоёв на GPU, версия ROCm и драйвера влияют на prefill сильнее, чем на decode, а в отчёте эти параметры не указаны. Возможно, часть разрыва дала бы и настройка -ngl на одной карте, но проверить это по имеющимся данным невозможно.
Strix Halo против 7900 XTX + XT: что на самом деле сравнивают
Сравнение не изолирует tensor-split. В одном случае работает iGPU с общей памятью системы, во втором - две дискретные карты с собственной GDDR6. Различаются пропускная способность памяти, вычислительные блоки, поведение драйвера и, вероятно, настройки запуска. Корректная формулировка: в конфигурации пользователя связка двух карт оказалась быстрее примерно в 1,7 раза по prefill и в 1,9 раза по decode. Утверждение «tensor-split ускоряет модель вдвое» из этих данных не следует.
Про Strix Halo полезно помнить, что это APU: память делится с CPU, а дискретные карты работают со своей VRAM. Как такая платформа ведёт себя под реальной нагрузкой с параллельными запросами, видно по тестам Ryzen AI Max+ 395 в сценариях инференса LLM и эмбеддингов: там счёт идёт на единицы и десятки токенов в секунду при куда более тяжёлой модели.
Как tensor-split распределяет модель между GPU
llama.cpp делит слои и отдельные тензоры между устройствами по заданным пропорциям, обмен активациями идёт через PCIe. Для LFM3-1.7B в Q8_0 с её ~1,8 ГБ весов split не нужен, чтобы модель поместилась: она целиком влезает в 24 ГБ одной 7900 XTX. Смысл здесь другой - разложить вычисления и трафик памяти между двумя вычислителями.
Практическое правило: tensor-split оправдан, когда модель не влезает в одну карту или когда нужно поднять пропускную способность на генерации. Если весов мало, накладные расходы на обмен могут съесть часть выигрыша, и выгоднее оставить модель на одной карте с большим батчем. Похожая логика работает в гибридных сборках, где APU объединяют с дискретной картой: llama-halo-hybrid делит слои между Strix Halo и Radeon R9700 и получает на декодировании больше 60 ток/с по данным автора проекта.
Что значат 32k–64k промпты для 1,7B на практике
Вторая часть отчёта - про качество. Пользователь пишет, что на промптах размером 32k–64k модель остаётся заметно более связной, чем можно ожидать от 1,7B. Это субъективная оценка без метрик: ни сравнения с эталонными суммаризациями, ни слепой проверки, ни замеров ROUGE в отчёте нет.
Для сжатия и суммаризации такая оценка всё равно информативна. Задача требует удержать структуру документа и не потерять ключевые факты на длинном входе, а компактные модели ломаются именно там: путают разделы и пересказывают начало вместо вывода. Если модель держит это на 32k–64k, для черновой суммаризации её уже можно рассматривать.
Практическая цена длинного входа - время. 64 тыс. токенов при prefill 4,1 тыс. ток/с это примерно 16 секунд ожидания до первого токена на Strix Halo и около 9 секунд на связке двух карт. Для пакетной обработки документов терпимо, для интерактивного диалога заметно, особенно если пользователь дописывает промпт на ходу.
KV-кэш и длинный контекст: где начинаются ограничения
На коротком контексте в памяти доминируют веса модели, на длинном - KV-кэш; это две разные задачи настройки (материал про квантование и расход памяти). У 1,7B в Q8_0 веса занимают около 1,8 ГБ, то есть немного, и на промпте в 64k именно кэш становится заметной статьёй расхода.
Сколько гигабайт займёт кэш у LFM3-1.7B, по имеющимся данным не посчитать: в отчёте нет ни числа слоёв, ни конфигурации attention, ни размера контекста, с которым запускали сервер. Оценивать надо на своей машине, замеряя потребление памяти при разных значениях -c. Отдельный нюанс: чем длиннее контекст, тем сильнее меняется профиль скорости, и цифры, снятые на 4k, ничего не говорят о поведении на 64k.
Как воспроизвести замеры и не обмануться
Свои цифры получить несложно, сложнее сделать их сравнимыми. Минимальный набор того, что нужно зафиксировать и записать вместе с результатом:
- версии llama.cpp, ROCm и драйвера GPU;
- квантование и файл модели (в отчёте это Q8_0 GGUF);
- размер контекста, с которым запускался сервер, и длину тестового промпта;
- batch и ubatch, число слоёв на GPU (
-ngl), флаги tensor-split (-ts); - режим замера: prefill и decode отдельно, с прогревом и несколькими повторами.
В llama.cpp есть llama-bench, который меряет prefill и decode раздельно и показывает разброс по повторам. Замер секундомером в чате даёт другую цифру: туда попадут токенизация, работа сервера и время до первого токена, то есть задержка, а не пропускная способность.
В исходном отчёте ни один из этих параметров не раскрыт, поэтому воспроизводимость не подтверждена. Это не упрёк автору: человек делился наблюдением, а не проводил бенчмарк. Но сравнивать iGPU и дискретную связку без фиксации настроек легко, и ложный вывод получается почти автоматически.
Какие цифры считать ориентиром, а какие нет
Ориентир - порядок величин и соотношение этапов. Prefill в тысячи токенов в секунду и decode в десятки для модели на 1,7B выглядят правдоподобно, они согласуются с формулой из предыдущего раздела. Точные 78 и 151 ток/с переносить на другую сборку нельзя: другая версия ROCm, другой контекст или другое квантование дадут иные числа, иногда вдвое отличающиеся.
Для калибровки полезно помнить, как выглядит медленный режим: разбор запуска DeepSeek V4.1 Flash на RTX 5090 с результатом около 10 токенов в секунду показывает, что на такой скорости ещё можно работать, но комфортным это не назовёшь. 78 и 151 ток/с находятся в другой категории.
Кому и зачем нужна LFM3-1.7B в таком сетапе
Замеры описывают узкий, но востребованный сценарий: сжатие и суммаризация текста на AMD-железе, где нужны скорость и приемлемое качество на длинном входе. 1,7B в Q8_0 через llama.cpp на ROCm подходит для пакетной обработки документов, черновых выжимок, переупаковки логов и переписки в короткие отчёты. Универсальным ассистентом такую модель делать не стоит: для сложных рассуждений и кода 1,7 млрд параметров мало при любом квантовании.
Выбор между двумя конфигурациями определяется удобством. На Strix Halo 78 токенов/с дают комфортную интерактивную работу без дискретной карты, и это сильный аргумент платформы. Связка 7900 XTX + XT почти удваивает скорость, но требует двух GPU, более мощного блока питания и аккуратной настройки tensor-split. Если задача - прогонять пачки документов, второй вариант окупается временем. Если нужно иногда суммировать статью или договор, хватит первого.
Есть и более общий контекст выбора модели. Рядом с компактными плотными моделями существуют MoE-варианты на 35B и больше, которые на старом железе ведут себя иначе: сравнение 35B, 120B и 176B MoE на GTX 1080 Ti показывает, что рабочий результат даёт только одна конфигурация из трёх. Для суммаризации решают устойчивость на длинном тексте и скорость обработки входа, а не число параметров само по себе.
Что сделать дальше: прогнать LFM3-1.7B Q8_0 на своих документах длиной 32k–64k, записать версии и флаги запуска, замерить prefill и decode отдельно в llama-bench и сравнить с альтернативой из того же класса. После этого чужие 78 и 151 ток/с станут полезным ориентиром, а не просто цифрой с чужого скриншота.