api llama — когда локальный сервер готов к отказу узла

Локальная модель становится сервисом в тот день, когда единственный GPU перестаёт отвечать. До этого момента легко считать, что inference уже есть: endpoint поднят, запросы идут, данные не покидают периметр. Но запущенный процесс и сервис - не одно и то же. Сервис - это то, у чего есть решение на случай, когда железо молчит.

Тезис у меня один: если команда не может назвать владельца восстановления, очередь и резерв на момент отказа узла, локальный Llama-сервер не готов как сервис - как бы уверенно он ни отвечал прямо сейчас. Проверять этот тезис я предлагаю настольным инцидентом: разговорным прогоном сценария отказа, из которого выходит плейбук и список рисков, которые вы пока не приняли.

И сразу честная граница. Настольный прогон не измеряет реальное время восстановления и не доказывает, что внешний fallback вообще допустим по твоим данным. Он вскрывает решения, которых ещё нет. Это его работа - и это же его предел.

Платите в рублях за AI-модели без наценки на токены через provod.ai

Отвечающий GPU - ещё не готовность

Ходовое допущение звучит так: локальный endpoint готов к эксплуатации, если отвечает GPU. С этого допущения я и предлагаю снять доверие. Контроль над данными - реальная и часто главная причина держать модель у себя. Но контроль над данными не равен устойчивости к поломке.

Начни с того, что живёт до инфраструктуры. Llama 3.1 под Community License можно разворачивать без отдельной коммерческой лицензии, если сервис обслуживает меньше 700 миллионов активных пользователей в месяц - но лицензия обязывает приложить копию соглашения, показать атрибуцию «Built with Llama» и соблюдать Acceptable Use Policy Meta, включённую по ссылке (по тексту лицензии Llama 3.1, Meta, developer.meta.com, доступ 2026-07-18). Это юридические и документационные обязательства, привязанные к самим весам, и они существуют раньше вопроса об отказе узла. «Бесплатно» здесь означает «с условиями», а не «без обязательств».

Оговорка важна: это условия конкретно Llama 3.1. У релизов 3.2 и 4 свои файлы лицензий с потенциально другими порогами MAU и пунктами атрибуции, так что версию весов надо проверять по факту, а не по памяти.

Отсюда выводится первое непринятое решение. Ты закрыл юридический вопрос и вопрос данных, но ни то, ни другое не отвечает на простой сценарий: узел не поднялся после обновления драйвера. Если ты заранее закладываешь внешний маршрут на такой случай, provod.ai (российский OpenRouter) - один из кандидатов на роль такого резерва, но только в явно согласованном маршруте данных, о чём ниже.

Вопрос про этот endpoint всегда обрывается на моменте вызова

Прежде чем спорить об устойчивости, стоит посмотреть, в какой форме этот вопрос вообще существует. Он раскладывается на десяток формулировок, и все они про одно: как достучаться до модели и чем авторизовать вызов. Слева - как звучит вопрос, справа - что за ним стоит.

Разные написания тут ничего не меняют: liama и лама - это латиница и кириллица для того же llama. Меняет другое. Каждая формулировка обрывается ровно там, где вызов удался. Ни одна не спрашивает, что произойдёт с сервисом, когда узел под этим доступом умрёт. Вопрос про доступ и вопрос про эксплуатацию живут в разных фазах жизни одного и того же endpoint, и вторую фазу приходится придумывать самому.

Локально этот endpoint чаще всего поднимают три рантайма: Ollama, vLLM и сервер из llama.cpp. Все три отдают HTTP-совместимый интерфейс, у всех трёх можно закрыть вызов ключом. И у всех трёх документированный дефолт - один процесс на одном узле.

Что на самом деле обещает документация локального сервера?

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

Ollama в своём FAQ описан как single-server, single-process рантайм: OLLAMA_MAX_QUEUE по умолчанию ставит в очередь до 512 ожидающих запросов, после чего сервер начинает возвращать HTTP 503 «overloaded», а OLLAMA_NUM_PARALLEL и OLLAMA_MAX_LOADED_MODELS управляют только внутрипроцессной конкуренцией (Ollama, docs.ollama.com/faq, доступ 2026-07-18). Никакого встроенного кластера, мультиузла или failover в документации нет. Это не потолок - значения настраиваются, - но это то, что ты получаешь из коробки.

# документированные дефолты Ollama: очередь 512, затем 503 OLLAMA\_MAX\_QUEUE=512 OLLAMA\_NUM\_PARALLEL=1 ollama serve

# вызов к локальному серверу, ключ - на твоей стороне curl http://localhost:11434/v1/chat/completions \
  -H "Authorization: Bearer $LLAMA\_KEY" \
  -d '{"model":"llama3.1","messages":[{"role":"user","content":"ping"}]}'

vLLM в официальной инструкции по мультиузловому развёртыванию требует, чтобы оператор вручную открыл и держал shell-сессию на каждом узле, поддерживая живым кластер Ray, и документация прямо говорит: «any shell disconnect will terminate the cluster» (vLLM, docs.vllm.ai, доступ 2026-07-18). У референсного мультиузлового пути нет встроенной отказоустойчивости к потерянному узлу - разрыв сессии рушит кластер.

Kubernetes на этом фоне выглядит как страховка, но и это надо читать буквально. PodDisruptionBudget управляет только добровольными нарушениями - drain, rolling update; официальная документация прямо пишет, что PDB «does not ensure that the specified number... of pods will always be available», и оставляет приложение открытым к недобровольным нарушениям вроде отказа узла или железа (Kubernetes, kubernetes.io, доступ 2026-07-18). PDB - это не план восстановления после отказа узла.

Даже готовый производственный рецепт наследует ту же осторожность. Официальный гайд Oracle по развёртыванию vLLM production stack на OKE поставляет пример Helm-конфигурации с replicaCount: 1 по умолчанию - одной точкой отказа - и выносит «high availability» (поднять число реплик, разнести GPU-узлы по availability-доменам, чтобы роутер мог переключиться) в отдельный шаг «what's next», а не в базовый рабочий деплой (Oracle, docs.oracle.com, доступ 2026-07-18). Отвечающий single-replica endpoint - это документированный дефолт, а не готовность к failover.

Важно, что это про референсные пути в официальных документах, а не про любую возможную топологию. Команды на управляемых платформах inference или на своей оркестрации могли уже решить хрупкость одного узла. Факт устанавливает лишь одно: документированный путь по умолчанию её не решил.

Настольный инцидент вместо ожидания реального

Раз документация не даёт готовности, готовность надо смоделировать заранее - до первого реального отказа. Настольный инцидент как метод не выдумка: NIST SP 800-84 - стоящая федеральная методология для discussion-based (tabletop) упражнений. Её суть: собрать людей, которые держат роли в реагировании на инцидент, провести их через разворачивающийся сценарий с вбросами новой информации и выпустить документированный after-action отчёт о пробелах (NIST SP 800-84, nvlpubs.nist.gov, доступ 2026-07-18). Это и есть основание считать настольный прогон легитимным методом добычи доказательств, а не болтовнёй у доски.

Оговорка от того же источника: SP 800-84 - общий стандарт методологии упражнений, а не документ про ML-инфраструктуру. Здесь он используется как процедурный шаблон для настольного инцидента, не как GPU-специфичное руководство.

Прогон устроен просто. Собираешь тех, кто реально будет действовать. Даёшь стартовый вброс: единственный GPU-узел не поднялся после планового обновления. Дальше добавляешь инъекции - очередь запросов растёт, приходят первые 503, поступает вопрос от продукта «когда починим». И на каждом шаге фиксируешь не что «должно» произойти, а кто именно делает следующий шаг и чем. Выход прогона - две вещи: плейбук и список рисков, которые команда пока не приняла.

Четыре решения плейбука: владелец, очередь, резерв, восстановление

Плейбук «отказ узла - очередь - резерв - восстановление» отвечает на четыре вопроса, и все четыре - решения, а не факты из документации.

Владелец. Кто именно отвечает за восстановление в момент отказа - поимённо, а не «команда». Если владельца нет, плейбук не проходит: некому запустить остальные три шага.

Очередь. Что происходит с входящими запросами, пока узел лежит. У Ollama по умолчанию это 512 мест в очереди и затем 503 - решаешь, держать ли клиентов в ожидании, отбивать ли их сразу честной ошибкой или уводить на резерв. Молчаливая деградация - худший из вариантов, потому что продукт узнает о простое от пользователей.

Резерв. Что подхватывает нагрузку - вторая локальная модель в горячем резерве или внешний маршрут. Это выбор с ценой, и источники его за тебя не делают: правильность «очередь против standby-модели» - твоя проектная позиция, а не установленный факт.

Восстановление. Кто и по какому шагу возвращает основной узел, и какой признак считается «сервис снова здоров».

Именно на шаге резерва внешний маршрут становится предметным. Тут решает протокол. Резерв, говорящий на том же OpenAI-совместимом интерфейсе, что и локальный сервер, включается двумя переменными окружения - без ветки в коде, которую в момент инцидента никто не хочет писать первый раз. У единого API с поддержкой OpenAI-совместимых клиентов меняешь ключ и base_url, и тот же клиент уходит на внешний канал. За одним ключом там доступен широкий набор моделей, так что резерв можно держать и на той же Llama, и на другой модели - решение принимаешь заранее, на бумаге, а не в момент отказа. И только если маршрут данных согласован.

# основной локальный маршрут export OPENAI\_BASE\_URL=http://localhost:11434/v1

# согласованный внешний резерв - только если маршрут данных разрешён export OPENAI\_BASE\_URL="$FALLBACK\_BASE\_URL"   # base\_url внешнего провайдера export OPENAI\_API\_KEY="$FALLBACK\_KEY"         # ключ внешнего канала

Компромисс стоит назвать прямо: план восстановления повышает объём эксплуатации - его надо написать, назначить, отрепетировать и пересматривать. Но именно он превращает локальность из запущенного процесса в реальный сервис. Без него локальный контроль над данными остаётся, а сервиса нет.

Пределы настольного инцидента: чего он не решает

Настольный инцидент честен ровно настолько, насколько честно ты называешь его пределы.

Он не заменяет реальное восстановление. Прогон у доски не измеряет фактическое время подъёма узла и не проверяет, что резерв выдержит боевую нагрузку. Эти риски остаются неизмеренными и составляют выходы будущей проверки, а не результаты, которые можно предъявлять как наблюдённые (полный список - на схеме ниже).

Он не решает юридический вопрос за тебя. Атрибуция «Built with Llama», редистрибуция соглашения и Acceptable Use Policy остаются обязательствами при любой топологии, и внешний резерв на них не влияет.

Маршрут данных он тем более не разрешает за тебя. Внешний fallback не подразумевается по умолчанию: если по классу данных внешняя отправка недопустима, резервом остаётся локальный standby - и это тоже отдельная строка плейбука, которую кто-то должен подписать.

И он не превращает резерв в замену локальной инфраструктуре. Внешний маршрут закрывает одно окно - то, пока твой узел лежит. Он не даёт того, ради чего локальный сервер вообще ставили: изоляции весов и данных внутри периметра. Если прогон показал, что резерв нужен постоянно, у тебя не проблема плейбука, а проблема выбранной топологии.

Короткий FAQ

Локальный сервер отвечает уже полгода без сбоев. Зачем плейбук? Полгода без сбоев говорят о том, что отказа пока не случилось, и ровно ничего - о том, как вы его переживёте. План принимают до первого отказа: после него у тебя одновременно простой и открытый вопрос, кто им занимается.

Достаточно ли поднять replicaCount больше единицы? Это снимает документированный single point of failure из дефолта Oracle, но не отвечает на вопросы очереди, владельца и маршрута данных. Больше реплик - часть резерва, а не весь плейбук.

Можно ли считать Kubernetes PDB защитой от отказа узла? Нет. PDB держит только плановые операции - drain и обновление; сгоревшая карта или упавший узел проходят мимо него как недобровольное нарушение.

Внешний резерв - это признание, что локальность не работает? Нет. Локальность даёт контроль над данными; внешний маршрут - это согласованный резерв на случай, когда узел молчит. Одно не отменяет другое, если маршрут данных разрешён явно.

Настольный прогон - это формальность? Только если провести его без ролей и без вбросов. По методологии NIST SP 800-84 ценность даёт документированный after-action список пробелов, а не сам факт встречи.

У резервного маршрута есть организационная сторона, о которую планы обычно и спотыкаются: завести его нужно до инцидента, иначе дежурный в три ночи упрётся не в конфиг, а в закупку. Здесь помогает то, что оформляется один раз и заранее: рублёвый баланс организации, договор и закрывающие документы, общий ключ и рабочее пространство на команду. Цены на модели при этом остаются провайдерскими, без наценки provod.ai (owner-approved, 2026-07-15).

provod.ai — отдельное пространство для задач компании

Рабочие запросы, доступы и расходы не должны жить в личных аккаунтах сотрудников: корпоративное пространство объединяет команду и помогает сохранять управляемый контур использования AI.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Компания получает единый тарифный принцип: цены 1:1 с официальными поставщиками и нулевая собственная наценка provod.ai.

Создайте рабочее пространство команды: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных

Источники

• Meta, лицензия Llama 3.1 Community License, developer.meta.com, доступ 2026-07-18.
• Ollama, FAQ (очередь OLLAMA_MAX_QUEUE, HTTP 503, отсутствие кластеризации), docs.ollama.com/faq, доступ 2026-07-18.
• vLLM Project, distributed serving (ручная shell-сессия, разрыв рушит кластер), docs.vllm.ai, доступ 2026-07-18.
• Kubernetes, Disruptions (PDB и добровольные нарушения), kubernetes.io, доступ 2026-07-18.
• NIST SP 800-84, методология tabletop-упражнений, nvlpubs.nist.gov, доступ 2026-07-18.
• Oracle, deploy vLLM production stack on OKE (replicaCount: 1, HA в «what's next»), docs.oracle.com, доступ 2026-07-18.