Smart model selection
Smart model selection automatically evaluates request difficulty through an external classifier service and routes requests to candidate models at different tiers (L1/L2/L3), reducing inference costs while maintaining response quality.
Overview
Smart model selection is an advanced routing feature in the InferX configuration center. When enabled, the gateway calls an external classifier service to evaluate each request's difficulty and routes it to candidate models at the corresponding tier:
L3 (Strong): Handles complex reasoning, code generation, and other high-difficulty tasks.
L2 (Medium): Handles regular conversations, knowledge Q&A, and other medium-difficulty tasks.
L1 (Light): Handles simple formatting, information extraction, and other low-difficulty tasks.
By matching requests with appropriately capable models, smart model selection significantly reduces inference costs without sacrificing response quality.
The workflow is as follows:
The client sends a request with the
modelfield set toauto.The gateway calls the classifier service to evaluate the request difficulty and determine the target tier.
The gateway selects an available instance from the candidate models at the target tier to process the request.
The response returns with the
resp.modelfield showing the model actually selected by the gateway.
Subsequent requests within the same conversation can reuse the previous difficulty assessment (conversation classification cache), avoiding redundant classification calls and reducing latency.
Prerequisites
The workstation version is 0.4.0 or later.
Enable and configure
Step 1: Configure the classifier service for the smart routing service
Edit the JSON configuration of the LLM smart routing service and add the llm_gateway.model_selection section:
{
"properties": {
"llm_gateway.model_selection": {
"classifier": {
"api_key": "<classifier_service_credentials>",
"endpoint": "http://<classifier_service_IP>:<port>",
"model_name": "<classifier_service_model_name,default:model>"
}
}
}
}Step 2: Enable smart model selection
In the left-side navigation pane of InferX, click Configuration Center.
On the configuration center page, find the Smart model selection card and click the toggle on the right side of the card title to enable the feature.
After enabling, the /v1/models endpoint will expose the auto model, and a "Smart model selection" section will appear on the InferX real-time monitoring page where you can verify the classifier service is healthy.
Conflict notice: If the current traffic distribution policy is set to Weight and there are active distribution routes, enabling smart model selection will trigger a conflict warning. Switch the traffic distribution policy to Prefix or deactivate the routes before enabling smart model selection.
Step 3: Configure basic parameters
After enabling the feature, the card automatically enters edit mode. Configure the following parameters and click Save.
Default tier
The fallback tier when the classifier service is unavailable or classification fails. L2 is recommended.
Candidate models per tier
Select candidate models for each of the three tiers (L3, L2, L1). The dropdown lists models reachable by the gateway; you can also enter model names manually. Within a tier, models are prioritized from left to right — if the first model is unavailable, the gateway automatically falls through to the next candidate.
If no candidate models are configured for a tier, that tier becomes unavailable.
Recommended models per tier:
Tier | Recommended models |
L1 | qwen3.6-35BA3B, qwen3.8-27B |
L2 | qwen3.8-next-flash, deepseek-v4-flash-0731, glm5.3flash |
L3 | DeepSeek-v4-pro-0813, kimi-k3, qwen3.8max |
After configuration, click Save. A change confirmation dialog appears showing a JSON diff of the before and after states. Click OK to submit.
Configuration fan-out is asynchronous and takes effect within seconds after submission.
Step 4: Call smart model selection
After configuration, set model to auto in your request to delegate model selection to the gateway. Example:
from openai import OpenAI
client = OpenAI(
# Gateway endpoint
base_url="http://xxxx/api/predict/group_llmgw_with_smart_model_selector/v1",
api_key="<credentials>",
)
resp = client.chat.completions.create(
model="auto", # auto = delegate model selection to the gateway
messages=[{"role": "user", "content": "Introduce yourself in one sentence"}],
)
print("Model selected by gateway:", resp.model)
print("Response:", resp.choices[0].message.content)Advanced settings
Expand the Advanced settings area in the smart model selection card to configure the following parameters. Skip these if you don't have specific requirements.
Parameter | Description |
Selection scope | Controls when smart model selection is triggered. See Selection scope comparison for a comparison of the two modes.
|
Session Classification Cache | When enabled, subsequent requests within the same session reuse the previous difficulty assessment instead of re-classifying. This reduces classification latency and classifier service load. |
Classification interval (turns) | Effective only when Session Classification Cache is enabled. Re-evaluates difficulty every N turns within a session; intermediate turns reuse the previous result. Set to 1 to re-evaluate every turn. |
No Session Downgrade | When enabled, a session can only upgrade to a higher tier mid-session, never downgrade. Enabling this automatically enables Session Classification Cache; disabling Session Classification Cache automatically disables this option. |
Request header | HTTP header field name used to identify a conversation. Supports multiple fields separated by commas; the first non-empty value is used. When both header and body are configured, the header takes priority. |
Request body | Field path of the session ID in the request body (e.g., metadata.session_id). Supports multiple fields separated by commas, tried in order. Used as fallback when the request header yields no value. |
When Session Classification Cache (or No Session Downgrade) is enabled, at least one of Request Header or Request Body must be filled in. Otherwise, saving will fail with the message "At least one conversation identification key (Request Header or Request Body) is required when Session Classification Cache is enabled." If a request doesn't carry the configured session key, that request will be re-evaluated each time without affecting other requests.
Selection scope comparison
All requests | Only requests whose model is auto (default) | |
Requests with a specific model name | Re-evaluated and rewritten to the selection result | Follows original routing; no classification call is made |
| Enters model selection | Enters model selection |
Suitable for | Letting the gateway manage tier selection for all traffic | Using native models for some traffic while delegating the rest to the gateway |
Observe effects
Overview — Smart model selection tier distribution
On the Overview page, the Smart model selection tier distribution card shows the basic distribution of model selection requests:
Selection request count: Request count and token count distribution across tiers (L3/L2/L1).
Selection coverage: The proportion of requests whose model was determined by smart model selection out of total requests within the selected time range. This metric uses the global scope and is not affected by user or department filters.
This card appears whenever there is model selection traffic within the selected time range, regardless of the current toggle state. It is not displayed under user or department filter scopes.
Real-time monitoring — Smart model selection health section
Displayed only when the feature is enabled. Includes a health status banner and six core metrics:
Health status banner
Status | Banner text |
Healthy | Model selection decision service is healthy |
Endpoint not configured | Smart model selection is enabled but no decision service endpoint is configured; health probe unavailable |
Probe failed | Decision service endpoint unreachable or probe timed out; or probe returned HTTP {{code}}. Both cases append "Traffic fail-open to {{tier}}" |
Endpoint reachable but quality degraded | Classification quality degraded: success rate {{rate}} / fail-open {{ratio}} (endpoint reachable; check authentication, model name, or output parsing) |
Six core metrics
Metric | Description |
Classify Success Rate | Proportion of classification calls that successfully returned a valid tier = classified / (classified + parse_fallback + fail_open). Cache hits and passthrough requests don't trigger classification calls. |
Fail-open ratio | Proportion of decisions that fell through to the default tier after classification failure. A value greater than 0 indicates classifier service issues; the number turns red. |
Session Cache Hit Rate | Hit rate of conversation-level classification result cache = cache_hits / (cache_hits + cache_misses). On a hit, the previous tier is reused without a classification call. |
Classify Latency | Time spent calling the external classifier service (milliseconds). Shows the window average and the window maximum. |
Reselects | Number of times re-selection was triggered due to backend execution failures or other reasons; subtitle shows the cumulative count since process startup. |
Decisions | Breakdown of selection decisions by source within the window: ✓ (classification success), cache, parse, fail (passthrough forwards the user-specified model and is not counted in total decisions); subtitle shows cumulative decisions since startup. |
Exception handling
Configuration conflicts
Smart model selection cannot be enabled simultaneously with Weight-based traffic distribution in the traffic proxy. If both are enabled, the configuration center shows a conflict warning and the backend rejects the save.
If both are forcefully enabled through backend configuration updates or other means, smart model selection takes no effect and traffic continues to follow the weight-based distribution logic.
Classifier service issues
Smart model selection depends on the classifier service. When the classifier service has issues, the health status is shown on the "Smart model selection" panel in real-time monitoring, with the fail-open ratio > 0 (displayed in red). Affected requests in the access logs carry the source=fail_open annotation.
The gateway probes the classifier periodically (approximately every 10 seconds). Three consecutive failures trigger degradation; a single success restores normal operation.
During degradation, each request that times out or fails during classification automatically falls through to the default tier. No requests are blocked or rejected. Normal model selection resumes automatically after recovery.
Classifier service issues don't affect inference request success rates but may increase time to first token (TTFT).
Log clues
The gateway access log appends an annotation segment to each model selection request. You can search for model_selection::
model_selection:tier=L2,classifier_tier=L2,task_type=,source=cascade,classify_ms=35,classify_llm_ms=30,reselects=0,selected_model=mock-tier-l2,session_id=xxxField | Meaning |
| Final selected tier |
| Decision source: |
| Classification call duration (with/without preprocessing), in milliseconds |
| Model actually used |
| Key used for conversation cache |
| Number of re-selections triggered by this request |
When classification fails, the gateway log contains a WARN entry: [ModelSelection][Req:xxx] classify failed, fail-open to tier L2: <reason>.