Где ломается схема с openclaw
Я посмотрел на кейс с игровым PC, где крутится qwen на RTX 5090, и MacBook M5 Pro как запасная площадка. Сценарий очень житейский: днём у меня локальная модель летает на большой карте, вечером я тушу Ollama на десктопе, и запросы должны спокойно уйти на мак. На бумаге это выглядит как обычный failover. На практике — зависшие heartbeat, LLM API timeout и ощущение, что роутер просто не верит, что первый backend умер.
И вот тут у меня главный вывод: проблема, скорее всего, не в Ollama, а в прокси-слое. Если прокси слишком долго ждёт сокет, не умеет агрессивно резать таймауты или не держит нормальную health-check модель, он будет висеть на мёртвом узле хоть 40 минут. Для cron-задач и фоновых агентов это особенно неприятно, потому что пайплайн вроде жив, а по факту уже нет.
Я бы не строил такую схему вокруг openclaw/lm-proxy, если задача — именно надёжное автоматическое переключение. Идея из серии try connection1, except connection2 здравая, но в продовой жизни этого мало. Нужны короткие таймауты, ретраи, статус бэкендов и понятная маршрутизация.
Что я бы поставил вместо этого
Для такого self-hosted контура я бы взял LiteLLM как единый OpenAI-совместимый прокси перед двумя Ollama-инстансами. Один Ollama живёт на RTX 5090, второй — на MacBook M5 Pro. Клиенты, агенты, cron и всё остальное бьют не в Ollama напрямую, а в LiteLLM.
Почему мне это нравится: я один раз меняю endpoint у приложений и дальше играю маршрутизацией в одном месте. Можно задать primary backend на десктопе, fallback на маке, а при желании ещё и третий уровень — облако вроде OpenRouter. Это уже не кустарная ИИ интеграция, а нормальный транспортный слой для локальных моделей.
Базовая идея конфига такая:
- primary: Ollama на RTX 5090
- fallback: Ollama на Mac M5
- timeout: 15-30 секунд, не больше
- retries: 1-2, иначе только размазываете задержку
- общий alias модели для клиента, чтобы ему было всё равно, где она реально крутится
Если у вас qwen3.5:35b-a3b не совпадает по имени или по ресурсам с qwen3.5:27b на маке, я бы не скрывал это полностью. Лучше давать одному логическому имени класс задачи, а не делать вид, что модели идентичны. Иначе потом всплывут странные расхождения в ответах, и вы будете ловить баги уже не в сети, а в поведении модели.
Что это меняет для бизнеса и автоматизации
Самое полезное здесь не экономия на облаке, а предсказуемость. Когда ИИ автоматизация завязана на локальный inference, нельзя позволять пайплайну ждать мёртвый GPU полчаса. Бизнесу не нужен героизм железа, ему нужен маршрут запроса, который не тупит.
Выигрывают команды, у которых есть несколько узлов и понятная AI-архитектура: мощная машина под тяжёлые задачи, более слабая — как резерв, облако — как аварийный контур. Проигрывают те, кто шьёт логику переключения в каждый скрипт отдельно. Я такое уже видел: сначала «временно захардкодим», потом полгода никто не помнит, почему ночные джобы падают только по пятницам.
Мы в Nahornyi AI Lab как раз часто собираем такие ИИ решения для бизнеса: локальные модели, прокси, очереди, fallback, мониторинг и безопасная публикация сервисов во внутреннюю сеть. И почти всегда проблема не в модели как таковой. Ломается клей между компонентами — таймауты, маршрутизация, health checks, состояние очередей.
Если делать по уму, схема PC + Mac выглядит вполне рабочей. Я бы поставил LiteLLM как прослойку, дал каждому Ollama короткий timeout, добавил простой health endpoint и отдельно проверил, как ведут себя стриминг, cron и длинные генерации. Один вечер на настройку — и вместо магии появляется управляемая архитектура ИИ-решений.
Этот разбор я сделал как Вадим Нагорный из Nahornyi AI Lab — я такие self-hosted связки не коллекционирую в закладках, а реально собираю, дебажу и встраиваю в рабочие процессы.
Если хотите, я могу помочь разобрать именно ваш стек: что оставить на локалке, как сделать внедрение ИИ без хрупких костылей и где лучше поставить резервный маршрут. Пишите в Nahornyi AI Lab — посмотрим ваш кейс предметно.