|
1 |
| -## `huggingface_hub` |
2 | 1 |
|
3 |
| -### Client library to download and publish models and other files on the huggingface.co hub |
| 2 | +This repositories enable third-party libraries integrated with [huggingface_hub](https://github.com/huggingface/huggingface_hub/) to create |
| 3 | +their own docker so that the widgets on the hub can work as the `transformers` one do. |
4 | 4 |
|
5 |
| -<p align="center"> |
6 |
| - <img alt="Build" src="https://github.com/huggingface/huggingface_hub/workflows/Python%20tests/badge.svg"> |
7 |
| - <a href="https://github.com/huggingface/huggingface_hub/blob/master/LICENSE"> |
8 |
| - <img alt="GitHub" src="https://img.shields.io/github/license/huggingface/huggingface_hub.svg?color=blue"> |
9 |
| - </a> |
10 |
| - <a href="https://github.com/huggingface/huggingface_hub/releases"> |
11 |
| - <img alt="GitHub release" src="https://img.shields.io/github/release/huggingface/huggingface_hub.svg"> |
12 |
| - </a> |
13 |
| -</p> |
| 5 | +The hardware to run the API will be provided by Hugging Face for now. |
14 | 6 |
|
15 |
| -> **Do you have an open source ML library?** |
16 |
| -> We're looking to partner with a small number of other cool open source ML libraries to provide model hosting + versioning. |
17 |
| -> https://twitter.com/julien_c/status/1336374565157679104 https://twitter.com/mnlpariente/status/1336277058062852096 |
18 |
| -> |
19 |
| -> Advantages are: |
20 |
| -> - versioning is built-in (as hosting is built around git and git-lfs), no lock-in, you can just `git clone` away. |
21 |
| -> - anyone can upload a new model for your library, just need to add the corresponding tag for the model to be discoverable β no more need for a hardcoded list in your code |
22 |
| -> - Fast downloads! We use Cloudfront (a CDN) to geo-replicate downloads so they're blazing fast from anywhere on the globe |
23 |
| -> - Usage stats and more features to come |
24 |
| -> |
25 |
| -> Ping us if interested π |
| 7 | +The `docker_images/common` folder is intended to be a starter point for all new libs that |
| 8 | +want to be integrated. |
26 | 9 |
|
27 |
| -<br> |
| 10 | +### Adding a new container from a new lib. |
28 | 11 |
|
29 |
| -### β»οΈ Partial list of implementations in third party libraries: |
30 | 12 |
|
31 |
| -- http://github.com/asteroid-team/asteroid [[initial PR π](https://github.com/asteroid-team/asteroid/pull/377)] |
32 |
| -- https://github.com/pyannote/pyannote-audio [[initial PR π](https://github.com/pyannote/pyannote-audio/pull/549)] |
33 |
| -- https://github.com/flairNLP/flair [[work-in-progress, initial PR π](https://github.com/flairNLP/flair/pull/1974)] |
34 |
| -- https://github.com/espnet/espnet [[initial PR π](https://github.com/espnet/espnet/pull/2815)] |
| 13 | +1. Copy the `docker_images/common` folder into your library's name `docker_images/example`. |
| 14 | +2. Edit: |
| 15 | + - `docker_images/example/requirements.txt` |
| 16 | + - `docker_images/example/app/main.py` |
| 17 | + - `docker_images/example/app/pipelines/{task_name}.py` |
| 18 | + to implement the desired functionnality. All required code is marked with `IMPLEMENT_THIS` markup. |
| 19 | +3. Feel free to customize anything required by your lib everywhere you want. The only real requirements, are to honor the HTTP endpoints, in the same fashion as the `common` folder for all your supported tasks. |
| 20 | +4. Edit `example/tests/test_api.py` to add TESTABLE_MODELS. |
| 21 | +5. Pass the test suite `pytest -sv --rootdir docker_images/example/ docker_images/example/` |
| 22 | +6. Submit your PR and enjoy ! |
35 | 23 |
|
36 |
| -<br> |
| 24 | +### Going the full way |
37 | 25 |
|
38 |
| -## Download files from the huggingface.co hub |
| 26 | +Doing the first 6 steps is good enough to get started, however in the process |
| 27 | +you can anticipate some problems corrections early on. Maintainers will help you |
| 28 | +along the way if you don't feel confident to follow those steps yourself |
39 | 29 |
|
40 |
| -Integration inside a library is super simple. We expose two functions, `hf_hub_url()` and `cached_download()`. |
| 30 | +1. Test your creation within a docker |
41 | 31 |
|
42 |
| -### `hf_hub_url` |
43 |
| - |
44 |
| -`hf_hub_url()` takes: |
45 |
| -- a repo id (e.g. a model id like `julien-c/EsperBERTo-small` i.e. a user or organization name and a repo name, separated by `/`), |
46 |
| -- a filename (like `pytorch_model.bin`), |
47 |
| -- and an optional git revision id (can be a branch name, a tag, or a commit hash) |
48 |
| - |
49 |
| -and returns the url we'll use to download the actual files: `https://huggingface.co/julien-c/EsperBERTo-small/resolve/main/pytorch_model.bin` |
50 |
| - |
51 |
| -If you check out this URL's headers with a `HEAD` http request (which you can do from the command line with `curl -I`) for a few different files, you'll see that: |
52 |
| -- small files are returned directly |
53 |
| -- large files (i.e. the ones stored through [git-lfs](https://git-lfs.github.com/)) are returned via a redirect to a Cloudfront URL. Cloudfront is a Content Delivery Network, or CDN, that ensures that downloads are as fast as possible from anywhere on the globe. |
54 |
| - |
55 |
| -### `cached_download` |
56 |
| - |
57 |
| -`cached_download()` takes the following parameters, downloads the remote file, stores it to disk (in a versioning-aware way) and returns its local file path. |
58 |
| - |
59 |
| -Parameters: |
60 |
| -- a remote `url` |
61 |
| -- your library's name and version (`library_name` and `library_version`), which will be added to the HTTP requests' user-agent so that we can provide some usage stats. |
62 |
| -- a `cache_dir` which you can specify if you want to control where on disk the files are cached. |
63 |
| - |
64 |
| -Check out the source code for all possible params (we'll create a real doc page in the future). |
65 |
| - |
66 |
| -### Bonus: `snapshot_download` |
67 |
| - |
68 |
| -`snapshot_download()` downloads all the files from the remote repository at the specified revision, |
69 |
| -stores it to disk (in a versioning-aware way) and returns its local file path. |
70 |
| - |
71 |
| -Parameters: |
72 |
| -- a `repo_id` in the format `namespace/repository` |
73 |
| -- a `revision` on which the repository will be downloaded |
74 |
| -- a `cache_dir` which you can specify if you want to control where on disk the files are cached. |
75 |
| - |
76 |
| -<br> |
77 |
| - |
78 |
| -## Publish models to the huggingface.co hub |
79 |
| - |
80 |
| -Uploading a model to the hub is super simple too: |
81 |
| -- create a model repo directly from the website, at huggingface.co/new (models can be public or private, and are namespaced under either a user or an organization) |
82 |
| -- clone it with git |
83 |
| -- [download and install git lfs](https://git-lfs.github.com/) if you don't already have it on your machine (you can check by running a simple `git lfs`) |
84 |
| -- add, commit and push your files, from git, as you usually do. |
85 |
| - |
86 |
| -**We are intentionally not wrapping git too much, so that you can go on with the workflow youβre used to and the tools you already know.** |
| 32 | +```python |
| 33 | +./manage.py docker --model-id MY_MODEL |
| 34 | +``` |
87 | 35 |
|
88 |
| -> π To see an example of how we document the model sharing process in `transformers`, check out https://huggingface.co/transformers/model_sharing.html |
| 36 | +should work and responds on port 8000. `curl -X POST -d "test" http://localhost:8000` for instance if |
| 37 | +the pipeline deals with simple text. |
89 | 38 |
|
90 |
| -Users add tags into their README.md model cards (e.g. your `library_name`, a domain tag like `audio`, etc.) to make sure their models are discoverable. |
| 39 | +If it doesn't work out of the box and/or docker is slow for some reason you |
| 40 | +can test locally (using your local python environment) with : |
91 | 41 |
|
92 |
| -**Documentation about the model hub itself is at https://huggingface.co/docs** |
| 42 | +`./manage.py start --model-id MY_MODEL` |
93 | 43 |
|
94 |
| -### API utilities in `hf_api.py` |
95 | 44 |
|
96 |
| -You don't need them for the standard publishing workflow, however, if you need a programmatic way of creating a repo, deleting it (`β οΈ caution`), pushing a single file to a repo or listing models from the hub, you'll find helpers in `hf_api.py`. |
| 45 | +2. Test your docker uses cache properly. |
97 | 46 |
|
98 |
| -We also have an API to query models by specific tags (e.g. if you want to list models compatible to your library) |
| 47 | +When doing subsequent docker launch with the same model_id, the docker should start up very fast and not redownload the whole model file. If you see the model/repo being downloaded over and over, it means the cache is not being used correctly. |
| 48 | +You can edit the `docker_images/{framework}/Dockerfile` and add an environement variable (by default it assumes `HUGGINGFACE_HUB_CACHE`), or your code directly to put |
| 49 | +the model files in the `/data` folder. |
99 | 50 |
|
100 |
| -### `huggingface-cli` |
| 51 | +3. Add a docker test. |
101 | 52 |
|
102 |
| -Those API utilities are also exposed through a CLI: |
| 53 | +Edit the `tests/test_dockers.py` file to add a new test with your new framework |
| 54 | +in it (`def test_{framework}(self):` for instance). As a basic you should have 1 line per task in this test function with a real working model on the hub. Those tests are relatively slow but will check automatically that correct errors are replied by your API and that the cache works properly. To run those tests your can simply do: |
103 | 55 |
|
104 | 56 | ```bash
|
105 |
| -huggingface-cli login |
106 |
| -huggingface-cli logout |
107 |
| -huggingface-cli whoami |
108 |
| -huggingface-cli repo create |
109 |
| -``` |
110 |
| - |
111 |
| -### Need to upload large (>5GB) files? |
112 | 57 |
|
113 |
| -To upload large files (>5GB π₯), you need to install the custom transfer agent for git-lfs, bundled in this package. |
114 |
| - |
115 |
| -To install, just run: |
116 |
| - |
117 |
| -```bash |
118 |
| -$ huggingface-cli lfs-enable-largefiles |
| 58 | +RUN_DOCKER_TESTS=1 pytest -sv tests/test_dockers.py::DockerImageTests::test_{framework} |
119 | 59 | ```
|
120 | 60 |
|
121 |
| -This should be executed once for each model repo that contains a model file >5GB. If you just try to push a file bigger than 5GB without running that command, you will get an error with a message reminding you to run it. |
122 |
| - |
123 |
| -Finally, there's a `huggingface-cli lfs-multipart-upload` command but that one is internal (called by lfs directly) and is not meant to be called by the user. |
124 |
| - |
125 |
| -<br> |
126 |
| - |
127 |
| -## Visual integration into the huggingface.co hub |
128 |
| - |
129 |
| -Finally, we'll implement a few tweaks to improve the UX for your models on the website β let's use [Asteroid](https://github.com/asteroid-team/asteroid) as an example: |
130 |
| - |
131 |
| - |
132 |
| - |
133 |
| -Model authors add an `asteroid` tag to their model card and they get the advantages of model versioning built-in |
| 61 | +### Modifying files within `api-inference-community/{routes,validation,..}.py`. |
134 | 62 |
|
135 |
| - |
| 63 | +If you ever come across a bug within `api-inference-community/` package or want to update it |
| 64 | +the developpement process is slightly more involved. |
136 | 65 |
|
137 |
| -We add a custom "Use in Asteroid" button. |
| 66 | +- First, make sure you need to change this package, each framework is very autonomous |
| 67 | + so if your code can get away by being standalone go that way first as it's much simpler. |
| 68 | +- If you can make the change only in `api-inference-community` without depending on it |
| 69 | +that's also a great option. Make sure to add the proper tests to your PR. |
| 70 | +- Finally, the best way to go is to develop locally using `manage.py` command: |
| 71 | +- Do the necessary modifications within `api-inference-community` first. |
| 72 | +- Install it locally in your environment with `pip install -e .` |
| 73 | +- Install your package dependencies locally. |
| 74 | +- Run your webserver locally: `./manage.py start --framework example --task audio-source-separation --model-id MY_MODEL` |
| 75 | +- When everything is working, you will need to split your PR in two, 1 for the `api-inference-community` part. |
| 76 | + The second one will be for your package specific modifications and will only land once the `api-inference-community` |
| 77 | + tag has landed. |
| 78 | +- This workflow is still work in progress, don't hesitate to ask questions to maintainers. |
138 | 79 |
|
139 |
| - |
| 80 | +Another similar command `./manage.py docker --framework example --task audio-source-separation --model-id MY_MODEL` |
| 81 | +Will launch the server, but this time in a protected, controlled docker environment making sure the behavior |
| 82 | +will be exactly the one in the API. |
140 | 83 |
|
141 |
| -When clicked you get a library-specific code sample that you'll be able to specify. π₯ |
142 | 84 |
|
143 |
| -## Inference API integration into the huggingface.co hub |
144 | 85 |
|
145 |
| -In order to get a functional Inference API on the hub for your models (and thus, cool working widgets!) check out this [doc](https://github.com/huggingface/huggingface_hub/tree/master/api-inference-community) |
| 86 | +### Available tasks |
146 | 87 |
|
147 |
| -<br> |
| 88 | +- **Automatic speech recognition**: Input is a file, output is a dict of understood words being said within the file |
| 89 | +- **Text generation**: Input is a text, output is a dict of generated text |
| 90 | +- **Image recognition**: Input is an image, output is a dict of generated text |
| 91 | +- **Question answering**: Input is a question + some context, output is a dict containing necessary information to locate the answer to the `question` within the `context`. |
| 92 | +- **Audio source separation**: Input is some audio, and the output is n audio files that sum up to the original audio but contain individual soures of sound (either speakers or instruments for instant). |
| 93 | +- **Token classification**: Input is some text, and the output is a list of entities mentionned in the text. Entities can be anything remarquable like locations, organisations, persons, times etc... |
| 94 | +- **Text to speech**: Input is some text, and the output is an audio file saying the text... |
| 95 | +- **Sentence Similarity**: Input is some sentence and a list of reference sentences, and the list of similarity scores. |
148 | 96 |
|
149 |
| -## Feedback (feature requests, bugs, etc.) is super welcome ππππβ₯οΈπ§‘ |
0 commit comments