# Unum | One Hardware-Friendly AI Stack > Unum builds open-source search, storage and communication engines, USearch, UStore and UCall, on its own kernel libraries. Inside ClickHouse, DuckDB and 100M+ devices. Building AI infra · Since 2015 · Unum The hardware moved on. Most software Didn’t. Six assumptions worth revisiting, and what changes when you do. And the open-source engines we built around each answer. [Open Source](https://github.com/unum-cloud) [USearch Search and sparse algebra ](https://www.unum.cloud/engines/usearch.md)[UStore Blobs, docs and graphs ](https://www.unum.cloud/engines/ustore.md)[UForm Multi-modal perception](https://www.unum.cloud/engines/uform.md) [01 · Network latency](#networking) ## Latency doesn’t autoscale. > Capacity scales. Distance doesn’t. Separating storage from compute is the most repeated lesson of the last decade of systems design, and it earned the repetition: storage scales on its own invoice, compute comes and goes, and durability becomes somebody else’s problem. For bulk scans it holds. A column store streaming a terabyte barely notices whether the bytes came from a bucket or a drive. It stops holding where one read decides the next. A transaction commit, a graph walk and a nearest-neighbor search each issue hundreds of dependent reads, each waiting for the last, so a round trip of milliseconds becomes seconds per query. Those workloads belong beside the compute, with one copy of the data on local drives, in RAM or in VRAM, reached through direct I/O and not over a network. Once the bytes are local, the bottleneck moves into the core. ### Fig. 1.1: A server of local drives answers four orders of magnitude more random reads than one object-storage prefix Random 4 KiB reads in one second on one linear axis · KIOXIA CM9 15.36 TB, PCIe 5.0, rated - more random reads a second: one server of drives against one S3 prefix ×14,800 - lower latency per read: ≈ 80 µs on NVMe against ≈ 30 ms per S3 GET ×375 1. One server 81,600,000 24× KIOXIA CM9 2. One KIOXIA CM9 3,400,000 3. S3 Express One Zone 200,000 one bucket 4. S3 Standard 5,500 one prefix · Yes, the bar is here. Drive figures are KIOXIA’s rating for the 15.36 TB CM9, a PCIe 5.0 drive, at queue depth 512. Object-storage figures are AWS’s documented request rates, which grow only as you add prefixes or buckets. Sources [KIOXIA CM9](https://americas.kioxia.com/en-us/business/ssd/enterprise-ssd/cm9-r-e3s.html) · [S3 performance guidelines](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) · [S3 Express One Zone](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-express-performance.html) ### Fig. 1.2: Scans tolerate a round trip; dependent reads multiply it | Workload | Dependent reads per op | Local NVMe | Object storage | Verdict | | - | - | - | - | - | | Bulk scan of 1 TB | streamed | ≈ 5 s | ≈ 80 s | tolerable | | Transaction commit | ≈ 2 + a write | ≈ 0.2 ms | ≈ 100 ms | prohibitive | | Vector search, 1 B | ≈ 250 hops | ≈ 20 ms | ≈ 7.5 s | impractical | | Vector search, 100 B | ≈ 400 hops | ≈ 32 ms | ≈ 12 s | impractical | A graph search walks ≈ 250 hops at a billion vectors, and the path grows with the dataset. Reading eight neighbors per hop shortens both columns about eightfold and leaves the 375× gap untouched. The times are estimates, not measurements, built from ≈ 80 µs per NVMe read and ≈ 30 ms per object-store GET. Sources [Durner, Leis & Neumann, VLDB 2023](https://www.vldb.org/pvldb/vol16/p2769-durner.pdf) · [DiskANN, NeurIPS 2019](https://papers.nips.cc/paper_files/paper/2019/file/09853c7fb1d3f8ee67a61b6bf4a7f8e6-Paper.pdf) [02 · Wider cores](#wider) ## Your compiler knows over 80,000 intrinsics. It just doesn’t know where they go. > Cores got wider. Compilers still use a fraction of what they know. Trusting the compiler is the right default, and it won for good reasons: for scalar control flow, clang and GCC schedule better than any hand, and portable source outlives any one chip. Two decades of flat clocks were absorbed mostly by compilers and runtimes getting smarter. Auto-vectorization stops at the loop it can prove. Mixed-precision dot products, masked substring search, AES-based hashing and predicated edit distances are different algorithms, not differently scheduled ones, and every extension spells them out as one intrinsic per type, width and mask. Those kernels are written by hand, one per ISA generation, and chosen at runtime. The same gap repeats across the PCIe bus, where most of the box’s compute now sits. ### Fig. 2.1: A course teaches 40 instructions, a compiler emits a few hundred, a vector ISA offers thousands - Taught in a course 40 instructions - Emitted at ‑O2 ≈ 240 instructions - x86 AVX2, AVX-512 & AMX 5,335 intrinsics - Arm NEON, SVE & SME 13,383 intrinsics - RISC-V RVV 1.0 61,397 intrinsics * What compilers use * What the hardware added One square is 100 words. A course teaches RV32I’s 40 instructions, and a clang 20 ‑O2 build of SQLite emits about 240 distinct mnemonics. Vector extensions are spelled out as C intrinsics, one per type, width, mask and policy. Counting typed names without overloads, clang 23’s AVX2, AVX‑512, AMX, NEON, SVE and SME headers declare 18,718, and it accepts all 61,397 names in the RVV 1.0 specification’s base and policy lists, which leave out BF16, crypto and later extensions: over 80,000 in all. Sources [riscv-opcodes](https://github.com/riscv/riscv-opcodes/tree/master/extensions) · [instruction popularity in Ubuntu, SYSTOR 2019](https://oscarlab.github.io/papers/instrpop-systor19.pdf) · [Intel Intrinsics Guide](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html) · [Arm intrinsics](https://developer.arm.com/architectures/instruction-sets/intrinsics/) · [RVV intrinsics](https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/main/auto-generated) ### Fig. 2.2: Every layer below the engine has a hand-written replacement 1. Byte & string primitives [StringZilla](https://www.unum.cloud/docs/stringzilla.md) Most software `memmem · std::hash · std::sort` Generic string routines and hashing We built `sz_find · sz_hash · sz_levenshtein_*`Vectorized search, hashes and edit distances 2. Mixed-precision numerics [NumKong](https://www.unum.cloud/docs/numkong.md) Most software `for (…) · cblas_sgemm` Auto-vectorized loops or vendor BLAS We built `nk_dot_* · nk_dots_* · nk_attention_*`Typed products, attention and matrix tiles 3. Parallelism & scheduling [ForkUnion](https://www.unum.cloud/docs/forkunion.md) Most software `std::async · #pragma omp parallel` General-purpose tasks and thread pools We built `forkunion_t · extended_atomic_ref` NUMA-aware fork-join and extended atomics 4. Atomics & collections [SmashTable](https://www.unum.cloud/docs/smashtable.md) Most software `std::mutex · std::unordered_map` A lock around each shared container We built `atomic_hash_table · transaction_group::commit` Atomic slots and commits across containers 5. Search & storage engines [USearch](https://www.unum.cloud/docs/usearch.md) [UStore](https://www.unum.cloud/docs/ustore.md) Most software `SELECT … · HTTP / JSON` A separate server for each data model We built `usearch_* · ustore_*`Embedded search and storage behind one ABI [03 · Accelerators](#watts) ## 80% of the watts. Petabytes of capacity. Terabytes a second. > A GPU brings compute. An SSD brings capacity. Neither helps an application that can’t reach it. Keeping the engine on the CPU and the dataset in RAM was right for a long time: GPUs were for training, VRAM was small, PCIe was slow, and a pointer-chasing index wanted a general-purpose core. Most storage engines and vector indexes still assume it. In a current node most of the rated watts are in the accelerators and most of the capacity is in the drives, with the CPU and its RAM between them as the narrowest tier. A CPU-only engine idles the compute; a RAM-only engine caps the data at terabytes. So the graph walk belongs in VRAM, the merge of sorted runs on the GPU, and the kernels on NVIDIA, AMD and Apple devices beside six CPU families. The problem is no longer the number of devices but the copies between them. ### Fig. 3.1: The watts are in the GPUs, the capacity is in the drives, and the CPU sits between them Rest of one DGX B300 ≈ 13.3 kW, ≈ 95% of the box; 2× Xeon 6776P ≈ 0.7 kW ← Higher peak bandwidth Larger maximum capacity → Higher bandwidth first. Larger capacity below. #### VRAM · GDDR & HBM 8 GB–2.3 TB ≈ 256 GB/s–64 TB/s From 1x laptop GPU to 8x B300s with NVLink and HBM3e - Strength Massive parallelism and aggregate HBM bandwidth - Tradeoff Smaller capacity; irregular work needs new algorithms #### RAM · DDR5 4 GiB–32 TB ≈ 40 GB/s–2.3 TB/s From 32-bit WASM sandboxes to 8x-socket Xeon Platinum systems - Strength Low-latency random access and flexible control flow - Tradeoff Capacity costs more; remote NUMA access adds latency #### NVMe · NAND 1.92 TB–2.46 PB ≈ 14–540 GB/s From 1x to 40x PCIe 5.0 ×4 drives on dual-socket AMD Zen 5 - Strength Petabyte capacity close to the compute - Tradeoff Higher read latency; batch requests and overlap I/O **Beyond one node** NVLink, InfiniBand and Ethernet connect the next tier. Scale locally first; cross the network when the workload needs it. Power: NVIDIA rates one DGX B300 at about 14 kW, and Intel rates each of its two Xeon 6776P at 350 W. Capacity spans separate configurations. Hardware bandwidth ceilings use one DDR5-4800 through 64 DDR5-4400 channels for RAM, one 8 GB laptop GPU through eight B300s for VRAM, and CM9 sequential reads for NVMe. Forty drives devote all 160 PCIe lanes to storage; application throughput depends on the workload. Sources [Xeon 8490H](https://www.intel.com/content/www/us/en/products/sku/231747/intel-xeon-platinum-8490h-processor-112-5m-cache-1-90-ghz/specifications.html) · [DGX B300](https://www.nvidia.com/en-us/data-center/dgx-b300/) · [DGX B300 user guide](https://docs.nvidia.com/dgx/dgxb300-user-guide/introduction-to-dgxb300.html) · [Xeon 6776P](https://www.intel.com/content/www/us/en/products/sku/243691/intel-xeon-6776p-processor-336m-cache-2-30-ghz/specifications.html) · [CM9 SSDs](https://www.kioxia.com/ja-jp/business/ssd/enterprise-ssd/cm9-r.html) ### Fig. 3.2: One runtime dispatch covers 40+ CPU and GPU generations | Kernel family | x86 | | | | | | | | | | Arm | | | | Others | | | | | NVIDIA | | | | | AMD | | Apple | | | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | | | Haswell | Skylake | Ice Lake | Sapphire | Granite | Sierra | Milan | Genoa | Turin | Diamond | NEON | SVE | SVE2 | SME | RVV | LoongArch | Power | WASM SIMD | WASM Relaxed | Ampere | Ada | Hopper | Blackwell | Blackwell RTX | CDNA 4 | CDNA 5 | Metal 9 | Metal 10 | | NumKong | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vector Products | dedicated | dedicated | dedicated | compatible | compatible | dedicated | compatible | dedicated | compatible | dedicated | dedicated | dedicated | compatible | compatible | dedicated | dedicated | dedicated | dedicated | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | compatible | compatible | | Matrix Products | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | compatible | dedicated | compatible | dedicated | dedicated | compatible | compatible | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | compatible | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | | Dense Attention | dedicated | dedicated | dedicated | dedicated | compatible | compatible | compatible | dedicated | compatible | dedicated | dedicated | compatible | compatible | dedicated | dedicated | fallback | fallback | fallback | dedicated | dedicated | compatible | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | | Late Interaction | dedicated | compatible | dedicated | dedicated | compatible | compatible | compatible | dedicated | compatible | compatible | dedicated | compatible | compatible | dedicated | fallback | fallback | fallback | fallback | dedicated | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | | Geodesic Metrics | dedicated | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | compatible | compatible | compatible | dedicated | fallback | fallback | fallback | dedicated | dedicated | compatible | compatible | compatible | compatible | unavailable | unavailable | unavailable | unavailable | | StringZilla | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hashes & Overlaps | dedicated | dedicated | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | dedicated | dedicated | compatible | dedicated | dedicated | dedicated | dedicated | dedicated | dedicated | compatible | compatible | dedicated | compatible | dedicated | compatible | dedicated | compatible | | Unicode Matching | dedicated | compatible | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | compatible | dedicated | compatible | dedicated | dedicated | dedicated | dedicated | compatible | dedicated | compatible | compatible | compatible | compatible | dedicated | compatible | dedicated | compatible | | Edit Distances | dedicated | dedicated | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | compatible | compatible | compatible | fallback | fallback | fallback | fallback | fallback | dedicated | compatible | compatible | dedicated | compatible | dedicated | compatible | dedicated | compatible | | Regex & Lookarounds | dedicated | compatible | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | compatible | compatible | compatible | fallback | fallback | fallback | fallback | fallback | dedicated | compatible | compatible | compatible | compatible | dedicated | compatible | dedicated | compatible | | JSONPath & XPath | dedicated | compatible | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | compatible | dedicated | compatible | dedicated | dedicated | dedicated | dedicated | compatible | dedicated | compatible | compatible | compatible | compatible | dedicated | compatible | dedicated | compatible | | ForkUnion | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended Atomics | fallback | fallback | fallback | fallback | fallback | dedicated | fallback | fallback | fallback | dedicated | fallback | dedicated | dedicated | dedicated | dedicated | fallback | fallback | dedicated | compatible | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | | SmashTable | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Collections | dedicated | dedicated | dedicated | compatible | compatible | compatible | compatible | compatible | compatible | compatible | dedicated | dedicated | compatible | compatible | dedicated | fallback | fallback | dedicated | compatible | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | unavailable | - Dedicated path for at least one operation or type - Reuses a compatible implementation - Portable fallback - Unavailable A selection from NumKong v8, StringZilla v6, ForkUnion v4 and SmashTable v1. Columns group representative platform generations; optional extensions are checked at runtime. Sources [NumKong dispatch lists](https://github.com/ashvardanian/NumKong/tree/main-v8/c/dispatch) · [StringZilla dispatch lists](https://github.com/ashvardanian/StringZilla/tree/main-v6/c/dispatch) · [ForkUnion atomics](https://github.com/ashvardanian/ForkUnion/blob/main-v4/include/forkunion/atomics.hpp) · [SmashTable row kits](https://github.com/ashvardanian/SmashTable/blob/main-v1/include/smashtable/row_search.hpp) [04 · Data movement](#placement) ## Linking jemalloc is not enough. > The fastest byte is the one that never moves. When a profile shows `malloc`, swapping in jemalloc or mimalloc is the right first move, and for allocation-heavy services it pays. Rewriting the hot loop is the right second. Both act on the compute third of the profile. The other two thirds are `memcpy`, page faults, cross-socket stalls and waiting, and a faster allocator only makes the next copy cheaper to start. We design the path so the bytes stop moving: `io_uring` and SPDK read into registered buffers, threads and memory stay on one NUMA node, and pinned buffers or GPUDirect Storage land drive reads in VRAM without a staging copy. A path this direct also removes the safety nets that catch mistakes, which is where testing has to change. ### Fig. 4.1: Two thirds of a typical first profile is moving and waiting for bytes - memcpy 31% - malloc / free 11% - page faults 9% - cross-socket stalls 8% - sync 9% - compute 32% Illustrative shares, the pattern we meet most often: two thirds of the time is spent moving, allocating and waiting for bytes. ### Fig. 4.2: Each path to the drive skips one more stop Five routes from the application. libc passes userspace buffers, the page cache and the block I/O layer; mmap joins at the page cache; io_uring with O_DIRECT and GPUDirect Storage both reach the block layer and the kernel NVMe driver; SPDK reaches the NVMe device from user space. For GPUDirect Storage the device writes by peer-to-peer DMA into VRAM. Every layer between the application and the drive is another copy, lock or context switch. io_uring with O_DIRECT stops at the block layer. GPUDirect Storage skips host memory, not the kernel: the drive DMAs reads into VRAM. SPDK skips the kernel, not host memory. ### Fig. 4.3: Four of six stages between NVMe and a GPU need not exist 4 batches moving from NVMe to a GPU. Run one at a time they take 12.4 time units. With pinned buffers and triple buffering they overlap and finish in about 3.9, 3.2 times sooner. The same work twice. On top, the defaults: buffered reads, heap copies, threads on the wrong socket and a staging copy per transfer. Below, the path we build, with GPUDirect Storage landing reads in VRAM and three shards in flight at once. Without it, one pinned copy from host to VRAM stays. [05 · Deep testing](#testing) ## Rewriting in Rust is not enough. > We test at nanosecond resolution and petabyte scale. Memory safety is worth the rewrite: a borrow checker retires a whole class of crashes and exploits, and for most services that is the class that pages someone at night. It is the right floor. It says nothing about the bugs that survive it. A safe program can still leave a graph region no search reaches, accumulate numerical error, publish half a commit, or wrap an address past 2⁶⁴ and keep running. Each needs its own proof: audit reachability from landmarks, check every kernel against extended-precision references, model-check rings and commits in Spin, and schedule with miniature index types to hit every boundary. Those races are decided in nanoseconds, six orders below where a cluster test suite looks. ### Fig. 5.1: Four failure modes a borrow checker cannot see #### Connected nodes, unreachable results Deleting a bridge can leave valid nodes unreachable. Average recall can hide the lost neighborhood. Audit connectivity Audit reachability after every graph refinement, including deletions and merges. #### Small errors, long-term drift Small rounding errors accumulate over long sequences. Wider sums keep that drift within bounds. Bound numerical error Compare every numeric type with extended-precision references and enforce ULP bounds. #### Safe threads, unsafe schedules Memory-safe threads can still publish the wrong result. The order of operations decides correctness. Explore every interleaving Model-check protocol interleavings in Spin and GenMC, beyond the schedules ordinary tests encounter. #### 2⁶⁴ is smaller than you think Valid operands can overflow an address. A petabyte offset times a wide stride reaches beyond 64 bits. Check arithmetic boundaries Check arithmetic at the boundary and return an explicit error, without allocating a petabyte. ### Fig. 5.2: Six orders of magnitude between two definitions of “correct” A timeline from one nanosecond to one second. Our races live between 1 and 100 nanoseconds; most databases look between a millisecond and a second, six orders of magnitude later. [06 · One framework](#one-tool) ## Speed, scale, portability: pick three. > The world is increasingly multimodal… one tastefully crafted framework is much more pleasant than buying from 10 different vendors. ### Fig. 6.1: Where four engines stop Building this far down is rare, and the next section says why we do it anyway. | Engine | **Speed** Parallel algorithms One writer < Many readers < GPU writers | **Scale** External-memory algorithms RAM < One drive < Many drives | **Portability** Bindings and packaging Few languages < Many < Preinstalled | | - | - | - | - | | Faiss | 2 of 3, Many readersWriters and GPU indexes need a lock | 2 of 3, One driveOn-disk IVF, apart from GPU indexes | 1 of 3, Few languagesC++ and Python bindings, plus a thin C API | | RocksDB | 2 of 3, Many readersParallel writes, compaction on the CPU | 3 of 3, Many drivesBuilt for flash, `db_paths` spans drives | 1 of 3, Few languagesC++, C and Java in tree, others third-party | | SQLite | 1 of 3, One writerOnly one writer at any instant, and no GPUs | 2 of 3, One driveOne file per database, up to 281 TB in size | 3 of 3, PreinstalledSelf-contained C, in every phone and Mac | | Unum | 3 of 3, GPU writersCPUs and GPUs from NVIDIA, AMD and Apple | 3 of 3, Many drivesRAM, VRAM and NVMe, [two-phase commits](https://www.unum.cloud/engines/ustore.md#acid) | 2 of 3, Many14 languages over [one C ABI](https://www.unum.cloud/engines/ustore.md#abi), not preinstalled | Bars count rungs reached, not benchmark scores. Only SQLite is preinstalled. Only Unum stays off the bottom rung on all three. Sources [Faiss on the GPU](https://github.com/facebookresearch/faiss/wiki/Faiss-on-the-GPU) · [Faiss threads](https://github.com/facebookresearch/faiss/wiki/Threads-and-asynchronous-calls) · [Faiss beyond RAM](https://github.com/facebookresearch/faiss/wiki/Indexes-that-do-not-fit-in-RAM) · [Faiss README](https://github.com/facebookresearch/faiss) · [RocksDB README](https://github.com/facebook/rocksdb) · [RocksDB compaction](https://github.com/facebook/rocksdb/wiki/Compaction) · [RocksDB thread pool](https://github.com/facebook/rocksdb/wiki/Thread-Pool) · [RocksDB options.h](https://github.com/facebook/rocksdb/blob/main/include/rocksdb/options.h) · [RocksDB bindings](https://github.com/facebook/rocksdb/blob/main/LANGUAGE-BINDINGS.md) · [SQLite self-contained](https://www.sqlite.org/selfcontained.html) · [SQLite most deployed](https://www.sqlite.org/mostdeployed.html) · [SQLite limits](https://www.sqlite.org/limits.html) · [When to use SQLite](https://www.sqlite.org/whentouse.html) > Talk is cheap.\ > **Show me the code.** > > [Linus Torvalds](https://lkml.iu.edu/0008.3/0272.html) ### Fig. 6.2: Same calls in every language, wherever the data lives [C](https://www.unum.cloud/docs/usearch.md) #### Python ```python from usearch import Arena, DenseIndex index = DenseIndex.init_ram(768) index.insert(keys, vectors) arena = Arena() matches = index.search(queries, 10, arena) ``` #### Rust ```rust use usearch::*; let index = DenseIndex::init_ram(&DenseOptions { dimensions: 768, ..Default::default() }, &[])?; index.insert(&keys, &rows(&vectors, 768)?)?; let mut arena = Arena::new()?; let matches = index.search(&rows(&queries, 768)?, 10, &mut arena)?; ``` #### JavaScript ```javascript const usearch = require('usearch'); const index = usearch.DenseIndex.initRam({ dimensions: 768 }); index.insert(keys, vectors); const arena = new usearch.Arena(); const matches = index.search(queries, 10, arena); ``` #### Swift ```swift import USearch let index = try DenseIndex.initRam(DenseOptions(dimensions: 768)) try index.insert(keys: keys, vectors: vectors) let arena = try Arena() let matches = try index.search(queries, wanted: 10, arena: arena) ``` Four bindings, the same native library. Follow the C link to explore the interface underneath. ## A very small company **with a Big Tech habit.** Google and Meta build their own engines because they have to. We build ours because we can’t stop. The symptoms so far: four engines and four libraries.\ **We’ve stopped pretending we can quit.** | Problem | Google | Meta | Unum | | - | - | - | - | | Storage | [LevelDB](https://github.com/google/leveldb) | [RocksDB](https://github.com/facebook/rocksdb) | [UStore](https://www.unum.cloud/engines/ustore.md) | | Search | [ScaNN](https://github.com/google-research/google-research/tree/master/scann) | [Faiss](https://github.com/facebookresearch/faiss) | [USearch](https://www.unum.cloud/engines/usearch.md) | | Networking | [gRPC](https://grpc.io/about/) | [Thrift](https://thrift.apache.org/about) | [UCall](https://www.unum.cloud/docs/ucall.md) | | Models | [Gemma](https://ai.google.dev/gemma) | [Llama](https://ai.meta.com/blog/llama-4-multimodal-intelligence/) | [UForm](https://www.unum.cloud/engines/uform.md) | [See all layers](https://www.unum.cloud/about.md#big-tech) ## That’s why you may already be running Unum without knowing it, through the databases that embed it. Some government agencies, frontier AI labs and search companies use it directly. Every engine above is one shared library away. - Government agencies Petabyte-scale search on hardware they own - Frontier AI labs Retrieval and data pipelines at GPU speed - Search companies Billions of vectors, one box before a cluster Built with Unum building blocks - [ClickHouse](https://clickhouse.com/docs/whats-new/cloud#vector-search-using-vector-similarity-indexes-early-access) - [DuckDB](https://duckdb.org/2024/05/03/vector-similarity-search-vss) - [YugabyteDB](https://www.yugabyte.com/blog/yugabytedb-vector-indexing-architecture/) - [ScyllaDB](https://www.scylladb.com/2025/10/08/building-a-low-latency-vector-search-engine/) - TiDB Open source ## **Best of all — it’s all under Apache 2.0.** Free for commercial use, built with love, so the world can build its AI infrastructure on Unum. [GitHub](https://github.com/unum-cloud) [Documentation](https://www.unum.cloud/docs.md) [Talk to us](https://discord.com/invite/4mxGrenbNt) From our blog ## [Long reads, measured on real hardware](https://www.unum.cloud/blog.md) Benchmarks, kernels and the reasoning behind them. [![Shell attractor with a wide aperture](https://www.unum.cloud/art/wide-aperture.webp)](https://www.unum.cloud/blog/float8.md) [Apr 20, 2026 IO · AI](https://www.unum.cloud/blog/float8.md) ### [FP8 Search & KV-Caching in USearch](https://www.unum.cloud/blog/float8.md) [GPUs moved to FP8. CPUs didn't. 200'000 lines of SIMD kernels later, USearch bridges both worlds — native Float8 Vector Search and KV Caching for the upcoming Arm-based NVIDIA Vera racks, Intel Xeons, open-source RISC-V chips, IBM Mainframes, Chinese LoongArch, and even WebAssembly in the browser — for higher throughput at 99% recall and half the memory cost](https://www.unum.cloud/blog/float8.md) [![Chaotic attractor: an open vortex of filaments](https://www.unum.cloud/art/open-vortex.webp)](https://www.unum.cloud/blog/scaling-vector-search-with-intel.md) [Nov 7, 2023 IO · AI](https://www.unum.cloud/blog/scaling-vector-search-with-intel.md) ### [USearch: 10x - 100x Faster than Meta's FAISS](https://www.unum.cloud/blog/scaling-vector-search-with-intel.md) [Scaling Retrieval Augmented Generation with the USearch vector search engine on Intel Sapphire Rapids CPUs on Gcore, outperforming Meta's FAISS library by 10x - 100x on a scale of 100M to 1B vectors.](https://www.unum.cloud/blog/scaling-vector-search-with-intel.md) [![Carved interlace: a vaulted knot](https://www.unum.cloud/art/vaulted-knot.webp)](https://www.unum.cloud/blog/intel-gcore-unum.md) [Jun 8, 2023 IO · News](https://www.unum.cloud/blog/intel-gcore-unum.md) ### [Making the Edge Efficient with Gcore and Intel](https://www.unum.cloud/blog/intel-gcore-unum.md) [Partnering with Gcore and Intel to deploy the world most efficient data-processing infrastructure at the edge, powered by Unum assembly-optimized engines.](https://www.unum.cloud/blog/intel-gcore-unum.md)