What It Costs to Embed a Genome for Search

There is no price list for this, so the only useful version of the answer is the arithmetic with every input named. Substitute your own numbers into the same four steps and the result is yours rather than somebody else’s guess.

The inputs, all of them assumptions

Four numbers determine the compute bill and two more determine the storage bill. Every one of them is stated here so you can replace it:

A. genome length          3.1e9 bases  (see below)
B. chunk size             1,000 bases
C. chunk overlap            200 bases  -> stride 800
D. tokens per chunk       two cases, worked separately
E. price per 1M tokens    $0.02        (ASSUMPTION)
F. embedding dimension    768          (ASSUMPTION)

Only A is a published figure. The human reference assembly GRCh38 is about 3.1 billion bases for the primary haploid assembly, which you can read off NCBI’s assembly record for GRCh38.p14. B and C are design choices. D depends entirely on the tokenizer. E is a stand-in for a price you must look up for the specific model you intend to call — embedding prices vary by more than an order of magnitude across providers and change frequently. F is a common dimension for a small embedding model.

Genome length to chunk count

A model has a maximum input length, so the genome is cut into overlapping windows. Overlap exists so that a feature straddling a boundary appears intact in at least one chunk; with a 1,000-base chunk and 200-base overlap, the window advances 800 bases each time.

chunks = genome length / stride
       = 3.1e9 / 800
       = 3,875,000 chunks

Two multipliers are easy to forget and each doubles the bill. If your search must work regardless of which strand a query comes from, and you are not canonicalising, you embed both strands: 7,750,000 chunks. If you are embedding two haplotypes of a diploid individual rather than the haploid reference, double again. The 3,875,000 figure is the single-strand, haploid-reference case, and it is the smallest honest number.

Chunk size is not only a cost parameter, which is why it is worth choosing before rather than after this calculation. It sets the granularity of what you can retrieve: a 1,000-base chunk returns a 1,000-base region, and if what you wanted was a 200-base regulatory element then most of the returned vector is context diluting the signal you searched on. Halving the chunk size to 500 bases at the same overlap sharpens retrieval and, because stride falls from 800 to 300, raises the chunk count to about 10.3 million — roughly 2.7 times the cost of every line below. The two effects pull in opposite directions and there is no general answer; the point is that the retrieval decision and the bill are the same decision.

Chunks to tokens to a bill

Tokens per chunk is the input with the widest range, because DNA tokenizers differ fundamentally. A character-level tokenizer emits one token per base. A k-mer tokenizer emitting non-overlapping 6-mers emits one token per six bases. Byte-pair encodings trained on nucleotide text land somewhere between. Work both ends:

CASE 1 -- character-level, 1 token per base
  tokens/chunk   1,000
  total tokens   3,875,000 x 1,000  = 3.875e9
  cost           3,875 M tokens x $0.02/M
                 = $77.50

CASE 2 -- non-overlapping 6-mers, ~167 tokens per chunk
  tokens/chunk   ceil(1000/6) = 167
  total tokens   3,875,000 x 167   = 6.47e8
  cost           647 M tokens x $0.02/M
                 = $12.94

both strands: multiply by 2
diploid, both haplotypes, both strands: multiply by 4

So the same genome, the same chunking and the same assumed price give answers a factor of six apart purely because of tokenizer granularity. That is the first thing to pin down when someone quotes you a number.

The self-hosted route has different arithmetic. Suppose, as a labelled assumption, an accelerator that embeds 1,000 chunks per second at this chunk size, rented at $2.00 per hour:

wall time  3,875,000 / 1,000 = 3,875 s = 1.08 hours
compute    1.08 h x $2.00/h   = $2.16

An order of magnitude below the hosted figure at this volume, which is the usual shape: the hosted price includes availability and operational work you are not doing. The crossover is engineering time, not compute — an afternoon spent making the self-hosted path work costs more than the difference here, and stops doing so somewhere above a few hundred genomes. The general treatment of that trade is in inference economics.

What the vectors cost to keep

Compute is a one-off. Storage recurs, and at this chunk count it is usually the larger number over a year.

vectors            3,875,000
dimension          768

float32   768 x 4 bytes = 3,072 B/vector
          3,875,000 x 3,072 = 11.9 GB

float16   768 x 2 bytes = 1,536 B/vector  =  5.95 GB

PQ, 96 bytes per vector                   =   372 MB

HNSW graph, M = 16 links (32 at layer 0),
4-byte ids: 128 B/vector                  =   496 MB

Two readings. Quantisation is the dominant lever on storage — a 32-fold reduction from float32 to product quantisation at 96 bytes, at a cost in recall you have to measure on your own queries, which is the trade in vector quantisation. And the index structure is not free: an HNSW graph at these settings costs more per vector than product-quantised vectors do, so a quantised-vector-plus-graph configuration is dominated by the graph. Priced against monthly storage rates, see vector storage cost for how that recurs.

Which input moves the answer

• Tokenizer granularity — a factor of six here. The largest single lever, and the one least often stated when a cost is quoted. Establish tokens per base for your actual model before anything else.
• Overlap — up to a factor of five. Stride is chunk size minus overlap, and chunk count is inversely proportional to stride. Going from 200-base to 800-base overlap on a 1,000-base chunk takes the stride from 800 to 200 and quadruples everything. This is the cost that disappears into a config file.
• Strand and ploidy — factors of two. Both are decisions about what you are searching, not about the pipeline, and both are usually made implicitly.
• Dimension — linear in storage, not in compute. A 1,280-dimension model costs about the same to run per token and 1.7 times as much to store as a 768-dimension one; see what embedding dimension costs.
• Re-embedding. Every model change is a full rebuild at the full cost. Treat the figure above as recurring at whatever cadence you expect to change models, not as a one-time capital cost.

What this arithmetic deliberately does not include: the cost of downloading and preparing the sequence, the engineering time to write and babysit the job, retries on failed requests, and the query-side cost of running searches against the finished index. Each is real and none of them has a general number.