🔶 Arduino UNO Q 与 Ventuno Q 上的 Moorcheh Edge：1536 维向量基准测试
英文标题：🔶 Moorcheh Edge on Arduino UNO Q vs. Ventuno Q: 1536-D Vector Benchmark
本次测试比较了 Arduino UNO Q（约 3.6 GB RAM）和 Ventuno Q（约 15 GB RAM）运行 Moorcheh Edge 处理 1536 维纯向量检索负载的表现，不涉及文本管线、嵌入模型或 LLM。10k 向量规模下，两款设备的搜索中位延迟均约为 25 ms；在 100 万向量规模下，Ventuno Q 的搜索中位延迟为 269 ms，约比 UNO Q 的 833 ms 快 3 倍。完整导入 100 万向量时，Ventuno Q 约需 8 小时，而 UNO Q 约需 32 小时，前者快约 4 倍。测试表明，Moorcheh Edge 的 MIB 二值化存储让 100 万条 1536 维向量可部署在真实边缘设备上，但开发者应根据目录规模、可接受的导入时间和延迟选择硬件。
336.2 KB
1.2 KB
1.4 KB
25.5 KB
326.2 KB
中文
我们比较了两款运行相同 Moorcheh Edge 工作负载的 ARM64 边缘开发板：Arduino UNO Q（约 3.6 GB RAM）和 Ventuno Q（约 15 GB RAM）。每块开发板均以纯向量模式写入和搜索 1536 维向量——没有文本管线、嵌入模型或 LLM。查询是通过 POST /search 发送的原始浮点向量。
在本次基准测试中，我们将每个存储库的项目上限提升至 1,000,000，以便对大规模写入和搜索进行压力测试。典型的 Moorcheh Edge 部署会采用更适合自助终端规模目录的较小上限。即使采用 Moorcheh 的紧凑存储方式，100 万个向量仍是一个极端场景；该测试展示了当目录规模扩大时两块开发板的表现。
如需了解此前针对 UNO Q 的 RAG 管线拆解测试（嵌入 + LLM 与检索），请参阅 4 GB 硬件上的 Edge RAG。
**核心结果：**在 1 万向量规模下，搜索中位延迟基本持平（两者均约为 25 ms）。在 100 万向量规模下，Ventuno Q 的搜索速度约快 3 倍（中位数为 269 ms，而 UNO Q 为 833 ms），完整写入速度约快 4 倍（墙钟时间为 8 小时，而 UNO Q 为 32 小时）。
详细表格（上传进度、每次运行的 50 个搜索样本、写入期间的 RAM 数据，以及 100 万向量规模下的 50 次查询搜索与 RAM 研究）均收录在“完整结果”部分链接的 Google Sheets 中。
为什么 Moorcheh Edge 能实现这项基准测试
传统的 100 万 × 1536 维 float32 向量存储，仅嵌入数据就约为 6 GB（1,000,000 × 1536 × 4 字节），这还未包括索引结构和运行时开销。这无法装入 Arduino UNO Q 的实际可用内存预算；如果目标是边缘部署而非单纯追求原始存储容量，那么对 Ventuno Q 而言也是低效的使用方式。
Moorcheh Edge 会在写入时通过 MIB（Moorcheh Information Binarization，Moorcheh 信息二值化）对向量进行二值化，并通过紧凑形式上的 EDM（Enhanced Distance Metric，增强距离度量）执行检索。在我们的测试中：
- 磁盘占用：约 3.2 MiB（10k）、约 32 MiB（100k）、约 319 MiB（1M）
- 100 万向量时 Docker 内存占用：在提供搜索服务时约 1.2–1.5 GiB
两块开发板上的相同项目数量证明，存储库大小由 Moorcheh 的编码方式决定，而不是由运行服务器的 CPU 决定。正是这一较小的占用空间，使我们能够在真实边缘硬件上运行 100 万 × 1536 维压力测试，而不必只在云实例上进行测试。
我们如何运行基准测试
我们在每块开发板上部署了一个 Moorcheh Edge 服务器实例（ARM64、纯向量技术栈）。客户端同样运行在开发板上并通过 localhost 访问服务器，因此计时包含 HTTP JSON 传输及服务器处理时间。
针对每种目录规模（10k、100k、1M）的测试流程如下：
- 清空存储库（该规模下的全新测试）。
- 分批上传随机单位向量，直至达到目标数量；记录墙钟时间和吞吐量。
- 在写入期间采样主机和容器内存。
- 执行 5 次预热搜索，随后以
top_k = 5、固定seed = 42进行 50 次计时搜索，并报告最小值、中位数、均值、p95 和 p99。
在每块开发板完成 100 万向量测试后，我们针对已加载的 100 万向量目录进行了独立的 50 查询研究：每次搜索前后均记录延迟和 RAM（主机已用内存，以及 Moorcheh 容器的 Docker 统计数据）。
两块开发板使用了相同的软件和测试参数；唯一差异是硬件资源。
完整结果
每次测试均记录在两个公开的 Google Sheets 中——每份表格均包含汇总数据、逐查询搜索延迟、上传进度、写入期间的 RAM 采样，以及 50 查询 RAM 工作表：
测试配置
| 参数 | 值 |
|---|---|
| 服务器 | Moorcheh Edge（两块开发板使用相同部署） |
| 存储库上限（本次基准测试） | 1,000,000 个项目（为压力测试而提高） |
| 存储库模式 | 向量（来自客户端的预计算浮点数） |
| 维度 | 1536（首次上传时锁定） |
| 查询 | 随机单位向量，种子为 42 |
| 搜索 | top_k = 5，5 次预热 + 50 次计时运行 |
| 测试目录规模 | 10,000 / 100,000 / 1,000,000（独立运行） |
| 设备 | RAM 背景信息（来自测量数据） |
|---|---|
| Arduino UNO Q | Docker 限制约为 3.58 GiB；在 1M 规模下压力较大 |
| Ventuno Q | Docker 限制约为 14.93 GiB；运行相同的 Moorcheh 服务器，可用余量更多 |
结果：存储库大小
在每个规模下，两块开发板的磁盘存储库大小均完全相同。
磁盘存储库大小：Moorcheh MIB 存储库与原始 float32 对比（MiB）
绿色：Moorcheh 存储库（两块开发板上完全相同）。红色：1M × 1536 规模下的原始 float32 嵌入——在尚未计算索引结构或运行时开销前，体积已约为 Moorcheh 存储库的 19 倍。
Moorcheh Edge 会将二值化目录加载到内存中用于搜索；它不会为每个向量保留完整的 float32 矩阵。
结果：上传（写入）
| 向量数 | Arduino UNO Q | Ventuno Q | Ventuno 优势 |
|---|---|---|---|
| 10k | 59.3 秒 | 29.5 秒 | 快约 2.0 倍 |
| 100k | 约 19 分钟 | 约 10 分钟 | 快约 1.9 倍 |
| 1M | 约 32.1 小时 | 约 8.0 小时 | 快约 4.0 倍 |
在 10k 规模下，UNO Q 的写入仍具备实用性（约 1 分钟）。在 1M 规模下，写入成为墙钟时间的主要部分：UNO Q 完整加载约需 32 小时，Ventuno 约需 8 小时。
写入期间的主机内存峰值：
| 规模 | UNO Q 峰值（MB） | Ventuno 峰值（MB） |
|---|---|---|
| 10k | 817 | 1,028 |
| 100k | 875 | 1,155 |
| 1M | 2,673 | 2,708 |
两块开发板在 1M 规模下的主机内存使用量均达到约 2.7 GB。UNO Q 已接近其上限；Ventuno 仍低于其 Docker 内存限制，保有余量。
结果：搜索延迟（每个规模运行 50 次）
按目录规模划分的搜索中位延迟（ms，top_k = 5，50 次运行）
在 10k 规模下持平；在 1M 规模下，Ventuno Q 快约 3.1 倍（269 ms 对 833 ms）。p99 和每次运行的样本数据可见链接的电子表格。
搜索成本随 N 增长。在自助终端规模（10k）下，两块开发板均可实现约 25 ms 的中位延迟，适合交互式边缘检索。在 1M 规模下，UNO Q 的每次查询约为 0.83 秒，Ventuno 则约为 0.27 秒。延迟大致随目录规模线性增长，这与扫描完整的内存驻留二值化索引相一致。
结果：1M 目录、50 次查询及每次搜索的 RAM 数据
在 100 万个向量已经加载后，我们对 50 次搜索中的每一次都测量了请求前后的 RAM。UNO Q 的典型主机 RAM 使用量保持在约 2.26 GB，Ventuno Q 则约为 2.11 GB。
已加载 1M 目录上的 50 查询研究
Docker 内存（占容器限制的百分比）
两块开发板上的索引占用空间相近（约 1.2–1.5 GiB）——Ventuno 的额外 RAM 提供的是余量，而不是更大的索引。全部 50 行数据均在链接的电子表格中。
搜索期间，每次查询的 RAM 几乎没有变化，因为目录已驻留在内存中。性能差距来自 CPU 和系统吞吐量，而非索引大小。
如何选择开发板
Arduino UNO Q 适合运行具有 10k（及类似）规模目录的 Moorcheh Edge：搜索约 25 ms、写入约 1 分钟、存储库约 3 MiB。如果可接受约 100 ms 的检索延迟，100k 规模也可使用。1M 规模在该硬件上可作为压力实验运行，但若没有充分考虑较长的写入时间和约 800 ms 级别的搜索延迟，则不应作为默认生产目标。
Ventuno Q 运行的是相同的 Moorcheh Edge 技术栈，但对于 100k–1M 规模目录而言是更合适的选择：大规模下搜索延迟更低，且 1M 向量写入时间显著缩短。
方法与局限性
- 搜索计时包含 localhost HTTP JSON 开销，而非仅使用 Rust 内部计时器。
- 每次运行均使用相同的种子和查询向量以保证可重复性，并未混合不同类型的查询。
- 我们仅报告向量写入、搜索速度和内存数据（不涉及文本 RAG 质量或 LLM 测试）。
- Ventuno Q 是我们在本研究中对一款高 RAM ARM64 边缘同类设备的命名。
- 面向典型边缘应用的产品存储库上限仍低于此处使用的 1M 上限；我们仅为在极端规模下对 Moorcheh Edge 进行压力测试而提高了该限制。
试用 Moorcheh Edge
pip install moorcheh-edge
moorcheh-edge up -y
moorcheh-edge status
基准测试于 2026 年 9 月 29 日至 10 月 1 日运行。
English / 原文
We compared two ARM64 edge boards running the same Moorcheh Edge workload: Arduino UNO Q (about 3.6 GB RAM) and Ventuno Q (about 15 GB RAM). Each board ingested and searched 1536-dimensional vectors in vector mode only — no text pipeline, no embedding model, no LLM. Queries were raw float vectors sent to POST /search.
For this benchmark we raised the per-store item limit to 1,000,000 so we could stress-test ingest and search at scale. Typical Moorcheh Edge deployments use a smaller cap suited to kiosk-sized catalogs. Even with Moorcheh's compact storage, 1M vectors is an extreme case; it shows how the two boards behave when the catalog grows.
For the earlier UNO Q RAG pipeline breakdown (embed + LLM vs retrieval), see Edge RAG on 4 GB Hardware.
Headline results: At 10k vectors, median search latency is a tie (about 25 ms on both). At 1M, Ventuno Q is about 3× faster on search (269 ms vs 833 ms median) and about 4× faster on full ingest (8 hours vs 32 hours wall clock).
Detailed tables (upload progress, 50 search samples per run, RAM during ingest, and the 50-query search + RAM study at 1M) are in the Google Sheets linked under Full results.
Why Moorcheh Edge makes this benchmark possible
A conventional 1M × 1536 float32 vector store is roughly 6 GB of embedding data alone (1,000,000 × 1536 × 4 bytes), before index structures and runtime overhead. That does not fit the practical memory budget on Arduino UNO Q and is a poor use of Ventuno Q if the goal is edge deployment rather than raw storage.
Moorcheh Edge binarizes vectors at ingest with MIB (Moorcheh Information Binarization) and retrieves with EDM (Enhanced Distance Metric) over those compact forms. In our runs:
- On disk: about 3.2 MiB (10k), about 32 MiB (100k), about 319 MiB (1M)
- In Docker at 1M: about 1.2–1.5 GiB while serving search
The same item counts on both boards confirm that store size is driven by Moorcheh's encoding, not by which CPU runs the server. That small footprint is why we could run a 1M × 1536 stress test on real edge hardware instead of only on a cloud instance.
How we ran the benchmark
We used one Moorcheh Edge server deployment on each board (ARM64, vector-only stack). The client ran on the board against localhost, so timings include HTTP JSON plus server work.
Procedure for each catalog size (10k, 100k, 1M):
- Clear the store (fresh run at that scale).
- Upload random unit vectors in batches until the target count is reached; record wall time and throughput.
- Sample host and container memory during ingest.
- Run 5 warmup searches, then 50 timed searches with
top_k = 5, fixedseed = 42, and report min, median, mean, p95, and p99.
After the 1M run completed on each board, we ran a separate 50-query study on the loaded 1M catalog: before and after each search, record latency and RAM (host used memory and Docker stats for the Moorcheh container).
Both boards received the same software and the same test parameters; only hardware resources differ.
Full results
Every run is documented in two public Google Sheets — each contains the summary, per-query search latencies, upload progress, RAM samples during ingest, and the 50-query RAM worksheet:
Test configuration
| Parameter | Value |
|---|---|
| Server | Moorcheh Edge (same deployment on both boards) |
| Store limit (this benchmark) | 1,000,000 items (raised for stress testing) |
| Store mode | Vector (precomputed floats from client) |
| Dimension | 1536 (locked on first upload) |
| Query | Random unit vector, seed 42 |
| Search | top_k = 5, 5 warmup + 50 timed runs |
| Catalog sizes tested | 10,000 / 100,000 / 1,000,000 (separate runs) |
| Device | RAM context (from measurements) |
|---|---|
| Arduino UNO Q | Docker limit about 3.58 GiB; strong pressure at 1M |
| Ventuno Q | Docker limit about 14.93 GiB; same Moorcheh server, more headroom |
Results: store size
On-disk store size was identical on both boards at every scale.
On-disk store size: Moorcheh MIB store vs raw float32 (MiB)
Green: Moorcheh store (identical on both boards). Red: raw float32 embeddings at 1M × 1536 — ~19× larger than the Moorcheh store, before index structures or runtime overhead.
Moorcheh Edge loads the binarized catalog into memory for search; it does not keep full float32 matrices for every vector.
Results: upload (ingest)
| Vectors | Arduino UNO Q | Ventuno Q | Ventuno advantage |
|---|---|---|---|
| 10k | 59.3 s | 29.5 s | about 2.0× faster |
| 100k | about 19 min | about 10 min | about 1.9× faster |
| 1M | about 32.1 h | about 8.0 h | about 4.0× faster |
At 10k, UNO Q ingest stays practical (about 1 minute). At 1M, ingest dominates wall clock: UNO Q needs on the order of 32 hours for a full load; Ventuno about 8 hours.
Peak host memory during ingest:
| Scale | UNO Q peak (MB) | Ventuno peak (MB) |
|---|---|---|
| 10k | 817 | 1,028 |
| 100k | 875 | 1,155 |
| 1M | 2,673 | 2,708 |
Both boards reach about 2.7 GB host use at 1M. UNO Q is near its ceiling; Ventuno still has room below its Docker limit.
Results: search latency (50 runs per scale)
Median search latency by catalog size (ms, top_k = 5, 50 runs)
Tie at 10k; at 1M Ventuno Q is ~3.1× faster (269 vs 833 ms). p99 and per-run samples are in the linked spreadsheets.
Search cost grows with N. At kiosk scale (10k), both boards deliver about 25 ms median, which is suitable for interactive edge retrieval. At 1M, UNO Q is about 0.83 s per query vs Ventuno about 0.27 s. Latency scales roughly linearly with catalog size, consistent with scanning the full in-memory binarized index.
Results: 1M catalog, 50 queries with RAM per search
With 1M vectors already loaded, we measured each of 50 searches together with RAM immediately before and after the request. Typical host RAM stayed around 2.26 GB on UNO Q and 2.11 GB on Ventuno Q.
50-query study on the loaded 1M catalog
Docker memory (% of container limit)
Similar index footprint (~1.2–1.5 GiB) on both boards — Ventuno's extra RAM is headroom, not a larger index. All 50 rows are in the linked spreadsheets.
Per-query RAM barely changes during search because the catalog is already resident. The gap is CPU and system throughput, not index size.
Choosing a board
Arduino UNO Q fits Moorcheh Edge at 10k (and similar) catalog sizes: about 25 ms search, about 1 min ingest, about 3 MiB store. 100k is usable if about 100 ms retrieval is acceptable. 1M is viable as a stress experiment on this hardware but not as a default production target without long ingest times and about 800 ms-class search.
Ventuno Q runs the same Moorcheh Edge stack but is the better match for 100k–1M catalogs: lower search latency at scale and much shorter 1M ingest.
Methodology and limitations
- Search timings include localhost HTTP JSON, not internal Rust-only timers.
- Each run uses the same seed and query vector for repeatability, not a mix of query types.
- We report vector ingest, search speed, and memory only (no text RAG quality or LLM tests).
- Ventuno Q is our name for a higher-RAM ARM64 edge peer in this study.
- Product store limits for typical edge use remain below the 1M cap used here; we raised the limit only to stress-test Moorcheh Edge at extreme scale.
Try Moorcheh Edge
pip install moorcheh-edge
moorcheh-edge up -y
moorcheh-edge status
Benchmarks run 29 September – 1 October 2026.