В этом материале
Закрытый клиентский socket подтверждает только локальную отмену. Остановку upstream-работы и освобождение ресурсов нужно наблюдать отдельно.
Пользователь остановил ответ, и интерфейс перестал показывать текст. Это ещё не доказывает, что вычисление завершилось на сервере. Клиент мог прекратить чтение, прокси сохранить upstream-соединение, а движок продолжить генерацию. Для провайдера важна вся цепочка отмены: где возник сигнал, какие компоненты его обработали и какие ресурсы действительно освободились. Проверка начинается с ограниченного синтетического сценария, а не с предположения об автоматическом распространении disconnect.
Разделите наблюдаемые границы
AbortController позволяет прервать fetch, чтение body и связанные streams на стороне клиента. Такое действие подтверждает поведение клиента. Оно само по себе не описывает, что сделал удалённый inference-движок, особенно при наличии промежуточного прокси и внутренних очередей.
Составьте карту: логическая операция клиента, внешнее соединение, запрос API-процесса, upstream-операция. Для каждой границы укажите доступный идентификатор и признак завершения. Если часть цепочки не наблюдается, сохраните этот предел в результате вместо утверждения «всё остановлено» по одному внешнему событию.
Проверьте политику прокси
NGINX описывает client abort и связанные настройки proxy-модуля. Поведение зависит от фактической конфигурации. Не переносите результат прямого подключения на маршрут с прокси и не считайте исчезновение клиента доказательством немедленного закрытия каждой внутренней операции.
Запишите эффективные настройки тестового location без секретов. Сравните прямой путь и путь через промежуточный слой на одном и том же сценарии. Так можно локализовать случай, где сигнал не проходит дальше либо где уже накопленный буфер скрывает продолжающуюся работу источника.
Испытайте две точки отмены
Первый fixture отменяет запрос после принятия, но до первого content. Второй прекращает чтение после известного числа событий. Оба имеют небольшой предел выхода, общий timeout и верхнее число попыток. Не используйте настоящие клиентские данные и не создавайте бесконечную генерацию ради наблюдения cleanup.
Документация OpenRouter прямо связывает поддержку отмены с конкретными провайдерами и режимом. Поэтому способность одного маршрута остановить processing нельзя объявлять общей гарантией любых интеграций. Для собственного сервиса тест должен назвать проверенную конфигурацию и отдельно указать, что не подтверждено.
Наблюдайте освобождение ресурсов
Метрики vLLM описывают серверные показатели, которые помогают следить за состоянием запросов и очередями. Сохраните baseline до fixture, временной ряд во время него и состояние после завершения. Снижение числа внешних соединений не заменяет подтверждение соответствующей upstream-операции.
Рост или задержка возврата gauges требуют отдельной развилки: запрос ещё выполняется, ожидает в очереди, удерживает буфер либо метрика обновляется с другой частотой. Не называйте один поздний sample утечкой. Повторите ограниченный тест и сравните идентификаторы, прежде чем делать вывод о механизме.
Отделите cleanup от расчётов
Подтверждённое освобождение памяти или остановка stream не определяют оплату самостоятельно. Учёт работы зависит от выбранного контракта и доступных итоговых записей. Отмена может оставлять неполный клиентский usage, поэтому отсутствие счётчика не означает отсутствие выполненной работы.
Полезны ошибки потоков и карта мониторинга GPU. Итог здесь — прослеживаемая отмена на известных границах, без обещания универсальной остановки processing, биллинга или работающих ресурсов конкретного проекта.