Перейти к содержанию
Публикация AiManual

Форк Strata для Jetson AGX Orin 64GB: запуск Qwen3.6-35B-A3B и разбор замеров скорости

Автор выложил форк Strata v0.1.45 под Jetson AGX Orin 64GB и запустил на нём Qwen3.6-35B-A3B. Разбираем замеры 21, около 30 и 40-41 tok/s, три новые функции дви

Коротко

Что будет в материале

  1. 01

    Что за форк Strata-Orin и кому он адресован

  2. 02

    Замеры скорости: 21, около 30 и 40-41 tok/s, что за ними стоит

  3. 03

    Что дают новые функции форка на практике

  4. 04

    Ограничения и риски: что автор честно оговаривает

Пользователь No-Setting8461 выложил форк Strata v0.1.45, адаптированный под Jetson AGX Orin с 64 ГБ памяти, и запустил на нём Qwen3.6-35B-A3B. Код открыт на GitHub в репозитории moontato/Strata-Orin, оригинальному проекту Strata автор отдаёт должное как основе. Это личная адаптация под конкретную плату и конкретную модель, а не официальный релиз движка.

Три числа из поста: около 21 tok/s декодирования с MTP-3 в llama.cpp, порядка 30 tok/s в более ранних прогонах Strata и 40-41 tok/s на коротких промптах при включённом sampled MTP-2. Автор сразу оговаривает, что парных бенчмарков llama.cpp против Strata не проводил, поэтому цифры описывают только его сетап.

Поверх базовой версии в форке появились три механизма: унифицированный INT8 KV-кэш, префиксные чекпоинты и опциональное предвыделение KV. Разработка шла с активным использованием AI-ассистентов, об этом автор пишет прямо.

Что за форк Strata-Orin и кому он адресован

Публикация появилась 25 октября 2026 года в r/LocalLLaMA: Strata Optimized for 64GB AGX Orin. Задача, которую автор ставил перед собой, скромная: получить рабочий инференс Qwen3.6-35B-A3B на одной плате Jetson AGX Orin 64GB и посмотреть, что выйдет по скорости.

Чем форк отличается от оригинальной Strata

За базу взята Strata v0.1.45. Движок не переписан с нуля: правки касаются памяти под KV-кэш и работы с повторяющимися промптами. В посте перечислены три добавления.

  • Унифицированный INT8 KV-кэш: ключи и значения хранятся в 8-битном формате.
  • Префиксные чекпоинты: сохранение посчитанного состояния по префиксу промпта.
  • Опциональное предвыделение KV: память под кэш резервируется заранее, по желанию пользователя.

Что даёт каждый пункт и где подвох, разберём ниже. Здесь важен масштаб: это правки к одному движку под одно железо, а не новая архитектура инференса. Сама Strata изначально появилась как движок под конкретную модель и недорогое железо, а поддержка Qwen 3.6 35B уже есть в апстриме, что это даёт на практике и какие компромиссы накладывают 16 ГБ VRAM.

Отдельный пункт, который автор не скрывает: heavy AI-assisted / vibe-coded. Часть кода написана AI-ассистентами под его контролем. На доверие к проекту это влияет не напрямую: работоспособность проверяется сборкой и прогоном, а не способом написания кода. Но при чтении diff это стоит держать в голове.

Кому материал полезен, а кому нет

Полезен, если выполняются три условия:

  • у вас Jetson AGX Orin с 64 ГБ памяти и вы запускаете на нём локальные LLM;
  • вас интересует Qwen3.6-35B-A3B или похожие MoE-модели, которые упираются в память;
  • вы готовы собирать из исходников и присылать замеры.

Менее полезен владельцам Orin Nano, Orin NX 16GB и Xavier: форк заточен под 64 ГБ общей памяти, на 8-16 ГБ сценарий меняется полностью.

Почти бесполезен, если вы не запускаете LLM локально или вам нужна готовая продакшен-сборка с гарантией стабильности. Автор тестировал форк только на своём Orin и прямо просит отзывы других владельцев платы. Других отчётов в источнике нет.

Замеры скорости: 21, около 30 и 40-41 tok/s, что за ними стоит

Свести три цифры в одну кривую нельзя: они получены в разных режимах и на разных сборках. Ниже условия каждого замера в том виде, как их описывает автор.

ЗамерДвижок и режимУсловияРезультат
1llama.cpp, MTP-3декодирование, конфигурация автораоколо 21 tok/s
2Strata, более ранние прогонычто именно было включено, в посте не уточняетсяоколо 30 tok/s
3Strata-Orin, sampled MTP-2контролируемые тесты на коротких промптах40-41 tok/s

Ключевая переменная во всех трёх случаях, режим MTP (multi-token prediction, спекулятивное декодирование). В llama.cpp использовался MTP-3, в лучшем прогоне Strata-Orin sampled MTP-2. Это разные настройки с разной долей принятых спекулятивных токенов и разной нагрузкой на движок, поэтому сравнивать их напрямую некорректно.

Почему 40-41 tok/s нельзя считать универсальным результатом

Формулировка автора звучит как latest controlled short-prompt tests. Значимых слов два: controlled и short-prompt. Контролируемый тест означает фиксированные условия внутри одной серии, короткий промпт означает малую долю префилла в общей задержке. В свободном чате с длинной историей и большим системным промптом картина будет другой, но автор таких замеров не приводит. Переносить 40-41 tok/s на любые сценарии не стоит.

Для 35B MoE-модели на Orin важен и prefill: время до первого токена определяется обработкой промпта, а не скоростью декодирования. Метрики tok/s decode и tok/s prefill смешивать нельзя, иначе сравнение теряет смысл.

Как читать такие цифры, чтобы не обмануться

Чек-лист для любого чужого бенчмарка локальной LLM:

  • зафиксирован ли режим MTP и какая именно версия (MTP-3, sampled MTP-2, без спекуляции);
  • длина промпта и длина контекста на момент замера;
  • тип KV-кэша: FP16, INT8 или иной;
  • версия сборки или коммит, а также флаги запуска;
  • железо целиком, включая режим питания платы;
  • какая метрика измерялась: decode, prefill или время до первого токена.

Если хотя бы один пункт не совпадает, разница в ток/с может объясняться им, а не движком. Для сравнения с llama.cpp нужен парный прогон на одной модели, одном кванте и одном промпте, иначе выводы шаткие.

Что дают новые функции форка на практике

У Jetson AGX Orin память общая: 64 ГБ LPDDR5 делят CPU и GPU. Любая экономия на KV-кэше конвертируется в доступный контекст и в запас под веса, буферы и служебные структуры движка.

INT8 KV-кэш: экономия памяти под длинный контекст

KV-кэш растёт линейно с длиной контекста и числом слоёв. На 35B-модели при длинных диалогах он занимает заметную долю бюджета. Хранение ключей и значений в INT8 вместо FP16 примерно вдвое сокращает этот объём: 8 бит на значение вместо 16. Практический выигрыш в том, что тот же лимит памяти вмещает более длинный контекст или оставляет больше запаса под остальное.

Плата за это стандартная для квантования: возможная потеря точности. Автор не приводит замеров качества, поэтому утверждать ни деградацию, ни её отсутствие нельзя. Проверять нужно на своих задачах. Похожая логика уже разбиралась на примере настроек Strata 0.1.45, которые незаметно портят качество вывода: два параметра движка при бюджете 64 ГБ RAM.

Префиксные чекпоинты и предвыделение KV: зачем это в быту

Префиксные чекпоинты сохраняют посчитанное состояние по префиксу промпта. Если системный промпт и начало диалога не меняются, движку не нужно пересчитывать их на каждом запросе. Экономия уходит в prefill, а он на Orin обычно и определяет время до первого токена. В агентских сценариях, где один и тот же длинный системный промпт повторяется десятки раз подряд, эффект заметнее всего.

Предвыделение KV резервирует память под кэш заранее. Смысл в предсказуемости: длинная сессия не упирается в OOM на середине из-за фрагментации. Минус очевиден: зарезервированное под кэш не отдаётся другим частям движка, поэтому польза зависит от сценария.

Отдельных цифр ускорения для этих двух функций автор не публикует. Любые проценты здесь были бы выдумкой.

Ограничения и риски: что автор честно оговаривает

Оговорки автора меняют интерпретацию цифр, поэтому их стоит прочитать целиком:

  • замеры не парные: llama.cpp и Strata сравнивались в разных условиях;
  • все результаты получены на одной конфигурации и описывают только её;
  • лучший результат относится к контролируемым тестам на коротких промптах;
  • форк проверен только на Orin автора, отзывов от других владельцев пока нет;
  • разработка велась heavy AI-assisted, о чём автор сообщает сам;
  • v0.1.45 это база форка, а не гарантия стабильности конкретной сборки.

Почему отсутствие парного бенчмарка - важное ограничение

Разница между «у меня в прогонах вышло 40-41 tok/s» и «Strata быстрее llama.cpp» принципиальная. Первое, наблюдение в одной точке. Второе, вывод, который требует одинаковой модели, одинакового кванта, одного промпта, одинаковой длины контекста и одинакового режима декодирования. Здесь наборы условий расходятся: MTP-3 в llama.cpp против sampled MTP-2 в Strata.

Корректная формулировка: в конфигурации автора на коротких промптах sampled MTP-2 дал 40-41 tok/s, и это выше его же более ранних прогонов Strata с примерно 30 tok/s. Из этого не следует, что Strata-Orin обгоняет llama.cpp в общем случае, и не следует, что на вашем Orin цифры повторятся.

AI-ассистенты в разработке: на что смотреть при проверке кода

Автор сам раскрывает степень участия AI, и это скорее плюс: читатель знает, чего ждать. Практический вывод простой. Перед сборкой пройдитесь по diff, посмотрите открытые issues, проверьте, что INT8 KV-кэш, префиксные чекпоинты и предвыделение действительно включаются и работают, а не только перечислены в описании. Код, написанный с AI-ассистентом, может быть вполне рабочим, но ревью перед использованием на важных задачах всё равно нужно.

Стоит ли пробовать Strata-Orin на своём Jetson AGX Orin 64GB

Решение зависит от того, что вам нужно от платы. Сценарии, где попробовать осмысленно:

  • есть Jetson AGX Orin 64GB и вы уже запускаете Qwen3.6-35B-A3B или другие MoE-модели;
  • интересует именно скорость декодирования на коротких промптах в чате и агентских вызовах;
  • вы готовы собрать проект из исходников и вернуть автору замеры, он об этом прямо просит.

Сценарии, где лучше подождать:

  • нужна стабильная сборка под продакшен, а не эксперимент;
  • железо отличается от Orin 64GB: Orin Nano, Orin NX 16GB, десктопные GPU;
  • нет времени на отладку и чтение diff.

Полезно для калибровки ожиданий: на десктопе Qwen3.6-35B-A3B в кванте Q4_K_M на RTX 2060 с 6 ГБ VRAM в форке ik_llama.cpp выдаёт 45-48 т/с, с механике размещения экспертов и ограничениях одиночного теста. Другое железо, другие условия, прямой перенос цифр на Orin невозможен.

Как подойти к собственным замерам, чтобы они были сопоставимы

  1. Зафиксируйте режим MTP и запишите его в отчёт: MTP-3 и sampled MTP-2 дают разную скорость.
  2. Замерьте отдельно короткий промпт и промпт на несколько тысяч токенов.
  3. Укажите тип KV-кэша и то, включено ли предвыделение.
  4. Сохраните версию сборки или коммит.
  5. Прогоните llama.cpp и Strata-Orin на одном промпте, одном кванте и одной модели.
  6. Считайте отдельно prefill и decode, плюс время до первого токена.

Такой протокол даёт цифры, которые можно сравнивать между собой и с чужими отчётами. Пример аккуратного подхода к замерам на нестандартном железе: форк Strata под IBM AC922, где prefill и decode считались раздельно и на разных типах текста.

Итог: что мы реально знаем о Strata-Orin

По факту есть форк Strata v0.1.45 под Jetson AGX Orin 64GB с тремя добавлениями (унифицированный INT8 KV-кэш, префиксные чекпоинты, опциональное предвыделение KV), открытый код в репозитории moontato/Strata-Orin и три числа с разными условиями: около 21 tok/s в llama.cpp с MTP-3, около 30 tok/s в ранних прогонах Strata и 40-41 tok/s в контролируемых тестах на коротких промптах с sampled MTP-2.

Это кейс одного автора на одной плате, а не отраслевой бенчмарк. Если у вас есть Orin 64GB, самый полезный шаг сейчас: собрать форк, прогнать свой промпт по протоколу выше и отправить результат автору, именно на такие отчёты он и рассчитывает. Первоисточник со всеми формулировками и обсуждением: пост в r/LocalLLaMA.

Подписаться на канал