Де ламається схема з openclaw
Я розглянув кейс з ігровим ПК, де працює qwen на RTX 5090, та MacBook M5 Pro як запасний майданчик. Сценарій дуже життєвий: вдень у мене локальна модель літає на потужній карті, ввечері я вимикаю Ollama на десктопі, і запити мають спокійно перенаправлятися на Mac. На папері це виглядає як звичайний 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 на Mac, а за бажанням додати ще й третій рівень — хмару на кшталт OpenRouter. Це вже не кустарна ШІ-інтеграція, а нормальний транспортний шар для локальних моделей.
Базова ідея конфігу така:
- primary: Ollama на RTX 5090
- fallback: Ollama на Mac M5
- timeout: 15-30 секунд, не більше
- retries: 1-2, інакше ви лише розтягуєте затримку
- спільний alias моделі для клієнта, щоб йому було байдуже, де вона насправді працює
Якщо ваша qwen3.5:35b-a3b не збігається за назвою чи ресурсами з qwen3.5:27b на Mac, я б не приховував це повністю. Краще давати одній логічній назві клас задачі, а не вдавати, що моделі ідентичні. Інакше потім виникнуть дивні розбіжності у відповідях, і ви будете ловити баги вже не в мережі, а в поведінці моделі.
Що це змінює для бізнесу та автоматизації
Найкорисніше тут не економія на хмарі, а передбачуваність. Коли ШІ-автоматизація зав'язана на локальний 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 — розглянемо ваш кейс предметно.