Teams from Tsinghua and others have released TokenRouter, which helps small and large AIs collaborate on writing the same answer: the small model writes first, and when the system determines that the large model is needed, it hands off to the large model to continue writing, after which it can even pass back to the small model. You can think of it as an assistant and an expert working together, with the expert not having to handle everything from start to finish.

Official introduction: https://fuvty.github.io/thinking_yard_project_page/projects/tokenrouter/…

But frequent handoffs between the two AIs can also waste time. What TokenRouter does is reduce these waits, allowing the same device to generate more content per second. The authors used the Qwen3-0.6B and 32B models, sharing two A100 80GB GPUs (CUDA MPS), to process 8 requests simultaneously: with the R2R collaboration scheme, the total content generated per second across all requests increased from about 135 tokens in the original program to 372 tokens, which is 2.76 times more. Tokens can be roughly understood as small chunks of text, but not equivalent to a single Chinese character. This number refers to the total output when serving multiple users at once, and does not mean that each person gets their answer 2.76 times faster.

Paper: https://arxiv.org/html/2610.12242v1…

The code has been made public, and the authors tested five different collaboration schemes for small and large models. Developers can use it to build their own collaboration services and decide when to hand off to which model.

Code: https://github.com/thu-nics/TokenRouter…

TokenRouter · A serving engine for token-level LLM routing

Source: https://fuvty.github.io/thinking_yard_project_page/projects/tokenrouter/ A serving engine for token-level LLM routing.

The opportunity

One response. Different models.

Token-level routing lets small and large models collaborate within a single response. The serving engine must keep up with every switch.

Where does routing happen?

Model assignment at three granularities

Turn 1 · Token 1

Illustrative model assignments for three turns of one session; not a measured generation trace.### Independent progress.

A fast model should keep decoding while a slower peer handles routed tokens.

Useful batches.

Irregular token arrivals need a scheduler that brings requests together at the right time.

A simple interface.

The routing policy describes one request. The runtime manages batching, handoff and cache state.

The engine

Each model moves at its own pace.

Request-centric programming. Model-centric execution.

One serving endpointRequest admission & streaming

S

Small model

Entry subserver

SchedulerLLM runnerRouter

Decoding

ABC

Step 1

Local KV cacheRequest A · runningA

send / receive

Token suffix + routing state

L

Large model

Peer subserver

SchedulerLLM runnerRouter

Decoding

Idle

—

Local KV cacheIndependent model state

Decode a local batch.

The small model advances requests A, B and C in one batch.

Decode

Illustrative handoff; animation speed does not represent model latency. Each subserver has its own decoding loop. Only token suffixes and routing state travel between models; KV caches stay local. The architecture extends to more than two models.Client–server loopAdmit requests and stream completed tokens.

Decoding loopSchedule local batches and execute model steps.

Inter-model loopSend, receive and resume routed requests.

Resume without starting over.

A pending request keeps its serving state and KV slot. Returning tokens are appended without repeating prefix matching or KV allocation.

RunningPendingRunningor finished

Programming interface

Three functions. One routing policy.

Describe when a request changes models, what travels with it, and how decoding resumes.

route(batch, result)

Choose the next model.

After each forward pass, return one model name per request. Returning the current model name continues local decoding. Existing two-model schedulers also accept Boolean decisions.

R-Stitch example: True delegates to the only peer; False keeps decoding locally.

R-Stitch excerpts from thereleased implementation. Configuration and surrounding class definitions are omitted.

Five evaluated policies, the same interfaceThe released code also includes GlimpRouter, query-level routing and a random baseline. See thesupported schedulers.

Quick startInstall from source and launch an R2R server with the Qwen3 0.6B / 32B configuration.

git clone https://github.com/thu-nics/TokenRouter.git
cd TokenRouter
conda create -n tokenrouter python=3.10
conda activate tokenrouter
pip install -e .
python -m tokenrouter.launch_server \
  --config_path config/r2r/Qwen3-0.6B_Qwen3-32B.yaml

Once the server is running, use theOpenAI client exampleor therequests example. ThePython engine exampleruns directly without a separate HTTP server.

TheREADMEcovers multi-node serving; thereproduction guideincludes configurations, workloads and benchmark commands.

Delayed batching

A small wait. A better batch.

Starting immediately can leave the next arrival waiting for a whole decoding step. A short, controlled wait brings routed requests into the same batch.

Same tokens. Different schedules.

Three requests · five tokens per request

Scheduling timelineA conceptual comparison of four execution strategies.

t = 0.0

Small model

Ready

Large model

Idle

Completed

0 of 3 requests

**—**Mean completion time

Fixed routing sequences and latencies from the paper’s scheduling example. Each block is one token; shared start times indicate a batch. Delayed batching uses Bsmall= 1 and Blarge= 2.Measured threshold sweep

The threshold matters.

A larger batch is useful until waiting leaves too little work in flight. The best threshold depends on concurrency and routing behavior.

Throughput · output tokens/s

R2R · Qwen3-0.6B / 32B · AIME2024. Measured values from the supplied threshold sweep. How is the threshold selected?A discrete-time Markov chain models queued requests, active batches and remaining execution time for each subserver. Given concurrency, routing probabilities and model step latencies, TokenRouter searches the feasible thresholds for the highest expected throughput.

B* = arg maxBE[committed tokens] / E[elapsed time]

The condition ∑i(Bi− 1) < N avoids a state where all requests wait in queues. The analytical model assumes stationary routing probabilities and fixed per-step model latencies; it does not model every nonstationary routing pattern.

Serving efficiency

Routing gains. Delivered in tokens per second.

Five algorithms, three workloads, and two baselines. TokenRouter accelerates the system that executes the routing policy.

High-effort reasoning

Concurrency 4 · output tokens/s · higher is better

Official CodeStd. ServingTokenRouter

Ratios compare TokenRouter with the stronger available baseline for each algorithm. All bars share a linear scale starting at zero.Exact values for this selectionModels, workloads and measurement setup### Models & hardware

CITER, R2R, R-Stitch and Co-LLM use Qwen3-0.6B / 32B. ME adds Qwen3-8B, with weights 0.5 / 0.3 / 0.2.

Experiments use an 8 × A100-80GB host. Two-model runs share two GPUs via CUDA MPS: the small model uses TP1 and the large model TP2. ME places each model on one GPU.

Workloads

**Low-effort:**AIME2024, ~100-token inputs and a 2,048-token output cap.

**High-effort:**selected AIME2024 problems, ~100-token inputs and an 8,192-token output cap.

**Agentic:**multi-turn SWE-Smith trajectories, ~8,192 input tokens and a 1,024-token output cap.

Baselines & metrics

**Official Code:**the algorithm’s released implementation. Unavailable entries are shown as N/A.

**Std. Serving:**one SGLang server per model, returning one token per call to an external dispatcher.

Throughput is total generated output tokens divided by elapsed time. Latency is end-to-end request completion time. TokenRouter builds on SGLang 0.5.1.

Scaling concurrency

More throughput. Responsive generation.

As concurrency grows, asynchronous execution turns more in-flight requests into useful model work.

Generation speed vs. total throughput

R2R · concurrency 1–16

TokenRouterR2R official

Throughput and per-user generation speedTokenRouter and the official R2R implementation across concurrency levels one through sixteen.Concurrent requests8

Each point is a measured concurrency setting; lines connect settings in order. Speed is per-user token generation rate. Throughput aggregates all requests.18.58×

Throughput with comparable per-user speed.

TokenRouter at concurrency 16 reaches 630.57 tokens/s and 39.41 tokens/s per user. R2R official at concurrency 1 reaches 33.94 tokens/s and 34.87 tokens/s per user. This comparison uses different concurrency levels.

Inside the gains

The runtime matters at every step.

CUDA graph support, asynchronous execution and delayed batching build on one another.

Cumulative system optimizations

R2R · concurrency 8

Output tokens/s

Each row includes the preceding optimizations. The official R2R implementation reaches 134.90 tokens/s; the complete engine reaches 372.48 tokens/s (2.76×). These are sequential ablations, not independent additive effects.### Extend CUDA graphs.

Capture a wider range of extend lengths encountered when a routed request resumes.

Keep routing local.

Run the router alongside the model to avoid a separate IPC round trip on every token.

Preserve serving state.

Retain pending requests and coordinate the KV budget across colocated models.

Different small / large model pairsAcross nodes, with the same model resourcesQwen3-0.6B uses one GPU and Qwen3-32B uses two GPUs (TP2), without GPU overlap. Models are deployed on one or two nodes connected by 3.7 GB/s RoCE. The following measurements use low-effort reasoning.

Algorithms in their original model and task settings Team

Meet the researchers.

*Equal contribution†Corresponding author

Citation

Cite our work.

@article{fu2026tokenrouter,
  title={TokenRouter: Efficient Serving System for Token-Level LLM Routing},
  author={Tianyu Fu and Tengxuan Liu and Ruoxi Wang and Yixin Dong and Yi Ge and Yichen You and Yu Wang},
  journal={arXiv preprint arXiv:2610.12242},
  year={2026},
}

Tianyu Fu (@fuvty123): 🔥 TokenRouter is out! Efficient token-level LLM routing, now ready for serving.

🚀 2.01–64.15× higher throughput vs. serving baselines ✍️ Just 3 functions: send, receive, route

Bring your routing algorithm. We handle the serving.