fastgpt vs ragflow
Short answer
FastGPT unless you need to redistribute the deployment. They score within a point of each other on parsing and retrieval, but FastGPT does it on 3.5 GB against RAGFlow's 10 GB and starts in half the time. RAGFlow's Apache 2.0 licence is the one thing FastGPT cannot match.
Measured side by side
| Measurement | fastgpt | ragflow | Better |
|---|---|---|---|
| Time to first served request | 239 s | 511 s | fastgpt |
| Containers | 13 | 5 | ragflow |
| Peak memory during ingestion | 3,478.8 MB | 9,959.6 MB | fastgpt |
| Parsing fidelity | 100% | 99% | fastgpt |
| Retrieval accuracy | 74% | 73% | fastgpt |
| Retrieval latency (p50) | 301.9 ms | 414.7 ms | fastgpt |
Both were run on the same host against the same corpus with the same embedding model, so these figures are directly comparable. Everything behind them is in the raw data.
Pick fastgpt if
- Memory is a real constraint — 3,479 MB against 9,960 MB for the same work
- You want a shorter path to a running instance: 239 seconds against 511
- Retrieval latency matters slightly: 301 ms against 414 ms at the median
Pick ragflow if
- You need to redistribute or resell a hosted deployment; RAGFlow is Apache 2.0 and FastGPT's licence forbids it
- You want a model endpoint validated at registration rather than failing later
- Fewer containers is worth more to you than less memory — five against thirteen
On accuracy there is almost nothing in it
| FastGPT | RAGFlow | |
|---|---|---|
| Documents ingested | 36/36 | 36/36 |
| Parsing fidelity | 100% | 99% |
| Retrieval accuracy | 74% | 73% |
One point on parsing, one on retrieval. On a single run with 93 questions, that is inside the noise — treat them as equivalent on quality and decide on everything else.
Everything else favours FastGPT, except the licence
| FastGPT | RAGFlow | |
|---|---|---|
| Peak memory | 3,479 MB | 9,960 MB |
| Ready to serve | 239 s | 511 s |
| Retrieval latency (p50) | 301 ms | 414 ms |
| Containers | 13 | 5 |
| Licence | prohibits SaaS | Apache 2.0 |
RAGFlow needs nearly three times the memory for the same result, because it bundles Elasticsearch, which holds several gigabytes before a document arrives. It also runs the fewest containers of the two, which is a good illustration that container count and memory are separate questions.
The licence is the one thing that overrides the rest
FastGPT’s licence permits commercial use but prohibits offering the software as a service. RAGFlow is Apache 2.0 with no restriction of that kind.
If you are building something you will host for customers, that single line outweighs the memory, the start-up time and the latency together. If you are running it for your own organisation, it costs you nothing and FastGPT is the cheaper deployment.
Rough edges on each
RAGFlow answers HTTP 200 with a small non-zero status code in the body when a call fails, so a client trusting the transport status reads a rejection as a success. Uploading a document does not start parsing — that is a separate call, without which the document sits at zero chunks indefinitely. Its login password must be RSA-encrypted with a key hard-coded in the web frontend, which is not documented for API clients. It also takes long enough to accept connections that our own harness initially recorded a failure that was ours, not RAGFlow’s.
FastGPT ships a compose file with two required values left empty, and the
app refuses to start until both are filled in — with an error that names the
variable but not the file, in a comment written in Chinese even in the
repository’s global directory. Model setup spans a bundled gateway and
FastGPT’s own catalogue, and its activation endpoint reports success on a
partial update without persisting it.