AutoArk/GPA: one autoregressive model for ASR, TTS and (later) voice conversion

What GPA actually unifies, and for whom

The name is an analogy the authors make explicit: a student's GPA collapses performance across unrelated subjects into one number, and GPA the model collapses speech recognition, text-to-speech and voice conversion into one auto-regressive transformer. The README's abstract states that GPA-v1.5 delivers near-SOTA performance on ASR and TTS in a single unified model, with VC support on the roadmap. That sentence is the honest scope. Two of the three headline tasks ship today.

The audience is narrower than the tagline suggests. This is for engineers who already run speech models and are tired of maintaining separate ASR and TTS stacks, separate preprocessing, and two sets of checkpoints. It is not aimed at someone who wants a hosted endpoint. The repository is a training and inference codebase: pyproject.toml names the project gpa-training, and the dependency list includes deepspeed, peft, bitsandbytes and vllm. That is a fine-tuning and serving toolkit, not a product.

The architecture as the repository presents it

GPA is described as an autoregressive audio-language model that handles both understanding and generation. Figure 1 in the README is captioned exactly that way: speech understanding and generation in one autoregressive audio-language model. The practical consequence is that ASR and TTS share one parameter set and one token space rather than being two models glued behind a router.

The repository splits the work across directories. GPA_1.5/ holds the mainline release with its own README, a training guide at GPA_1.5/docs/train.md and an inference guide at GPA_1.5/docs/infer.md. GPA_1.5/onnx_runtime/ holds a separate runtime guide. GPA_TTS/ is a standalone extraction of the synthesis component. The top level also carries data_utils/, models/, scripts/ and docs/, plus an old GPA-v1.0 document at docs/GPA-v1.0.md.

There are two deployment surfaces. The native path runs the checkpoint directly through PyTorch and Hugging Face, and the training guide points at the Hugging Face Trainer for fine-tuning and continued training. The ONNX path provides CLI inference, a FastAPI service, a browser UI and voice registration. The roadmap lists torch, vllm, llama-cpp, sglang and mlx-lm as supported frameworks; rknn is marked as not done.

Installing GPA-v1.5 and running a first inference

The repository ships two dependency files with different purposes. requirements.txt is described in its own header as core dependencies and is platform-agnostic. pyproject.toml declares the project as gpa-training and adds the training and serving stack on top. It requires Python 3.10 or newer.

For a training or fine-tuning environment, install from the project metadata:

pip install -e .

That pulls torch>=2.1.0, transformers>=4.57.0, deepspeed, peft, bitsandbytes and vllm>=0.6.0, among others. Note that flash-attn is commented out in the dependency list, and the uv extra-build-dependencies section only wires flash-attn to torch. If you want flash attention, the project leaves enabling it to you.

For an inference-only machine, the lighter list is the one to start from:

pip install -r requirements.txt

This installs torch, torchaudio, torchcodec, transformers, librosa, soundfile and soxr without deepspeed, vllm or bitsandbytes. The README does not give a one-line inference command at the top level. It points instead at GPA_1.5/docs/infer.md for the native path and at GPA_1.5/onnx_runtime/README.md for the ONNX path, and the checkpoint is published at huggingface.co/AutoArk-AI/GPA-v1.5. Read those two guides before assuming the API shape; the top-level README does not reproduce their commands.

GPA-TTS as the pragmatic deployment choice

The README is unusually candid about why GPA_TTS/ exists: TTS is by far the most popular feature in the online demo, so the authors extracted it into a self-contained runtime. The quantisation table lists Qwen INT4 plus a SparkDetokenizer in INT8, FP16 or FP32, all through ONNX Runtime. Decoder precision is selectable at runtime, with INT8 positioned for edge, FP16 as balanced and FP32 as highest quality.

Voice cloning is zero-shot from a short reference audio clip. The stated target is local CPU inference on Mac, Linux and edge hardware, and the authors claim it is among the smallest open-source TTS runtimes with cloning support. That claim is theirs, not something this article can verify. The FP16 and FP32 decoders arrived in a 2026.04.07 announcement, described as more stable and higher quality than INT8 for users with compute headroom.

If your goal is synthesis only, this is the smaller surface. You avoid the unified model's VRAM requirement and the vLLM dependency entirely, and you get a precision knob that the unified checkpoint does not expose in the same way.

Where GPA is the wrong tool

Voice conversion is the clearest gap. The roadmap table marks the native v1.5 VC path as not done, and the abstract says VC support is on the roadmap. The repository topic list includes vc, which will mislead anyone who reads topics before reading the roadmap. If conversion is your requirement, this project does not meet it yet.

Deployment maturity is the second gap. The roadmap marks basic service deployment via vLLM or FastAPI as not done, even though vllm>=0.6.0 sits in the dependency list and the ONNX runtime already exposes a FastAPI service. The dependency list and the roadmap disagree, which suggests the native serving path is not considered finished. There is also no interactive demo: the badge reads coming soon, and the ModelScope listing is likewise marked coming soon.

Finally, the top-level README does not reproduce inference commands. It routes you to per-directory guides. If you are evaluating this on a time budget, budget for reading four documents, not one, and expect the v1.0 material at docs/GPA-v1.0.md to describe an older checkpoint that no longer matches the mainline.

How this differs from a two-model ASR plus TTS pipeline

The conventional alternative is to pair a dedicated recognition model with a dedicated synthesis model, each with its own preprocessing, tokenizer and checkpoint lifecycle. That arrangement is well understood and each half can be swapped independently. GPA's difference is that one auto-regressive model produces both, so the token vocabulary and the audio front end are shared. Whether that is better depends on what you are optimising: a two-model pipeline lets you upgrade the recognition half without retraining synthesis, while a unified checkpoint forces you to take both at once.

Within the project there is a second, smaller alternative. GPA-TTS is the same synthesis capability without the unified model, quantised for CPU. Choosing between GPA-v1.5 and GPA-TTS is really a question of whether you need recognition in the same process. If you do not, the ONNX runtime is the leaner target and the INT8 decoder is the one aimed at edge hardware.

Licence, maintenance and the cost of upgrading

The repository carries an Apache-2.0 licence at the top level, which permits commercial use and modification with the usual notice and patent terms. That is the permissive end of the spectrum, and it is a genuine reason to prefer this over a research-only release. It is not legal advice; check the LICENSE file and the checkpoint's own terms on Hugging Face, since model weights can carry conditions the code licence does not.

On maintenance, the last push was on 2026-05-25, which is under six months before today. The repository is not archived. The announcement history shows a steady cadence through the first half of 2026: GPA-TTS on 2026.03.31, FP16 and FP32 decoders on 2026.04.07, and GPA-v1.5 with its ONNX runtime on 2026.04.29. There are no releases retrieved, so versioning is by directory and announcement date rather than by tagged release.

The upgrade cost is real. GPA-v1.0 documentation was moved to docs/GPA-v1.0.md and describes the GPA-0.3B-preview checkpoint. Anyone on that preview has to migrate to v1.5 to stay on the mainline, and the v1.5 guides are separate documents with their own API. If you fine-tuned the preview, assume the fine-tune does not carry over.

Editorial conclusion

Adopt GPA-v1.5 if you want a single Apache-2.0 checkpoint covering both recognition and synthesis, and you are willing to run the ONNX runtime or the native PyTorch path yourself. Do not adopt it if voice conversion is the requirement today: the roadmap marks the native VC path as not done, and the model card lists VC as on the roadmap. Before committing, check the Hugging Face checkpoint size, confirm the ONNX runtime bundle downloads, and read GPA_1.5/docs/infer.md to see whether your audio format is accepted without resampling.

Frequently asked questions

Official sources

1. AutoArk/GPA on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README