You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+30-3Lines changed: 30 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,8 @@ The goal of this library is to provide an easy, scalable, and hassle-free way to
12
12
2. Hassle-free and performant production use: we exclusively support onnx exports of huggingface models. Pytorch transformer models that don't have an onnx version can be easily exported to onnx via [huggingface optimum](https://huggingface.co/docs/optimum/index), and used with the library
13
13
3. Run on your hardware: this library is for those who want to run transformer models tightly coupled with their go applications, without the performance drawbacks of having to hit a rest API, or the hassle of setting up and maintaining e.g. a python RPC service that talks to go.
14
14
15
+
We support inference on CPU and on all accelerators supported by ONNXRuntime. Note, however, that currently only CPU and GPU inference on nvidia GPU (with cuda) are tested (see below).
16
+
15
17
## Why
16
18
17
19
Developing and fine-tuning transformer models with the huggingface python library is a great experience, but if your production stack is golang-based being able to reliably deploy and scale the resulting pytorch models can be challenging and require quite some setup. This library aims to allow you to just lift-and-shift your python model and use the same huggingface pipelines you use for development for inference in a go application.
@@ -20,7 +22,7 @@ Developing and fine-tuning transformer models with the huggingface python librar
20
22
21
23
For the golang developer or ML engineer who wants to run transformer piplines on their own hardware, tightly coupled with their own application.
22
24
23
-
## What is already there
25
+
## Implemented pipelines
24
26
25
27
Currently, we have implementations for the following transfomer pipelines:
26
28
@@ -32,11 +34,34 @@ Implementations for additional pipelines will follow. We also very gladly accept
32
34
33
35
Hugot can be used both as a library and as a command-line application. See below for usage instructions.
34
36
37
+
## Hardware acceleration 🚀
38
+
39
+
Hugot now also supports the following accelerator backends for your inference:
40
+
- CUDA (tested). See below for setup instructions.
41
+
- TensorRT (untested)
42
+
- DirectML (untested)
43
+
- CoreML (untested)
44
+
- OpenVINO (untested)
45
+
46
+
Please help us out by testing the untested options above and providing feedback, good or bad!
47
+
48
+
To use Hugot with nvidia gpu acceleration, you need to have the following:
49
+
50
+
- The cuda gpu version of onnxruntime on the machine/docker container. You can see how we get that by looking at the [Dockerfile](./Dockerfile). You can also get the onnxruntime libraries that we use for testing from the release. Just download the gpu .so libraries and put them in /usr/lib64.
51
+
- the nvidia driver for your graphics card
52
+
- the required cuda libraries installed on your system that are compatible with the onnxruntime gpu version you use. See [here](https://onnxruntime.ai/docs/execution-providers/CUDA-ExecutionProvider.html). For instance, for onnxruntime-gpu 17.3, we need CUDA 12.x (any minor version should be compatible) and cuDNN 8.9.2.26.
53
+
54
+
On the last point above, you can install CUDA 12.x by installing the full cuda toolkit, but that's quite a big package. In our testing on awslinux/fedora, we have been able to limit the libraries needed to run hugot with nvidia gpu acceleration to just these:
InterOpNumThreads and IntraOpNumThreads constricts each goroutine's call to a single core, greatly reducing locking and cache penalties. Disabling CpuMemArena and MemPattern skips pre-allocation of some memory structures, increasing latency, but also throughput efficiency.
198
223
224
+
For GPU the config above also applies. We are still testing the optimum GPU configuration, whether it is better to run in parallel or with a single thread, and what size of input batch is fastest.
0 commit comments