Move compute to the data,
from edge to data center

§0 · Key finding

One philosophy, two scales

"Move compute to the data" is a power-gating problem at the edge and a memory-wall problem in the data center — both rest on the same near-memory computing foundation.

At the edge, Kuiloong decides at mW-class power whether the host system deserves to wake: raw data never leaves the device, the NPU emits only labels, confidence and state, and the host wakes only after confirmation. In the data center, KXP moves Decode Attention next to the DDR where KV lives, cutting per-token cross-link traffic from ≈10 GiB to ≈2–3 MiB◆. Moving compute to the data — that is the shared foundation logic at both ends.

Cut wasteful system wake-ups with low-power semantic gating; unlock long-context capacity and bandwidth with KV near-memory computing.

— ACELab · Shenyi Technology, team deck STRATEGIC TAKEAWAY2026-09

ContextThe electricity bill of edge "always-on" and the HBM capacity wall in the data center are the same problem: moving data costs more than computing it.Why it mattersMove compute next to the data, and both ends escape the data-movement tax.

§1 · Sensing NPU

Kuiloong: between coarse triggers and heavy inference

Coarse sensor trigger, NPU semantic confirmation, host takeover on demand — multi-level power gating means "always-on" no longer implies an always-on electricity bill.

Kuiloong is positioned as a multimodal semantic-gating co-processor: visual confirmation, voice wake-up and event-stream triggering decide at low power whether the host system is worth waking. Architecturally it pairs a RISC-V control core with multi-dimensional compute and shared near-memory: scalar units, 1D vector cores and a 2D matrix/convolution array all access shared near-memory, eliminating DMA and data copies — one software stack, no dual-stack synchronization; anything ONNX can express, the toolchain can map.

§2 · KV Extension Processor

KXP: move Decode Attention next to the KV data

The bottleneck of LLM decode has shifted from compute to memory — KXP sits between the GPU and high-capacity DDR, dedicated to context storage, management and near-memory Decode Attention.

Long-context pressure follows one simple growth law: KV Cache inflates linearly with concurrency and context length. For a 70B-class GQA model at BF16, a single 1M-context request needs about 312 GiB of KV◆ — beyond any single GPU's HBM. Yet weights, KV and workspace all compete for the same indivisible HBM: what users actually lack is capacity and bandwidth, but they are forced to buy whole cards, and the surplus compute sinks into cost.

Storage offload alone (KV on DDR, hauled back to the GPU token by token) merely swaps a capacity bottleneck for a link-bandwidth one: at 32K context, each token drags ≈10 GiB of history KV across the link; 50 tokens/s means 500 GiB/s of sustained traffic, with the GPU idling while it waits. KXP's answer is to move compute to the data: finish Attention right next to the DDR where KV lives, and send only results back to the GPU.

KV semantic memory: the dividing line from generic CXL controllers

Even before any Attention is executed, KXP can solve KV's capacity, fragmentation, migration and isolation problems: paging and address translation, block allocation and reclamation, HBM/DDR/SSD three-tier hot-cold layering, prefix-cache sharing, branch management and deduplication, request-level address spaces and multi-tenant quotas. It understands layers, heads, tokens and requests — sharing and isolation that generic memory cannot offer.