Smart model selection

Updated at:

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:

  1. The client sends a request with the model field set to auto.

  2. The gateway calls the classifier service to evaluate the request difficulty and determine the target tier.

  3. The gateway selects an available instance from the candidate models at the target tier to process the request.

  4. The response returns with the resp.model field 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

  1. In the left-side navigation pane of InferX, click Configuration Center.

  2. 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.

Note

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.

Warning

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.

Note

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.

  • Only requests whose model is auto (default): Smart model selection is enabled only when the request's model field is auto. Requests that specify a concrete model name follow the original routing logic.

  • All requests: Smart model selection is enabled for all requests. Even requests that specify a model name will be re-evaluated and rewritten to the selection result.

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.

Note

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

model=auto

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.

Note

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.

Note

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=xxx

Field

Meaning

tier

Final selected tier

source

Decision source: cascade (classification success) / session_cache (cache hit) / fail_open (fail-open) / parse_fallback (parse fallback)

classify_ms / classify_llm_ms

Classification call duration (with/without preprocessing), in milliseconds

selected_model

Model actually used

session_id

Key used for conversation cache

reselects

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>.

FAQ

Classifier endpoint is correctly configured but saving still shows "Classifier probe failed"

The gateway health probe defaults to the classifier service's /health path. If the classifier's /health endpoint is not accessible, you can customize the probe path to /v1/models:

{
  "classifier": {
    "endpoint": "http://your-classifier:8000",
    "health_probe_path": "/v1/models"
  }
}

Feature is enabled but /v1/models doesn't show auto

Four conditions must all be met: the feature is enabled, the classifier endpoint is configured, the API key is configured, and at least one tier has non-empty candidate models. For classifier service configuration, see Step 1: Configure the classifier service for the smart routing service.

My request specified a model but it was still changed

The selection scope is set to "All requests". Change it to "Only requests whose model is auto" to let requests with specified models bypass model selection entirely.

Weight conflict warning / save returns 400

The traffic distribution policy is Weight with active routes. Go to the traffic distribution page and switch to Prefix or deactivate the routes, then enable model selection.

Every request in the same conversation is re-classified

The request doesn't carry the configured conversation key (header or body), or conversation cache is not enabled. Check the conversation identification settings in Advanced settings.

No tier downgrade happens even with "No tier downgrade" enabled

This is expected — the conversation only allows tier upgrades, never downgrades. To trigger re-evaluation, reduce the "Classification interval" or disable the cache.