vLLM-инференс в облаке без собственной инфраструктуры

Selectel запустил Foundation Models Catalog — управляемый сервис, где вы выбираете модель из каталога, а провайдер берёт на себя GPU, масштабирование и наблюдаемость. Движок под капотом: vLLM, питоновская библиотека поверх PyTorch, которую сейчас называют производственным стандартом для инференса.

Что это даёт на практике: вместо того чтобы поднимать свой vLLM-сервер, арендовать GPU и настраивать мониторинг, вы обращаетесь к уже готовому OpenAI-совместимому эндпоинту через openai-клиент или requests. Код тот же, что при локальном запуске. Автомасштабирование, логи и метрики включены.

В каталоге сейчас IBM Granite, Qwen, DeepSeek, Phi, Mistral; скоро Gemma и Whisper. Оплата пока за вычислительные ресурсы, следующим шагом станет тарификация по токенам.

Подробнее на Tproger.

@zen_of_python (теперь в VK и Max)

В Long Beach на PyCon US 2026 14 мая прошёл Typing Summit: четыре часа, восемь докладов, один трек. Несколько моментов с саммита.

Гвидо ван Россум открыл саммит докладом про то, что правило PEP 484 «никакого нового синтаксиса для типов» де-факто давно нарушено: TypedDict, ParamSpec, оператор type и прочее. Его аргумент: пора признать это формально и выбирать приоритеты по реальной боли пользователей. Опирался на Python Typing Survey 2025.

Дуглас Креагер из Astral (его слайд гласил «an OpenAI joint») показал девятистрочный пример, на котором все продакшен-чекеры (mypy, pyright, pyre, Pyrefly, ty) дают неверный ответ:

def choose[A](a1: A, a2: A) -> A:
    return random.choice([a1, a2])

def partial[X, Y, Z](fn: Callable[[X, Y], Z], x: X) -> Callable[[Y], Z]: ...

p = partial(choose, None)
p(2)         # все говорят: ошибка, 2 не None
p("hello")   # то же самое

Прямой вызов choose(None, 2) работает корректно: A решается в None | Literal[2]. После применения partial система ломается. Креагер предлагает другую стратегию: тянуть весь набор констрейнтов как отложенный обобщённый тип, без преждевременной подстановки. ty переезжает на этот подход, внутри используется тернарная структура BDD (двоичные решающие диаграммы с третьим «неопределённым» ребром).

Коннер Нильсен из команды Pyrefly доложил результаты экспериментов с ИИ-агентами. Если код хорошо типизирован и type checker подключён к агенту через обёртку с циклом «думай, действуй, наблюдай»:

— Доля успешных решений на внутренних бенчмарках команды поднялась с 79,6 до 83,9 процента.
— На 21 процент меньше шагов до решения.
— На 14 процентов быстрее по полному времени работы.

На слабо типизированном коде из SWE-bench Verified эффекта почти нет. Type checker ловит ошибки в соседних с задачей файлах, и агент уходит чинить их вместо основной задачи. Наблюдение по моделям: Claude Sonnet 4.5 чинит каждую ошибку, GPT-5 codex игнорирует типы, пока обёртка насильно их не подсунет.

Ещё были доклады про intersection types (Jelle Zijlstra), PEP 827 от Vercel про conditional и mapped types по образцу TypeScript, tensor-shape типы в Pyrefly, и формализация подмножества Python в Lean 4. Полный обзор здесь: https://bernat.tech/posts/pycon-us-2026-typing-summit-recap/

@zen_of_python (теперь в VK и Max)

Наткнулся тут на обсуждение, которое мне тоже периодически приходит в голову: стоит ли использовать uv, если OpenAI покупает Astral. Напомню, Astral это те ребята, которые сделали uv, ruff и ty, которые мы так любим.

Короткий вывод: для новых Python-проектов uv всё ещё выглядит самым практичным выбором.

Почему разработчики так за него держатся: uv закрывает сразу несколько бытовых задач: ставит Python-версии, создаёт venv, ставит зависимости, фиксирует lockfile, запускает команды в окружении и заменяет часть сценариев pip, pip-tools, pipx, poetry и pyenv.

Типичный flow становится проще:

uv init
uv add fastapi
uv run app.py
uv sync --frozen

Риск с OpenAI тут скорее управленческий, а не технический. Важно смотреть на лицензию, телеметрию, темп релизов и то, останется ли core-разработка открытой. На практике же зависимости живут в стандартном pyproject.toml, а Python уже движется к стандартному lockfile через PEP 751 / pylock.toml, так что миграция с uv должна быть проще, чем с более закрытых форматов.

То есть вопрос скорее не про то, использовать ли uv, а о том как использовать его без религии и без лишней привязки к одному владельцу.

А вы как думаете? Продолжаем жить на uv, всё норм?

@zen_of_python

Осенью нас ждёт Python 3.15, набор фич для него уже заморожен в бете. Заглянул, что там приедет, и нашёл пару вещей, которые поменяют привычки.

Самое заметное: явные ленивые импорты (PEP 810). Появляется ключевое слово lazy. Модуль пишется в импорте как обычно, но реально подгружается только при первом обращении.

lazy import json
lazy from pathlib import Path

print("старт")  # json и pathlib ещё не загружены
data = json.loads('{"ok": true}')  # здесь json наконец подгружается

Раньше ради быстрого старта тяжёлые импорты прятали внутрь функций. Теперь их можно держать наверху файла, как и положено, без платы за импорт при запуске. Есть и глобальные переключатели: флаг -X lazy_imports и переменная окружения, если хочется включить лень разом. И это не воскрешение отклонённого когда-то PEP 690, механизм тут другой и явный.

Второе приятное: встроенный frozendict (PEP 814). Неизменяемый и хешируемый словарь прямо в языке, без импортов. То же, чем frozenset является для set.

config = frozendict({"debug": True, "retries": 3})
# поменять значение уже нельзя, будет TypeError

Ещё одно: PEP 661 даёт штатный способ делать sentinel-значения вместо самодельных MISSING = object(). Теперь это нормальный механизм с человеческим repr и поддержкой в аннотациях типов.

Под капотом тоже движение: переработанный JIT даёт около 8-9% на Linux x86-64, интерпретатор с tail-call приехал и на Windows (там плюс 15-20%), появился стабильный ABI для free-threaded сборок.

Финальный 3.15 ждём осенью, но облик версии уже ясен. Лично я больше всего жду lazy import: сколько раз приходилось прятать импорты в функции ради быстрого CLI.

А вы ждёте 3.15 или пока сидите на чём-то постарше?

@zen_of_python

Astral завезла в uv защиту от уязвимостей и малвари. 8 июня в их блоге анонсированы две preview-фичи, и обе бьют точно в больное место экосистемы — атаки через цепочку поставок.

Первая: команда uv audit. Сканирует зависимости проекта по базе OSV на известные уязвимости и заброшенный статус пакетов. Работает в 4-10 раз быстрее pip-audit — фирменный стиль Astral на месте.

Вторая интереснее: проверка на малварь прямо при установке. С переменной окружения UV_MALWARE_CHECK=1 команды uv add и uv sync сверяют залоченные зависимости с MAL-записями OSV и блокируют установку известной малвари до того, как её код вообще запустится. Учитывая, что свежие PyPI-кампании прячут стилеры в .pth-хуки, которые срабатывают при каждом старте интерпретатора даже без импорта пакета, проверка до установки — единственный момент, когда ещё не поздно.

В планах у Astral резолвер, который сам избегает уязвимых версий при разрешении зависимостей, и режим предупреждений только для новых зависимостей, чтобы не тонуть в алертах по старым.

Обе фичи в preview, но включить UV_MALWARE_CHECK в CI можно уже сейчас — бесплатная страховка. Кто на uv, попробуйте uv audit на своём проекте и расскажите, сколько насыпало.

@zen_of_python