all-MiniLM-L12-v2 produces 384-dimensional embeddings. This means that every sentence or paragraph you encode is represented as a vector of 384 floating-point numbers. Embedding dimensionality is a critical design detail because it directly affects storage size, memory usage, and search performance. A 384-dimensional vector is considered compact by modern standards, which is one reason this model is widely used as a baseline in semantic search systems.
From a systems standpoint, the embedding dimension determines how much space your vector index will consume. For example, one million vectors at 384 dimensions stored as 32-bit floats require roughly 1.5 GB of raw vector data, before indexing overhead. This is manageable for many teams and fits comfortably in memory on a single machine or small cluster. Larger embedding dimensions increase memory pressure and can slow down similarity search, especially when scaling to tens or hundreds of millions of vectors.
This compact dimensionality works well with vector databases such as Milvus or Zilliz Cloud. These systems are optimized for dense vectors in the few-hundred-dimension range and provide indexing options that balance recall, latency, and memory usage. With 384 dimensions, you can often achieve low-latency search while maintaining acceptable recall, especially when combined with metadata filtering and good chunking strategies. The key takeaway is that the 384-dimension output is a practical sweet spot for many real-world retrieval workloads.
For more information, click here: https://zilliz.com/ai-models/all-minilm-l12-v2