-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
add hf_transfer to requirements.txt #3031
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the introduction, it seems like hf_transfer
is not at a stable stage as of now?
This library is a power user tool, to go beyond ~500MB/s on very high bandwidth network, where Python cannot cap out the available bandwidth.
This is not meant to be a general usability tool. It purposefully lacks progressbars and comes generally as-is.
Since using the library only requires installing hf_transfer
and setting the env variable, I believe we can leave this as optional for users. Instead, maybe we can mention it in our docs it so that the feature is more visible. WDYT? @RonanKMcGovern
@WoosukKwon I think it is actually pretty stable. The main problem is just progress bar which is fine to ignore for product use case. |
@simon-mo Could you provide more background on this? |
It is actively maintained and I also spent quite some time in the past benchmarking/reading its code. |
I see. Still, my impression is that this library is experimental. Even if we'd like to use it for vLLM, I believe we should set the env variable like |
Agreed, we should not make optional packages into core requirements. |
Maybe we could add a guide in Quickstart instead of an optional package in requirements.txt. |
That’s understandable on not wanting to include an unstable library. I
hadn’t appreciated that.
Putting it in quick start is an improvement, although it means that the
docker image couldn’t be used straight up on a service like runpod. (Unless
I’m missing something).
…On Tue, Feb 27, 2024 at 3:45 AM 陈序 ***@***.***> wrote:
Agreed, we should not make optional packages into core requirements.
Maybe we could add a guide in Quickstart instead of an optional package in
requirements.txt.
—
Reply to this email directly, view it on GitHub
<#3031 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASVG6CQGE6GYRCEZBS4X62LYVVJD5AVCNFSM6AAAAABDZCPB6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVG4ZTGNRZGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
FWIW hf_transfer is installed in the TGI docker image |
Perhaps we could include it in the vllm docker image, but not in the requirements? |
That would fit my needs anyway. Shall I put it under "# install build and runtime dependencies" |
This would be a good place to put it Line 99 in 3b7178c
|
Thanks! I've done that now and pulled it out from where I had added it to reqs |
Shouldn't we also add something like |
@WoosukKwon I think that can be optional? User can enable it by |
@simon-mo Is this true? Otherwise, I feel we can merge the PR? |
It had prebuilt package. Rust is not required. |
@simon-mo Got it. Let's merge the PR then? |
thanks for the merge, this is great |
does the docker image need to be re-built to incorporate this? @simon-mo |
Yes. It will be there for next release. Thank you for the patience. |
Thanks @simon-mo , I think it's worth pushing asap because the docker image is much more usable for drbx if hf_transfer is there. Otherwise it takes an age to start model. |
This will allow users to set 'HF_HUB_ENABLE_HF_TRANSFER=True' and greatly speed up weight download speed from HF.