# Отмена запроса: проверить всю цепочку от клиента до движка

Как проверить отмену inference-запроса по всей цепочке: abort клиента, прокси, операция движка, счётчики in-flight и освобождение ресурсов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-client-disconnect-cancellation-chain/
Language: ru

Пользователь остановил ответ, и интерфейс перестал показывать текст. Это ещё не доказывает, что вычисление завершилось на сервере. Клиент мог прекратить чтение, прокси сохранить upstream-соединение, а движок продолжить генерацию. Для провайдера важна вся цепочка отмены: где возник сигнал, какие компоненты его обработали и какие ресурсы действительно освободились. Проверка начинается с ограниченного синтетического сценария, а не с предположения об автоматическом распространении disconnect.

## Разделите наблюдаемые границы

[AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) позволяет прервать fetch, чтение body и связанные streams на стороне клиента. Такое действие подтверждает поведение клиента. Оно само по себе не описывает, что сделал удалённый inference-движок, особенно при наличии промежуточного прокси и внутренних очередей.

Составьте карту: логическая операция клиента, внешнее соединение, запрос API-процесса, upstream-операция. Для каждой границы укажите доступный идентификатор и признак завершения. Если часть цепочки не наблюдается, сохраните этот предел в результате вместо утверждения «всё остановлено» по одному внешнему событию.

## Проверьте политику прокси

[NGINX описывает client abort](https://nginx.org/en/docs/http/ngx_http_proxy_module.html) и связанные настройки proxy-модуля. Поведение зависит от фактической конфигурации. Не переносите результат прямого подключения на маршрут с прокси и не считайте исчезновение клиента доказательством немедленного закрытия каждой внутренней операции.

Запишите эффективные настройки тестового location без секретов. Сравните прямой путь и путь через промежуточный слой на одном и том же сценарии. Так можно локализовать случай, где сигнал не проходит дальше либо где уже накопленный буфер скрывает продолжающуюся работу источника.

## Испытайте две точки отмены

Первый fixture отменяет запрос после принятия, но до первого content. Второй прекращает чтение после известного числа событий. Оба имеют небольшой предел выхода, общий timeout и верхнее число попыток. Не используйте настоящие клиентские данные и не создавайте бесконечную генерацию ради наблюдения cleanup.

[Документация OpenRouter](https://openrouter.ai/docs/api_reference/streaming) прямо связывает поддержку отмены с конкретными провайдерами и режимом. Поэтому способность одного маршрута остановить processing нельзя объявлять общей гарантией любых интеграций. Для собственного сервиса тест должен назвать проверенную конфигурацию и отдельно указать, что не подтверждено.

## Наблюдайте освобождение ресурсов

[Метрики vLLM](https://docs.vllm.ai/en/stable/usage/metrics/) описывают серверные показатели, которые помогают следить за состоянием запросов и очередями. Сохраните baseline до fixture, временной ряд во время него и состояние после завершения. Снижение числа внешних соединений не заменяет подтверждение соответствующей upstream-операции.

Рост или задержка возврата gauges требуют отдельной развилки: запрос ещё выполняется, ожидает в очереди, удерживает буфер либо метрика обновляется с другой частотой. Не называйте один поздний sample утечкой. Повторите ограниченный тест и сравните идентификаторы, прежде чем делать вывод о механизме.

## Отделите cleanup от расчётов

Подтверждённое освобождение памяти или остановка stream не определяют оплату самостоятельно. Учёт работы зависит от выбранного контракта и доступных итоговых записей. Отмена может оставлять неполный клиентский usage, поэтому отсутствие счётчика не означает отсутствие выполненной работы.

Полезны [ошибки потоков](/ru/journal/openrouter-stream-errors/) и [карта мониторинга GPU](/ru/journal/gpu-monitoring-scorecard/). Итог здесь — прослеживаемая отмена на известных границах, без обещания универсальной остановки processing, биллинга или работающих ресурсов конкретного проекта.