Что происходит с 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
Оцените материал:
