Экосистема AI Vibe
Jev на одном TPU v6e: что влезает, что стоит и почему GPU-пайплайн чтения labels ломается
Три развилки для соло, который сам поднимает inference под классификацию или ветвление агента: какой чекпоинт Gemma 4 реально стартует на одном чипе, как vLLM на TPU режет log-probabilities до top-32 и что это делает с «уверенностью» модели, и когда более быстрый ответ не окупает счёт за миллион решений. В замере автор прогнал Jev-style decision read через vLLM на TPU v6e, сравнил с NVIDIA L4 и с опубликованными цифрами Jev 1.13.0; код и пререгистрация открыты.
Один чип: память, READY и таблица «что влезает»
На TPU v6e в эксперименте 31,24 GiB HBM; vLLM резервирует под модель до 28,74 GiB. В этом коридоре поднялись Gemma 4 E2B, E4B, 12B (bf16) и 26B-A4B в fp8 (26,67 GiB на диске); время до READY: от 346 до 616 секунд в зависимости от размера.
Два варианта 31B (w4a16 и 4-bit AWQ, от 19,47 до 21,67 GiB на диске) падают примерно через 120 секунд с одной и той же ошибкой JAX-пути vLLM: схема compressed-tensors для слоя attention пока не реализована. Gemma 4 на TPU идёт только через JAX; fp8 для 26B работает, плотная 4-bit пока нет. Единственный fp8-чекпоинт 31B в пререгистрации (30,98 GiB) выше usable memory одного чипа, в замере его не запускали.
Для сравнения платформ на той же L4 (g6.xlarge) под модель ушло 23034 MiB. Если вы выбираете «один инстанс под decision-сервис», таблица fit не абстракция: это граница между «сервис поднялся» и «час дебага OOM».
| Размер | Чекпоинт | Формат | Serves на v6e |
|---|---|---|---|
| E2B | google/gemma-4-E2B-it |
bf16 | да |
| E4B | google/gemma-4-E4B-it |
bf16 | да |
| 12B | google/gemma-4-12B-it |
bf16 | да |
| 26B-A4B | RedHatAI/gemma-4-26B-A4B-it-FP8-dynamic |
fp8 | да |
| 31B (два кванта) | см. пост | w4a16 / 4-bit | нет |
Как decision model читает labels и чем TPU отличается от L4
Jev-style read здесь не «свободный текст ответа», а вероятности по разрешённым label-токенам: промпт обрывается перед ответом, берутся scores только по whitelist label’ов, softmax считают только по ним. Hosted TypeSafe Jev использует тот же паттерн; открытая Gemma читается аналогично.
На GPU (L4) запрос log-probabilities идёт по конкретным token id label’ов. На TPU бэкенд vLLM отдаёт только top-k log-probabilities; прямой запрос по logprob_token_ids даёт 500 (list index out of range). Рабочий обход в замере: JEV_TOPK=32, label’ы из top-32; если label внутри 32, logprob точный, снаружи fallback (минимальный возвращённый logprob минус 5).
На четырёх задачах по 300 примеров хотя бы один label всегда попадал в top-32, и предсказанный label совпал с exact-read. Сдвиг raw ECE от fallback < 0,001; после калибровки на 50 labels ECE ≤ 0,005. Когда ветка агента смотрит на label_mass или калибровку, это важнее сырой accuracy: усечённый API может не менять класс, но искажать уверенность.
Стек serving в замере: VM ct6e-standard-1t, образ vllm/vllm-tpu с pin на digest из поста, vLLM 0.29.1rc1, флаги вроде --max-logprobs 32, --max-model-len 2048, prefix caching; KV на v6e по умолчанию fp8_e5m2, на L4 16-bit.
Скорость, доллар за решение и сверка с Jev 1.13.0
Для 26B latency одного решения на v6e от 27 до 33 ms против 61 ms на L4, примерно 2× по задержке. On demand в europe-west4 час v6e стоит $2,97, L4 на g6.xlarge $0,8048. В пересчёте на миллион decisions для 26B: $10,37 на TPU против ≤ $5,43 на L4; для 12B на TPU $8,19. TypeSafe Jev в том же сравнении $5,54 / 1M decisions (медианный prompt 132 token с L4-замера). Полный on-demand замер автора занял 48 min ($2,39), суммарное время инстанса ≤ $3,25; flex-start $1,35/ч для v6e упомянут, но capacity в момент замера не было.
На 3880 public records Bespoke Labs suite (checksums 13/13 на VM) опубликованный Jev 1.13.0 даёт 77,3% accuracy на всём срезе; 26B fp8 на TPU 76,0%, 12B 76,2%, E4B 72,8%, E2B 68,5%. Hosted Jev в этом сравнении не вызывался; цифры Jev взяты из published benchmarks на тех же records.
Согласованность TPU и L4 на тех же чекпоинтах: E2B/E4B, совпадение predicted label на 1186 и 1193 из 1200 примеров; расхождение accuracy по задаче ≤ 1,0 и 0,4 п.п. 26B fp8 на TPU против 4-bit AWQ на L4: разные квантизации, до 1,3 п.п. по задаче, 0,7 п.п. на suite.
Throughput при concurrency 8 на v6e: E2B ~274/s, E4B ~206/s, 12B ~101/s, 26B ~80/s.
12B, калибровка и три проверки перед продом
Автор для TPU-сервиса в духе Jev рекомендует Gemma 4 12B bf16 с калибровкой temperature на ~50 labels: 76,2% на suite против 76,0% у 26B fp8; median ECE после fit 0,070 (у shipped Jev 0,071). Если вы один человек и платите on demand, 12B выглядит компромиссом «почти 26B по метрикам, дешевле по $/decision, без third-party quant checkpoint».
Перед продом имеет смысл повторить три проверки из замера: (1) ваш label-set всегда попадает в top-32 при ваших промптах; (2) fallback logprob не раздувает уверенность на критичных ветках агента; (3) оговорки поста: training-data leakage, разные клиенты для timing L4 vs TPU, scope «один chip, on demand, клиент на VM». Код, пререгистрация и скрипты tpu/run.sh / tpu/serve.sh в репозитории автора.
Источники
- Пост-замер (primary): Running a Jev-Style Decision Model on One TPU v6e, доступ 2026-09-25 UTC.
- Код и пререгистрация: github.com/xbill9/gemma4-dev/tree/main/jev-tpu, доступ 2026-09-25 UTC.
- Published benchmarks Jev 1.13.0 (ссылка из References поста): PUBLIC_BENCHMARKS.md, доступ 2026-09-25 UTC.