В ноябре 2026 года инженер AMD AI Group опубликовал в r/LocalLLaMA экспериментальный стек hrx-loom и готовые ядра для LLM на Strix Halo. Заявка смелая: по замерам автора его ядра быстрее llama.cpp с бэкендами Vulkan и ROCm на части метрик decode и prefill. Независимой проверки пока нет, зато есть PyPI-пакет, две команды для запуска и агентный скилл, которым можно портировать собственную модель.
Суть в одном абзаце: hrx-loom - сквозной стек из компилятора, рантайма и серверных инструментов. Он позволяет собирать, оптимизировать, обслуживать и распространять модельные программы, не меняя движок инференса и сервер. Ядра вынесены в отдельный слой и компилируются под конкретное железо, движок остаётся нетронутым. Автор описал стек и выложил результаты в исходном посте.
Что такое AMD Loom и зачем нужен отдельный слой ядер
Привычный путь запуска GGUF выглядит так: взять llama.cpp, собрать с нужным бэкендом (Vulkan, ROCm, CPU), загрузить квант, получить токены. Всё, что влияет на скорость, спрятано внутри движка: ядра матричных умножений, attention, нормализаций. Если ядро под вашу GPU написано неоптимально, вы это почувствуете, но исправить не сможете без правки исходников движка.
Loom меняет точку приложения усилий. Ядра живут отдельно, в файлах .loom, и компилируются в машинный код под целевую платформу. Движок, сервер и формат модели остаются как есть: их задача сводится к вызову готового скомпилированного кода.
Компилятор, рантайм и сервер: как устроен стек
- Компилятор принимает .loom-файлы или C++ и генерирует код под выбранную платформу.
- Рантайм исполняет скомпилированные ядра на устройстве.
- Серверные инструменты: loom-serve поднимает standalone-сервер инференса.
SDK (компилятор, рантаймы и devtools) обходится без зависимостей: его можно скачать как wheel, слинковать со своим приложением или собрать из исходников примерно за минуту. Целевые платформы: x86, AMD-GPU, AMD-NPU и generic Vulkan. Слои компилятора и рантайма допускают встраивание в другие движки, а не только работу в виде отдельного сервера.
Статус стоит держать в голове с первой минуты: это экспериментальный стек, а не продукт с гарантиями. Автор сам называет его новым экспериментальным рабочим процессом и отдельно просит сообщество рассказать, как такие стеки будут разворачивать на практике.
Название легко спутать с релизом ROCm HRX Loom v0.1. О нём у нас отдельный разбор: там про место инструмента в экосистеме ROCm, подтверждённые факты о первой версии и риски ранней стадии.
Почему .loom, а не CUDA-подобный C++
.loom - векторная модель программирования, по духу близкая к MLIR. Человеку такой код читать тяжело, агенту писать - легко. C++ в стеке тоже поддерживается, так что выбор не бинарный.
Смысл нового формата раскрывается в связке с агентной генерацией. MLIR-подобная форма хорошо ложится на компиляцию и оптимизацию под разные бэкенды, а агент собирает ядро по описанию модели без ручной возни с векторизацией. Утверждать, что .loom лучше C++ в общем случае, нельзя: аргумент автора касается удобства для агентов, а не превосходства языка как такового.
Кому и зачем это нужно: сценарии на Strix Halo
Главная площадка, на которой автор мерил и портировал модели, - Strix Halo, APU-платформа AMD (Ryzen AI Max) с общей памятью, встречающаяся в мини-ПК и ноутбуках. Именно там важен каждый процент: память одна на CPU и GPU, бюджет под модель делится между ними, а упор идёт в пропускную способность памяти и качество ядер.
Типичные сценарии, где стек имеет смысл:
- локальный инференс GGUF в квантовании Q4_K_M, где критичны decode и prefill;
- желание выжать больше из AMD-железа без перехода на CUDA;
- эксперименты с tool calling, speculative decoding и вводом изображений;
- сравнение собственной реализации с llama.cpp Vulkan и ROCm на одной и той же модели.
SDK целится также в x86, AMD-NPU и generic Vulkan, то есть теоретически шире одной платформы. Замеры автора при этом сделаны именно на Strix Halo, и переносить их на другую конфигурацию без проверки не стоит. Если у вас NVIDIA или нужен стабильный продакшен, это история не про вас сейчас: целевые платформы перечислены выше, NVIDIA в них нет.
Смежный сценарий для той же платформы - гибридный запуск с дискретной картой. llama-halo-hybrid объединяет APU Strix Halo и Radeon R9700 в одну систему, и это другой подход к той же задаче «сделать локальный инференс быстрее».
Как запустить Loom на Linux и Windows: пошагово
Обе команды, loom-fetch и loom-serve, доступны на Linux и Windows, установка идёт из PyPI-пакета Loom. Порядок такой: поставить пакет, скачать модель, поднять сервер, отправить запрос и убедиться, что ответ приходит.
Установка пакета и загрузка модели через loom-fetch
Пакет ставится через pip. В примере автора фигурирует extra [hf] и версия 0.1.0; привязку к версии лучше сохранить, стек молодой и поведение между версиями меняется.
pip install "hrx-loom[hf]==0.1.0" loom-fetch --output=qwen3.8-27b
loom-fetch скачивает модель и раскладывает её в каталог, имя которого задаёт --output. Рабочий формат - Q4_K_M GGUF: именно под это квантование агентный скилл генерирует ядра. Модель должна умещаться на Strix Halo, в примере это модель 27B-класса. Точный синтаксис флагов и полный список аргументов сверяйте с README пакета: интерфейс версии 0.1.0 может измениться.
Запуск сервера через loom-serve и проверка
loom-serve --model=qwen3.8-27b/model.json --device=amdgpu --memory_bytes=52gb
loom-serve поднимает standalone-сервер инференса. Флаг --model указывает на model.json внутри скачанного каталога, --device выбирает устройство, --memory_bytes задаёт бюджет памяти. Дальше сервер отвечает по сети, и использовать его можно как обычный инференс-сервер, а не только как тестовую обвязку для замеров.
Конкретные порты и формат эндпоинтов в исходном посте не приводятся, эти детали смотрите в документации пакета. Проверка сводится к одному действию: отправить запрос на сервер и получить осмысленный ответ модели. Если сервер падает на старте, первое, что стоит проверить, - имя устройства в --device и бюджет в --memory_bytes.
Производительность: что именно обгоняет Loom и насколько можно верить цифрам
Формулировка автора: ядра стабильно быстрее llama.cpp Vulkan и llama.cpp ROCm на Strix Halo по ряду метрик decode и prefill. Результаты приведены картинкой в посте, отдельной таблицы с числами и методикой нет.
Из этого утверждения аккуратно вынимаются три вещи: платформа - Strix Halo, точка сравнения - два бэкенда llama.cpp, метрики - decode и prefill. Всё, что выходит за эти рамки, уже домысел.
Decode и prefill: почему метрики считают отдельно
Prefill - обработка входного промпта: модель прогоняет все токены контекста разом, и фаза упирается в матричные умножения и пропускную способность памяти. Decode - генерация по одному токену за шаг, где на первый план выходят задержки и работа с KV-кэшем. Длинный контекст и RAG-сценарии упираются в prefill, длинные ответы и агентные циклы - в decode. Поэтому корректная формулировка звучит как «быстрее по ряду метрик decode и prefill», а не «быстрее в целом».
Почему нельзя переносить бенчмарк на другое железо
Условия замера жёстко ограничены: Strix Halo, квантование Q4_K_M, отобранный автором набор моделей и его собственные методики. Другая платформа, другое квантование (например, Q8_0 или IQ-варианты) или другая модель дают другую картину. Воспринимайте цифры как сигнал «направление перспективное», а не как гарантию прироста на вашей машине.
Проверить самостоятельно можно тем же стеком: скилл /loom умеет отчитываться по скорости относительно llama.cpp ROCm, если запросить это прямо в постановке задачи. Сравнение на своей модели и своей конфигурации - единственный способ получить цифры, которым вы доверяете.
Портирование своих моделей через скилл /loom
Автор разработал агентный скилл, который пишет ядра под Q4_K_M GGUF любой LLM, а через /loom свои модели можно портировать и загружать. Масштаб проверки: скилл прогнали по топ-51 трендовым LLM с Hugging Face, умещающимся на Strix Halo. Все модели портированы успешно, с работающими tool calling, speculative decoding и вводом изображений. Оценка «успешно» здесь авторская, независимого аудита этих портов нет.
Логика агентного подхода объясняет, зачем понадобился свой формат. Человеку писать .loom тяжело, агенту - нормально: он генерирует векторизованные ядра по описанию архитектуры модели и проверяет их на реальном инференсе. Постановка задачи выглядит примерно так:
/loom get <hf-org>/<model-gguf> working on loom-serve, optimize it, and report the performance relative to llamacpp rocm
Практический смысл в снижении порога входа. Раньше оптимизация ядер требовала инженера по GPU-компиляторам, теперь достаточно поставить задачу агенту и проверить результат. Проверка результата остаётся на вас: сравнение с llama.cpp ROCm на вашей модели покажет, стало ли быстрее именно у вас.
Портированные модельные программы автор выложил обратно на Hugging Face, то есть часть работы уже сделана за вас. Имена, по которым ищутся материалы: репозиторий стека hrx-system, скиллы в loom-skills, сводка данных по 51 модели на странице loom-dev.
Ограничения и риски: что важно знать до установки
Список короткий, но каждый пункт способен испортить вечер.
- Экспериментальный статус. Стек молодой, поведение и интерфейсы меняются.
- Привязка к AMD-железу. Замеры на Strix Halo, целевые платформы SDK - AMD и Vulkan.
- Q4_K_M GGUF как основной сценарий. Под это квантование генерируются ядра, остальные варианты не заявлены.
- Замеры от автора. Независимого бенчмарка нет, числа даны картинкой.
- Молодой API. Флаги и структура каталогов могут измениться между версиями пакета.
Экспериментальный статус и привязка к AMD
Автор - сотрудник AMD AI Group, замеры сделаны на AMD-железе. Это не приговор проекту, но задаёт ожидания: баги, ломающие изменения, отсутствие гарантий и поддержки для нестандартных конфигураций. Для сценариев на NVIDIA смысла нет: целевые платформы SDK - x86, AMD-GPU, AMD-NPU и generic Vulkan.
Отдельно про Vulkan. Generic Vulkan в списке целей есть, но замеры проводились на Strix Halo, а не на произвольной видеокарте с Vulkan. Ждать тех же цифр на дискретной карте другого производителя не стоит, проверять придётся самому.
Замеры от автора: как читать цифры
Правило простое: цифры из поста - первичный сигнал, а не независимый бенчмарк. Смотрите на условия (Strix Halo, Q4_K_M, конкретные метрики decode и prefill), а не на общий вывод «быстрее llama.cpp». Нужна уверенность - воспроизводите на своей модели: loom-serve и скилл /loom для этого и сделаны.
Как Loom встроить в другие движки и что дальше
Standalone-сервер vs встраивание в движок
Режимов два. Первый: loom-serve как самостоятельный инференс-сервер. Быстро, без интеграции, хорошо подходит для проверки гипотезы «а не быстрее ли». Второй: взять слои компилятора и рантайма и встроить в свой движок. Дороже по времени, зато ядра Loom появляются там, где вам удобно.
Третий путь пока в разработке: команда работает над бэкендом hrx-loom для llama.cpp. Если он появится в рабочем виде, ядра Loom можно будет подключать внутри привычного llama.cpp, не переключаясь на отдельный сервер и не теряя доступ к экосистеме GGUF-инструментов. Сейчас это планы, а не готовая функция, и сроков в источнике нет.
Практический вывод для разработчика: если вы пишете свой движок или сервер, смотрите на слои компилятора и рантайма как на библиотеку. Если нужен быстрый результат без интеграции, ставьте пакет и запускайте loom-serve.
Стоит ли пробовать: короткий вывод
Пробовать, если у вас Strix Halo или другое AMD-железо из целевого списка, вы работаете с Q4_K_M GGUF, готовы к экспериментам и хотите сравнить с llama.cpp Vulkan и ROCm на своих моделях. Ещё один аргумент: 51 модельный файл уже портирован и выложен на Hugging Face, так что начинать с нуля не придётся.
Подождать, если нужен стабильный продакшен, у вас видеокарта NVIDIA или нет желания разбираться с .loom и агентным скиллом. В этом случае разумнее остаться на llama.cpp и вернуться к Loom, когда появится бэкенд hrx-loom для llama.cpp или независимые замеры на вашей платформе.
Самый дешёвый способ составить мнение: поставить пакет, прогнать loom-fetch и loom-serve на одной модели, которую вы хорошо знаете, и сравнить скорость с привычным бэкендом. Полчаса работы дадут больше, чем любые чужие цифры.