Что происходит с 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’а.