Bekko Static Embedding: Multilingual Retrieval on CPU Without a Transformer

Yuichi Tateno announced bekko-static-embedding-v1 on October 21, a multilingual embedding model that runs on CPU without Transformer layers. It turns text into vectors through token lookups and averaging, offering developers a different tradeoff for retrieval systems where encoding cost matters.

The release is useful because it makes that tradeoff concrete. You can compare retrieval quality, model memory and vector storage rather than assuming every semantic search system needs a contextual encoder running on a GPU.

What the new Bekko model does

The release explanation describes training on approximately 814 million text pairs across 40 target languages, using a custom 200,000-token tokenizer. Unlike a contextual model, a static model gives a token the same vector regardless of the surrounding sentence, then averages token vectors to represent the text.

That removes attention computation, but it also removes a mechanism for distinguishing how a word is being used. A retrieval evaluation needs to establish whether that loss matters for the questions and documents in your application.

The model is released under MIT licensing. Its model card documents Sentence Transformers support, with queries and documents encoded the same way and no special prefixes required.

Smaller vectors and smaller models are different choices

The standard output has 1,024 dimensions and can be shortened to 512, 256, 128, 64 or 32. This is supported by Matryoshka representation learning, which trains useful information into the beginning of the vector.

The important implementation detail is that shortening the output through truncate_dim still loads the full embedding table. Separate ONNX and OpenVINO files contain only the weights needed for a chosen dimensionality. The 512-dimensional INT8 weights occupy 103.2MB, excluding the shared tokenizer.

For deployment, these choices affect different resources. A shorter vector reduces what you store and compare for each document. A smaller weight file reduces the model's own memory footprint. Reducing vector storage does not automatically reduce the memory used to load the encoder.

That distinction is particularly useful when designing a CPU-only service with many small instances. Measure the complete process footprint rather than estimating it from the output dimension alone.

What the retrieval benchmarks show

In the author's reported NanoBEIR-en evaluation, Bekko scores 53.71, compared with 57.15 for BM25 and 58.37 for multilingual-e5-small. On MNanoBEIR, the corresponding numbers are 43.76, 46.46 and 51.17. These are retrieval scores, not percentages of questions answered correctly.

Bekko's reported advantage is against the compared static embedding models. It does not establish that it beats all retrieval architectures. The author also develops HAKARI-Bench, which supplies the Nano evaluations, so these should be read as author-run comparisons rather than independent replication.

A useful test would include your current retrieval system, BM25 and a small contextual encoder. Include exact product names, paraphrased questions and queries in the languages you actually serve. An average across many public tasks cannot tell you which option will retrieve the right internal document.

Do not read the generic speed claim as a Bekko measurement

The model card explicitly says the author has not published throughput measurements for this model. The often-mentioned 100x to 400x CPU speed range refers to earlier work on static embedding models, not a measured Bekko result.

That leaves an important part of the decision to deployment testing. Document length, batch size, tokenizer work and runtime choice can all influence the result. Encoding faster is helpful only if the retrieved candidates remain useful enough for the next stage.

For a retrieval-augmented application, I would also check the downstream answer rather than stopping at nearest-neighbor scores. If a cheaper encoder loses the one document containing the answer, the language model cannot reliably repair that missing evidence.

The release gives developers another practical baseline for inexpensive multilingual search. The strongest retrieval system is the one that meets your accuracy and operating-cost requirements, even when its best component is simpler than expected.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain engineering choices and AI launches in clear stories that developers can understand and share.

Book a 30-minute call.