OpenNMT / OpenNMT/CTranslate2

Ideas for better performance

Open
#1,140 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
4.7k
Forks
537
Avg merge
12h 12m
Merged PRs (30d)
4

Description

Hello.
So, I want to run NLLB-200 (3.3B) model on a server with 4x 3090, and a say, 16 core AMD Epyc cpu.
I wrapped Ctranslate2 in fastAPI, running with uvicorn, inside a docker container with GPU support.

All code is here, feel free to do whatever with it:
https://github.com/hobodrifterdavid/nllb-docker-rest

I want to handle requests with between 1 and 1000 sentences, with a reasonable balance between latency and throughput.

Here's a few things I did, from reading the documentation:

for ctranslate2.Translator:

device='auto', # May use CPU for very small translations?
compute_type="float16",
device_index=[0, 1, 2, 3]

for translator.translate_batch:

max_batch_size=256 # Bigger than this I get Cuda OOM errors.

I tried to use translate_batch with asynchronous=True, but couldn't figure out easily how to await the results (EDIT: figured it out, added results below)

uvicorn is run without the --workers flag, so, defaults to a python process, a single model loaded into GPU ram. FastAPI accepts up to 40 concurrent requests.

Anyway, I'll carry on trying to improve this setup, will post further results. If there are some suggestions for something I missed, it would be appreciated. Python is not my first langauge, please excuse naive errors.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked nllb-docker-rest setup and the Translator and translate_batch configuration described in the issue. Measure latency and throughput across request sizes and concurrency, then use the results to define a specific performance change; no project files or tests are named, and the issue does not establish a clear done condition.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, docker, fastapi, python
Domain
api, backend, machine-learning, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.