Что происходит с LLM‑пайплайном, если провайдер падает посреди выполнения

В 2025 году каждый крупный провайдер LLM пережил минимум один значимый сбой. Большинство решений этой проблемы — gateway‑слой снаружи приложения: LiteLLM, Bifrost, Kong AI Gateway. Они перехватывают упавший HTTP‑запрос и повторяют его на другом провайдере.

Это работает для одного вызова, но не работает для многошагового пайплайна — gateway не знает, что упавший запрос был вторым шагом из трёх. Он видит запрос, которому нужен retry, а не позицию в конечном автомате.

В этой статье — как реализовать fallback провайдера как явный переход FSM на реальном стеке llm‑nano‑vm 0.8.6, включая два бага, на которые мы наткнулись тестируя рабочий пакет, а не его модель.

Постановка задачи

Пайплайн кредитной заявки, три шага:

collect_application → verify_income → policy_decision

verify_income — LLM‑шаг. Провайдер может стать недоступен посередине. Нужно: пайплайн завершается на другом провайдере, а Receipt (детерминированный артефакт nano‑vm, вычисляемый после выполнения) показывает что именно произошло.

Первая попытка — дать LLM‑шагу упасть естественно

Интуитивно ожидаешь, что штатный LLM‑шаг бросит исключение, а FSM его перехватит и создаст точку ветвления. Это не работает в текущей модели шагов llm‑nano‑vm: если адаптер бросает исключение, шаг помечается FAILED, трейс завершается. Точки ветвления нет.

Механизм: отказ как результат TOOL, а не исключение

Вызов LLM выносится внутрь TOOL‑шага, который перехватывает исключение и возвращает сентинел:

async def attempt_llm_step(**kwargs): step_id = kwargs[«step_id»] try: result = await _call_adapter(prompt) return 1 # успех except ProviderUnavailableError: return 0 # отказ

FSM‑программа ветвится по этому сентинелу:

Step( id=»try_s2″, type=StepType.TOOL, tool=»attempt_llm_step», args={«step_id»: «s2_verify»}, output_key=»provider_ok», ), Step( id=»check_s2_result», type=StepType.CONDITION, condition=»$provider_ok < 1″, then=»switch_provider», otherwise=»s3_setup», ),

Это и есть механизм: отказ провайдера становится значением, которое FSM вычисляет, а не исключением, которое распространяется по стеку вызовов.

Баг № 1: ExecutionVM.run — асинхронный

Легко пропустить при беглом чтении документации. vm.run() возвращает корутину, не Trace. Решение —asyncio.run(vm.run(program, context=…)) на верхнем уровне, и async def для любой tool‑функции, вызывающей LLM‑адаптер: ExecutionVM проверяет inspect.iscoroutinefunction(fn) для каждого tool и авейтит соответственно.

Баг № 2: строковые литералы не работают в условиях ASTEngine

Первая версия условия:

condition=»try_s2.output == ‘PROVIDER_FAILED'»

Парсится без ошибки. Вычисляется в False всегда. Проверили напрямую:

from nano_vm.vm import eval_condition ctx = {«try_s2»: {«output»: «PROVIDER_FAILED»}} eval_condition(«try_s2.output == ‘PROVIDER_FAILED'», ctx) # False

ASTEngine в llm‑nano‑vm 0.8.6 поддерживает == != > < in not_in and or not contains, но правая часть сравнения должна быть числом или $var‑ссылкой, не строковым литералом в кавычках. Рабочий паттерн — числовой сентинел:

condition=»$provider_ok < 1″

Теперь это задокументированное ограничение проекта, а не устная договорённость.

Два сценария отказа

python receipt_demo.py —failure-mode retry # деградация: 3 попытки, затем switch python receipt_demo.py —failure-mode hard # отказ с первой попытки, мгновенный switch

Вывод для hard:

S2 verify_income EVENT: ProviderUnavailable (CLAUDE) ACTION: switch_provider claude → gpt S3 policy_decision ✓ GPT RECEIPT: { «final_status»: «SUCCESS», «provider_final»: «gpt», «switch_event»: «ProviderUnavailable», «trace_hash»: «c6f5c32c…» }

Почему trace_hash одинаковый в обоих сценариях

trace_hash — это SHA-256 над цепочкой Меркла по результатам шагов. Оба сценария проходят идентичный путь по FSM‑графу: retry‑цикл инкапсулирован внутри TOOL‑шага attempt_llm_step, поэтому FSM в обоих случаях видит ровно один результат этого шага. Одинаковый путь → одинаковый хэш. Это свойство конструкции, не совпадение, которое нужно объяснять постфактум — если пути расходятся, расходятся и хэши.

Что мы не делаем

• Fallback‑цепочка фиксированная (claude → gpt → qwen), не скоринговый выбор

• Нет активного health‑check polling — отказ детектируется только при попытке вызова, в отличие от заявленного Bifrost активного обнаружения с ~11μs overhead

• MockAdapter в демо не вызывает реальный API провайдера — ответы детерминированы намеренно, чтобы демо воспроизводилось без API‑ключей

С чем это сочетается, а не конкурирует

Gateway вроде LiteLLM продолжает владеть роутингом моделей, рейт‑лимитами и учётом стоимости на уровне HTTP. Этот FSM‑паттерн владеет fallback’ом, осведомлённым о состоянии пайплайна — отвечает на вопрос «что делал пайплайн в момент смерти провайдера, и завершился ли он». Эти слои решают принципиально разные задачи, дополняя, а не дублируя функции друг друга.

Репозиторий: provider‑fallback‑demo

pip install «llm-nano-vm[litellm]» python receipt_demo.py —both

Следующий шаг планируемый — эмитить switch_provider как span OpenTelemetry, чтобы событие появлялось в существующих дашбордах, а не только в JSON Receipt’а.

Источник: habr.com