uvicorn vs gunicorn vs hypercorn vs granian: что выбрать в 2026

На каждый питон-сервис рано или поздно встаёт вопрос: что запускать в проде. Был uvicorn в одиночку, стал uvicorn под gunicorn, кто-то ушёл в hypercorn, кто-то на granian. Картина запутанная, особенно для тех, кто впервые поднимает FastAPI или Starlette.

Я разложу по полочкам, что есть, чем отличается, и какой набор реально стоит выбирать в 2026 году под разные сценарии.

Сначала про разницу WSGI и ASGI

Если коротко: WSGI — синхронный протокол (Flask, Django до 3.1, gunicorn по умолчанию). ASGI — асинхронный, поверх него работают Starlette, FastAPI, async-режим Django.

FastAPI — это ASGI-приложение. Значит, тебе нужен ASGI-сервер. Все три кандидата — uvicorn, hypercorn, granian — это ASGI-серверы. Gunicorn же по природе WSGI, но умеет запускать ASGI-приложения через специальные воркер-классы (например, uvicorn.workers.UvicornWorker).

uvicorn

De-facto стандарт для FastAPI. Реализация на uvloop и httptools, написана плотно, отлично оптимизирована. По бенчмаркам стабильно в верхней группе.

Плюсы:

• Производительность — одна из лучших в Python-экосистеме.
• Отлично документирован, поддерживается командой Encode (FastAPI/Starlette).
• Нативно умеет lifespan-эвенты ASGI, поддерживает HTTP/1.1 и WebSocket.
• В 2024 году добавился полноценный multi-worker режим без gunicorn (--workers).

Минусы (точнее, ограничения):

• Нет HTTP/2 и HTTP/3 из коробки. Если нужно — ставь reverse proxy (nginx, envoy, caddy) перед uvicorn.
• Multi-worker режим до 0.30 не умел нормально перезапускать упавшие воркеры. Сейчас умеет, но стабильнее всё ещё gunicorn в этом плане.

Запуск:

uvicorn app.main:app --host 0.0.0.0 --port 8000 --workers 4

gunicorn (с uvicorn-воркерами)

Gunicorn сам по себе ASGI не понимает, но в связке с UvicornWorker запускает FastAPI без проблем. Долгие годы это была стандартная схема для прода.

Плюсы:

• Зрелое управление воркерами: graceful restart, preload, max_requests, perfect signal handling.
• Умеет worker-class из коробки, можно смешивать.
• Хорошая телеметрия процессов.

Минусы:

• Дополнительный слой между tcp-сокетом и приложением. Микро-оверхед, но в большинстве случаев заметить нельзя.
• Конфигурация чуть сложнее — нужно держать два конфига, gunicorn и uvicorn worker.

Запуск:

gunicorn app.main:app \
  -k uvicorn.workers.UvicornWorker \
  -w 4 \
  -b 0.0.0.0:8000 \
  --max-requests 1000 \
  --max-requests-jitter 50

Параметр --max-requests с jitter полезен против медленных утечек памяти: воркер сам перезапускается через N запросов и освобождает RAM. На длинноживущих процессах это иногда спасает.

hypercorn

Самый зрелый ASGI-сервер с поддержкой HTTP/2 и HTTP/3 (через QUIC). Написан на чистом Python с помощью anyio, что даёт ему хорошую совместимость с trio (если ты используешь trio).

Плюсы:

• Поддержка HTTP/2 и HTTP/3 без reverse proxy.
• WebSocket, server-sent events работают штатно.
• Конфигурация через файл, что удобно для сложных деплоев.

Минусы:

• На бенчмарках обычно медленнее uvicorn в HTTP/1.1 сценариях.
• Меньше комьюнити и меньше готовых рецептов.

Запуск:

hypercorn app.main:app --bind 0.0.0.0:8000 --workers 4 --bind-h2 :8443

Реальный плюс hypercorn проявляется, когда тебе нужен HTTP/2 без nginx. Например, в окружении, где трафик идёт сразу через Envoy с gRPC. Если у тебя обычный REST поверх HTTP/1.1 — uvicorn будет быстрее и проще.

granian

Сравнительно новый игрок. Сервер на Rust, поддерживает ASGI, RSGI и WSGI. По бенчмаркам быстрее uvicorn, особенно на маленьких ответах. В 2025 году подрос до уровня production-ready.

Плюсы:

• Производительность — лидер по бенчмаркам.
• Один бинарь без Python-зависимостей в рантайме воркера (Rust-процесс с GIL только в воркере).
• Поддержка HTTP/2, плюс WebSocket.

Минусы:

• Молодой, документация местами скуднее.
• В 2026 пока нет такого количества рецептов и интеграций.
• Рутина типа graceful reload, preload — есть, но менее обкатана.

Если ты строишь новый сервис и готов к чуть большему риску — granian уже стоит попробовать. Особенно если упираешься в throughput на FastAPI.

Что выбрать

Скучный, но честный ответ: для большинства команд в 2026 году рабочий выбор — uvicorn в multi-worker режиме. Это сочетание простоты, производительности и стабильности.

Когда стоит подумать про gunicorn-обёртку:

• У вас уже есть привычная конфигурация gunicorn в инфраструктуре.
• Нужно plug-in мониторинга на уровне процессов.
• Памятные утечки приходится глушить через max-requests.

Когда брать hypercorn:

• Нужен HTTP/2 или HTTP/3 без proxy перед сервером.
• Часть кода уже на trio или anyio.

Когда смотреть granian:

• Высокий RPS, упираемся в скорость.
• Хочется единый бинарь без Python-сервера в стеке.
• Команда готова немного потерпеть в плане документации.

Несколько практических советов

Независимо от выбора, есть вещи, которые мы делаем во всех сервисах.

Worker count. Стандартная формула 2 * cpu + 1 подходит для синхронного кода. Для async-эндпоинтов часто хватает cpu + 1 или просто cpu. Лишние воркеры жрут память и не дают прироста, потому что async и так держит много соединений на воркер.

Графы рестарта. Используй --graceful-timeout и --timeout. На k8s pod terminationGracePeriod должен быть больше graceful timeout сервера, иначе SIGTERM прервёт активные запросы.

Preload. В gunicorn (--preload) и granian преlode app в parent-процессе. Память шарится через copy-on-write, на больших приложениях экономия может быть в гигабайтах.

Логи. Все три сервера логируют по-своему, и форматы немного отличаются. Если у тебя структурированное логирование — настрой кастомный logger, не полагайся на встроенный access log в проде.

Reverse proxy. Перед любым из этих серверов в проде стоит nginx, envoy или caddy. Не выставляй python-сервер напрямую в интернет: ему нужен буфер для медленных клиентов, обработки TLS, статики, защиты от slowloris.

Что в сухом остатке

В 2026 году дефолт для FastAPI-приложения — uvicorn с multi-worker. Если есть привычка к gunicorn — оставь, ничего страшного. Hypercorn — нишевый выбор для HTTP/2/3 без прокси. Granian — кандидат для следующего сервиса, если ты упёрся в производительность.

Не гонись за самым свежим, если текущая связка работает. Серверный слой — место, где стабильность важнее, чем 5% прироста на синтетике.