What is the tradeoff of offering tenants a 'bring your own embedding model' option in a shared collection?

The fundamental problem is that different embedding models produce vectors in different vector spaces. Two models with the same output dimension may produce vectors that are not comparable - the distance between two texts under model A is not the same as under model B. And models with different output dimensions cannot even be stored in the same vector field. If tenants in a shared collection use different models, the vector field must be partitioned: either by using a different named vector for each model, or by using a different collection for each model. A named vector field in Qdrant has its own dimension, metric, and index, so it can accommodate a different model's output. But every point must have a value for every named vector it is supposed to have, and a query only searches one named vector at a time. So a tenant using model A queries the model-A field, and a tenant using model B queries the model-B field. The collection can host multiple models, but each point belongs to one model (or has separate values for each), and queries are model-specific.

The mechanism that makes this work is that Qdrant supports multiple named vectors in a single collection, each with its own size and metric, and each with its own HNSW index. A point can carry a value for each named vector, or only for the vectors it needs. The query specifies which named vector to search (using='field'), so a tenant query is scoped to its model's field. The cost is that the collection's memory and storage are multiplied by the number of models: each model's field has its own index, its own quantized vectors, and its own storage. If tenants are distributed across several models, the collection may have many named vectors, most of which are used by a small fraction of tenants, which is inefficient. The alternative is separate collections per model, which gives each model its own configuration and avoids the multiplication of indexes in a single collection, but adds the operational overhead of managing multiple collections. The choice depends on how many models are in use and how much the tenants need independent configuration.

The trade-off is between flexibility for tenants and efficiency for the platform. Offering BYO model lets tenants use the model that best fits their data and their quality requirements, which is a competitive advantage. But it multiplies the platform's storage and memory costs, complicates the query routing, and makes the collection harder to manage. The common mistake is to allow tenants to use different models in the same vector field, which produces meaningless results. The second mistake is to not consider the storage multiplication when pricing the BYO feature. The third mistake is to not provide a migration path when a tenant wants to change models, so they are stuck with their initial choice. The fourth mistake is to not enforce that a point has a value for the field it is queried on, which produces dimension errors or missing results. The fifth mistake is to assume that same-dimension models are interchangeable, which they are not. Version note: named vectors with different dimensions and metrics, and the ability to have optional vector fields, have evolved across Qdrant releases. The multivector field is a different feature that is sometimes confused with named vectors; it represents a single field with a list of vectors, not multiple independent fields.

Version-dependent: named vectors with different dimensions and metrics have been supported for several releases, but the exact shape of the vectors_config and the ability to have optional vector fields have evolved. The multivector field type is a newer feature and is different from named vectors. If you are designing a BYO-model architecture, verify the version's support for multiple named vectors with different dimensions and metrics, and benchmark the storage and memory cost of hosting multiple model fields in a single collection.