For enterprise
Your infrastructure.
Your language.
The recognition weights are open and the service is one container with no GPU and no call home. If your audio cannot leave your network, that is not a special arrangement to negotiate, it is the default you can test this afternoon.
Amharic available. Afaan Oromoo in training.
The short version
Nothing here needs our account
You can build the image, fetch the weights and transcribe your own audio without speaking to us at all. The reason to speak to us is a fine-tune, a sizing review, or an invoice your finance team accepts.
docker build -t hohe-asr .
docker run --rm -p 8080:8080 hohe-asr
curl -F [email protected] http://localhost:8080/transcribeIt fetches the weights on first start, loads them onto the processor and serves on port 8080. No credentials, no licence key, no GPU. Any format ffmpeg reads works, including the audio a phone records.
0
GPUs required
The service uses one if it finds one and expects not to.
4
cores to provision
Eight threads is barely quicker and on short clips it is slower.
1
system dependency
ffmpeg, to decode whatever your audio arrives as.
0
outbound calls
Once the weights are in place there is no dependency on us.
Where it runs
Three deployments, and the last one is the real test
Plenty of vendors will say on premise. The question that separates them is whether the thing still works with the network cable out, and for this service it does.
Your own cloud account
most common
The container runs in your VPC, on your instances, under your own billing and your own security review. Nothing calls home, so your audio never reaches a network you do not control and there is no usage report for us to read.
Suited to a team that already runs containers and wants the audio to stay inside its own account.
Your own hardware
on premise
The same container on a machine in your building. It needs no GPU and no accelerator, which is what makes this practical: the requirement is a few ordinary server cores rather than a procurement cycle for hardware that is hard to import.
Suited to a bank, a hospital or a government office with a rule about where recordings may be stored.
Disconnected and air gapped
no internet
The image pulls the weights from the internet on first start, so for a machine with no route out we hand you the weights and the image to load from disk. After that the service has no outbound dependency at all.
Suited to an environment where the network itself is the control, and verify it before you commit to it.
What you get
Everything in the left column exists today
The right column is the honest half. Only the recognition model ships as a container, and we would rather you read that here than discover it in a technical call.
Included
- The container image
- One Dockerfile, one system dependency (ffmpeg), and a build that needs no credentials of ours. docker run and it serves.
- The open weights
- The recognition weights are public. They are the same weights the hosted API serves, so your own measurement and ours are comparable.
- The serving code
- The HTTP service, in readable Python, including the chunking that makes long audio both cheaper and responsive. Not a compiled artefact you cannot inspect.
- The deployment scripts
- What we use ourselves: an auto scaling group behind an internal load balancer, the weights delivered from object storage, the shared secret read from a parameter store rather than baked into an image.
- The CPU sizing sweep
- The script and the results, at several clip lengths and thread counts, in fp32 and int8, so you can size a machine from measurement rather than from our recommendation.
- The model card
- What the model was trained on, what it was scored against, and where it is weak. The telephone number is in it.
Not included
- Speech synthesis and voice cloning
- Available on the hosted API, not as a container today. Cloning is also gated behind a consent review that does not survive being handed to someone else, which is the point of it.
- Subtitle rendering
- The transcription runs anywhere. The render workers that burn captions into video are part of the hosted product.
- The dashboard, keys and credit metering
- A self-hosted service has no credit balance to meter and no keys of ours to check. You authenticate it with a shared secret and account for it however you already account for your own services.
If one of those is what you need on your own hardware, ask. It is a conversation about what we would have to build, not a no.
Sizing
What machine it needs, measured rather than recommended
Real time factor is seconds of compute per second of audio. Anything under 1.0 is faster than real time, so one four core machine keeps up with a continuous stream of recordings and has room left over.
5 seconds
0.078
about four tenths of a second
15 seconds
0.155
about two and a third seconds
30 seconds
0.258
about eight seconds
int8 at four threads, measured on a c7i.2xlarge in eu-central-1 on 20 September 2026. int8 is the default and needs no calibration step, so the served weights cannot drift from the evaluated ones.
What the sweep decided
- Four cores, not eight
- Eight threads is barely quicker than four and on short clips it is slower, because the work per thread stops covering the cost of splitting it. Four ordinary cores is the size to provision.
- No GPU, and none wanted
- The service uses a GPU if it finds one and expects not to. On four cores a thirty second recording is transcribed in eight seconds, and a GPU would mostly be paid for sitting idle between requests.
- Cut long audio into pieces
- Attention is quadratic, so cost grows faster than length: thirty seconds costs 0.258 against 0.078 for five. The service already cuts recordings at their quietest instants, which makes it cheaper as well as more responsive.
The service
The whole integration surface
Two endpoints and two environment variables. There is no client library to adopt and nothing to keep up to date.
- POST /transcribe
- Multipart, field audio, any format ffmpeg reads. Returns newline delimited JSON: a partial transcript after each chunk, then the final text with its duration and compute time.
- GET /health
- Open, because a load balancer asks it and cannot send a header.
- ASR_SECRET
- Set it and the service requires it back as an x-asr-secret header. Leave it unset and the service is open, which is right on a laptop and wrong on a network.
- MODEL_DIR
- Mount your own fine-tune at /model and it serves that instead of fetching ours.
The hosted API is a different surface, with keys, credits and per second metering. It is documented in the developer documentation.
Use cases
What people actually bring us
Five shapes of problem, with the one that needs a warning first.
Call recordings and quality monitoring
fine-tune firstThousands of hours of Amharic phone audio that nobody has ever listened to twice. Read the research page before you plan this one: telephone audio is narrowband and compressed, and the model is substantially worse on it than on the read speech its headline number comes from. The answer is a fine-tune on your own calls, measured on your own held-out set, and that is an engagement rather than an API key.
Voice self-service and IVR
latencyRecognition inside a phone tree, where the audio is already on your switch. Running the model next to the switch rather than across the internet removes a round trip from every turn, which on a live call is the difference a caller actually notices.
Broadcast and archive transcription
bulkA back catalogue to make searchable, or a daily feed to caption. This is the case the hosted API suits best, because it is bulk work with no latency requirement, and it is also the easiest to run yourself overnight on hardware you already own.
Records where the audio cannot leave
residencyHealth, legal, financial and government recordings under a rule about where they may be processed. Open weights and a container with no outbound dependency are a stronger answer to that than any assurance we could write about our own handling.
Accessibility and public service
coverageCaptions and transcripts for Amharic speakers, in a product that already exists. Tell us the volume and the languages you need, including the ones we have not finished, and we will tell you honestly which part is ready.
An agreement
What a contract adds that open weights do not
If the container is all you need, take it and go. These are the things that are genuinely work rather than a download.
- A fine-tune on your own audio
- The single biggest accuracy gain available to most deployments, and the only honest answer to telephone audio. Scored on a held-out set from your own recordings, not on ours.
- Sizing and a deployment review
- We have run this service on spot instances behind a load balancer for long enough to know where it breaks. You get that, rather than a sizing guess.
- Private model updates
- A build pinned for you, so an improvement to the public weights does not change your output on a day you were not expecting it.
- A named contact and an agreed response time
- Written into the agreement. We do not publish a service level we have not committed to, so the number is one we agree with you rather than one you read here.
- Invoicing that your finance team accepts
- Card, or bank transfer in birr against an invoice. The hosted product is prepaid credits, and an organization that cannot pay by card does not have to.
Start a conversation
Tell us what the audio is and where it has to stay
A person reads these and replies. Three fields are required and the rest save a round trip, so answer what you know and leave the rest.
Edges
The questions a procurement review asks
Including the one about whether we will still be here, which is a fair thing to ask a company this size.
Evaluate it first, then tell us what it got wrong
Build the image, run it on your own recordings, and bring us the cases where it failed. That conversation is far more useful than a demo, and it is the one that tells us whether a fine-tune is worth your money.