ZSE - open-source движок для запуска LLM локально на GPU - 2026

Published: 2026-08-16

Видеокарта NVIDIA Tesla A100 — одна из целевых платформ ZSE (Wikimedia Commons, CC BY-SA 4.0)

Что такое ZSE

ZSE (Zero-dependency Server Engine) — это open-source движок для запуска больших языковых моделей (LLM) на GPU, развиваемый компанией Zyora Labs под лицензией Apache 2.0. По назначению это прямой аналог vLLM: движок принимает модель (Qwen, Mistral, Llama, Gemma, Phi и другие), загружает её в память видеокарты и предоставляет наружу OpenAI-совместимый API, к которому можно подключать любые существующие приложения — от простых чат-клиентов до Aider, собственных сервисов и пайплайнов RAG.

Главная особенность, отличающая ZSE от всех остальных движков инференса, — полный отказ от стандартного ML-стека. В проекте нет ни PyTorch, ни Triton, ни Transformers, ни bitsandbytes, ни accelerate. Весь стек — от компилятора GPU-ядер до HTTP-сервера — написан на чистом Python с использованием ctypes и собственного компилятора, который умеет генерировать код сразу для трёх платформ: NVIDIA CUDA, AMD ROCm (HIP) и Apple Metal.

Позиционирование проекта сформулировано в его слогане: «Самый быстрый холодный старт. Самый маленький след в памяти. На любом GPU» («The fastest cold start. The smallest memory footprint. On every GPU»). Согласно заявленным авторами тестам, ZSE загружает модель Qwen2.5-7B в INT4 за 5–7 секунд и умещается в ~6 ГБ VRAM на видеокарте NVIDIA T4, тогда как vLLM на той же модели требует порядка 14 ГБ и минут на загрузку.

Схема работы выглядит так:

LLM model (.zse файл)
       ↓
      ZSE
       ↓
OpenAI-совместимый API (localhost:8000/v1)
       ↓
твой клиент / приложение / Aider / собственный сервис

Зачем это нужно: проблема классических движков

Чтобы понять мотивацию авторов ZSE, нужно посмотреть, из чего состоит типичный современный движок LLM-инференса вроде vLLM:

PyTorch — фреймворк для тензорных вычислений, тянет за собой сотни мегабайт зависимостей;
CUDA toolkit / cuDNN — несколько гигабайт на диске;
Triton — компилятор GPU-ядер, используемый vLLM для многих операций;
transformers / accelerate — библиотеки для работы с моделями Hugging Face;
bitsandbytes, safetensors, tokenizers и прочие вспомогательные пакеты.

В итоге установка типичного движка весит около 3 ГБ, а холодный старт (загрузка модели, инициализация CUDA-контекста, десериализация весов safetensors) занимает от 30 секунд до нескольких минут. Помимо этого, PyTorch-аллокатор памяти часто захватывает всю видеопамять GPU целиком (так называемый preallocation), из-за чего на одной карте нельзя разместить несколько моделей, даже если фактически они занимают лишь часть VRAM.

Авторы ZSE решили убрать этот слой целиком: модель заранее конвертируется в собственный двоичный формат .zse с предквантованными весами и mmap-отображением, а все GPU-ядра генерируются и компилируются собственным компилятором через NVRTC/HIPRTC/Metal. Результат — установка пакета весит около 5 МБ, а загрузка модели занимает секунды.

История и статус проекта

ZSE развивался в два крупных этапа:

Версии 1.x (до 2026-03) — движок с двойным бэкендом: собственные ядра + bitsandbytes для квантованных операций. Пакет назывался zllm-zse. Последний релиз этой эпохи — 1.4.1 от 2 марта 2026 года.
Версия 2.0.0 (22 мая 2026) — полная переработка под названием «The Own Everything Release». Все зависимости от PyTorch, Triton, transformers, bitsandbytes и accelerate удалены; пакет переименован в zse-engine; введён новый формат .zse v2; появился отдельный самодостаточный пакет-компилятор zse-compiler. Размер установки сократился с ~3 ГБ до ~5 МБ.

На момент написания статьи (август 2026) репозиторий Zyora-Dev/zse содержит:

72 коммита в основной ветке;
около 50 600 строк Python-кода;
201 звезду и 11 форков;
1 открытый issue и 2 pull request;
версию пакетов 2.0.1.

Проект поддерживается компанией Zyora Labs (штаб-квартира в Нагеркойле, Индия). AMD-часть (валидация на MI300X, бенчмарки 32B-модели, значительная доля разработки ROCm-ядер) выполнена при поддержке грантовой программы DigitalOcean Open Source Sponsorship Program.

Архитектура

ZSE состоит из двух pip-пакетов:

zse-compiler — компилятор GPU-ядер, полностью самостоятельный и работающий без зависимостей (dependencies = []);
zse-engine — сам движок, зависящий только от zse-compiler.

Общая архитектура движка (по описанию в README):

┌───────────────────────────────────────────────────────────────────┐
│  HTTP / SSE · OpenAI API · Web-дашборд · API-ключи + RAG         │
├───────────────────────────────────────────────────────────────────┤
│           ZStreamer — continuous batching, планировщик           │
├───────────────────────────────────────────────────────────────────┤
│  Оркестратор  │  KV-кэш (PagedAttention)  │  Менеджер LoRA       │
│  29 GPU-ядер  │  адаптивные блоки · evict │  hot-swap            │
├───────────────────────────────────────────────────────────────────┤
│  Формат .zse  │  VRAM-аллокатор (unified) │  CUDA/HIP Graphs     │
├───────────────────────────────────────────────────────────────────┤
│         ZSE Kernel Compiler — Python DSL → GPU-код               │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────────────┐   │
│   │  CUDA C     │    │  HIP C      │    │  Metal Shading Lang │   │
│   │  (nvrtc)    │    │  (hiprtc)   │    │  (компилятор Metal) │   │
│   └─────────────┘    └─────────────┘    └─────────────────────┘   │
└───────────────────────────────────────────────────────────────────┘
          Нет PyTorch · Нет Triton · Нет transformers

Рассмотрим каждый слой подробнее.

Компилятор GPU-ядер (zse-compiler)

Компилятор позволяет писать GPU-ядра на чистом Python с помощью декоратора @zse.kernel. При объявлении функции её исходный код парсится через модуль ast в промежуточное представление (IR, 25+ типов узлов), проходит валидацию, вывод типов и фазу фьюжена, после чего генерируется исходный код на CUDA C, HIP C или Metal Shading Language.

Пример из документации пакета:

import zse_compiler as zse

@zse.kernel
def vector_add(a: zse.Tensor, b: zse.Tensor, out: zse.Tensor):
    idx = zse.global_id(0)
    out[idx] = a[idx] + b[idx]

print(vector_add.source("cuda"))      # сгенерированный CUDA C
vector_add.compile(backend="cuda")    # компиляция
vector_add.launch(grid=(N // 256,), block=(256,), args=(a, b, out))

Возможности DSL:

варп-примитивы: shuffle (down/up/xor/idx), reduce, ballot, vote, идентификаторы lane/warp;
векторизованная работа с памятью: float4, half2;
блок-редукции (двухступенчатая: варп + shared memory);
тилинговая DSL (tile_load/tile_store с предикацией границ);
фьюжен ядер (zse.fuse()) — устранение промежуточных обращений к глобальной памяти;
тензорные ядра NVIDIA: интринсики WMMA (wmma_load_a/b, wmma_mma, wmma_store);
матричные ядра AMD CDNA: mfma_f32_16x16x16_f16, mfma_f32_32x32x8_f16;
интринсики распаковки INT4 (unpack_int4, unpack_uint4);
локальные стековые массивы (zse.local_array) и типизированное переосмысление указателей (zse.reinterpret).

В рантайме компилятор работает через ctypes с NVRTC (NVIDIA), HIPRTC (AMD) и системным компилятором Metal (Apple), что исключает необходимость в Xcode для Metal и в Triton вообще. Дополнительно есть автотюнер с профилированием событий CUDA/HIP, профайлер и дисковый кэш ядер (~/.cache/zse/kernels/): ядро компилируется один раз и далее загружается мгновенно.

Важный нюанс, который виден в исходниках: сложные ядра (де-квантизация matmul, paged attention) всё ещё написаны как «сырые» CUDA C строки и компилируются рантайм-компилятором, поскольку возможности AST-парсера пока недостаточны для сложных паттернов тилинга, shared memory и распаковки INT4. Однако ряд горячих ядер уже переписан на чистом DSL — например, bgemv_int4_wave64 и fused_rope_kv_write генерируются из Python при импорте модуля.

Формат модели .zse

Формат .zse — сердце всей идеи быстрого старта. Это один двоичный файл, содержащий всё: веса, токенизатор, конфигурацию модели и кэш ядер.

Спецификация формата (из модуля spec.py):

магическая сигнатура ZSE\x01, версия 1;
заголовок 64 байта + CRC32 + таблица секций по 32 байта;
секции: CONFIG, TOKENIZER, WEIGHT_INDEX, WEIGHT_DATA, KERNELS;
веса выровнены по границе страницы (4096 байт) — файл готов к mmap;
тензоры внутри секции весов выровнены по 256 байт (кэш-линия GPU);
флаги: HAS_TOKENIZER, HAS_KERNELS, MMAP_READY.

Квантование — асимметричное INT4 с групповыми масштабами и нулевыми точками. Каждая группа из 128 весов квантуется независимо:

scale = (max - min) / 15
zero  = min
q[i]  = clamp(round((w[i] - zero) / scale), 0, 15)

Упаковка: два значения INT4 в один байт (сначала младший ниббл). Масштабы и нулевые точки хранятся в float16. Квантование выполняется в момент конвертации модели, а не при загрузке, поэтому рантайм не платит налог на десериализацию и квантование.

Критически важные для качества тензоры (эмбеддинги, layernorm-ы, все bias) автоматически остаются в FP16 — для них в спецификации предусмотрен список исключений NO_QUANTIZE_PATTERNS. Также поддерживается INT8-симметричное квантование (зарезервировано) и FP16 без квантования.

Конвертация модели из Hugging Face выполняется командой zse convert. Квантование ускорено C-расширением: по заявлению авторов, конвертация работает примерно в 600 раз быстрее чистой Python-версии, поддерживает возобновление после сбоя (crash recovery) и потоковую запись.

Оркестратор и GPU-ядра

Оркестратор — это слой, исполняющий прямой проход модели. Он включает 29 GPU-ядер (18 базовых + 7 оптимизированных + 4 переписанных на портируемом DSL). Ключевые из них:

Tiled matmul с shared memory (TILE=32) — в 10–20 раз быстрее наивной реализации «один поток на один выходной элемент»;
fused residual + RMSNorm — три запуска ядра сведены в один;
пакетные RoPE / KV-write / decode — сокращение числа запусков ядер в 27 раз;
ручной wave-64 INT4 GEMV для MI300X (bgemv_int4_wave64_v2) — 128-битные загрузки весов через uint4, в 2,14 раза быстрее скалярного варианта; именно это ядро даёт значительный прирост на AMD при малых размерах батча;
фьюжен RoPE + запись в KV-кэш — устраняет промежуточный буфер K.

Для снижения латентности декодинга применяются CUDA Graphs и HIP Graphs (захват последовательности запусков ядер в единый граф), а для выборки следующего токена — оптимизированный argmax на GPU с массовым переносом результата на CPU.

Памятью управляет унифицированный VRAM-аллокатор: KV-кэш и активации живут в одном пуле, размер KV-кэша подбирается по фактическому спросу (demand-based), а не выделяется статически. При холодном старте используется серия оптимизаций: закреплённая host-память, асинхронное копирование, потоковая загрузка весов чанками по 64 МБ, posix_fadvise(WILLNEED), параллельное чтение секций, а также выделение всей памяти одним вызовом cuMemAlloc вместо 771 отдельных аллокаций.

Управление KV-кэшем

Менеджер кэша реализует PagedAttention (страничную адресацию KV-кэша) с рядом отличий от vLLM:

адаптивный размер блоков — не фиксированные 16 токенов, как в vLLM;
поуровневое вытеснение на уровне токенов — vLLM вытесняет только целые последовательности;
умная политика вытеснения — частота × давность + стоимость пересчёта (настраиваемые LRU/LFU);
дедупликация блоков по хешу FNV-1a с верификацией по равенству токенов;
COW-форкинг (copy-on-write) для beam search;
поддержка sliding-window attention.

Планировщик ZStreamer

ZStreamer — «мозг» непрерывного пакетного обслуживания (continuous batching). Его архитектура:

раздельное планирование prefill и decode — prefill-итерации обрабатывают новые промпты (высокая вычислительная нагрузка), decode-итерации — все активные последовательности (узкое место — память);
анти-burst дизайн — бюджет токенов на итерацию (по умолчанию 4096), лимит последовательностей (64), постепенная адмиссия (не более 2 новых prefill за цикл), вытеснение при нехватке памяти;
chunked prefill — длинные промпты режутся на чанки по 512 токенов;
SLO-ориентированная сортировка запросов — срочность > приоритет > время прибытия;
прогнозируемое бюджетирование памяти — предсказание потребности KV-кэша и admission control;
соотношение планирования: 4 шага decode на 1 возможность prefill.

Дополнительно реализовано спекулятивное декодирование (n-gram + self-draft с безусловным accept/reject, по схеме Leviathan/Chen): движок генерирует черновик из нескольких токенов и проверяет его параллельно, что даёт заявленный прирост пропускной способности в 2–4 раза на отдельных нагрузках.

Сервер и API

HTTP-сервер написан на чистом asyncio с собственным роутером — ни одной веб-фреймворк-зависимости. Поддерживаются:

OpenAI-совместимые эндпоинты: /v1/chat/completions, /v1/completions, /v1/models;
потоковая передача через SSE;
управление API-ключами: создание, список, отзыв (SQLite-база ~/.zse/server.db);
per-key rate limiting по RPM (запросов в минуту) и TPM (токенов в минуту);
админ-API, LoRA-менеджмент API, RAG-ingest API;
веб-дашборд для чата и управления сессиями;
при первом запуске генерируется админ-ключ вида sk-zse-admin-<hex>.

Встроенный RAG

ZSE включает полноценный RAG-стек без дополнительных моделей и зависимостей:

гибридный поиск: BM25 + TF-IDF + плотные эмбеддинги, получаемые усреднением скрытых состояний уже загруженной LLM (mean-pooling) — нулевой дополнительный VRAM;
Reciprocal Rank Fusion (k=60) для слияния результатов;
LLM-реранкер — кросс-энкодер на основе логитов Yes/No;
ZPF-формат сжатия документов — заявлено на 25% меньше токенов при 100% точности поиска;
полноценный PDF-парсер: ToUnicode CMap (шрифты Word/LaTeX), фильтры потоков ASCIIHex/ASCII85/RunLength/LZW/Flate, шифрование RC4-40/128, AES-128/256 (Standard Security Handler V=1/2/4/5, R=2/3/4/5/6), перетекание многоколоночной вёрстки, потоковые объекты /ObjStm (PDF 1.5+), хук OCR для сканов.

LoRA

Поддержка адаптеров LoRA реализована «горячей» (hot-swap):

накладные расходы на адаптер — менее 1% VRAM (например, rank=16 на 7B-модели ≈ 16 МБ);
до сотен адаптеров на одну GPU;
маршрутизация по запросу через параметр lora_id;
собственный бинарный формат адаптеров .zse-lora.

Тензорный параллелизм

Мульти-GPU режим реализован через обёртку NCCL (NVIDIA) / RCCL (AMD) на чистом ctypes: AllReduce, AllGather, Broadcast, ReduceScatter, Barrier. Веса шардируются между процессами: колоночно-параллельно для QKV/Gate/Up и строково-параллельно для O/Down. Запуск — zse serve model.zse --tp 4.

Установка и быстрый старт

Требования: Python 3.11+, один из вариантов — драйвер NVIDIA + CUDA runtime, AMD ROCm 6+, или Apple Silicon. Больше ничего.

pip install zse-engine

Шаг 1 — получить модель (готовую предконвертированную или сконвертировать самостоятельно):

# готовая модель (мгновенно)
zse pull qwen-7b              # 5.18 GB
zse pull qwen-32b             # 17.9 GB
zse pull mistral-7b           # 3.86 GB

# или конвертация любой HuggingFace-модели
zse convert Qwen/Qwen2.5-7B-Instruct qwen-7b.zse --quant int4

Шаг 2 — запустить сервер:

zse serve qwen-7b.zse --port 8000

Шаг 3 — использовать как обычный OpenAI-совместимый API:

import openai

client = openai.OpenAI(base_url="http://localhost:8000/v1", api_key="zse")
response = client.chat.completions.create(
    model="default",
    messages=[{"role": "user", "content": "Объясни mixture of experts одним абзацем."}],
    stream=True,
)
for chunk in response:
    print(chunk.choices[0].delta.content or "", end="", flush=True)

Дополнительные команды CLI: zse info (информация о GPU и бэкенде), zse version, zse keys create/list/revoke (управление API-ключами), zse warm model.zse (прогрев файла в page cache для ещё более быстрого старта).

Поддерживаемое оборудование

Архитектура GPU определяется автоматически во время выполнения: компилятор запрашивает compute capability и генерирует корректный PTX / GCN / MSL.

Оборудование	Вендор	Архитектура	Статус
NVIDIA T4	NVIDIA	Turing (sm_75)	✓ проверено
NVIDIA L4	NVIDIA	Ada (sm_89)	✓ проверено
NVIDIA A10G	NVIDIA	Ampere (sm_86)	✓ проверено
NVIDIA A100 (40/80 ГБ)	NVIDIA	Ampere DC (sm_80)	✓ проверено
NVIDIA H100 / H200	NVIDIA	Hopper (sm_90)	✓ проверено
AMD Instinct MI300X (192 ГБ)	AMD	CDNA3 (gfx942)	✓ проверено
Apple M1	Apple	Apple Silicon	✓ ядра, полный инференс — в разработке

Из архитектур моделей «из коробки» поддерживаются Llama, Mistral, Qwen2, Gemma2, Phi3 (в исходниках также присутствует адаптер Gemma4).

Производительность: заявленные цифры

Все цифры в этом разделе взяты из README проекта и результатов бенчмарков, закоммиченных в репозиторий. Тесты проводились авторами на инфраструктуре Modal (NVIDIA) и DigitalOcean (AMD MI300X). Сравнение — ZSE INT4 против vLLM AWQ INT4 на моделях Qwen2.5 7B/14B/32B. Это не независимые бенчмарки, к цифрам стоит относиться с осторожностью.

Холодный старт

GPU	Модель	ZSE	vLLM	Ускорение
NVIDIA T4 (16 ГБ)	Qwen2.5-7B	7.25 с	218.96 с	30.2×
NVIDIA L4 (24 ГБ)	Qwen2.5-7B	5.58 с	145.22 с	26.0×
NVIDIA A10G (24 ГБ)	Qwen2.5-7B	6.01 с	193.05 с	32.1×
NVIDIA A100-80GB	Qwen2.5-14B	6.29 с	127.02 с	20.2×
AMD MI300X (192 ГБ)	Qwen2.5-32B	3.14 с	42.65 с	13.6×

Экономия VRAM

GPU	Модель	ZSE	vLLM	Сокращение
NVIDIA T4	Qwen2.5-7B	5.79 ГБ	~14 ГБ	~2.5×
NVIDIA A100-80GB	Qwen2.5-14B	12.28 ГБ	71.45 ГБ	5.82×
AMD MI300X	Qwen2.5-32B	22.07 ГБ	161.77 ГБ	7.33×

Как отмечают авторы, vLLM-аллокатор PyTorch + KV-слабы захватывают всю GPU независимо от квантования; ZSE благодаря предквантованному формату и собственному аллокатору размещает 32B INT4 в 22 ГБ.

Пропускная способность (одна последовательность)

GPU	Модель	ZSE	vLLM	Отношение
NVIDIA A100-80GB	Qwen2.5-14B	37.0 tok/s	26.5	1.40×
NVIDIA A10G	Qwen2.5-7B	48.6 tok/s	50.9	0.95×
NVIDIA L4	Qwen2.5-7B	36.3 tok/s	47.3	0.77×
AMD MI300X	Qwen2.5-32B	38.4 tok/s	56.4	0.68×
NVIDIA T4	Qwen2.5-7B	18.8 tok/s	35.2	0.53×

Здесь картина уже не столь однозначная: на датацентровых GPU (A100) ZSE обгоняет vLLM, но на T4, L4 и MI300X уступает.

Честные ограничения

Авторы проекта прямо перечисляют, в чём ZSE пока проигрывает vLLM:

Concurrent throughput при N≥4 на INT4 — ручные ядра AWQ Marlin от vLLM достигают потолка пропускной способности памяти, который ZSE на NVIDIA пока не повторил. На AMD через переписанный wave-64 bgemv разрыв удалось сократить до 2.12×;
Apple Silicon: полный инференс — ядра валидированы на M1 (E2E vector_add: 0/1024 несовпадений), но полный путь трансформера ещё требует прогона на реальном железе;
Тензорный параллелизм в песочницах без сетевого доступа — worker bootstrap использует AF_UNIX-сокеты ncclCommInitRank, которые блокируются в песочницах Modal, поэтому полный TP работает на bare-metal-серверах.

Итоговая рекомендация авторов звучит так: если единственная метрика — установившаяся пропускная способность батча при бюджете VRAM в ~50 раз больше, используйте vLLM. Если важны холодный старт, след в памяти, отсутствие вендор-лока и работа на чём угодно, кроме H100, — используйте ZSE.

Сравнение с vLLM

Параметр	vLLM	ZSE
Холодный старт (7B)	30 с – 4 мин	5–7 с
VRAM (14B INT4)	71 ГБ	12 ГБ
Зависимости	PyTorch + Triton + CUDA toolkit (~12 ГБ)	Нулевые
Размер pip-установки	~3 ГБ	~5 МБ
Бэкенды	преимущественно CUDA	CUDA + ROCm + Metal
Формат модели	safetensors (десериализация при загрузке)	.zse (mmap, предквантованный)
KV-кэш	фиксированные блоки 16 токенов, LRU	адаптивные блоки, поуровневое вытеснение
Конвертация модели	нет — квантование в рантайме	разовая, ~600× быстрее чистого Python
Встроенный RAG	нет	есть (гибридный поиск + реранкер + ZPF)
Auth + rate limiting	нет	есть (SQLite)
LoRA hot-swap	есть (S-LoRA)	есть

Сравнивать ZSE с Ollama или llama.cpp тоже уместно: Ollama ориентирован на простоту локального запуска на одной машине, llama.cpp — на CPU и небольшие GPU с собственным форматом GGUF. ZSE ближе к vLLM по назначению (серверное обслуживание многих клиентов), но с философией llama.cpp по части минимализма зависимостей.

Риски и ограничения

Несмотря на впечатляющие заявленные цифры, есть факторы, о которых стоит помнить перед выбором ZSE для продакшена:

Молодость проекта — 72 коммита, 201 звезда, один issue и два PR на момент написания статьи. Это очень маленькая экосистема по сравнению с vLLM (тысячи коммитов, десятки тысяч звёзд, сотни контрибьюторов);
Отсутствие независимых бенчмарков — все цифры производительности получены авторами; выводы о 20–30× ускорении требуют самостоятельной проверки на собственном железе;
Скорость декодирования на бюджетных GPU — на T4, L4 и MI300X ZSE уступает vLLM в токенах в секунду;
Один контрибьюторный центр — проект фактически развивается одной командой (Zyora Labs), что увеличивает bus-factor;
Нет тюнинга/обучения в мейнстриме — позиционирование строго инференсное;
Формат .zse v2 несовместим с v1 — старые файлы придётся переконвертировать;
Apple Silicon не доведён до полного инференса;
Тензорный параллелизм требует bare-metal-серверов с сетевым доступом.

С другой стороны, у проекта есть и явные сильные стороны: полная прозрачность (нет чёрного ящика PyTorch), воспроизводимость бенчмарков (скрипты и JSON-результаты закоммичены в tests/), честный раздел ограничений в README и нулевые зависимости, что резко снижает риск supply-chain атак.

Перспективы

Судя по последним коммитам (например, «perf: close M=8->16 INT4 decode cliff — 2x concurrent throughput») и дорожной карте в README, следующие направления развития очевидны:

сокращение разрыва в concurrent throughput на NVIDIA (аналог AMD wave-64 bgemv для CUDA);
доведение полного инференса на Apple Silicon до production-состояния;
расширение числа поддерживаемых архитектур моделей (адаптер Gemma4 уже появился в исходниках);
дальнейший перенос рукописных CUDA-ядер на портируемый DSL @zse.kernel.

Экономика проекта тоже любопытна: развитие ROCm-части поддержано грантом DigitalOcean, что говорит о серьёзности намерений команды в отношении AMD-платформы.

Резюме

ZSE — это амбициозный open-source эксперимент по созданию LLM-инференс-движка «с нуля и без посредников». Его ключевые достижения — предквантованный mmap-формат с загрузкой за секунды, собственный компилятор GPU-ядер для трёх аппаратных платформ, экономия VRAM в 2,5–7 раз по сравнению с vLLM и нулевые сторонние зависимости.

Для кого ZSE подходит лучше всего:

владельцы ограниченных по VRAM GPU (T4 16 ГБ, L4 24 ГБ), которые хотят запускать 7–14B модели с место под несколько моделей сразу;
пользователи AMD MI300X и других ROCm-карт, которым важна честная поддержка без «CUDA-first» политики;
те, кому критичен быстрый холодный старт (serverless-сценарии, автоскейлинг);
проекты, где важен аудит кода без многослойных зависимостей;
любители Apple Silicon, ожидающие завершения Metal-пути.

Для кого он пока не подходит: продакшены с пиковым многопользовательским батчем на NVIDIA (где vLLM с Marlin-ядрами стабильно быстрее), а также те, кому нужны устоявшиеся экосистема, сообщество и независимо подтверждённые бенчмарки.

В любом случае ZSE — один из самых интересных проектов 2026 года в нише локального LLM-инференса: он демонстрирует, что современные модели можно обслуживать без гигабайтов ML-фреймворков, и задаёт планку для «лёгких» движков следующего поколения.

Ссылки

×

← В главную