Автор под ником cortexist выложил форк exllamav3, в который перенёс ключевой код своего движка little-gemma V1.0, заточенного под Jetson Orin. Задача узкая: ускорить prefill для модели Gemma E4B на плате Jetson Orin Nano Super 8GB. Результат: prefill вырос, скорость decode упала, но суммарная задержка в голосовом чате всё равно оказалась ниже. Форк открыт на GitHub, готовые веса в квантовании EXL3 4.0 bpw выложены на Hugging Face.
До этого автор перебрал все практичные варианты GGUF и не получил нужного уровня производительности Gemma E4B на Jetson Orin Nano Super 8GB. То есть форк появился не как эксперимент ради интереса, а как попытка закрыть конкретный провал по скорости обработки промпта. Исходный пост на Reddit
Главный вывод автора звучит без рекламы: EXL3 на Jetson Orin Nano подходит не всем, но если нужна более высокая скорость prefill, это рабочий вариант. Ниже разберём, что именно произошло, почему decode просел и в каких сценариях такой размен оправдан.
Что случилось: форк exllamav3 для Gemma E4B на Jetson Orin
exllamav3 - движок инференса для локального запуска LLM. Автор взял его как базу, форкнул и перенёс в него ключевой код из собственного движка little-gemma V1.0. По его словам, это дало ровно тот прирост prefill, которого не хватало.
Кто такой cortexist и что такое little-gemma V1.0
cortexist - автор форка, весов и исходного материала. Публичной биографии за проектом нет, и приписывать ему лишние регалии смысла не имеет. Известно другое: он написал движок little-gemma V1.0 с прицелом на Jetson Orin и утверждает, что тот существенно обходит llama.cpp по производительности. Независимых замеров, которые это подтверждали бы, в источнике не приводится, поэтому относиться к формулировке стоит как к заявлению автора.
little-gemma V1.0 появился раньше форка и был первой итерацией под голосовой сценарий на Jetson Orin. Логика ускорения к этому моменту уже была обкатана, и её перенесли в exllamav3 как готовый блок. Отдельный практический разбор сборки голосового ассистента на базе Little Gemma, включая запуск Gemma 4 12B на настольной карте и Gemma 4 E2B на встраиваемом модуле, смотрите в материале про Little Gemma, лип-синк и открытый код.
Зачем понадобился форк exllamav3
Причина прямая. Автор перебрал все практичные варианты GGUF и всё равно не достиг идеального уровня производительности Gemma E4B на Jetson Orin Nano Super 8GB. Дальше перебирать было нечего, и он пошёл другим путём: взял exllamav3, форкнул его и перенёс код из little-gemma V1.0, чтобы вытянуть prefill.
Формулировка "не достиг идеального уровня" здесь важнее, чем кажется. Речь не о том, что GGUF-путь сломан, а о том, что конкретная модель на конкретной плате с 8 ГБ памяти упирается в потолок. Форк - это точечная настройка под одну задачу: одна модель, одна плата, один сценарий. Универсальным решением для всех Jetson его назвать нельзя.
Prefill vs decode: почему автор пожертвовал скоростью декодирования
Что такое prefill и decode на пальцах
Prefill - этап, на котором модель читает входной промпт целиком и считает контекст: системную инструкцию, историю диалога, вставки из базы знаний. Работа идёт параллельно по всем токенам промпта, поэтому чем длиннее вход, тем дороже этот этап.
Decode - пошаговая генерация. На каждый новый токен модель прогоняет очередной шаг, и токены считаются последовательно, один за другим. Время здесь растёт линейно относительно длины ответа.
Для пользователя эти два этапа превращаются в две разные метрики: prefill отвечает за время до первого токена, decode - за то, с какой скоростью текст появляется дальше.
Почему в голосовом чате выигрыш в prefill перекрывает просадку decode
В голосовом чате реплики короткие, а контекст длинный: системный промпт, история диалога, иногда результаты поиска. Человек ждёт ответа сразу после того, как договорил, и в этот момент ему важна суммарная задержка. Если prefill занимает заметную её часть, ускорение этого этапа сдвигает общую картину даже при более медленном decode.
Именно так и получилось: скорость декодирования просела, а общая задержка в голосовом чате стала ниже. Числа автор не приводит, так что перевести разницу в проценты или миллисекунды не получится. Про то, как соотношение prefill и decode меняется на длинном контексте, есть отдельный разбор сравнения TensorSharp и llama.cpp на GLM-5.3-Flash.
Обратная сторона размена тоже очевидна: там, где основной вес в задержке даёт decode (длинные ответы, кодогенерация, пакетная обработка), ускорение prefill уже не компенсирует просадку.
Как запустить: форк на GitHub и веса EXL3 4.0 bpw на Hugging Face
Что понадобится для запуска
Порог входа тут не нулевой. Как минимум нужны:
- плата Jetson Orin Nano Super 8GB;
- рабочее окружение с CUDA на базе JetPack;
- навыки сборки exllamav3 из исходников: форк опубликован на GitHub под именем пользователя cortexist;
- веса Gemma E4B в квантовании EXL3 4.0 bpw с Hugging Face (пример имени пакета: gemma-4-E4B-it-qat-exl3-4.0bpw);
- готовность к ручной отладке, если сборка или запуск пойдут не с первого раза.
Установщика в один клик нет. Это сборка движка из исходников плюс загрузка весов, а не готовый продукт с графическим интерфейсом. Точные версии JetPack и команды сборки в источнике не приводятся, поэтому их придётся подбирать по документации репозитория.
Ограничения квантования EXL3 4.0 bpw
EXL3 - формат квантования, в котором выложены готовые веса. Обозначение 4.0 bpw значит примерно 4 бита на вес: модель занимает меньше памяти, но часть точности теряется. На плате с 8 ГБ общей памяти этот параметр критичен, потому что именно он определяет, влезет модель целиком или нет.
Сравнения качества EXL3 и GGUF между собой в источнике нет, как нет и замеров perplexity. Поэтому утверждать, что один формат точнее другого, оснований не хватает. Практический вывод проще: 4.0 bpw - компромисс между размером и точностью, и на 8 ГБ экономия памяти весит больше, чем на карте с 24 ГБ.
Схожие идеи встречаются и в других проектах: в разборе движка Gem16 для Gemma4 12B и 26B на 16 ГБ VRAM тоже используется собственная квантизация в стиле EXL3. А как EXL3 ведёт себя на другой модели и другом железе, видно в опыте запуска Flash Next через ExllamaV3 с квантом exl3 3bpw: около 80 токенов/с prefill на трёх RTX 3090 против 29 токенов/с на одной RTX 5090 при контексте 262k.
Сравнение с llama.cpp и GGUF: что не получилось и почему
Почему GGUF-варианты не дали идеальной производительности
Технических деталей автор не раскрывает, и придумывать причины не стоит. Известен результат: все практичные варианты GGUF были перебраны, идеального уровня для Gemma E4B на Jetson Orin Nano Super 8GB достичь не удалось. Это мотивация для форка, а не доказательство, что GGUF плох. Формат и рантайм llama.cpp поддерживают огромный зоопарк моделей и работают на большинстве платформ.
Когда llama.cpp остаётся лучшим выбором
llama.cpp - зрелый проект с широкой поддержкой моделей и форматов, понятной установкой и живым сообществом. Оставайтесь на нём, если хотя бы один пункт про вас:
- задача не требует выжимать prefill на Jetson Orin;
- вы работаете с моделями, для которых нет весов в формате EXL3;
- вам важнее скорость decode, а не время до первого токена;
- вы не хотите собирать движок из исходников и разбираться с ошибками сборки.
Кому подходит EXL3 на Jetson Orin, а кому нет
Сценарии, где выигрыш в prefill критичен
Голосовой чат с длинным системным промптом и историей диалога. Ассистент, который на каждый запрос подмешивает контекст из RAG. Интерактивные сценарии, где человек ждёт ответ сразу после реплики, а не через несколько секунд. Во всех этих случаях prefill формирует основную долю задержки, и его ускорение заметно на глаз.
Сценарии, где просадка decode перевесит
Длинная генерация текста, кодогенерация, пакетная обработка, реферирование больших документов. Здесь пользователь ждёт готовый результат, а не первый токен, и более медленный decode скажется сильнее, чем поможет быстрый prefill.
Риски перечислю прямо. Числовых замеров в источнике нет, только качественные сравнения, так что оценить величину выигрыша заранее не получится. Идеальный уровень производительности Gemma E4B на Jetson Orin Nano Super 8GB так и не достигнут. Решение узкое: конкретная модель, конкретная плата, ручная настройка. Всё это делает предварительную оценку на бумаге почти бесполезной, тестировать придётся на своей задаче.
Итог: стоит ли пробовать форк exllamav3 на Jetson Orin
Форк exllamav3 с кодом из little-gemma V1.0 - рабочий практический кейс под одну задачу: Gemma E4B на Jetson Orin Nano Super 8GB, где prefill важнее decode. Код опубликован на GitHub под ником cortexist, веса в EXL3 4.0 bpw лежат на Hugging Face. Проект открыт, повторить конфигурацию можно.
Что делать дальше, зависит от вашего профиля нагрузки. Сначала посмотрите, какой этап у вас узкое место: если при длинном промпте раздражает время до первого токена, а скорость генерации вторична, форк стоит попробовать. Если основной сценарий - длинные ответы и код, оставайтесь на llama.cpp, там компромисс не в вашу пользу. И в любом случае сверяйтесь с показателями на своём железе, а не с чужими формулировками вроде "существенно быстрее": выше головы Jetson Orin Nano Super 8GB всё равно не прыгнет.