For some reason n8n-vector store nodes always return vectors in 192 dimension to the vector-database.
The emebedding models I tried should return 768 vectors according to their datasheet and do so if I call them via terminal or http-node with some test input.
So the model, and LM-Studio as hosting framework, dont seem to be the problem.
I also explicitly checked with chroma and qdrant that they allow for 768 collections if i set them manually.
For my understanding there seems to be an issue with either the Vector store nodes or with the openai embedding tool node.
The problem is that you’re using the Embeddings OpenAI node pointed at LM-Studio. That node is built around OpenAI’s embedding models and their specific dimension values (256, 512, 1024, 1536, 3072), which is why 768 isn’t in the dropdown. Somewhere in the node’s processing pipeline, your 768-dimension vectors are being truncated to 192 (which is exactly 768/4, so it’s likely not random).
Two things to try:
Use the Embeddings Ollama node instead if your LM-Studio instance exposes an Ollama-compatible API, or check if there’s an LM-Studio community node that handles non-OpenAI embedding dimensions properly.
As a workaround, try setting the Dimensions option explicitly in the Embeddings OpenAI node. Even though 768 isn’t in the dropdown, switch the field to Expression mode and type 768 manually. The dropdown is just a UI convenience for OpenAI’s standard values, but the underlying API parameter might accept arbitrary numbers.
If the expression workaround doesn’t work, this is worth filing as a GitHub issue. The Embeddings OpenAI node is commonly used with OpenAI-compatible backends (LM-Studio, Ollama, vLLM, etc.) and should pass through whatever dimension the model actually returns rather than forcing OpenAI-specific values.
Could you test the expression approach and let me know?
Je te recommande de signaler un problème sur GitHub pour cela. Le nœud Embeddings OpenAI est largement utilisé avec des backends compatibles OpenAI (LM-Studio, vLLM, LocalAI, etc.) et devrait soit utiliser les dimensions natives du modèle, soit permettre des valeurs arbitraires dans le champ Dimensions. Tes captures d’écran et tes résultats de test constituent un bon cas de reproduction.
Confirmé : le nœud OpenAI Embeddings ne convient pas ici s’il ne peut pas accepter des dimensions arbitraires comme 768.
Mettre en place Ollama en parallèle est probablement la solution la plus propre si vous voulez rester dans les nœuds AI/vector-store de n8n.
Une autre solution de contournement, si vous voulez conserver LM Studio :
Au lieu d’utiliser le nœud Embeddings OpenAI, appelez LM Studio directement avec un nœud HTTP Request, puisque vous avez déjà confirmé qu’il retourne des vecteurs de 768 dimensions. Ensuite, soit :
envoyez les vecteurs à Qdrant via l’API REST de Qdrant en utilisant des nœuds HTTP Request, ou
utilisez un nœud Code pour reformater la réponse au format attendu par le nœud suivant.
Le besoin clé est :
Sortie d’embedding LM Studio : 768 dimensions
Taille du vecteur de la collection Qdrant : 768
Nœud n8n transmettant le vecteur complet sans le modifier
Si un nœud intermédiaire suppose des dimensions OpenAI ou transforme le vecteur, Qdrant le rejettera.
Aussi, lors des tests, assurez-vous que la collection Qdrant est recréée après modification de la taille du vecteur. Qdrant ne permettra pas à une collection existante de passer de 192 à 768 dimensions.
Donc oui, le nœud Ollama est probablement la solution de contournement native n8n la plus facile, mais la route HTTP Request → LM Studio → Qdrant REST devrait également fonctionner et évite complètement la limitation du nœud OpenAI.
