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?
Ich würde dir empfehlen, ein GitHub Issue dafür zu erstellen. Der Embeddings OpenAI Node wird häufig mit OpenAI-kompatiblen Backends (LM-Studio, vLLM, LocalAI, etc.) verwendet und sollte entweder die nativen Dimensionen des Modells durchleiten oder beliebige Werte im Feld Dimensions zulassen. Deine Screenshots und Testergebnisse bilden einen soliden Reproduktionsfall.
Bestätigt: Der OpenAI Embeddings-Node ist hier nicht die richtige Wahl, wenn er keine beliebigen Dimensionen wie 768 übergeben kann.
Die parallele Einrichtung von Ollama ist wahrscheinlich der sauberste Weg, wenn du bei n8n’s AI/Vector-Store-Nodes bleiben möchtest.
Ein weiterer Workaround, falls du LM Studio behalten möchtest:
Anstatt den Embeddings OpenAI-Node zu verwenden, rufe LM Studio direkt mit einem HTTP Request-Node auf, da du bereits bestätigt hast, dass es 768-dimensionale Vektoren zurückgibt. Dann entweder:
sende die Vektoren über die Qdrant REST API mit HTTP Request-Nodes zu Qdrant, oder
verwende einen Code-Node, um die Antwort in das vom nächsten Node erwartete Format umzuformen.
Die Schlüsselanforderung ist:
LM Studio Embedding-Ausgabe: 768 Dimensionen
Qdrant Collection Vektorgröße: 768
n8n Node übergibt den vollständigen Vektor unverändert
Falls irgendein Node in der Mitte OpenAI-Dimensionen annimmt oder den Vektor transformiert, wird Qdrant ihn ablehnen.
Außerdem solltest du beim Testen sicherstellen, dass die Qdrant Collection nach einer Änderung der Vektorgröße neu erstellt wird. Qdrant erlaubt nicht, dass eine bestehende Collection von 192 auf 768 Dimensionen wechselt.
Also ja, der Ollama-Node ist wahrscheinlich der einfachste native n8n-Workaround, aber die HTTP Request → LM Studio → Qdrant REST-Route sollte auch funktionieren und umgeht die OpenAI-Node-Limitierung komplett.
