Проблема: тяжёлые AI-агенты на маленьком железе

Последнее время я экспериментировал с AI-агентами на Raspberry Pi 5.

И довольно быстро столкнулся с проблемой: большинство существующих агентных фреймворков оказываются слишком тяжёлыми для небольшого железа.

Типичная архитектура таких решений включает:

  • Python-фреймворк

  • несколько фоновых сервисов

  • orchestration слой

  • иногда векторную базу

  • довольно сложную конфигурацию

На сервере это нормально работает. Но на Raspberry Pi всё начинает ощущаться иначе:

  • долгий старт

  • лишние зависимости

  • больше потребление памяти

  • сложность там, где задачи на самом деле простые

А задачи, ради которых я хотел использовать агента, были довольно базовые:

  • посмотреть загрузку CPU

  • проверить диск

  • прочитать логи

  • перезапустить сервис

Для этого не хотелось поднимать целую AI-платформу.

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

Проект называется openLight

Что хотелось получить

Основные требования были довольно простыми:

  • минимальная инфраструктура

  • быстрый запуск

  • предсказуемое выполнение команд

  • возможность использовать LLM, но не везде

Идея была в том, чтобы агент не превращался в “LLM для всего”.

Многие действия можно выполнить детерминированно и быстрее.

LLM полезен скорее для:

  • классификации запросов

  • интерпретации текста

  • сопоставления команды со skill

Основная идея: deterministic routing + LLM

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

Это удобно с точки зрения универсальности, но на практике приводит к нескольким проблемам:

  • задержки

  • галлюцинации

  • лишние вычисления

В openLight логика немного другая.

Сначала система пытается обработать запрос детерминированно.

Если это не удаётся, то используется LLM для классификации.

Таким образом:

  • простые команды выполняются мгновенно

  • модель используется только там, где это действительно нужно

Path

Route classification

Skill classification

Skill execution

Total

Ollama (qwen2.5:0.5b)

19.84s

22.56s

0.15s

42.55s

OpenAI (gpt-4o-mini)

1.35s

1.77s

0.15s

3.28s

Как работает маршрутизация запросов

Telegram message
      ↓
Auth + persistence
      ↓
Deterministic routing
      ├─ match → execute skill
      └─ no match → LLM route classifier
                       ↓
                 chat / skill
                       ↓
                   validate
                       ↓
                   execute

Последовательность примерно такая:

  1. сообщение приходит из Telegram

  2. проходит авторизацию и сохраняется

  3. система пытается сопоставить его с известным skill

  4. если совпадение найдено — действие выполняется сразу

  5. если нет — LLM используется для классификации

  6. перед выполнением skill проходит валидация

Такой подход позволяет сохранить контроль над исполнением команд.

Архитектура openLight

Проект специально сделан максимально простым.

Основные решения:

  • написан на Go

  • распространяется как один бинарник

  • используется SQLite

  • минимальные зависимости

Это позволяет запускать систему на небольших устройствах без сложной инфраструктуры.

Интерфейс через Telegram

Пока основной интерфейс — Telegram.

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

Преимущества такого подхода:

  • не нужен веб-интерфейс

  • есть уведомления

  • доступ с телефона

  • встроенная авторизация

Например, можно отправить команду:

что там по статусу системы

Агент интерпретирует запрос и запускает соответствующий skill, который собирает информацию о системе.

Ответ выглядит примерно так:

Hostname: raspberry
CPU: 0.0%
Memory: 2.1 GiB used / 7.9 GiB total
Disk: 864.2 GiB free / 916.3 GiB total
Uptime: 1d 22h 38m 16s
Temperature: 51.8C

В этом случае LLM используется только для того, чтобы сопоставить текст запроса с системным skill.

Само выполнение происходит детерминированно: runtime собирает метрики системы и возвращает результат.

Это позволяет:

  • быстро обрабатывать типовые запросы

  • не гонять каждое действие через модель

  • сохранить предсказуемость выполнения

Что дальше

Проект пока на ранней стадии.

Сейчас основной интерфейс Telegram, но дальше планируется добавить:

  • дополнительные интерфейсы

  • новые skills

  • расширение возможностей работы с локальными LLM

Идея остаётся той же: небольшой runtime для персональной инфраструктуры, где детерминированная логика выполняет большую часть работы, а LLM используется там, где это действительно полезно.

Если интересно посмотреть проект или поэкспериментировать

Буду рад фидбеку и идеям для новых skills.