Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Usage Does Not Decrease After Large Inputs #185

Open
mihainiculai opened this issue Sep 6, 2024 · 3 comments
Open

Memory Usage Does Not Decrease After Large Inputs #185

mihainiculai opened this issue Sep 6, 2024 · 3 comments

Comments

@mihainiculai
Copy link

I am using only the anonymizer scanner with the LLM Guard API, and I noticed significant memory (RAM) increase when processing larger inputs, with the memory usage never decreasing afterward. For example, when processing small inputs, memory consumption is around 2GB. However, when I pass inputs of around 4-5k characters, the memory usage increases to 4-5GB and stays at that level even after the processing is complete. If I input something excessive, like 15k characters, memory usage spikes to 240GB (likely starting to write to disk at that point).

I experience this behavior with all default settings, except for removing some scanners from the scanners.yaml file. Is this expected behavior, or is there an issue with memory management when using the anonymizer scanner?

@asofter
Copy link
Collaborator

asofter commented Sep 7, 2024

Hey @mihainiculai , thanks for submitting this bug. I will check

@jo-jstrm
Copy link

jo-jstrm commented Sep 19, 2024

From my use of LLM Guard's Anonymizescanner, I can confirm the above behavior. For longer inputs, crazy amounts of memory are allocated. I checked the source code, but there seems to be no way to influence this behavior with a param to the Anonymize constructor.

I wondered though, if in the model config in ner_mapping.py, the dict key chunk_size is respected when running the models. I would expect a fixe chunk size of 600, as it is set in the config, to not lead to such extensive memory usage. But maybe this assumption is wrong and it's still about the original input's size.

@jo-jstrm
Copy link

@asofter Can we assist in any way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants