С большой GPU большая ответственность

Разберем стек
vLLM + LiteLLM + Codex CLI

Часть первая, когда у вас много GPU серверов под LLM инференс, а у меня часть в одном офисе, часть в колокейшене (когда арендуешь стойку в датацентре под свое железо, не AWS) и нужно все же понять как сделать одно API окно сверху всего этого, привет https://hub.neuraldeep.ru/ и все наши эксперименты выше =)

В целом это проблема любой связки vLLM + LiteLLM даже если вы заводите это внутри компании, не на продажу

У меня заняло неделю по вечерам найти, и решить проблемы, пройдусь по пунктам чтобы вам было быстрее

Вы так же найдете те же проблема на GitHub vLLM висят открытые issues с января-апреля 2026
#33089 (multi-turn Responses API),
#39426 (tool-aggregation protocol drift) десятки людей жалуются на одно и то же, апстрим месяцами не закрывает

Боль набер ван роутинг

LiteLLM по дефолту simple-shuffle или следующий кандидат latency-based routing
Звучит умно выбирает самый быстрый сервер или рандомим
По факту на двух одинаковых инстансах LLM с GPU он залипает на winner-сервер навсегда, второй простаивает в ноль, курит за деньги вашей компании

Включить round-robin?
Нельзя
Round-robin для multi-turn агент loop убивает кеш на каждом turn'е попадаешь на другой сервер история пере-prefillится с нуля +5-10s к ответу, песня да?

Нужен sticky session (один user всегда на одном сервере) + балансировка между разными user'ами
Из коробки в LiteLLM такого нет, оно как бы есть но его как бы нет 💀

Решение простое как две копейки главное на него выйти сразу, "custom routing strategy"
180 строк кода
Внутри consistent-hash md5 от api_key_alias, один user всегда на одном сервере
Разные user'ы, разные сервера через равномерное распределение хеша, что делать когда будет требоваться масштабирование дальше? Расскажу в следующих сериях
Сервер в колокейшене ожил (ура) и по логам есть кеш!

Боль набер два кеш умирает без sticky решается первым пунктом и сильно связан с роутингом, но дальше сложнее

Боль 3 Codex CLI шлет нестандартные tool types

Я хочу использовать Codex CLI как агентный харнес в своих экспериментах, с qwen3.6 все просто фиксим протокол и поехали, с gpt oss 120b чуть сложнее так как там что? Правильно harmony =)

Codex CLI отправляет в запрос tools которые vLLM не понимает custom, image_generation, namespace
vLLM на это шлет вам 400 tool type custom not supported, вы оптекаете и думаете что с этим делать
Codex падает на старте, до первой генерации

Лезу в исходники vLLM есть файл harmony_utils.py (harmony это внутренний формат сообщений для gpt-oss моделей, как ChatML для других)
Там whitelist tool types web_search_preview, code_interpreter, container, function
Все
Никаких custom или image_generation 😳

Решение в лоб, bind-mount (монтируете файл с хоста поверх файла в контейнере, апстрим не трогаете) с пропатченным harmony_utils.py
Расширил whitelist на custom, web_search, file_search, image_generation, local_shell, apply_patch, mcp_*
После этого Codex реально начинает работать делает git rev-parse, читает файлы, пишет код

Боль набер 4 Responses API строгая валидация

Responses API это новый OpenAI endpoint /v1/responses (на смену /v1/chat/completions)
С server-side state через previous_response_id
Codex с ним и работает (completions дипрекейтнули еще 2-3 месяца назад)

На каждом turn'е шлет previous_response_id + полный input[] с историей
В истории assistant-айтемы которые vLLM ранее сам сгенерировал
У них нет полей id, status="completed", annotations=[]

По OpenAI-схеме это required-поля
vLLM строгая Pydantic-валидация запрос делает что?
Правильно отлетает
Codex в ступоре
Вы тоже

Решение тот же подход bind-mount пропатченных Pydantic-моделей делаем поля optional с дефолтами

Итого
Кодинг агенты помогли собрать все это в кучу, и локализовать проблемы, да не так элегантно но работает!
Базовый вывод это легко находится через Codex/Claude Code главное тесты и что бы вы понимали что делаете
Все это решилось так же через подробные логи на всех сторонах систем

Затестить все это можно тут https://hub.neuraldeep.ru/docs#agents