TL;DR

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

Технически это работает. Но как только включается реальная нагрузка и «тяжёлый» системный контекст OpenClaw, начинаются тайм-ауты и эксплуатационные нюансы.

Рабочим для меня стал гибрид: локалка по умолчанию + автоматический fallback в облако при серии ошибок + возврат на локалку после успешного прогона.

Есть идея, в которую легко влюбиться: перенести важную автоматизацию локально и не зависеть от облака в каждом чихе.

Я взял OpenClaw, поднял локальную модель через Ollama и прогнал всё на реальной задаче из умного дома. Не на «привет-мир», а на ежедневной рутине, где цена ошибки — это пропущенная проблема в доме.

Что за задача

Каждый день система должна:

  1. сходить в VictoriaMetrics за телеметрией сенсоров;
  2. прогнать значения через набор правил аномалий;
  3. отправить короткую понятную сводку в Telegram.

Цель — не «поболтать с LLM», а получить короткий и практичный отчёт: что сломалось, где и насколько критично, без спама из сотен строк.

Почему именно qwen3:14b

Выбор был прагматичный.

Я пробовал более крупные модели, но они упирались в VRAM. Когда модель не помещается в видеопамять и начинает уезжать в RAM/CPU, скорость резко падает.

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

Поэтому qwen3:14b на RTX 4090 оказался рабочим компромиссом.

Инфраструктурная реальность

Контур был такой:

  • Windows-хост с GPU;
  • SSH-доступ;
  • WSL как рабочее Linux-окружение.

Критичный момент — автоподъём после перезагрузки:

  • сначала поднять WSL от пользователя;
  • затем внутри WSL поднять Ollama;
  • плюс Wake-on-LAN для удалённого включения машины.

Главная сложность — не «запустить один раз», а сделать предсказуемый старт каждый день без ручных действий.

Где болело

Я поймал три типа ошибок:

  • LLM request timed out — запрос до модели ушёл, но ответ не вернулся в лимит времени;
  • cron: job execution timed out — уже вся джоба не завершилась в отведённое окно;
  • зависание в running — GPU загружен, железо шумит, а финального результата нет.

По наблюдениям в пике:

  • GPU load до ~85%;
  • потребление до ~350W;
  • VRAM около 74%.

Что пробовал и почему не помогало

Я сначала лечил симптомы: увеличивал timeout, перезапускал сервисы, гонял ручные прогоны, проверял логи.

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

Что реально сработало

Переломный момент — разделить процесс:

  1. отдельный скрипт (daily_anomaly_collect.sh) собирает и нормализует данные;
  2. в модель идёт уже компактный JSON;
  3. модель делает только финальную короткую сводку.

Плюс пришлось поправить PromQL/лейблы под реальные данные сенсоров.

После этого сценарий стал предсказуемым и начал стабильно укладываться по времени.

Итоговая архитектура для этой джобы

  • основной путь: локальная ollama/qwen3:14b;
  • если N запусков подряд падают — автоматический fallback на облачную модель;
  • после успешного прогона — автоматический возврат на локалку.

Это даёт и автономность, и надёжность: локалка работает там, где уместно, но задача не умирает в момент деградации.

Вывод

Локальная LLM на RTX 4090 — рабочий инструмент. Но как единственный «мозг» для регулярных прод-задач дома — пока слишком много компромиссов по latency, VRAM и поддержке.

На сегодня лучший результат для меня — гибридная схема с автоматическим failover: меньше идеологии, больше инженерной прагматики.