Processing speed benchmark (CPU/GPU)

The processing speed of Bareun depends on the execution environment (CPU/GPU), batch configuration, sentence length, and number of concurrent requests. Rather than fixing absolute numbers, this document explains what determines speed and how to measure it fairly. The same analyzer can give very different results in different environments, so we recommend running benchmarks yourself in your own environment.

What determines speed

Factor	Setting/characteristic	Effect
Execution provider	`executionProvider` (cpu/gpu, etc.)	GPU is better for high-volume and long-sentence throughput
Batch processing	Send multiple sentences at once with `AnalyzeSyntaxList`	Reduces per-call overhead
Sentence length	Segmentation processes text in 160-character units	Long sentences are split, which adds steps
Concurrent requests	Server concurrency and hardware	Directly affects throughput
Model stages	Two inference stages: segmentation → tagging	Balance between accuracy and speed

Choosing an executionProvider

Bareun runs inference with ONNX Runtime, and you can choose an execution provider such as CPU or GPU with executionProvider in bareun.json. If the GPU provider fails, the server automatically falls back to CPU, so it runs safely in any environment.

CPU or GPU: which to choose

CPU: Simple to set up and suited to small-volume, real-time single requests. A good fit when single-request latency matters.
GPU: Good for raising throughput on high-volume batch processing and long documents. The benefit is larger when you analyze many sentences at once.

If throughput matters, it is better to bundle multiple sentences with AnalyzeSyntaxList than to repeat single requests. This reduces the communication and initialization overhead of each call. If responses are slower than expected, check the items in When responses are slow.

Fair measurement methodology

For a benchmark to be meaningful, control the following.

graph TD
  A[Define the goal: latency vs throughput] --> B[Fix the input: same corpus and sentence-length distribution];
  B --> C[Fix the environment: CPU/GPU, core count, memory];
  C --> D[Warm up, then measure multiple times];
  D --> E[Report mean and percentiles + state the environment];

What you measure: Decide first whether you are measuring single-request latency or throughput (eojeol (a space-delimited word unit) or sentences per second).
Fix the input: Measure with the same corpus and a similar sentence-length distribution. Comparisons are meaningless if the input differs.
Fix the environment: Record the CPU/GPU type, core count, memory, and number of concurrent requests.
Warm up: The first call is slow because of model loading and initialization, so exclude it, repeat several times, and look at the mean and percentiles.
State the environment: Always write down the measurement environment along with the results.

Absolute numbers depend on the environment

Absolute numbers such as "eojeols per second" vary greatly with hardware, batching, sentence length, and concurrency. To compare Bareun with other analyzers fairly, measure again with the same input, hardware, and method. This document does not guarantee any specific absolute number.

When responses are slow — Causes of slowdowns and how to check
How was the 99.6% accuracy measured? — Assumptions behind the accuracy measurement
Morphological analysis API — Batch calls with AnalyzeSyntaxList

Frequently asked questions

Q. Is Bareun fast enough on a CPU?

A CPU is fine for small-volume, real-time single requests. If you have many large batches or long documents, raise throughput with a GPU provider and batched input. The right setup depends on your workload.

Q. How do I increase processing speed?

Choose executionProvider to match your environment, bundle multiple sentences with AnalyzeSyntaxList, and adjust the number of concurrent requests and the hardware to your workload. Exclude the warm-up cost of the first call from your measurements.

Q. Is it faster or slower than other analyzers?

Speed depends entirely on the measurement environment. A fair comparison is only possible with the same corpus, hardware, batching, and measurement method. Bareun delivers its accuracy (POS tagging 99.6%, eojeol segmentation/restoration 99.7%) and lets you tune speed by choosing the execution provider.

Q. Does sending requests in batches really make it faster?

Throughput goes up because the communication and initialization overhead of each call is reduced. Instead of repeating single requests, bundle multiple sentences with AnalyzeSyntaxList, and if you have many large or long documents, use a GPU provider as well. Exclude the warm-up cost of the first call from your measurements.