Embed a billion documents.
Pay for GPU-seconds.
batchembed runs open-source embedding models on dedicated GPUs and hands the vectors back. You pick the model, including your own fine-tune. The job runs until it's finished, and you're billed for the hardware it ran on.
bge-m3 · e5-mistral · nomic-embed · gte-qwen2 · or bring your own
Why embeddings
The model only knows what you hand it
The weights are frozen. Everything a model knows about yourbusiness — the tickets, the contracts, the codebase, ten years of documents — it knows because retrieval put it in the context window at inference time. That's the only route your data has in, and embeddings are what it runs on.
Agents have made this heavier. A single task now fans out into dozens of retrievals over a corpus that keeps growing, and each one of those is a vector lookup. Something had to generate the vectors.
The re-embed tax
Embeddings are the one layer you can't patch in place. Change anything upstream and every vector you have stored is wrong, not just the ones the change touched.
So teams stop changing things. Plenty of production indexes are still serving vectors from a model two generations old, because the re-embed means weeks of queue time and a bill somebody has to defend in a planning meeting.
Retrieval sets the ceiling for everything above it: the agents, the RAG pipeline, the search box, the eval you can't quite get over the line. No model can reason about a document your index never returned. Better embeddings would fix that, and the cost of getting them is why nobody does.
That's usually why a system stops getting better.
Make a full re-embed cheap and quick enough and it stops being a migration you schedule for next quarter. It turns into something you try on a Tuesday afternoon to see whether it helps.
Hosted embedding APIs weren't built for this
They're a good deal at small volumes. Past a certain size the per-token bill and the throughput ceiling both start to hurt.
How it works
Four steps from raw data to vectors on disk.
Point us at your data
S3, GCS, a warehouse table, or a pile of files. Millions of rows or billions.
Pick a model
Any open-source embedding model: BGE, E5, Nomic, GTE, Qwen3. Or upload your own fine-tuned checkpoint.
We provision the GPUs
Dedicated workers spin up for your job and run the model in process. How many depends on how fast you want it back.
Vectors out, GPU-seconds billed
Results land wherever you want them. The bill is the GPU time your job used, at the rate you saw before it started.
Built for the jobs hosted APIs turn away
Any open-source model
BGE, E5, Nomic, GTE, Qwen3-Embedding. If you've fine-tuned your own, we'll run that instead.
Priced in GPU-seconds
You pay for the hardware your job occupies, at a rate you can check before you start it.
No rate limits
The GPUs are yours for the duration. What caps your throughput is the hardware you picked.
Your VPC or ours
If the text can't leave your infrastructure, run the whole thing inside it. Nothing goes out to a third-party API.
Sized for billions of rows
Full-corpus re-embeds, RAG backfills, search index rebuilds. The jobs that take a weekend.
Jobs that resume
Runs are checkpointed. A dropped node picks up where it stopped rather than starting the corpus again.
Work out what your job costs
Per-token pricing hides the machine behind a single number. This is the machine: the settings that move throughput, and what the job costs once they do. Have a play with it.
Your job
Multilingual, competitive with text-embedding-3-large.
Your truncation cap. Anything longer gets cut.
This is what you pay for. The gap up to your 512-token cap spends 6% of the GPU on padding.
The default. No measurable retrieval loss versus FP32.
A mixed fleet, scheduled promptly. The default, and the right pick for a corpus refresh that isn't urgent.
Estimated total
$102.89
$0.00322 per 1M tokens · 32B tokens total, at 320 avg
Throughput
7.8K/s
documents
Wall clock
3h 43m
across 8 GPUs
GPU time
29.5h
at $3.49/hr
The same job elsewhere, cost and time to finish
› How this is calculated
A forward pass costs roughly 2 × params + 2 × layers × seq_len × hidden FLOPs per token. Divide the GPU's dense tensor-core peak at your chosen precision by that, multiply by the utilisation a batch server sustains in practice, and you have tokens per second. From there it's arithmetic: tokens ÷ throughput = GPU-seconds, GPU-seconds × the hourly rate = the bill.
Utilisation is the assumption doing the most work here, being the fraction of a GPU's peak a batch server holds once it's running. Ours is calibrated against published embedding runs and assumes an optimised inference stack rather than a naive one. It does not assume we beat the best figures anyone has published. If we do, you'll see it in a benchmark before you see it in a price.
There are two token dials because they do different jobs. The averagesets how many tokens exist, so it drives the bill and the throughput both. It matters most and it's the one people usually guess wrong. The max is only a truncation cap, but the gap between the two is padding: batch a corpus averaging 200 tokens under an 8192 cap naively and most of the GPU goes on pad tokens. Hence billing on the average.
Time matters as much as price here. A batch API pays for its 50% discount with a queue. OpenAI returns batches on a 24-hour window and caps how many tokens you can enqueue at once, so a corpus larger than that cap turns into a run of sequential 24-hour windows, and a few hundred million documents can mean a week of waiting for a file to show up. Cohere and Voyage have no window, but their sustained tokens-per-minute ceiling puts a floor under how fast a large corpus can move. Our wall clock is the job itself, split across however many GPUs you asked for. Those API limits are indicative top-tier figures; yours depend on your account.
Speed costs money because urgency costs us money. Economy backfills preemptible capacity whenever there's room, so it's cheap because it can wait, and it can wait because the work is checkpointed. Turbo needs a fleet warm and reserved the moment you submit, and we pay to hold that whether you submit or not. The premium is that cost passed through. It's the batch-API bargain the other way round: they make you wait a day to save half, we let you pay to skip the queue.
You're never charged for parallelism the job was too small to use. Pick Turbo for ten thousand documents and we'll run it on the handful of GPUs that can stay busy and charge the premium pro-rata, which usually rounds to nothing. Every job pays a short per-GPU warmup on top of that. On a small enough job the warmup is most of the bill, and the estimator will say so.
How we source the capacity behind the GPU rate is our problem, not yours. “Neocloud” here means Lambda- and RunPod-class hardware; the hyperscalers charge several times as much for the same silicon, which you can watch happen by switching provider. Hosted API costs use each provider's cheapest published tier, including OpenAI's 50% batch discount, so we're comparing against them at their best.
The headline compares you against the hosted model closest in retrieval quality, so it's like for like. A 7B model beating text-embedding-3-small on price proves nothing, because it should. That pairing is our judgement call from public MTEB retrieval scores, which is why every other API's price is on the chart as well. If a cheaper, weaker model would do the job, we say so.
Estimates, not quotes. Throughput moves with tokeniser output, padding strategy and batch shape. We'll benchmark your corpus before you commit to anything.
Founder pricing
Waitlist members lock in a discounted GPU rate before general availability. Lower than every number above.
Frequently asked questions
- Why would I re-embed a corpus I've already embedded?
- Because the vectors go stale as soon as anything upstream moves: a better model, a new chunking strategy, a domain fine-tune, another language. There's no incremental fix. They came out of one specific model over one specific chunking, so changing either invalidates all of them. Most teams deal with this by never changing anything, which freezes retrieval quality in place, and retrieval quality is the ceiling on every agent and RAG pipeline above it.
- What models can I use?
- Any open-source embedding model: BGE, E5-Mistral, Nomic Embed, GTE, Qwen3-Embedding, and the rest. Your own fine-tuned checkpoints too. If it runs on a GPU, we can probably serve it.
- How is this cheaper than OpenAI or Cohere's batch APIs?
- Hosted APIs charge per token, with margin on every one. We charge for the GPU. On a large, steady batch job that works out to a fraction of the per-token bill, and the gap widens at the volumes where hosted APIs start throttling you.
- Is my data secure?
- Jobs run in-process on GPU workers dedicated to you, and you can run them inside your own VPC. Nothing is used for training and nothing is shared between customers.
- What scale are we talking about?
- Hundreds of millions to billions of rows. The product exists for the jobs hosted APIs weren't designed to take, so if you're re-embedding a full corpus after a model upgrade, that's the case we built for.
- When do you launch?
- We're onboarding a small group of design partners now. Join the waitlist and we'll get in touch about early access and founder pricing.
Get early access
Founder pricing and a design-partner slot, before general availability.