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

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

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

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

• Python-фреймворк
• несколько фоновых сервисов
• orchestration слой
• иногда векторную базу
• довольно сложную конфигурацию

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

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

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

• посмотреть загрузку CPU
• проверить диск
• прочитать логи
• перезапустить сервис

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

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

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

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

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

• минимальная инфраструктура
• быстрый запуск
• предсказуемое выполнение команд
• возможность использовать LLM, но не везде

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

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

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

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

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

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

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

• задержки
• галлюцинации
• лишние вычисления

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

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

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

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

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

Route classification

Skill classification

Skill execution

Ollama (qwen2.5:0.5b)

OpenAI (gpt-4o-mini)

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

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

1. сообщение приходит из Telegram
2. проходит авторизацию и сохраняется
3. система пытается сопоставить его с известным skill
4. если совпадение найдено — действие выполняется сразу
5. если нет — LLM используется для классификации
6. перед выполнением skill проходит валидация

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

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

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

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

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

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

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

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

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

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

• не нужен веб-интерфейс
• есть уведомления
• доступ с телефона
• встроенная авторизация

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

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

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

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

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

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

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

Что дальше

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

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

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

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

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

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

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

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

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

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

• Python-фреймворк
• несколько фоновых сервисов
• orchestration слой
• иногда векторную базу
• довольно сложную конфигурацию

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

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

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

• посмотреть загрузку CPU
• проверить диск
• прочитать логи
• перезапустить сервис

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

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

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

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

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

• минимальная инфраструктура
• быстрый запуск
• предсказуемое выполнение команд
• возможность использовать LLM, но не везде

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

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

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

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

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

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

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

• задержки
• галлюцинации
• лишние вычисления

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

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

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

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

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

Route classification

Skill classification

Skill execution

Ollama (qwen2.5:0.5b)

OpenAI (gpt-4o-mini)

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

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

1. сообщение приходит из Telegram
2. проходит авторизацию и сохраняется
3. система пытается сопоставить его с известным skill
4. если совпадение найдено — действие выполняется сразу
5. если нет — LLM используется для классификации
6. перед выполнением skill проходит валидация

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

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

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

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

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

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

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

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

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

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

• не нужен веб-интерфейс
• есть уведомления
• доступ с телефона
• встроенная авторизация

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

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

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

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

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

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

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

Что дальше

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

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

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

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

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

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