What changes
Three changes
- Index building and search run on the VDPU card
- A PCIe card goes into your server
- Milvus or FAISS is pointed at the card
VDPU Vector Data Processing Unit
Vector search on a PCIe card, right next to your index
VDPU keeps your vector index in memory on the card and runs index building and search there. Your CPUs and GPUs stay on the application and the models.
- Form factor
- Standard PCIe card
- Runs on the card
- Index building and search
- Works with
- Milvus, FAISS, hnswlib
Full specifications are available under NDA. Contact us
How a query runs on VDPU
The index stays on the card. Queries cross PCIe, run on the card, and only the results come back.
- 1Your serverYour application sends queries through Milvus or FAISS, as it does today.
- 2SchedulingThe card takes in many concurrent queries and schedules them together.
- 3Near-memory searchCompute reads the index directly from on-card memory, with no host round trips.
- 4ResultsOnly the top matches return to the host. The index never leaves the card.
What makes random-access search fast
Index data is placed on the card to suit the way search reads it, so scattered reads stay close to where they are needed.
Reads are grouped and reordered before they're issued, so less bandwidth goes to data the search never uses.
Queries are searched in parallel on the card, so concurrency rises while response times hold.
Hardware and software are built together, from the vector database plugin down to the silicon.
Built for the access pattern CPUs and GPUs handle worst
Vector search reads memory at random, for many queries at a time. VDPU is designed around that pattern, instead of borrowing a processor built for other work.
Design targets
-
10×
throughput per server
Same server, same recall
-
90%
lower 5-year TCO
Same throughput
-
87%
less rack space
Same throughput
*V110 ASIC projection based on FPGA measurements. Throughput is compared on the same server at the same recall; TCO and rack space at the same throughput.
| Property | CPU | GPU | VDPUDedicated vector search silicon |
|---|---|---|---|
| Where the index lives | Host memory, shared with everything else on the server | GPU memory, shared with the models it serves | Memory on the card, dedicated to the index |
| Random memory reads | Cores sit idle waiting on memory | Built for dense, regular math rather than scattered reads | Designed for scattered reads |
| Many concurrent queries | Keep up by adding servers | Competes with embedding and inference for the same card | Served in parallel on the card |
| Effect on the rest of the stack | Fewer cores left for the application | Less memory and time left for models | CPUs and GPUs go back to the app and models |
- Recall
- >99%
- Measured by the lab outside its accredited scope
- p99 latency, single query
- ~5ms
- Tested within the lab's accredited scope
Independently tested by a KOLAS-accredited lab (KOLAS is Korea's national accreditation body, an ILAC member).
Is VDPU right for your workload?
VDPU pays off when the index is large, queries are many and response time matters. Below that, a CPU is enough, and we'll tell you so.
| Signal | VDPU pays off | VDPU likely not needed |
|---|---|---|
| Index size | Large and growing | Small and stable |
| Query load | Sustained, high concurrency | Light or occasional |
| Response time | Interactive, even under load | Batch or offline is fine |
| Agent workload | Several retrievals per request | One lookup per request |
| Deployment | On-premises or private cloud servers | Fully managed vector service |
Works with the stack you have
Index building and search move to the card. Your embedding model, vector database API and application code stay as they are.
Supported software
- Search
- Exact and approximate, including graph-based indexes
- Libraries
- FAISS, hnswlib
- Vector database
- Milvus
- Embedding
- Stays on your GPU or CPU
Milvus and FAISS are supported today, along with hnswlib. Other vector databases and libraries are supported on request.
What stays the same
No rewrite on your side
- Your embedding model and where it runs
- Your vector database schema and query API
- Your RAG and agent application code
- Your servers and network
How a PoC works
You see throughput, latency and recall on your own data before you buy, on your server or ours. Every PoC runs under NDA, and your index can stay on your own servers if your policy requires it.
-
Step 1
Share
Your index, or a sample of it, and a query log.
- Index or sample
- Query log
-
Step 2
Size
We size cards and servers on your index and query load.
- Cards per server
- Server count
-
Step 3
Measure
We run your query log against your index on VDPU.
- Throughput
- Latency
- Recall
-
Step 4
Decide
Results and a cost comparison against your current setup.
- Results
- Cost comparison
Questions
Does VDPU replace my GPUs?
No. Embedding and LLM inference stay on your GPUs or CPUs. VDPU takes over vector index building and search, which frees host cores and GPU memory for the work they are built for.
Which vector databases and libraries work today?
Milvus and FAISS are supported today, along with hnswlib. Other vector databases and libraries are supported on request.
How do I see performance numbers?
Independent lab results are shown under Performance. For your own workload, we measure them in a PoC. See how a PoC works.
Does my data leave my servers?
No. VDPU runs in your on-premises or private cloud servers. For a PoC we can test on your server or ours, whichever your policy allows.
When is a CPU enough?
When the index is small, queries are light and answers can take a while. See Is VDPU right for your workload?
Can I get cards today?
VDPU sample chips were completed in July 2026 and are now in chip-level testing. Contact us for current availability.
Bring your index. We'll bring the card.
Send us your index and query log, and we'll measure throughput, latency and recall on your data.
