Первый опыт запуска локальной LLM на Jetson Orin Nano
Проверим, насколько современные edge-устройства готовы к локальному запуску языковых моделей. В качестве платформы — Jetson Orin Nano Developer Kit 8GB, в качестве модели — Qwen2.5-3B-Instruct через llama.cpp.
😼 В итоге модель успешно заработала локально на GPU, но по пути встретилось несколько нюансов, о которых стоит знать заранее.
После загрузки в последовательной консоли появляется стандартный запрос входа Ubuntu:
Ubuntu 22.04.5 LTS
yahboom login:
Если используется готовый образ от производителя (например, Yahboom), первоначальная настройка пользователя уже выполнена. Вместо мастера oem-config сразу появляется приглашение к входу в систему, поэтому необходимо знать логин и пароль, заданные производителем образа. Тут придется поискать логин/пароль 🔪
Отдельный момент — перепрошивка устройства 🤔
Официальные инструменты NVIDIA для прошивки Jetson ориентированы на Linux (Ubuntu). На macOS полноценной поддержки нет, поэтому перепрошивка с Mac заметно сложнее, приходится использовать виртуальную машину, отдельный Linux-компьютер или искать неофициальные способы. Если планируется менять JetPack или восстанавливать устройство, проще заранее иметь доступ к ПК с Ubuntu.
После первого подключения оказалось, что GitHub недоступен:
fatal: Could not resolve host: github.com
Причина была в конфигурации сети.
По умолчанию устройство подняло собственную точку доступа (Jetson_Orin_Hot), а маршрут был направлен через USB-подключение к компьютеру, которое не обеспечивало доступ в интернет.
После подключения Jetson к домашнему Wi-Fi всё заработало без дополнительной настройки. Мой косяк и тупняк 🥳, но вдруг кому пригодится.
Далее был собран llama.cpp с поддержкой CUDA. Компиляция заняла значительно больше времени, чем ожидалось. Ну ничего, шалость удалась!
Производительность 👇
Замеры сделаны через llama-bench из состава llama.cpp (build 876a43211) (JP 6.2, режим питания MAXN_SUPER, jetson_clocks, графическая оболочка отключена, модель Qwen2.5-3B-Instruct в кванте Q4_K_M (1.79 GiB), все слои на GPU, flash attention включён, 5 повторов).
🤡 Без nvpmodel -m 2 и jetson_clocks результаты получаются ниже и с большим разбросом. Наверно, именно поэтому в сети гуляют замеры Orin Nano, различающиеся в разы. Плюс обратная сторона, jetson_clocks поднял потребление в простое с 4.6 до 7.0 Вт и температуру с 54 до 63 °C.
Две метрики:
🤜 pp (prompt processing) — скорость чтения того, что отправили модели (упирается в вычислительную мощность GPU).
🤜 tg (token generation) — скорость, с которой модель пишет ответ (упирается в пропускную способность памяти, поскольку на каждый токен нужно прочитать все веса).
pp512 895.27 ± 10.50 t/s
tg128 23.98 ± 0.01 t/s
Проверка теорией 😳
У Orin Nano 102 ГБ/с LPDDR5, модель весит 1.79 ГБ, потолок генерации — около 53 т/с. Достигнутые 24 т/с это 45% от паспортной полосы, что для реальной нагрузки нормально (помимо весов на каждый токен читается ещё и KV-кэш).
Деградация при росте контекста:
┌─────────┬────────┬────────┐
│ Глубина │ pp512 │ tg128 │
├─────────┼────────┼────────┤
│ 0 │ 895.3 │ 23.98 │
│ 1024 │ 866.0 │ 23.69 │
│ 4096 │ 773.3 │ 23.01 │
│ 8192 │ 667.9 │ 22.18 │
└─────────┴────────┴────────┘
На 8K контекста генерация теряет 7.5%, обработка запроса — 25%. Для практики это значит, что длинная беседа скорость ответа почти не замедляет.
Влезет ли 7B проверить руки пока не дошли
После отключения графики свободно ~5.5 ГБ из 7.6. Qwen2.5-7B в Q4_K_M это ~4.7 ГБ весов плюс около 0.5 ГБ KV-кэша на 8K контекста плюс compute buffers — влезает впритык и только headless. Ожидаемая скорость по той же формуле, 102 / 4.7 ≈ 21 потолок, реально порядка 10–12 т/с. Q5 и выше на 8 ГБ уже не поместятся. 🤨
Все!
💡
PS
В рецепте лимонного пирога первым ингредиентом идёт 200 г твёрдого сыра, потом чайная ложка соли и масло оливковое. Модель поплыла 😏.
3B на русском и вот вам лимонный пирог с грюйером! Но это уже совсем другая история!
Проверим, насколько современные edge-устройства готовы к локальному запуску языковых моделей. В качестве платформы — Jetson Orin Nano Developer Kit 8GB, в качестве модели — Qwen2.5-3B-Instruct через llama.cpp.
😼 В итоге модель успешно заработала локально на GPU, но по пути встретилось несколько нюансов, о которых стоит знать заранее.
После загрузки в последовательной консоли появляется стандартный запрос входа Ubuntu:
Ubuntu 22.04.5 LTS
yahboom login:
Если используется готовый образ от производителя (например, Yahboom), первоначальная настройка пользователя уже выполнена. Вместо мастера oem-config сразу появляется приглашение к входу в систему, поэтому необходимо знать логин и пароль, заданные производителем образа. Тут придется поискать логин/пароль 🔪
Отдельный момент — перепрошивка устройства 🤔
Официальные инструменты NVIDIA для прошивки Jetson ориентированы на Linux (Ubuntu). На macOS полноценной поддержки нет, поэтому перепрошивка с Mac заметно сложнее, приходится использовать виртуальную машину, отдельный Linux-компьютер или искать неофициальные способы. Если планируется менять JetPack или восстанавливать устройство, проще заранее иметь доступ к ПК с Ubuntu.
После первого подключения оказалось, что GitHub недоступен:
fatal: Could not resolve host: github.com
Причина была в конфигурации сети.
По умолчанию устройство подняло собственную точку доступа (Jetson_Orin_Hot), а маршрут был направлен через USB-подключение к компьютеру, которое не обеспечивало доступ в интернет.
После подключения Jetson к домашнему Wi-Fi всё заработало без дополнительной настройки. Мой косяк и тупняк 🥳, но вдруг кому пригодится.
Далее был собран llama.cpp с поддержкой CUDA. Компиляция заняла значительно больше времени, чем ожидалось. Ну ничего, шалость удалась!
Производительность 👇
Замеры сделаны через llama-bench из состава llama.cpp (build 876a43211) (JP 6.2, режим питания MAXN_SUPER, jetson_clocks, графическая оболочка отключена, модель Qwen2.5-3B-Instruct в кванте Q4_K_M (1.79 GiB), все слои на GPU, flash attention включён, 5 повторов).
🤡 Без nvpmodel -m 2 и jetson_clocks результаты получаются ниже и с большим разбросом. Наверно, именно поэтому в сети гуляют замеры Orin Nano, различающиеся в разы. Плюс обратная сторона, jetson_clocks поднял потребление в простое с 4.6 до 7.0 Вт и температуру с 54 до 63 °C.
Две метрики:
🤜 pp (prompt processing) — скорость чтения того, что отправили модели (упирается в вычислительную мощность GPU).
🤜 tg (token generation) — скорость, с которой модель пишет ответ (упирается в пропускную способность памяти, поскольку на каждый токен нужно прочитать все веса).
pp512 895.27 ± 10.50 t/s
tg128 23.98 ± 0.01 t/s
Проверка теорией 😳
У Orin Nano 102 ГБ/с LPDDR5, модель весит 1.79 ГБ, потолок генерации — около 53 т/с. Достигнутые 24 т/с это 45% от паспортной полосы, что для реальной нагрузки нормально (помимо весов на каждый токен читается ещё и KV-кэш).
Деградация при росте контекста:
┌─────────┬────────┬────────┐
│ Глубина │ pp512 │ tg128 │
├─────────┼────────┼────────┤
│ 0 │ 895.3 │ 23.98 │
│ 1024 │ 866.0 │ 23.69 │
│ 4096 │ 773.3 │ 23.01 │
│ 8192 │ 667.9 │ 22.18 │
└─────────┴────────┴────────┘
На 8K контекста генерация теряет 7.5%, обработка запроса — 25%. Для практики это значит, что длинная беседа скорость ответа почти не замедляет.
Влезет ли 7B проверить руки пока не дошли
После отключения графики свободно ~5.5 ГБ из 7.6. Qwen2.5-7B в Q4_K_M это ~4.7 ГБ весов плюс около 0.5 ГБ KV-кэша на 8K контекста плюс compute buffers — влезает впритык и только headless. Ожидаемая скорость по той же формуле, 102 / 4.7 ≈ 21 потолок, реально порядка 10–12 т/с. Q5 и выше на 8 ГБ уже не поместятся. 🤨
Все!
💡
PS
В рецепте лимонного пирога первым ингредиентом идёт 200 г твёрдого сыра, потом чайная ложка соли и масло оливковое. Модель поплыла 😏.
3B на русском и вот вам лимонный пирог с грюйером! Но это уже совсем другая история!