-
-
Notifications
You must be signed in to change notification settings - Fork 199
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
README Indexing fails on two GPUs #17
Comments
Hey @timothepearce, I've created the issue here! I think this is what's going on: The README examples are too short. I'll update shortly to make sure the doc collections are big enough. I spy in your trace that you're using 2 GPUs ( Does it work if you use more examples? |
I've just merged #18 and pushed a fixed version to pypi (to add the wikipedia page fetcher), the readme example should be a lot more functional now! |
That was quick! I was inspecting the source code while you were fixing it. Nice job! I'm struggling with another issue (not related to your package), but I'll keep you informed. |
Thanks, glad I could fix it for you! |
Oh sorry I glanced over that -- let me know if it's something I can assist with! |
@bclavie, the |
My bad, seems like poetry silently crashed during |
@bclavie not a bug, but to carry out some benchmarks, I indexed 1000 documents and noticed that the library currently only uses one GPU at a time but loads the embedding model on both devices.
Here is the output of
Do you know how I can optimise the embedding/indexing phase? |
Oh this is interesting, thanks for flagging it! For the indexing part, it's fully deferred to ColBERT itself (the Stanford's Overall, sadly indexing can be quite slow (it's by far the slowest part of ColBERT). |
@bclavie Yes, I noticed this is one of the main disadvantages compared to dense embedding models. The 1000 documents took almost 4 hours to process, but the CPU was the bottleneck, not the GPU (even with only one running). Do you have any QPS benchmarks and memory footprint compared to the number of vectors indexed? For my use case, which consists of indexing several million documents, ColBERT is probably a better choice as a reranker. Given the number of vectors, I wouldn't be surprised if queries were slower than more traditional methods. Thanks for all your hard work, ColBERT has always been challenging to use! |
cc @okhat
That's fair! I'm planning on looking at building
I'm pretty sure once indexed (that is indeed a challenging task), ColBERT would still query super fast, but would be worth double checking!
Thank you, I'm glad this has been useful to you! |
Please yes!
I'm still working on RAGatouille. I'll run some benchmarks on a more extensive dataset and post them here if you're interested. |
Would love the yes! All early feedback is more than welcome, thank you! I'll close the issue for now (to keep tracks of bug) but feel free to post it here (I'll ping you on the reranker issue once that's live) |
I'm not sure if the problem is related to Colab, I also have an error using Jupyter locally on my Ubuntu server.
The basic
readme.md
example doesn't work and the cell never finish executing.Here's the code and stacktrace if that helps:
output the following:
Originally posted by @timothepearce in #14 (comment)
The text was updated successfully, but these errors were encountered: