Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4529] [FEAT]: OllamaEmbedder Support Batched or Parallel Embeddings to Improve Performance #2881

New Issue
Closed
opened 2026-02-22 18:31:39 -05:00 by yindo · 2 comments
yindo commented 2026-02-22 18:31:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @theseaiying on GitHub (Oct 12, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4529

Originally assigned to: @shatfield4 on GitHub.

Hi there, thank you for building such a powerful tool with anythinglmm!

While using the OllamaEmbedder for document embedding, I noticed that the current implementation processes text chunks sequentially (using for...of + await). This results in very poor performance when handling large documents, even when the backend Ollama instance is running on high-end hardware with multiple GPUs.

📌 Problem Description
Currently, in OllamaEmbedder.embedChunks():

Each chunk is sent in a separate /api/embeddings request
Only one chunk is processed per request
It does not leverage Ollama’s built-in support for batched input via the input: string[] field
This leads to extremely long processing times (e.g., 30+ minutes for 10k+ chunks)
✨ Suggested Improvement
Please consider adding support for one of the following optimizations:

✅ Option 1: Use Ollama’s Batched Embeddings API (Recommended)
Ollama’s /api/embeddings endpoint supports passing an array of strings:

await client.embeddings({
  model: "qwen3-embedding:8b",
  input: ["text1", "text2",  #...],
})

This drastically reduces network overhead and fully utilizes GPU parallelism.

✅ Option 2: Concurrent Processing (Fallback)
If batched input is not compatible with certain models, please support concurrent requests using Promise.all() with a configurable concurrency limit (e.g., maxConcurrentChunks) to prevent OOM issues.

🔧 Example Code (for reference)

async embedChunks(textChunks) {
  const response = await this.client.embeddings({
    model: this.model,
    input: textChunks, // Batched input
    options: { num_ctx: this.embeddingMaxChunkLength }
  });
  return response.embeddings;
}
Originally created by @theseaiying on GitHub (Oct 12, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4529 Originally assigned to: @shatfield4 on GitHub. Hi there, thank you for building such a powerful tool with anythinglmm! While using the OllamaEmbedder for document embedding, I noticed that the current implementation processes text chunks sequentially (using for...of + await). This results in very poor performance when handling large documents, even when the backend Ollama instance is running on high-end hardware with multiple GPUs. 📌 Problem Description Currently, in OllamaEmbedder.embedChunks(): Each chunk is sent in a separate /api/embeddings request Only one chunk is processed per request It does not leverage Ollama’s built-in support for batched input via the input: string[] field This leads to extremely long processing times (e.g., 30+ minutes for 10k+ chunks) ✨ Suggested Improvement Please consider adding support for one of the following optimizations: ✅ Option 1: Use Ollama’s Batched Embeddings API (Recommended) Ollama’s /api/embeddings endpoint supports passing an array of strings: ``` await client.embeddings({ model: "qwen3-embedding:8b", input: ["text1", "text2", #...], }) ``` This drastically reduces network overhead and fully utilizes GPU parallelism. ✅ Option 2: Concurrent Processing (Fallback) If batched input is not compatible with certain models, please support concurrent requests using Promise.all() with a configurable concurrency limit (e.g., maxConcurrentChunks) to prevent OOM issues. 🔧 Example Code (for reference) ``` async embedChunks(textChunks) { const response = await this.client.embeddings({ model: this.model, input: textChunks, // Batched input options: { num_ctx: this.embeddingMaxChunkLength } }); return response.embeddings; } ```
yindo added the enhancementfeature request labels 2026-02-22 18:31:39 -05:00
yindo closed this issue 2026-02-22 18:31:39 -05:00
yindo commented 2026-02-22 18:31:39 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Oct 13, 2025):

We actually used to do this like option 1, but apparently the average person has low-end hardware and would try to push an insane throughput and crash their ollama service instantly. Which is why it is sequential now

@timothycarambat commented on GitHub (Oct 13, 2025): We actually used to do this like option 1, but apparently the average person has low-end hardware and would try to push an insane throughput and crash their ollama service instantly. Which is why it is sequential now
yindo commented 2026-02-22 18:31:39 -05:00
Author
Owner
Copy Link
Copy Source

@theseaiying commented on GitHub (Oct 14, 2025):

Got it — thanks for the explanation!

@theseaiying commented on GitHub (Oct 14, 2025): Got it — thanks for the explanation!
yindo changed title from [FEAT]: OllamaEmbedder Support Batched or Parallel Embeddings to Improve Performance to [GH-ISSUE #4529] [FEAT]: OllamaEmbedder Support Batched or Parallel Embeddings to Improve Performance 2026-06-05 14:49:03 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2881
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?