HRBench Guide: Thinking-Mode Switching in Hybrid LLMs

The emergence of reasoning-oriented Large Language Models (LLMs)—including OpenAI o1, DeepSeek-R1, and Qwen-3.5—has demonstrated the extraordinary power of test-time compute. By generating extensive internal Chain-of-Thought (CoT) sequences before emitting final answers, reasoning models achieve breakthrough accuracy on competitive mathematics, complex systems architecture, and automated software engineering tasks. In high-concurrency production workflows powered by AI Fetchly, reasoning capabilities allow agents to resolve nuanced user intents with superhuman fidelity.
However, deploying static reasoning models in commercial production introduces a severe economic and latency dilemma: the all-or-nothing reasoning trap. Under standard serving, a model configured in Full-Think mode expends thousands of tokens analyzing trivial conversational queries (such as greeting a user or retrieving a static database entry), wasting over 80% of serving budgets. Conversely, forcing the model into No-Think mode disables reasoning entirely, causing catastrophic accuracy collapse on non-trivial logic puzzles and coding bugs.
To achieve adaptive compute allocation, the community developed hybrid-reasoning LLMs that support dynamic thinking-mode switches. Yet, despite dozens of published techniques, the field lacked a unified benchmark to compare how different switching strategies behave across model scales. To resolve this, researchers from HKUST and Tsinghua University introduced HRBench: Benchmarking and Understanding Thinking-Mode Switch Strategies in Hybrid-Reasoning LLMs (arXiv:2605.28398, usail-hkust/HRBench).
HRBench establishes the first systematic taxonomy of thinking-mode switching, crossing three strategy families (Prompt-Tuning, External Routing, and Speculative Execution) with four training regimes (Training-Free, SFT, DPO, and GRPO) across six foundation models spanning 2B to 1.1T parameters (including Qwen3.5, Seed-OSS-36B, and Kimi-K2.5). In this technical guide, we dissect the findings of HRBench, analyze the trade-off mechanics between token cost and benchmark accuracy, implement a production hybrid router in Python, and map out architectural rules for enterprise deployment.
The All-or-Nothing Reasoning Dilemma in Enterprise Serving
To understand why hybrid thinking-mode switching is essential, we must examine the operational cost profile of fixed-mode reasoning models.
The Over-Thinking vs. Under-Thinking Tradeoff
In production enterprise environments, incoming user queries exhibit a broad spectrum of difficulty:
The Query Complexity Spectrum in Production:
┌────────────────────────────────────────────────────────────────────────┐
│ Level 1: Trivial Queries (60% of volume) │
│ "Convert this timestamp to UTC", "Summarize this 10-line email" │
├────────────────────────────────────────────────────────────────────────┤
│ Level 2: Moderate Synthesis (25% of volume) │
│ "Extract specific fields from nested JSON and reconcile IDs" │
├────────────────────────────────────────────────────────────────────────┤
│ Level 3: Deep Multi-Step Deduction (15% of volume) │
│ "Verify algebraic proofs for this crypto protocol, optimize SQL AST" │
└────────────────────────────────────────────────────────────────────────┘ When serving these queries with fixed baselines:
- Full-Think (Static Over-Thinking): The model applies exhaustive Chain-of-Thought across all queries. For a Level 1 query that requires only 50 tokens to answer, the model generates 4,000 tokens of internal rumination. This inflates latency from 200ms to 8 seconds and drains cloud GPU budgets.
- No-Think (Static Under-Thinking): The model generates direct answers without scratchpad reasoning. While fast and cheap for Level 1, accuracy on Level 3 queries collapses from 85% to less than 20%.
- Static Rule-Based Gating: Simple regex or keyword heuristics fail because query length does not correlate with intrinsic reasoning complexity: a concise 10-word math puzzle can require 10,000 reasoning tokens, while a 2,000-word legal document may only require simple text extraction.
When building multi-agent workflows that interact with data fetching APIs, dynamic compute allocation ensures that routine API data parsing executes with sub-second response times while complex data synthesis triggers deep analytical reasoning.
The HRBench Taxonomy: 3 Strategy Families x 4 Training Regimes
HRBench organizes the vast space of thinking-mode switching along two formal axes: strategy families and training paradigms, yielding a comprehensive 12-cell evaluation matrix.
The HRBench 3x4 Evaluation Matrix:
┌─────────────────────┬───────────────────┬──────────────┬──────────────┬──────────────┐
│ Strategy Family │ Training-Free │ SFT │ Offline DPO │ Online GRPO │
├─────────────────────┼───────────────────┼──────────────┼──────────────┼──────────────┤
│ 1. Prompt-Tuning │ S1 / TALE-EP │ OThink-R1 │ AdaR1 │ ACPO / HGPO │
│ 2. External Routing │ Rule Classifier │ SFT Router │ DPO Router │ AdaptThink │
│ 3. Speculative Exec │ Output Entropy │ ADR Policy │ DPO Re-think │ RL Escalator │
└─────────────────────┴───────────────────┴──────────────┴──────────────┴──────────────┘ 1. Prompt-Tuning (PT): Self-Guided Single-Pass Execution
In Prompt-Tuning strategies, the foundation model itself determines whether and how deeply to reason during a single forward inference pass via prompt conditioning:
- Mechanism: Prompts inject token-budget instructions or complexity-aware meta-prompts (e.g., “Evaluate problem difficulty and decide whether to think before answering”).
- Training Regimes: Ranges from training-free budget forcing (S1, TALE) to RL-aligned policy gradients (ACPO) that train the model’s internal mode-selection head.
- Characteristics: Zero external model dependency; achieves the most favorable token-accuracy Pareto tradeoff on frontier models ($>30\text{B}$ parameters).
2. External Routing (RT): Classify-Then-Generate
External Routing adopts a two-stage pipeline where a lightweight secondary classifier inspects the user query before dispatching it to the main model:
- Mechanism: An external classifier (such as a BERT encoder, a compact 1B LLM, or a GRPO-trained router like AdaptThink) classifies the query difficulty into discrete tiers (
no_think,low_think,full_think). - Characteristics: Highly consistent and predictable cost reduction. Reduces total serving tokens by up to 45% with near-zero latency overhead, making it ideal for small-to-medium foundation models.
3. Speculative Execution (Spec): Dynamic Escalation on Uncertainty
Speculative switching starts generation in fast no_think mode and dynamically switches to deep reasoning upon detecting runtime uncertainty signals:
- Mechanism: During decoding, if token-level entropy or top-2 probability margin exceeds a calibrated threshold, generation halts, and the model re-executes the query in
full_thinkmode. - Characteristics: Maximizes peak accuracy on edge cases, but incurs additional token overhead due to discarded speculative prefixes.
Key Empirical Findings Across Models (2B to 1.1T Parameters)
HRBench evaluated all 12 configurations across five rigorous benchmarks: AIME 2025, MATH500, GPQA-Diamond, LiveCodeBench, and Codeforces, testing models from Qwen3.5-2B/9B to Seed-OSS-36B, DeepSeek-V3.1-671B, and Kimi-K2.5-1.1T.
Finding 1: Strategy Effectiveness is Strongly Scale-Dependent
One of the most consequential insights from HRBench is that the optimal switching strategy inverts based on model parameter scale:
- Small Models (2B to 9B): Prompt-Tuning fails because small models lack the meta-cognitive calibration to accurately assess their own competence. Self-prompting actually increases token cost by $+9.8%$ at 2B scale. For small models, External Routing (RT) is strictly superior, achieving stable $-13%$ to $-22%$ token reductions.
- Frontier Models (36B to 1.1T): At large scales, the model’s internal self-assessment becomes highly accurate. Prompt-Tuning (PT) achieves dramatic token savings (-39% at 36B, -17% at 1.1T) with virtually zero accuracy loss, outperforming external classifiers.
Token Savings Across Model Scales (HRBench Empirical Data):
Model Scale: 2B Model 9B Model 36B Model 1.1T Model
Prompt-Tuning: +9.8% (Worse) -4.2% -39.1% (Best!) -17.4% (Best!)
External Routing: -13.2% (Best!) -22.5% (Best!) -45.2% (Stable) -17.1% (Stable)
Speculative Exec: +15.4% (Extra) +12.1% (Extra) +6.4% (Extra) +2.1% (Extra) Finding 2: Training Regimes Matter More Than Architecture
Training-free prompt heuristics (e.g., S1 budget forcing) suffer from severe sensitivity to prompt phrasing. Conversely, reinforcement learning via GRPO aligns mode selection with true problem difficulty, ensuring that token reductions come exclusively from solved trivial queries rather than prematurely cut reasoning chains.
End-to-End Implementation: Building an Adaptive Hybrid Router
Let us build a production-grade, extensible Python implementation of a hybrid thinking-mode router that incorporates external difficulty classification and dynamic mode dispatch.
import re
from typing import Dict, Any, Tuple
import torch
import torch.nn as nn
import torch.nn.functional as F
class HybridReasoningRouter(nn.Module):
"""
Production Hybrid-Reasoning Router inspired by HRBench (arXiv:2605.28398).
Dynamically classifies query difficulty and selects thinking mode:
0: NO_THINK (Direct Generation)
1: LOW_THINK (Concise 500-token CoT)
2: FULL_THINK (Exhaustive Deep Reasoning)
"""
MODE_NAMES = {0: "NO_THINK", 1: "LOW_THINK", 2: "FULL_THINK"}
def __init__(self, feature_dim: int = 256):
super().__init__()
self.classifier = nn.Sequential(
nn.Linear(feature_dim, 128),
nn.ReLU(),
nn.Linear(128, 3)
)
def forward(self, query_embedding: torch.Tensor) -> Tuple[int, Dict[str, float]]:
"""
Classifies query into discrete thinking mode.
Args:
query_embedding: [1, FeatureDim] encoded query representation.
Returns:
Tuple of (selected_mode_int, mode_probabilities_dict).
"""
logits = self.classifier(query_embedding) # [1, 3]
probs = F.softmax(logits, dim=-1).squeeze(0)
selected_mode = torch.argmax(probs).item()
prob_dict = {
self.MODE_NAMES[i]: round(probs[i].item(), 4)
for i in range(3)
}
return selected_mode, prob_dict
class HybridServingEngine:
"""
Inference Dispatcher formatting prompts and parameters based on selected mode.
"""
def __init__(self, router: HybridReasoningRouter):
self.router = router
def format_request(self, query: str, mock_embedding: torch.Tensor) -> Dict[str, Any]:
"""
Routes query and generates engine configuration for vLLM or SGLang.
"""
mode_id, mode_probs = self.router(mock_embedding)
mode_name = HybridReasoningRouter.MODE_NAMES[mode_id]
if mode_name == "NO_THINK":
prompt = f"Question: {query}\nDirect Answer:"
max_tokens = 512
stop_tokens = ["\n\n"]
elif mode_name == "LOW_THINK":
prompt = f"Question: {query}\n<think>\nProvide brief step-by-step logic under 500 tokens.\n</think>\nAnswer:"
max_tokens = 1024
stop_tokens = ["<end_of_thought>"]
else: # FULL_THINK
prompt = f"Question: {query}\n<think>\nAnalyze exhaustively, verify all edge cases, and self-correct any contradictions.\n</think>\nFinal Solution:"
max_tokens = 8192
stop_tokens = []
return {
"mode": mode_name,
"probabilities": mode_probs,
"formatted_prompt": prompt,
"max_tokens": max_tokens,
"stop_tokens": stop_tokens
} Functional Validation Harness
Let us verify our hybrid routing engine across simulated query embeddings:
def verify_hybrid_routing():
torch.manual_seed(42)
dim = 256
router = HybridReasoningRouter(feature_dim=dim)
engine = HybridServingEngine(router)
# Simulate a user query
test_query = "Prove that every positive integer greater than 1 has a unique prime factorization."
test_emb = torch.randn(1, dim)
print('Routing simulated query...')
req = engine.format_request(test_query, test_emb)
print(f'Selected Mode: {req["mode"]}')
print(f'Mode Probabilities: {req["probabilities"]}')
print(f'Allocated Max Tokens: {req["max_tokens"]}')
assert req["max_tokens"] in [512, 1024, 8192]
print('Verification Succeeded: Hybrid routing executed with zero errors!')
if __name__ == '__main__':
verify_hybrid_routing() When designing enterprise intelligence platforms that integrate with custom backend endpoints, deploying an adaptive hybrid router guarantees that simple API lookups return instantly while complex queries receive deep reasoning.
Production Benchmarks: Token Cost vs. Accuracy Tradeoffs
The table below reports measured benchmark accuracy (Pass@1 %) and average token consumption per query across Qwen3.5-9B and Seed-OSS-36B on the comprehensive HRBench evaluation suite:
| Model & Strategy | Training Regime | AIME 2025 Acc | MATH500 Acc | LiveCodeBench | Avg Tokens / Query | Token Cost Reduction |
|---|---|---|---|---|---|---|
| Qwen3.5-9B (Full-Think) | Baseline | 34.2% | 83.6% | 68.4% | 4,820 tok | 0.0% (Baseline) |
| Qwen3.5-9B (No-Think) | Baseline | 12.5% | 48.2% | 34.1% | 420 tok | -91.3% (Accuracy Loss) |
| Qwen3.5-9B + Prompt-Tuning | Training-Free (S1) | 31.8% | 79.4% | 62.5% | 4,610 tok | -4.3% |
| Qwen3.5-9B + Routing (RT) | GRPO (AdaptThink) | 33.8% | 82.9% | 67.8% | 3,735 tok | -22.5% (Optimal for 9B) |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Seed-OSS-36B (Full-Think) | Baseline | 48.6% | 91.2% | 76.5% | 6,240 tok | 0.0% (Baseline) |
| Seed-OSS-36B + Routing (RT) | GRPO | 47.9% | 90.5% | 75.8% | 3,420 tok | -45.2% |
| Seed-OSS-36B + PT | GRPO (ACPO) | 48.4% | 91.0% | 76.2% | 3,798 tok | -39.1% (Optimal for 36B) |
Token Cost vs Accuracy Tradeoff (Seed-OSS-36B Serving):
Full-Think Baseline: [████████████████████] 6,240 tok (48.6% Acc)
Routing (GRPO): [███████████ ] 3,420 tok (47.9% Acc, -45.2% Cost!)
Prompt-Tuning (GRPO):[████████████ ] 3,798 tok (48.4% Acc, -39.1% Cost!) By deploying an aligned hybrid switching strategy, organizations eliminate nearly half of their inference compute expenditure while maintaining within 0.2% to 0.7% of peak frontier reasoning accuracy.
Organizations evaluating infrastructure cost reductions and cloud compute allocations can explore flexible pricing structures to calculate ROI when migrating from static Full-Think clusters to hybrid serving.
Production Deployment Guide: Deploying Hybrid Serving with vLLM
HRBench provides reference implementations integrated with vLLM and verl (github.com/usail-hkust/HRBench):
# 1. Clone the HRBench evaluation and serving repository
git clone https://github.com/usail-hkust/HRBench.git
cd HRBench && pip install -r requirements.txt
# 2. Launch high-throughput server with dynamic mode switching
python3 -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen3.5-9B \
--enable-reasoning \
--reasoning-parser deepseek_r1 \
--port 8000 Engineering teams can consult the full developer documentation for detailed configuration manifests, verl RL training scripts, and multi-node Tensor Parallelism parameters.
Key Takeaways and Architectural Summary
- The End of Static CoT: Static Full-Think serving wastes over 80% of token budgets on simple queries. Hybrid thinking-mode switching is mandatory for enterprise scale.
- Three Strategy Families: Prompt-Tuning (self-guided), External Routing (classify-then-generate), and Speculative Execution (dynamic escalation) form the foundational design space.
- Scale Dictates Strategy: Use External Routing for smaller models (2B–9B) where self-assessment fails; use Prompt-Tuning for frontier models (36B–1.1T) where meta-cognitive calibration is strong.
- RL Training is Paramount: GRPO alignment significantly outperforms training-free heuristics, ensuring that token reductions target solved trivial problems without truncating hard proofs.
- 45% Cost Reduction with Zero Regret: Hybrid switching preserves peak Olympiad-level reasoning accuracy while slashing token costs by nearly half across production workloads.
HRBench establishes the definitive roadmap for hybrid reasoning, unlocking cost-effective, high-intelligence AI serving across every enterprise scale.