Надежность сети и координация производительности (медленные узлы, рост базы данных, пропущенный вывод)
Оригинал: Network reliability and performance coordination (slow nodes, DB growth, missed inference)
Сигнал 502/пропущенные запросы на 4090 при обработке запросов с большими токенами — таймаут чтения прокси (900с)
Графический процессор окружающей среды: RTX 4090 (48 ГБ)
Что мы видим Мы видим, что некоторые запросы на завершение чата заканчиваются на 502 Bad Gateway и фактически считаются пропущенным выводом. Из наших журналов:
Журналы vLLM: прерванный запросchatcmpl-xxx
- Журналы прокси-сервера API: не удалось подключиться к серверной части vLLM → httpx.ReadTimeout.
- Клиент получает 502 для POST /v1/chat/completions.
Паттерн, который мы выявили
- Неудачные запросы выполняются долго: длинные запросы (например, юридическое извлечение нескольких документов) + высокие max_tokens (например, 5000), общее время может превышать 15 минут.
- Прокси использует таймаут чтения 900 секунд (15 минут). Когда запрос выполняется так долго, мы достигаем этого таймаута, поток прерывается, vLLM прерывает запрос, и мы возвращаем 502 → пропущенный запрос.
Журнал
2026-02-27T05:35:45.999662386Z INFO 02-26 21:35:45 [logger.py:43] Получен запросchatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf: приглашение: ... параметры: SamplingParams(n=1, присутствие_пеналти=0,0, частота_пеналти=0,0, повторение_пеналти=1,0, температура=0,1, top_p=2026-02-27T05:35:45.999662386Z 0,8, top_k=20, min_p=0,0, начальное число=922553843, stop=[], stop_token_ids=[], bad_words=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=5000, min_tokens=0, logprobs=5, Prompt_logprobs=None, Skip_special_tokens=False, space_between_special_tokens=True, truncate_prompt_tokens=Нет,guide_decoding=Нет, extra_args = Нет, Enforced_token_ids = Нет, Prompt_token_ids: Нет, Форма Prompt_embeds: Нет, lora_request: Нет, Prompt_adapter_request: Нет. 2026-02-27T05:35:46.000070586Z ИНФОРМАЦИЯ 02-26 21:35:45 [async_llm_engine.py:212] Добавлен запросchatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf. ... 2026-02-27T05:50:45.969437878Z INFO 02-26 21:50:45 [async_llm_engine.py:224] Прерванный запросchatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf. 2026-02-27T05:50:45.970448508Z 2026-02-26 21:50:45,969 - api.proxy - ОШИБКА - Не удалось подключиться к серверной части vLLM:
Таким образом, на наших узлах 4090 запросы с большими токенами/длительной продолжительностью с большей вероятностью достигнут этого тайм-аута прокси и будут отмечены как пропущенные.
Вопросы
- Является ли этот жестко запрограммированный 15-минутный тайм-аут чтения прокси известным ограничением где-либо еще? Мы рассматриваем возможность увеличения времени ожидания чтения прокси-сервера для нашего развертывания, чтобы уменьшить количество таких промахов.
- Узлы более низкой спецификации (например. 4090, 48 ГБ) могут выполнить PoC, но испытывают проблемы с обслуживанием более крупных/длительных запросов на вывод (например, тайм-аут прокси-сервера → пропущенные запросы). Будет ли сеть поддерживать эти узлы в будущем?
Привет @icydark (https://github.com/icydark)! Спасибо!
- да, имеет смысл попробовать увеличить время ожидания чтения прокси-сервера в вашем развертывании.
- что касается узлов с более низкими характеристиками — это зависит от решений руководства и может меняться со временем.
Русский перевод
Цель: собрать сигналы, сойтись в первопричинах
Это обсуждение предназначено для координации на высоком уровне и сбора доказательств. Работа по внедрению отслеживается в связанных эпиках (выпусках).
Темы:
- За последние несколько дней несколько хостов сообщили о замедлении работы узлов.
Рост application.db (обрезка не эффективна)
Пропущенный вывод на некоторых узлах
Примечания
- Если у вас есть частичные данные, все равно опубликуйте их.
Если хотите помочь реализовать, оставляйте комментарии в соответствующем вопросе
Сигнал 502/пропущенные запросы на 4090 при обработке запросов с большими токенами — таймаут чтения прокси (900с)
Графический процессор окружающей среды: RTX 4090 (48 ГБ)
Что мы видим Мы видим, что некоторые запросы на завершение чата заканчиваются на 502 Bad Gateway и фактически считаются пропущенным выводом. Из наших журналов:
Журналы vLLM: прерванный запросchatcmpl-xxx
- Журналы прокси-сервера API: не удалось подключиться к серверной части vLLM → httpx.ReadTimeout.
- Клиент получает 502 для POST /v1/chat/completions.
Паттерн, который мы выявили
- Неудачные запросы выполняются долго: длинные запросы (например, юридическое извлечение нескольких документов) + высокие max_tokens (например, 5000), общее время может превышать 15 минут.
- Прокси использует таймаут чтения 900 секунд (15 минут). Когда запрос выполняется так долго, мы достигаем этого таймаута, поток прерывается, vLLM прерывает запрос, и мы возвращаем 502 → пропущенный запрос.
Журнал
2026-02-27T05:35:45.999662386Z INFO 02-26 21:35:45 [logger.py:43] Получен запросchatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf: приглашение: ... параметры: SamplingParams(n=1, присутствие_пеналти=0,0, частота_пеналти=0,0, повторение_пеналти=1,0, температура=0,1, top_p=2026-02-27T05:35:45.999662386Z 0,8, top_k=20, min_p=0,0, начальное число=922553843, stop=[], stop_token_ids=[], bad_words=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=5000, min_tokens=0, logprobs=5, Prompt_logprobs=None, Skip_special_tokens=False, space_between_special_tokens=True, truncate_prompt_tokens=Нет,guide_decoding=Нет, extra_args = Нет, Enforced_token_ids = Нет, Prompt_token_ids: Нет, Форма Prompt_embeds: Нет, lora_request: Нет, Prompt_adapter_request: Нет. 2026-02-27T05:35:46.000070586Z ИНФОРМАЦИЯ 02-26 21:35:45 [async_llm_engine.py:212] Добавлен запросchatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf. ... 2026-02-27T05:50:45.969437878Z INFO 02-26 21:50:45 [async_llm_engine.py:224] Прерванный запросchatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf. 2026-02-27T05:50:45.970448508Z 2026-02-26 21:50:45,969 - api.proxy - ОШИБКА - Не удалось подключиться к серверной части vLLM:
Таким образом, на наших узлах 4090 запросы с большими токенами/длительной продолжительностью с большей вероятностью достигнут этого тайм-аута прокси и будут отмечены как пропущенные.
Вопросы
- Является ли этот жестко запрограммированный 15-минутный тайм-аут чтения прокси известным ограничением где-либо еще? Мы рассматриваем возможность увеличения времени ожидания чтения прокси-сервера для нашего развертывания, чтобы уменьшить количество таких промахов.
- Узлы более низкой спецификации (например. 4090, 48 ГБ) могут выполнить PoC, но испытывают проблемы с обслуживанием более крупных/длительных запросов на вывод (например, тайм-аут прокси-сервера → пропущенные запросы). Будет ли сеть поддерживать эти узлы в будущем?
Привет @icydark (https://github.com/icydark)! Спасибо!
- да, имеет смысл попробовать увеличить время ожидания чтения прокси-сервера в вашем развертывании.
- что касается узлов с более низкими характеристиками — это зависит от решений руководства и может меняться со временем.
Оригинал
Goal: collect signals, converge on root causes
This discussion is for high-level coordination and evidence gathering. Implementation work is tracked in the linked epics (issues).
Topics:
Node slowdowns reported by multiple hosts over the last few days
application.db growth (pruning not effective)
Missed inference on some nodes
Notes
- If you have partial data, post it anyway.
If you want to help implement, comment on the relevant issue
Signal 502 / missed requests on 4090 when handling large-token requests — proxy read timeout (900s)
Environment GPU: RTX 4090 (48GB)
What we're seeing We see some chat completion requests end in 502 Bad Gateway and effectively count as missed inference. From our logs:
vLLM logs: Aborted request chatcmpl-xxx
API proxy logs: Failed to connect to vLLM backend → httpx.ReadTimeout
Client receives 502 for POST /v1/chat/completions
Pattern we identified
- The failing requests are long-running : long prompts (e.g. multi-document legal extraction) + high max_tokens (e.g. 5000), total time can exceed 15 minutes .
- The proxy uses a read timeout of 900 seconds (15 min) . When the request runs that long, we hit that timeout, the stream breaks, vLLM aborts the request, and we return 502 → missed request .
Log
2026-02-27T05:35:45.999662386Z INFO 02-26 21:35:45 [logger.py:43] Received request chatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf: prompt: ... params: SamplingParams(n=1, presence_penalty=0.0, frequency_penalty=0.0, repetition_penalty=1.0, temperature=0.1, top_p=2026-02-27T05:35:45.999662386Z 0.8, top_k=20, min_p=0.0, seed=922553843, stop=[], stop_token_ids=[], bad_words=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=5000, min_tokens=0, logprobs=5, prompt_logprobs=None, skip_special_tokens=False, spaces_between_special_tokens=True, truncate_prompt_tokens=None, guided_decoding=None, extra_args=None, enforced_token_ids=None, prompt_token_ids: None, prompt_embeds shape: None, lora_request: None, prompt_adapter_request: None. 2026-02-27T05:35:46.000070586Z INFO 02-26 21:35:45 [async_llm_engine.py:212] Added request chatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf. ... 2026-02-27T05:50:45.969437878Z INFO 02-26 21:50:45 [async_llm_engine.py:224] Aborted request chatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf. 2026-02-27T05:50:45.970448508Z 2026-02-26 21:50:45,969 - api.proxy - ERROR - Failed to connect to vLLM backend:
So on our 4090 nodes, large-token / long-duration requests are more likely to hit this proxy timeout and be reported as missed.
Questions
- Is this hardcoded 15‑min proxy read timeout a known limitation elsewhere? We’re considering increasing the proxy read timeout for our deployment to reduce these misses.
- Lower-spec nodes (e.g. 4090, 48GB) can complete PoC but have trouble serving larger / long-running inference requests (e.g. proxy timeout → missed requests). Will the network support these nodes going forward?
Hi @icydark (https://github.com/icydark) ! Thanks!
- yes, it makes sense to try increasing the proxy read timeout on your deployment.
- regarding lower spec nodes - it is subject to governance decisions and may evolve over time.
Цель: собрать сигналы, сойтись в первопричинах
Это обсуждение предназначено для координации на высоком уровне и сбора доказательств. Работа по внедрению отслеживается в связанных эпиках (выпусках).
Темы:
Рост application.db (обрезка не эффективна)
Пропущенный вывод на некоторых узлах
Примечания
Если хотите помочь реализовать, оставляйте комментарии в соответствующем вопросе