github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-16 21:25:46 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #7665] Dealing with passing huge attachments to models? #30652

New Issue
Closed
opened 2026-04-22 10:31:33 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-22 10:31:33 -05:00
Owner
Copy Link

Originally created by @robotom on GitHub (Nov 14, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/7665

Hi all, I'm wondering what the best way is to pass huge amounts of "attachment" data to any of the models? A typical doc might be > 2 million words (~16 million characters).

I know this amount of data can't be fed to any under 70B as prompts due to context windows. If I go with llama 3.1 405B on a 4 x H100 NVL or 8 x H100 NVL, would that be the smart way to go?

Or is there a better approach to this that I'm missing (like training my own model or something).

Ideally I'd want to be able to just drop one of these docs into the model at any time as these files come new to me, frequently.

Thanks!

Originally created by @robotom on GitHub (Nov 14, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/7665 Hi all, I'm wondering what the best way is to pass huge amounts of "attachment" data to any of the models? A typical doc might be > 2 million words (~16 million characters). I know this amount of data can't be fed to any under 70B as prompts due to context windows. If I go with llama 3.1 405B on a 4 x H100 NVL or 8 x H100 NVL, would that be the smart way to go? Or is there a better approach to this that I'm missing (like training my own model or something). Ideally I'd want to be able to just drop one of these docs into the model at any time as these files come new to me, frequently. Thanks!
GiteaMirror added the question label 2026-04-22 10:31:33 -05:00
GiteaMirror commented 2026-04-22 10:31:36 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Nov 14, 2024):

There is currently no LLM, even from commercial providers, that has a context window long enough to process 16MB of text. The number of parameters in the model (7B, 70B, 405B, etc) has no bearing on the context window.

Your options are RAG or fine-tuning. There are RAG implementations for ollama in the community integrations. RAG doesn't "understand" the document, though, it just searches based on a query and responds with a result synthesized from the search results. Fine-tuning options include unsloth, llama factory and axolotl. The problem with fine-tuning is it takes time to generate the new model, if you are receiving daily doc dumps it might not be fit for purpose. A new entry in to the scene is instructlab, which from the sound of it is a more iterative approach to fine-tuning, so might fit your use case better. I haven't used it yet so my understanding may be incorrect.

<!-- gh-comment-id:2476236354 --> @rick-github commented on GitHub (Nov 14, 2024): There is currently no LLM, even from commercial providers, that has a context window long enough to process 16MB of text. The number of parameters in the model (7B, 70B, 405B, etc) has no bearing on the context window. Your options are [RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) or [fine-tuning](https://en.wikipedia.org/wiki/Fine-tuning_(deep_learning)). There are RAG implementations for ollama in the [community integrations](https://github.com/ollama/ollama?tab=readme-ov-file#community-integrations). RAG doesn't "understand" the document, though, it just searches based on a query and responds with a result synthesized from the search results. Fine-tuning options include [unsloth](https://unsloth.ai/), [llama factory](https://github.com/hiyouga/LLaMA-Factory) and [axolotl](https://github.com/axolotl-ai-cloud/axolotl). The problem with fine-tuning is it takes time to generate the new model, if you are receiving daily doc dumps it might not be fit for purpose. A new entry in to the scene is [instructlab](https://github.com/instructlab), which from the sound of it is a more iterative approach to fine-tuning, so might fit your use case better. I haven't used it yet so my understanding may be incorrect.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#30652
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?