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.