Экосистема AI Vibe
Gemma 4 E2B на EC2 G5g: свой inference там, где готовых сборок нет
Соло-разработчик, который поднимает LLM у себя в облаке вместо управляемого API, упирается не в выбор фреймворка, а в дыры экосистемы под редкое железо. На связке aarch64 + SM 7.5 — единственной у AWS на инстансах G5g — готовые артефакты для vLLM не покрывают архитектуру, а узкое место оказывается вовсе не в драйвере. В полевом отчёте разобран деплой Gemma 4 E2B через vLLM на g5g.4xlarge: что AWS уже закрыл в AMI, что придётся собирать вручную и почему без патча attention-ядра модель не стартует.
Почему aarch64 и Turing — мёртвая зона для готовых образов
Инстанс G5g — единственный тип в AWS, где NVIDIA GPU стоит за Graviton-хостом. На тестовой конфигурации g5g.4xlarge — Graviton2 плюс одна NVIDIA T4G с compute capability 7.5 и 15 360 MiB видеопамяти. Другого сочетания aarch64 + SM 7.5 в линейке AWS нет; индустрия давно сместилась к Grace и SM 9.0/10.0.
Для локального inference это значит одно: экосистема не держит эту платформу в приоритете. Образ vllm/vllm-openai arm64 (v0.27.1) перечисляет arch 8.0…12.0, тогда как amd64-вариант включает 7.5. На arm64 sm_75 отсутствует — и vLLM не деградирует в JIT из PTX: PTX-флаг отфильтровывается, на устройстве остаётся no kernel image is available for execution on the device.
| Артефакт | sm_75 на arm64 | Состояние |
|---|---|---|
vllm/vllm-openai arm64 |
нет | единственное расхождение arch lists с amd64 |
nvcr.io/nvidia/pytorch arm64 |
до 24.10 | убрано к 24.12 |
drikster80/vllm-aarch64 |
да | заброшен (сент. 2024), vLLM 0.6.1 — слишком стар для Gemma 4 |
PyPI torch aarch64 |
нет | 9.0 / 10.0 / 12.0 |
| AWS ARM64 GPU DLAMI | да | PyTorch 2.2–2.12 |
Сторонние колёса и контейнеры не спасают: придётся либо менять железо, либо собирать inference-стек под Turing на arm64 с нуля.
Что AWS уже закрыл в DLAMI — и что остаётся на вас
Формулировка «AWS тихо решает половину проблемы» относится не к драйверу и не к «магии» AMI, а к PyTorch на aarch64 с поддержкой sm_75. На Deep Learning ARM64 GPU AMI проверено:
torch 2.7.0+cu128→['sm_75', 'sm_90', 'sm_100', 'sm_120']torch 2.12.0+cu132→['sm_75', 'sm_80', 'sm_90', 'sm_100', 'sm_110', 'sm_120']
AWS продаёт G5g — значит, сохраняет Turing в сборке PyTorch вплоть до 2.12 на CUDA 13.2. Собирать из исходников нужен только vLLM со своими CUDA-ядрами, не весь PyTorch.
Из коробки DLAMI не даёт nvcc и полный CUDA toolkit. Перед сборкой vLLM понадобятся cuda-toolkit-13-2 из sbsa-репозитория NVIDIA (не x86) и Rust toolchain для vllm-rs / setuptools_rust. Базовый образ в отчёте — Deep Learning ARM64 AMI OSS Nvidia Driver GPU PyTorch 2.12 (Ubuntu 24.04).
Для соло-workflow вывод простой: половина пути — в правильной AMI, вторая — в часах компиляции и отладки ядер под вашу GPU.
Лимит 64 KiB shared memory: где ломается Gemma 4
Жёсткий блокер — не Docker и не версия CUDA, а attention backend под конкретную архитектуру модели. Gemma 4 E2B (google/gemma-4-E2B-it) имеет гетерогенные размеры голов: sliding layers — 256, global layers — 512. FA4 недоступен, vLLM принудительно выбирает TRITON_ATTN — в v0.27 переменная VLLM_ATTENTION_BACKEND игнорируется с предупреждением.
Triton unified attention kernel при head_size=512 запрашивает около 96 KiB shared memory на блок. У NVIDIA T4G статический лимит — 48 KiB; с dynamic shared memory потолок — 64 KiB (65 536 байт). Ошибка на железе: Required: 98304, Hardware limit: 65536.
Фикс из отчёта — локальный патч vllm/v1/attention/ops/triton_unified_attention.py: уменьшение KV-тайлов и launch_num_stages = 1 для pre-Ampere (capability < 8). Патч не в upstream vLLM; при апгрейде vLLM его придётся повторять.
Сборка vLLM и минимальный чеклист деплоя
Минимальная версия vLLM для Gemma 4 — v0.27.2rc0+: на v0.26.0 и v0.27.1 падает AmbiguousGlobalPerLayerAttributeError на head_dim. Сборка с TORCH_CUDA_ARCH_LIST=7.5 и use_existing_torch.py; CMake фиксирует -- CUDA target architectures: 7.5. На g5g.4xlarge при MAX_JOBS=12 компиляция заняла около 67 минут — значительная доля ушла на FlashAttention для arch sm80+, неприменимых на T4G.
Параметры сервинга из отчёта:
| Параметр | Значение |
|---|---|
| Модель | google/gemma-4-E2B-it (reference bf16) |
| Инстанс | g5g.4xlarge |
| Стек | torch 2.12.0+cu132 · CUDA 13.2 · vLLM v0.27.2rc0+ |
| Сервинг | --dtype float16, --kv-cache-dtype auto |
| Обязательно | патч Triton attention для Turing |
TORCH_CUDA_ARCH_LIST=7.5 python use_existing_torch.py
Начинать стоит с последнего релиза vLLM и откатываться только с явной фиксацией блокера — иначе легко застрять на старой версии, которая Gemma 4 просто не понимает.
Как не обмануться health-check'ом и цифрами
После патча engine init занял около 76,4 с; single-stream greedy — 43,1 tok/s при длине 256; KV cache — 2,95 GiB на 329 579 токенов; при сервинге занято 13 501 из 15 360 MiB GPU memory. Это единичный замер, нижняя граница, не характеризация — сравнивать с Inferentia (~44 tok/s E2B) бессмысленно: другой контур тестов и другой кремний.
Ловушка на финише — endpoint /v1/completions: может вернуть мусор (': ok: ok: ok: ok'), а не пустое тело. Проверять нужно /v1/chat/completions.
Конфигурация g5g.xlarge (8 GiB host RAM) против 9,5 GiB весов модели не тестировалась — гипотеза про mmap через safetensors остаётся гипотезой.
Если вы держите inference локально или на своём облаке, этот кейс — напоминание: редкая GPU-архитектура бьёт не по лицензии модели, а по тайлам в attention-ядре и по списку arch в Docker Hub. Закладывайте время на сборку, патч и повтор при каждом мажорном апгрейде vLLM.
Источники
- Running Gemma 4 on EC2 G5g: Graviton2 AMD with NVIDIA GPU — Dev.to, автор xbill; дата публикации 13 августа 2026; доступ 14 августа 2026 (UTC).