Raspberry Pi 5 y openLight: por qué los agentes de AI típicos sobrecargan el hardware modesto

Большинство популярных AI-агентов плохо переносятся на Raspberry Pi 5 не потому, что модель слишком слабая, а потому что весь окружающий стек изначально рассчитан на серверы. Автор статьи разобрал эту проблему на практике и собрал свой лёгкий runtime openLight, который убирает лишние слои и оставляет только то, что реально нужно для типовых задач.

Почему всё тяжелеет

На обычном сервере агентный фреймворк кажется удобным компромиссом: Python-рантайм, отдельные фоновые сервисы, orchestration-слой, иногда векторная база и ещё набор зависимостей поверх этого. Но на Raspberry Pi 5 каждый такой слой начинает ощущаться буквально физически: система стартует дольше, памяти уходит больше, а простое действие внезапно требует инфраструктуры, сравнимой с небольшой платформой. Проблема особенно заметна, когда сценарии на самом деле очень простые. Автору не нужен был универсальный «цифровой сотрудник» с длинной цепочкой рассуждений. Ему хотелось решать базовые админские задачи: посмотреть загрузку CPU, проверить свободное место на диске, прочитать логи или перезапустить сервис. Для такого набора поднимать тяжёлый агентный стек — это тратить ресурсы не на результат, а на обслуживание самого инструмента.

Что предложил openLight

Вместо ещё одного общего фреймворка автор сделал openLight — минималистичный runtime для персональной инфраструктуры. Ключевая идея здесь простая: агент не должен превращаться в LLM для всего. Если команду можно обработать детерминированно, её надо выполнять именно так. Модель подключается только там, где без неё действительно неудобно: чтобы классифицировать запрос, интерпретировать текст пользователя или сопоставить сообщение с нужным skill.

• Один бинарник без сложной обвязки Реализация на Go вместо тяжёлого Python-стека SQLite для хранения вместо отдельной базы сервисов Минимум зависимостей и быстрый запуск Валидация skill перед выполнением команды Такой подход даёт не только экономию ресурсов, но и выигрыш по времени. В примере автора путь через локальную модель Ollama с qwen2.5:0.5b занял 42,55 секунды, тогда как тот же сценарий через OpenAI gpt-4o-mini — 3,28 секунды. Но главный вывод даже не в сравнении моделей: самые частые команды вообще не должны каждый раз проходить полный круг через LLM, если система может понять их заранее.

Как идёт запрос

Маршрут сообщения устроен линейно и прозрачно: запрос приходит из Telegram, проходит авторизацию и сохранение, после чего система сначала ищет прямое совпадение с известным skill. Если такое совпадение находится, команда исполняется сразу. Если нет, подключается LLM-классификатор, который решает, что делать дальше: продолжать диалог или выбрать подходящий навык. Перед запуском skill проходит дополнительную проверку, чтобы сохранить контроль над исполнением.

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

Telegram здесь выбран не как временная заглушка, а как вполне рабочий интерфейс. Не нужен отдельный веб-клиент, уведомления приходят сразу, доступ есть с телефона, а авторизация уже встроена в канал общения. Пользователь может написать что-то вроде «что там по статусу системы», а runtime вернёт понятный ответ с именем хоста, загрузкой CPU, объёмом занятой памяти, свободным местом на диске, временем работы и температурой. При этом сами метрики собираются детерминированно, без лишней генерации.

Что это значит

История с openLight хорошо показывает, куда реально могут двигаться AI-агенты вне дата-центров и демо-сценариев. На маленьких устройствах выигрывает не самый «умный» стек, а тот, который умеет вовремя не звать модель. Для Raspberry Pi и домашней инфраструктуры это важный сдвиг: полезный агент может быть не гигантской платформой, а маленьким исполняемым слоем с чёткими правилами и точечным использованием LLM.