Почему большинство AI-агентов плохо работают на Raspberry Pi (и как я попытался это исправить)

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

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

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

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

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

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

• orchestration слой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• задержки

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

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

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

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

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

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

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

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

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

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.