Hugot: running Hugging Face transformer pipelines inside a Go service
Onnx transformer pipelines in Golang
At a glance
- What is it?
- Hugot brings the Hugging Face pipeline model to Go by loading ONNX models directly, so a Go application can do text, vision, audio and multimodal inference without a Python sidecar. The trade is that models must be exported to ONNX, and some pipelines only work on the ONNX Runtime backend.
- Who is it for?
- Hugot fits a Go team that already has transformer models in production through Python and wants inference inside the Go binary, with the same pipeline semantics and no REST hop in between. It does not fit a team that needs fine-tuning of the full model, or a project that cannot accept a build that pulls in the ONNX Runtime native libraries.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem is a Go stack with a Python model in it
The README's why section is a complaint about a very common production shape. Developing and fine-tuning transformer models with the Hugging Face Python library is fine, but if your production stack is Go based, reliably deploying and scaling the resulting PyTorch models is hard. The usual answers are worse. You can hit a REST API, which adds a network hop and a service to operate, or you can set up and maintain a Python RPC service that talks to Go, which is the hassle the library exists to avoid. The fourth principle in the README states the intent directly: 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. The target user is named as the Go developer or ML engineer who wants to run or fine-tune transformer pipelines on their own hardware, without writing their own inference or training code.
Hugging Face compatibility is the contract, and ONNX is the price
The first stated principle is that models trained and tested with the Python Hugging Face transformer library can be exported to ONNX and used with the Hugot pipelines to obtain identical predictions as in the Python version. Identical predictions is a strong claim and it is what makes the lift-and-shift story work. The second principle sets the constraint: the library exclusively supports ONNX models, and PyTorch models without an ONNX version can be exported via Hugging Face Optimum. That is a real dependency on the export path working for your model, and some architectures with custom operators do not export cleanly. The model format is settled. Hugot loads and saves models in the ONNX format, and the third principle is about deployment, running on your own hardware rather than through a service. The fourth is simplicity: the API lets you deploy pipelines without writing your own inference or training code.
Three backends, and the Go one is aimed at smaller models
The backends are pluggable, and the pure Go one is not the default choice for production. The README's important note says the Go backend is designed for simpler workloads, environments that disallow cgo, and for smaller models such as all-MiniLM-L6-v2, and that it works best with small batches of roughly 32 inputs per call. If you have performance requirements, you are told to move to a C backend such as XLA or ORT. The repository layout shows how the three are separated in the source, with hugot.go and hugot_go.go for the Go path, hugot_ort.go and hugot_ort_gomlx.go for the runtime paths, hugot_xla.go for XLA, and paired _disabled.go files that compile the backend out when its build tags are not set. Inference is supported on CPU and on all accelerators supported by ONNX Runtime or OpenXLA, but the README is specific about what is actually tested: CPU, TPU, and GPU on Nvidia GPUs via CUDA.
The dependency set explains the architecture
The go.mod is a map of the project. The module requires Go 1.27.0 and pulls in a cluster of gomlx projects: compute, compute-onnx, go-huggingface, go-xla, gomlx itself and onnx-gomlx. Those are the Go-side machine learning stack that sits under the pure Go and XLA paths. The ONNX Runtime path comes from the Microsoft onnxruntime/go package, and the knights-analytics/ortgenai module covers the generative AI extensions. Supporting libraries are the usual ones for a text and image pipeline: golang.org/x/image, x/sync and x/text, plus a direct dependency on testify for tests and the sentencepiece package for tokenisation. The indirect list includes the gomlx exceptions package, the flock package for file locking, google/uuid and the protobuf runtime. The repository root holds the top-level entry points, with hugot.go, hugot_ort.go, hugot_xla.go, a trainer.go, a downloader.go and a util directory, plus a pipelines directory for the individual pipeline implementations and a backends directory.
Around thirty pipelines, and many of them are ORT only
The implemented pipelines list is long and, more importantly, annotated. The entries marked currently ORT only include automaticSpeechRecognition, depthEstimation, documentQuestionAnswering, addressParse, imageTextToText, imageToText, groundedObjectDetection, tableQuestionAnswering, tabular for classic ML models such as decision trees and random forests, textGeneration, textToAudio, textToSpeech and visualQuestionAnswering. The ones without that marker include audioClassification, audioToAudio, backgroundRemoval, crossEncoder, fillMask, featureExtraction, imageClassification, imageFeatureExtraction, imageSegmentation, maskGeneration, objectDetection, questionAnswering, textClassification and tokenClassification. That distinction decides whether you can use the pure Go backend for your task at all, and for a given model it is a one-line check in the list rather than a discovery you make during a performance test.
Docker builds, CUDA variants and a dev compose file
The build infrastructure shows a project that takes its native dependencies seriously. The Dockerfile declares build arguments for the Go version, the ONNX Runtime version, the ONNX Runtime GenAI version and the GoPFRT version, and it starts from an Amazon Linux 2023 base on the build platform. It downloads the ONNX Runtime and the GenAI runtime through scripts in the scripts directory, then installs Go from the official tarball, and it patches glibc with a specific Fedora 43 package to get a version new enough for the runtime. The comments state the purpose of the runtime layer: the image generated does not contain the hugot code, only the dependencies needed by hugot. There is a separate cuda.Dockerfile, a models.Dockerfile and a test.Dockerfile, a docker-bake.hcl for multi-target builds, and compose-dev.yaml and compose-test.yaml for local work. The project is Apache-2.0 licensed, the repository is not archived, and the last push was on 2026-10-19 with v0.8.3 released on 2026-10-14.
Editorial conclusion
Hugot fits a Go team that already has transformer models in production through Python and wants inference inside the Go binary, with the same pipeline semantics and no REST hop in between. It does not fit a team that needs fine-tuning of the full model, or a project that cannot accept a build that pulls in the ONNX Runtime native libraries. Verify first which pipelines you need and whether they are marked ORT only, because a large share of them are, and benchmark the pure Go backend against your real batch size before you commit to it, since the README says it is aimed at smaller models and batches of roughly 32.
Frequently asked questions
What does Hugot do and who is it for?
Hugot brings Hugging Face style transformer pipelines to Go, letting you run and fine-tune ONNX models for text, vision, audio and multimodal workloads inside a Go application. The README names the audience as the Go developer or ML engineer who wants to run pipelines on their own hardware, tightly coupled with their application, without writing their own inference code.
Which Hugot pipelines only work with the ONNX Runtime backend?
The README marks automaticSpeechRecognition, depthEstimation, documentQuestionAnswering, addressParse, imageTextToText, imageToText, groundedObjectDetection, tableQuestionAnswering, tabular, textGeneration, textToAudio, textToSpeech and visualQuestionAnswering as currently ORT only, so those cannot use the pure Go backend.
When should I use the pure Go backend instead of ONNX Runtime or XLA?
The README says the Go backend is designed for simpler workloads, environments that disallow cgo, and smaller models such as all-MiniLM-L6-v2, and that it works best with small batches of roughly 32 inputs per call. If you have performance requirements, you are directed to a C backend such as XLA or ORT.
What model format does Hugot use?
Hugot loads and saves models in the ONNX format and exclusively supports ONNX models. The README says PyTorch transformer models that lack an ONNX version can be exported via Hugging Face Optimum, and that models trained with the Python library should give identical predictions once exported.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/knights-analytics-hugot)Was this useful?