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?
Te recomendaría abrir un issue en GitHub para esto. El nodo Embeddings OpenAI se usa ampliamente con backends compatibles con OpenAI (LM-Studio, vLLM, LocalAI, etc.) y debería pasar las dimensiones nativas del modelo o permitir valores arbitrarios en el campo Dimensions. Tus capturas de pantalla y resultados de pruebas hacen un buen caso de reproducción.
Confirmado: el nodo OpenAI Embeddings no es la opción correcta aquí si no puede pasar dimensiones arbitrarias como 768.
Configurar Ollama en paralelo es probablemente el camino más limpio si quieres mantenerte dentro de los nodos de AI/vector-store de n8n.
Un workaround más, si quieres mantener LM Studio:
En lugar de usar el nodo Embeddings OpenAI, llama directamente a LM Studio con un nodo HTTP Request, ya que ya confirmaste que devuelve vectores de 768 dimensiones. Luego:
envía los vectores a Qdrant a través de la REST API de Qdrant usando nodos HTTP Request, o
usa un nodo Code para reformatear la respuesta al formato esperado por el siguiente nodo.
El requisito clave es:
Salida de embedding de LM Studio: 768 dimensiones
Tamaño del vector de la colección Qdrant: 768
Nodo n8n pasando el vector completo sin cambios
Si algún nodo en el medio asume dimensiones de OpenAI o transforma el vector, Qdrant lo rechazará.
Además, cuando pruebes, asegúrate de recrear la colección de Qdrant después de cambiar el tamaño del vector. Qdrant no permitirá que una colección existente cambie de 192 a 768 dimensiones.
Así que sí, el nodo Ollama es probablemente el workaround nativo de n8n más fácil, pero la ruta HTTP Request → LM Studio → Qdrant REST también debería funcionar y evita completamente la limitación del nodo OpenAI.
