Close
0%
0%

TaqaBuddy — a fully offline AI assistant

Handheld AI assistant that runs entirely on-device: local tool-calling, local voice, local model, local knowledge.

Public Chat
Similar projects worth following
0 followers
TaqaBuddy is a handheld AI assistant that works with zero connectivity. Speech recognition, language model, and knowledge base all run on a small ARM board — nothing leaves the device, because nothing can: there's no radio link to a cloud.

The design principle came out of testing, not ideology: small language models confidently make things up, so **the model is never the source of truth**. Real answers come from the device's actual sensors and from reference texts stored verbatim on the device; the model's job is to understand what you asked and read the right answer back. It can't invent a sensor reading it never generates.

Built solo, documented honestly including the benchmarks nobody had published, the model failures, and the hardware decision that testing forced. Follow the build logs; the interesting parts are the failures.

Current hardware: Geniatech XPI-3566-ZERO — Rockchip RK3566 (4× Cortex-A55 @ 1.8 GHz), 8 GB single-channel LPDDR4, Debian 11. Chosen for cost; benchmarking on it produced the first public llama.cpp numbers for this chip (log #1).

Where testing has landed (so far): a fine-tuned Llama-3.2-3B is the model this product needs — stock models at any tested size fail tool-calling, and fine-tuning moved it from 5/13 to 10/13 with zero fabrications (log #5). Measured on the RK3566 the 3B runs 2.62 tok/s, below the 3.5 tok/s conversational kill line, so the compute is moving to RK3588-class silicon. That conclusion is a measurement, not a guess, and the logs show the path to it.

Architecture: whisper.cpp for speech in · Llama-3.2 (fine-tuned) for language · GBNF grammar-constrained decoding so tool outputs are structurally valid · routing done in ordinary code, not by the model · safety-critical reference content retrieved and read verbatim, never paraphrased · a code-side gate refuses out-of-corpus questions without ever invoking the model.

Status: pre-demo. Schematic complete (five sheets, KiCad), PCB not started, audio path (I2S) is the current bring-up blocker.

  • 1 × Geniatech XPI-3566-ZERO Rockchip RK3566 (4× Cortex-A55 @ 1.8 GHz), 8 GB single-channel LPDDR4, 64 GB eMMC. The compute — runs the LLM, speech recognition, and retrieval entirely on-device.
  • 1 × Heatsink Electronic Fitted at bring-up. Not sufficient on its own — see the benchmark log for what passive-only cooling cost.Components / Misc. Electronic Components
  • 1 × 5V USB fan Every unfanned benchmark number was thermally throttled
  • 1 × USB–serial UART adapter Console access for headless bring-up and debugging.
  • 1 × Breadboard + jumper wires Prototyping the sensor/interface modules the assistant will read from.

  • Benchmarking a chip nobody had benchmarked

    Adam Abu-Taqaan hour ago 0 comments

    I couldn't find a single published llama.cpp benchmark for the RK3566, so here's the first set. Geniatech XPI-3566-ZERO, 4× A55 @ 1.8 GHz, 8 GB single-channel LPDDR4, llama.cpp with cmake auto-detected -mcpu=cortex-a55+crypto+dotprod+noi8mm+nosve this core has dot-product but no i8mm, so ignore any guide telling you to add +i8mm.

    Headline numbers, 4 threads, cooled: Llama-3.2-1B Q4_0 generates at 6.30 tok/s (pp256 25.81). Qwen2.5-0.5B Q4_0: 12.31 tok/s — and note Q4_0 vs Q4_K_M matters enormously on this core (68.88 vs 11.73 prefill on the 0.5B; the Q4_0 repack path is 2–6× faster here).

    Two measurement mistakes worth confessing: a single-threaded STREAM triad understated real bandwidth (llama.cpp's four threads extract more via memory-level parallelism), and an early 1B run was silently thermally throttled. The two errors briefly agreed with each other, which looked like validation. It wasn't. Full table attached.

View project log

Enjoy this project?

Share

Discussions

Does this project spark your interest?

Become a member to follow this project and never miss any updates