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. 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.

  • The measurement that changed the hardware

    Adam Abu-Taqaa day ago 0 comments

    Big test: does more model fix the judgement problem? Ran stock and fine-tuned 1B and 3B through both evals. Capacity alone did nothing (stock 3B scored identical to stock 1B on grounded answers) and training alone did nothing, they worked together. Fine-tuned 3B took tool-calling from 5/13 to 10/13 with zero fabrications and zero inversions; the fine-tuned 1B had still said "continue to charge it" about a swollen lithium cell. The 3B produces nothing in that family.

    Unfortunately, the fine-tuned 3B on the RK3566 generates at 2.62 tok/s — below my 3.5 tok/s conversational kill line, before speech recognition contends for bandwidth. Scaling was textbook bandwidth-bound: 2.59× the parameters, 2.40× slower.

    So the compute moves to RK3588-class silicon (~10 tok/s class for 3B on the NPU per Rockchip's own tables; realistic contended estimate 5.3–6.3). The RK3566 answered the question I bought it to answer, and produced the first public numbers for the chip on the way.

  • Benchmarking a chip nobody had benchmarked

    Adam Abu-Taqa2 days 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 all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

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