Do AnyLanguageModel ao Agent Harness On-Device: Prática de Engenharia da Colaboração Heterogênea RK3588 + ESP32-S3

Introdução: Desafios de Engenharia de Hardware para Agentes On-Device

O AnyLanguageModel 1.0 demonstrou a viabilidade do runtime local de modelos em plataformas Apple, mas sua ideia central — desacoplar a inferência do modelo dos recursos de hardware e gerenciar memória, energia e agendamento de tarefas por meio de um Harness leve — é igualmente aplicável a plataformas embarcadas heterogêneas. Para IDH, o verdadeiro desafio está em: como implantar suavemente LLMs e interação de voz em bonecas companheiras de IA, óculos de guia de onda ou crachás inteligentes sob restrições de RAM/Flash limitadas, orçamentos de energia rigorosos e dissipação de calor em micro-chassi (≤38°C).

Este artigo usa a arquitetura heterogênea do Rockchip RK3588 e Espressif ESP32-S3 como exemplo para analisar os pontos de design do pipeline colaborativo de streaming fim-nuvem e fornecer uma implementação de referência reutilizável do Agent Harness.

Seleção da Arquitetura Heterogênea: Filosofia de Divisão de Trabalho do RK3588 + ESP32-S3

Especificações dos Chips e Posicionamento de Papel

| Modelo do Chip | Recursos Principais | Papel | Restrições Principais | |---------|---------|------|---------| | RK3588 | 4×A76 + 4×A55, NPU 6TOPS, 8GB LPDDR4X | Inferência local de LLM, reconhecimento de fala, compreensão de intenções | Potência 3-5W, requer resfriamento ativo ou grande dissipador | | ESP32-S3 | Xtensa LX7 dual-core @240MHz, 512KB SRAM, 8MB PSRAM | Front-end de áudio de baixo consumo, hub de sensores, detecção de palavra de ativação | Potência <100mW, sem pressão de resfriamento | | nRF5340 | Cortex-M33 dual-core, 1MB Flash, 512KB RAM | Conectividade BLE/Thread, standby de ultra baixo consumo | Adequado para cenários com espaço restrito, como hastes de óculos | | JieLi JL7016 | DSP de áudio dedicado, Bluetooth de baixo consumo | Codec de áudio, redução de ruído | Chassi de boneca sensível a custo |

Recomendação de Engenharia: Para bonecas companheiras de IA, recomenda-se a combinação RK3588 + ESP32-S3. O RK3588 lida com inferência pesada, enquanto o ESP32-S3 processa captura e pré-processamento de áudio. Os dois colaboram via UART/SPI ou Wi-Fi 6. Se o formato do produto for óculos de guia de onda, pode-se escolher o RK3566 (versão de baixo consumo) emparelhado com o nRF5340 para reduzir o consumo geral e o tamanho.

Orçamento de Memória e Armazenamento

RK3588: Executar um modelo de 1B-3B parâmetros quantizado em INT4 (ex.: Qwen1.5-1.8B-Chat) requer aproximadamente 1,5-2,5GB de memória. Recomenda-se reservar 4GB para o sistema e o modelo, com o restante para buffer de áudio e pilha de rede. Os arquivos do modelo são armazenados em eMMC (≥32GB) e carregados na memória dedicada da NPU na inicialização.
ESP32-S3: O modelo de palavra de ativação (ex.: WakeNet) ocupa <200KB de RAM. Recomenda-se um buffer circular de áudio de 32KB (16kHz, 16bit, mono, cerca de 1 segundo). A PSRAM é usada para armazenar resultados intermediários da extração de características de fala.

Esquema de Quantização e Otimização de Inferência

Estratégia de Quantização Mista INT4/INT8

Corpo Principal do LLM: Adotar quantização INT4 AWQ (Activation-aware Weight Quantization) para alcançar velocidade de geração de 15-20 tokens/s na NPU do RK3588 (modelo 1.8B). A perda de precisão é controlada dentro de 2% (comparado a FP16).
Modelo de Reconhecimento de Fala: Usar Conformer em streaming ou Whisper-tiny quantizado em INT8 para alcançar fator de tempo real (RTF) <0,3 na NPU.
Modelo de Palavra de Ativação: Executar DS-CNN quantizado em INT8 no ESP32-S3, com taxa de falsa ativação <1 vez/24h.

Toolchain de Quantização: A Rockchip fornece o RKNN-Toolkit2 com suporte à conversão e quantização de modelos ONNX/PyTorch; o ESP32-S3 pode usar o framework ESP-DL para quantização de 8 bits.

Reutilização de Memória e Carregamento Dinâmico

Para reduzir o pico de memória, pode-se adotar carregamento escalonado: durante a fase de ativação, apenas o modelo de palavra de ativação e o front-end de áudio são carregados; durante a fase de reconhecimento, o modelo ASR é carregado; durante a fase de geração, o modelo ASR é descarregado e o LLM é carregado. O driver da NPU do RK3588 suporta multiplexação por divisão de tempo de múltiplos modelos, exigindo gerenciamento do ciclo de vida dos modelos no Harness.

Pipeline Colaborativo de Streaming Fim-Nuvem: Design de Latência Full-Duplex <800ms

Arquitetura do Pipeline

[Microphone Array] → ESP32-S3 (AEC/NS/VAD) → Wake Word Detection → Audio Stream (Opus 16kbps) → Wi-Fi/BLE → RK3588
                                                                         ↓
[Speaker] ← ESP32-S3 (Decode/Playback) ← Audio Stream ← RK3588 (TTS) ← LLM Generation ← ASR Result

Detalhamento da Latência do Caminho Crítico (Meta <800ms):

| Estágio | Orçamento de Latência | Pontos de Implementação | |------|---------|---------| | Captura e Pré-processamento de Áudio | 20ms | I2S de hardware do ESP32-S3 + AEC de software | | Transmissão de Rede (Wi-Fi) | 30ms | Wi-Fi 6 local, transmissão UDP | | Reconhecimento ASR | 150ms | Reconhecimento em streaming, latência da primeira palavra <100ms | | Geração do Primeiro Token do LLM | 200ms | Quantização INT4 + aceleração NPU | | Síntese TTS | 100ms | TTS em streaming, latência do primeiro pacote <50ms | | Retorno de Rede e Reprodução | 50ms | Buffer de áudio 20ms | | Total | ~550ms | Margem reservada |

Recomendação de Engenharia: Adotar um protocolo full-duplex em streaming, ou seja, enviar áudio e receber o fluxo TTS simultaneamente enquanto o usuário fala, permitindo uma experiência de interação "ouvir enquanto fala". O ESP32-S3 deve suportar I2S full-duplex e concorrência Wi-Fi. Recomenda-se usar os componentes esp_http_client e esp_websocket_client do ESP-IDF.

Estratégia de Offloading de Tarefas Fim-Nuvem

Prioridade Local: Palavra de ativação, VAD e intenções simples (ex.: "acender a luz") são processados localmente no ESP32-S3 ou RK3588 com resposta <100ms.
Fallback para Nuvem: Perguntas e respostas complexas e diálogos multi-turno podem ser roteados para LLMs na nuvem, mas a comutação transparente deve ser garantida quando a rede estiver disponível. O Harness deve implementar um limiar de confiança: quando a confiança da saída do LLM local estiver abaixo do limiar, encaminhar automaticamente para a nuvem.

Dissipação de Calor e Orçamento de Energia: Caminho para Alcançar Micro-Chassi ≤38°C

Pontos de Design Térmico

Resfriamento do RK3588: Em espaços fechados como chassis de boneca, são necessários dissipadores de grafeno + microventiladores (ex.: ventilador 5V 3010) ou materiais de mudança de fase. Medições mostram que, durante inferência contínua de LLM, a temperatura de junção do RK3588 pode atingir 85°C. Através de folha de grafite de 1mm e condução para a carcaça metálica, a temperatura superficial pode ser controlada abaixo de 38°C (ambiente 25°C).
Resfriamento do ESP32-S3: Baixo consumo de energia, sem necessidade de resfriamento ativo, mas evitar layout adjacente a fontes de calor do RK3588.
Gerenciamento Dinâmico de Energia: O Harness deve implementar agendamento ciente da temperatura: quando um sensor de temperatura (ex.: TMP117) detectar a temperatura do invólucro >36°C, reduzir a frequência de inferência do LLM ou alternar para um modelo menor (ex.: 0.5B) para garantir que a temperatura superficial não exceda 38°C.

Exemplo de Orçamento de Energia (Boneca de IA)

| Componente | Potência Típica | Potência de Pico | |------|---------|---------| | RK3588 (Inferência) | 3W | 5W | | ESP32-S3 (Áudio) | 80mW | 120mW | | Microfone Array | 10mW | 10mW | | Alto-falante (1W) | 0,5W | 1W | | Total | ~3,6W | ~6,1W |

Autonomia da Bateria: Com uma bateria de 5000mAh (3,7V), a interação contínua dura cerca de 5 horas; em standby (apenas ESP32-S3 escutando) o consumo é <100mW, com autonomia de até 7 dias.

Formas Reais de Produto e Recomendações de Implementação de Engenharia

1. Boneca Companheira de IA (Tipo LYAAI)

Configuração de Hardware: RK3588 + ESP32-S3 + microfones duplos + alto-falante de 1W + bateria de 5000mAh.
Design do Harness: O ESP32-S3 executa FreeRTOS, responsável pela captura de áudio, palavra de ativação e VAD; o RK3588 executa Linux, hospedando ASR, LLM, TTS e comunicação com a nuvem. Os dois trocam comandos de controle e fluxos de áudio via UART ou SPI.
Resfriamento: RK3588 com folha de grafite de 1mm, invólucro de plástico termicamente condutivo e orifícios de ventilação se a estrutura permitir.

2. Óculos de Guia de Onda

Configuração de Hardware: RK3566 (baixo consumo) + nRF5340 + alto-falante de condução óssea + bateria de 400mAh.
Design do Harness: O nRF5340 lida com conectividade BLE e hub de sensores; o RK3566 executa LLM leve (0.5B) e ASR. Devido a restrições de espaço, são necessários carregamento de modelo por divisão de tempo e escalonamento dinâmico de tensão e frequência (DVFS).
Resfriamento: Filme de grafeno colado dentro das hastes, utilizando a armação metálica para dissipação de calor, temperatura superficial pode ser controlada abaixo de 35°C.

3. Crachá Inteligente de IA

Configuração de Hardware: ESP32-S3 (controle principal) + colaboração em nuvem, ou inferência local com RK3566.
Design do Harness: Se for usado apenas ESP32-S3, apenas a palavra de ativação e o front-end de áudio são executados, com o LLM inteiramente na nuvem; se for necessária inferência local, pode-se selecionar o RK3566 com modelo limitado a 0.5B INT4.
Resfriamento: O crachá fica próximo ao corpo humano, garantindo temperatura superficial ≤38°C. Recomenda-se invólucro de plástico + folha de grafite, e o tempo de inferência contínua deve ser limitado.

Conclusão: Design de Referência Reutilizável do Agent Harness

O conceito de runtime local do AnyLanguageModel é igualmente aplicável no campo embarcado. A chave é agendar dinamicamente modelos e tarefas com base nos recursos de hardware. A arquitetura heterogênea RK3588 + ESP32-S3 proposta neste artigo alcança interação full-duplex <800ms e temperatura superficial ≤38°C por meio de quantização, pipeline em streaming e agendamento ciente da temperatura, e pode ser reutilizada para formas de produto como bonecas de IA, óculos e crachás. Na implementação, o IDH deve focar em orçamento de memória, design térmico e estratégia de comutação fim-nuvem, e realizar ajuste fino da quantização com base nos modelos específicos dos chips.