The earlier versions of vLLM Semantic Router relied on classification-based routing, a straightforward approach where user queries are classified into one of 14 MMLU domain categories, and then routed to corresponding models. While this worked for basic scenarios, we quickly discovered its limitations when building production AI systems for enterprises.

Consider this real-world scenario: A user asks, “I need urgent help reviewing a security vulnerability in my authentication code.” The classification-based router would identify this as a “computer science” query and route it to a general coding model. But it misses critical context:

This single example reveals the fundamental constraint: classification-based routing captures only one dimension of user intent—the domain—while ignoring the rich, multi-dimensional signals embedded in natural language queries.

Today, we’re introducing the Signal-Decision Architecture—a complete reimagining of semantic routing that scales from 14 fixed categories to unlimited intelligent routing decisions. This new architecture combines multi-dimensional signal extraction, flexible decision logic with AND/OR operators, and built-in plugin orchestration to deliver production-ready semantic intelligence.

The Problem: Why Classification-Based Routing Doesn’t Scale

The previous vLLM Semantic Router architecture followed a simple pipeline:

User Prompt → MMLU Domain Classification → Model Selection

This approach has several fundamental limitations that prevent it from scaling to enterprise requirements.

Single-Dimensional Analysis

Classification-based routing only considers the domain or subject matter of the query. It cannot capture:

Real Impact: A medical query about “urgent patient data breach” gets routed to a medical model but lacks PII protection and security filtering—potentially violating HIPAA compliance.

Fixed Category Constraint

Limited to 14 predefined MMLU categories (math, physics, computer science, business, etc.), making it impossible to:

Real Impact: An enterprise with 50+ specialized use cases (legal contracts, financial compliance, medical diagnostics, code security audits) cannot express their routing requirements within 14 categories.

Inflexible Logic

Cannot combine multiple conditions or implement complex routing strategies:

Real Impact: Cannot implement layered routing strategies like “high-priority security issues get reasoning + jailbreak protection, while general questions get cached responses.”

Introducing Signal-Decision Architecture

The Signal-Decision Architecture fundamentally reimagines semantic routing by separating signal extraction from routing decisions and introducing a flexible decision engine with built-in plugin orchestration.

Architecture Overview

The new architecture introduces three key innovations:

  1. Multi-Signal Extraction: Captures multiple dimensions of user intent simultaneously
  2. Decision Engine: Combines signals using flexible AND/OR logic with priority-based selection
  3. Plugin Chain: Provides built-in intelligence for caching, security, and optimization

Complete Request Flow

Core Concepts

Signals: Multi-Dimensional Prompt Analysis

Instead of relying solely on domain classification, the Signal-Decision Architecture extracts three complementary types of signals from each user query. Each signal type leverages different AI/ML techniques and serves distinct purposes in the routing decision process.

Keyword Signals: Interpretable Pattern Matching

Keyword signals use regex-based pattern matching to detect specific terms or phrases in user queries. This approach provides human-interpretable routing logic—you can easily understand why a query matched a particular rule by examining the keywords.

Technical Approach:

Key Advantage - Interpretability: Unlike black-box ML models, keyword signals provide complete transparency. When debugging routing decisions, you can trace exactly which keywords triggered which rules. This is critical for compliance auditing and troubleshooting production issues.

Use Cases:

Embedding Signals: Scalable Semantic Understanding

Embedding signals use neural embedding models to compute semantic similarity between user queries and candidate phrases. This approach provides scalable semantic matching that understands intent beyond exact keyword matches.

Technical Approach:

Key Advantage - Scalability: Embedding-based matching scales to thousands of candidate phrases efficiently. Adding new routing patterns doesn’t require retraining models—simply add new candidate phrases and compute their embeddings. This enables rapid iteration and customization for specific business domains.

Use Cases:

Domain Signals: Dataset-Driven Classification

Domain signals use MMLU-trained classification models to identify the academic or professional domain of user queries. This approach provides dataset-driven domain expertise with support for custom domain expansion.

Technical Approach:

Key Advantage - Extensibility via LoRA: While the base model covers 14 MMLU categories, enterprises can train lightweight LoRA adapters to add private domain categories without retraining the entire model. For example:

This enables organizations to extend domain classification to their specific verticals while maintaining the base model’s general knowledge.

Use Cases:

Signal Comparison

Signal Type Technique Interpretability Scalability Extensibility
Keyword Regex matching High (transparent rules) Medium (manual patterns) Manual addition
Embedding Neural embeddings Low (black-box similarity) High (thousands of phrases) Add phrases dynamically
Domain MMLU + LoRA Medium (domain labels) Medium (14+ categories) LoRA adapters for custom domains

Why Three Signal Types?

The three signal types are complementary, not redundant:

By combining all three, the Signal-Decision Architecture captures multiple dimensions of user intent simultaneously, enabling far more sophisticated routing logic than any single signal type could achieve.

Decisions: Flexible Routing Logic

Decisions are the core routing rules that combine multiple signals using AND/OR logic to determine model selection and plugin configuration.

Decision Structure

Each decision consists of:

Signal Combination: AND/OR logic combining multiple signal conditions

Priority: Integer value for conflict resolution when multiple decisions match

Model Reference: Specifies which model (and optional LoRA adapter) to use

Plugin Chain: Ordered list of plugins to apply

Decision Evaluation Flow

When multiple decisions match, the system selects the one with the highest priority. If no decisions match, the system falls back to the default model.

Plugins: Built-in Intelligence

The architecture includes five built-in plugins that can be configured per decision:

Plugin Purpose Key Features
semantic-cache Cache similar queries Configurable similarity threshold, cost optimization
jailbreak Detect prompt injection attacks Threshold-based detection, request blocking
pii Protect sensitive information Redact/hash/mask modes, GDPR/HIPAA compliance
system_prompt Inject custom instructions Replace or insert mode, role customization
header_mutation Modify HTTP headers Add/update/delete headers, metadata propagation

Plugins execute in the configured order, with each plugin able to modify the request, block execution, or add metadata for downstream processing.

Plugin Chain Execution Flow

Scaling from 14 to Unlimited

The Signal-Decision Architecture removes the fundamental constraint of fixed categories. Here’s how it scales:

Traditional Approach (Limited)

14 MMLU Categories → 14 Routing Rules → 14 Model Selections

Constraints:

Signal-Decision Approach (Unlimited)

3 Signal Types × N Conditions × AND/OR Logic → Unlimited Decisions

Capabilities:

Scalability Example

Consider an enterprise IT support system:

Traditional Routing: Limited to 14 domain-based routes

Signal-Decision Routing: Hundreds of specialized routes

Each decision can have unique model selection, reasoning configuration, and plugin chains—enabling fine-grained control at scale.

Kubernetes-Native Design

The Signal-Decision Architecture is designed for cloud-native environments with two Custom Resource Definitions (CRDs):

Complete Example: Enterprise IT Support System

Let’s walk through a complete example that demonstrates how IntelligentPool and IntelligentRoute work together to build an enterprise IT support routing system.

IntelligentPool: Define Model Pool

First, we define the available models and their LoRA adapters:

This pool defines:

IntelligentRoute: Define Routing Logic

Next, we define the routing decisions with multi-signal extraction:

This configuration demonstrates:

Multi-Signal Extraction:

Layered Decision Logic:

Plugin Orchestration:

Fallback Behavior:

Dynamic Configuration Flow

The Kubernetes-native design enables:

Real-World Applications

Enterprise IT Support

Challenge: Route support tickets based on urgency, technical domain, and security sensitivity.

Solution: Multi-layered decisions with priority-based selection

Results: Appropriate model selection, cost optimization through caching, security protection for sensitive issues.

Healthcare Platform

Challenge: HIPAA compliance requiring PII protection and medical disclaimers.

Solution: Domain-based routing with mandatory compliance plugins

Results: Automatic PII protection, consistent disclaimers, audit trail for compliance.

Financial Services

Challenge: Multi-layered security with PII protection, jailbreak detection, and cost optimization.

Solution: Comprehensive plugin chain for financial queries

Results: Enterprise-grade security, regulatory compliance, cost efficiency.

Educational Platform

Challenge: Personalized learning experiences based on subject and learning intent.

Solution: Intent-based routing with customized teaching styles

Results: Personalized teaching approaches, appropriate reasoning for complex topics, cost optimization.

Code Assistant

Challenge: Different complexity levels require different model capabilities.

Solution: Complexity-aware routing with reasoning control

Results: Optimal model selection, cost-effective reasoning usage, fast responses for simple queries.

Future Roadmap

The Signal-Decision Architecture provides a foundation for future enhancements across multiple dimensions:

Routing Core Performance Optimization

Radix Tree for Keyword Matching: Replace regex-based keyword matching with radix tree data structures to achieve faster pattern matching for thousands of keyword patterns. This will enable enterprises to define 10,000+ keyword rules with consistent performance.

HNSW Index for Embedding Search: Implement Hierarchical Navigable Small World (HNSW) graphs for approximate nearest neighbor search in embedding space. This will significantly improve embedding signal performance while supporting millions of candidate phrases.

Parallel LoRA for Decode-Only Models: Enable parallel execution of multiple LoRA adapters during the decode phase, allowing a single base model to serve multiple specialized domains simultaneously. This will reduce model switching overhead and improve throughput for multi-tenant deployments.

Feature Enhancements

Visual Configuration Console: Web-based UI for creating and managing decisions without YAML editing, with real-time validation and testing capabilities.

Custom Plugin Framework: SDK for developing custom plugins with community marketplace, enabling enterprises to build domain-specific intelligence layers.

Advanced Analytics: Real-time monitoring of decision performance, signal effectiveness, and cost optimization opportunities with ML-driven recommendations.

Model Evaluation via Multi-Turn Dialogue: Intelligent model selection through multi-turn conversation evaluation. The system automatically engages multiple candidate models in parallel conversations, using LLM-as-a-Judge to assess response quality across dimensions like coherence, relevance, safety, and domain expertise. This enables dynamic routing optimization based on actual model performance rather than static rules.

Intent-Aware Internal/External Model Selection: Smart routing between internal private models and external APIs (OpenAI, Anthropic, etc.) based on intent analysis. Sensitive data and proprietary information automatically route to internal models for privacy and compliance, while general queries leverage external APIs for broader knowledge. Cost, latency, and compliance requirements are balanced dynamically based on query characteristics.

Conclusion

The Signal-Decision Architecture represents a fundamental shift in how we think about semantic routing. By moving from fixed classification to flexible signal-based decisions, we enable:

Unlimited Scalability: From 14 categories to unlimited custom routing rules

Multi-Dimensional Intelligence: Capture keyword, embedding, and domain signals simultaneously

Flexible Logic: Combine signals with AND/OR operators and priority-based selection

Built-in Security: Integrated plugins for jailbreak detection, PII protection, and compliance

Cloud-Native Design: Kubernetes CRDs with dynamic configuration and zero-downtime updates

Whether you’re building an enterprise AI gateway, a multi-tenant SaaS platform, or an industry-specific AI assistant, the Signal-Decision Architecture provides the scalability, flexibility, and intelligence needed for production deployments.

Getting Started

Ready to try Signal-Decision routing?

Join our community to share feedback and learn from other users building intelligent routing systems at scale.