The design approach of combining cloud LLMs with on-device SLMs and switching the processing destination based on the nature of the task is called "hybrid LLM design."

Relying on a single model creates trade-offs across three dimensions: cost, latency, and data protection. Cloud LLMs offer high accuracy but come with communication costs and delays, and can pose problems when sensitive data must be sent externally. On-device SLMs, on the other hand, excel in privacy and response speed but tend to fall short for complex reasoning tasks.

This article is aimed at AI engineers and system architects, and explains concrete strategies for routing tasks from the perspectives of cost, latency, and compliance. By the end, readers will have a clear understanding of how to choose the right hybrid configuration for their own systems and what to watch out for during implementation.

The design philosophy of combining cloud LLMs with on-device SLMs is called hybrid LLM design. The core concept is not to delegate all tasks to a single model, but to route each task to the most appropriate model based on the nature of the processing involved.

Simultaneously satisfying all three requirements—cost, latency, and data protection—is difficult with either a cloud-only or on-device-only approach. This reality is what elevates the hybrid configuration to a practical choice.

The sections that follow will cover, in order, the differences from single-model operation, the axes for routing decisions, and representative implementation patterns.

"Hybrid design," which combines cloud LLMs with on-device SLMs (Small Language Models), is fundamentally different from a simple choice of "which one to use." The biggest difference from operating either in isolation is the presence of a "routing layer" that dynamically directs processing to the appropriate destination based on the nature of the task.

In single-model operation, all requests flow to the same model. In hybrid design, by contrast, the system evaluates the characteristics of a task at the moment it is received and routes it to the optimal model.

The key differences can be summarized as follows:

• Diversification of processing destinations: Lightweight tasks are handled entirely by the on-device SLM, while complex reasoning and long-form generation are delegated to the cloud LLM.
• Control over data flow: Highly sensitive information can be processed entirely on-device, ensuring a pathway that never leaves the local network.
• Distribution of cost structure: Only requests with high token consumption are concentrated in the cloud, keeping overall API costs in check.

The background to why coexistence becomes "inevitable" lies in the fact that real-world applications are not composed of uniform tasks. For example, in a business app on a smartphone, tasks requiring immediate responsiveness—such as input completion—coexist with tasks that require multi-step reasoning as part of a Compound AI System. Routing everything uniformly to the cloud increases latency and cost, while processing everything uniformly on-device can lead to quality degradation in certain cases.

Hybrid design is a structure that presupposes this non-uniformity, enabling trade-off optimization that single-model operation cannot achieve.

When operating with a cloud LLM alone, issues of cost and latency tend to surface first. Sending large volumes of tokens to the cloud every time causes API costs to accumulate quickly, and network round-trip delays are unavoidable. In scenarios where response speed directly affects UX—such as mobile apps or terminals on a manufacturing line—this latency can be fatal.

Data protection considerations are equally important and cannot be overlooked. In regulated industries such as healthcare, finance, and legal services, the very act of transmitting personal or confidential information to an external server carries the risk of violating the EU AI Act, GDPR, and data localization regulations in various countries. With a cloud-only configuration, meeting these compliance requirements tends to complicate the overall design.

On the other hand, relying solely on an on-device SLM means hitting a capability ceiling.

• Complex reasoning and long-form generation: Many configurations have relatively narrow context windows, making it easy for accuracy to drop on tasks requiring multi-step reasoning.
• Multilingual support: The quality of multilingual NLP is heavily influenced by model size and the volume of training data, and SLMs tend to reach their limits here.
• Model update costs: Keeping the on-device model up to date incurs operational overhead in terms of distribution and management.

In short, cloud and on-device approaches each carry different trade-offs, and attempting to cover all tasks with just one of them will inevitably require compromise somewhere. The routing decision axes explained in the next section are a thinking framework for using both in combination according to task characteristics—built on the premise of this structure where neither option alone is the optimal solution.

"Routing"—deciding which model to send a task to—is the core of hybrid design. A poor routing decision can turn an intended cost reduction into increased latency, or result in a compliance violation when convenience is prioritized.

This section organizes the three axes of cost, latency, and compliance (including data protection). These axes are not independent; in practice, routing design requires considering multiple axes simultaneously. The details of each axis are explored in the H3 sections that follow.

Cost optimization is one of the most direct motivations for hybrid design. Cloud LLMs carry a high per-token cost, and when large volumes of requests accumulate, monthly expenses tend to spike sharply. On-device SLMs, by contrast, have near-zero inference costs, so assigning token-heavy or high-frequency tasks to an SLM can significantly reduce expenditure.

Core Metrics for Task Routing

• Input token count: Short classification and extraction tasks within a few hundred tokens are well-suited to SLMs. Long-form summarization or complex reasoning exceeding several thousand tokens should go to a cloud LLM.
• Call frequency: Batch processing or routine form analysis running tens of thousands of times per day can be absorbed by an SLM, reducing the number of cloud calls outright.
• Accuracy requirements: For tasks where the cost of an incorrect answer is high—such as contract review or medical documentation—a cloud LLM should be chosen for its accuracy even at greater expense.

Practical Approach

A good starting point is to divide tasks into two categories—"short-form, structured, low-risk" and "long-form, unstructured, high-risk"—and assign the former to the SLM as the default lane. From there, measuring monthly token consumption sent to the cloud and tracking the percentage successfully handled by the SLM as an AI ROI metric makes it easier to drive a continuous improvement cycle.

Latency and offline support are the most intuitive axes for deciding how to route between cloud LLMs and on-device SLMs. There are cases where the user experience differs markedly between the cloud, which incurs several hundred milliseconds of overhead from network round-trips alone, and an SLM, which can respond immediately via local inference.

Decision Criteria Based on Latency Requirements

• Scenarios requiring responses under 200ms (voice assistants, real-time subtitles, in-game NPCs, etc.) → Prioritize on-device SLM
• Scenarios where responses of roughly 1–3 seconds are acceptable (document summarization, code completion suggestions, etc.) → Cloud LLM is also a viable option
• Batch processing and asynchronous tasks (overnight report generation, large-scale translation, etc.) → Prioritize accuracy and cost over latency; route to cloud LLM

Requirements for Offline and Unstable Connectivity Environments

In environments where network connectivity cannot be guaranteed—such as factory floors, aircraft, or remote field sites—routing to a cloud LLM is simply not feasible. In such scenarios, an architecture where an SLM is deployed as edge AI resident on the device, with a cloud LLM used to validate and supplement results once connectivity is restored, proves effective.

Design Considerations

It is important to evaluate latency requirements based on P95–P99 outliers rather than average values. Since cloud API response times tend to spike during periods of high traffic, incorporating an on-device SLM as a fallback in scenarios with strict SLA requirements helps stabilize service quality.

Note that routing considerations from a compliance perspective will be covered in detail in the next section.

Data sensitivity and regulatory requirements are often the highest-priority decision axis when routing between cloud LLMs and on-device SLMs.

Categories of Data That Should Not Be Sent to the Cloud

• Personally identifiable information (names, addresses, My Number, etc.)
• Confidential documents related to healthcare, finance, or legal matters
• Internal undisclosed information or trade secrets
• Data subject to the EU AI Act, GDPR, or Japan's Act on the Protection of Personal Information

Sending such data to a cloud LLM introduces the risk of that data passing through third-party infrastructure. In situations where compliance requires explicit control over the location of processing, local processing via an on-device SLM becomes the default approach.

Routing Approach Based on Regulations and Policies

It is recommended to adopt a Privacy-by-Isolation approach, designing systems so that sensitive data never leaves the device boundary.

That said, even when using a cloud LLM, it is essential to review the contractual data processing terms (DPA) and confirm the model's training data opt-out settings. Combining this with guardrail configuration and incorporating a pipeline that detects and masks PII before transmission tends to safely expand the scope of cloud utilization.

There are multiple routing strategy approaches, each reflecting a different tradeoff between design complexity and operational cost. Broadly speaking, three representative patterns exist: static routing, which pre-defines task types and assigns them to fixed destinations; cascade routing, which dynamically switches based on the model's output confidence; and SLM draft + cloud validation, in which the SLM generates a draft that the cloud LLM then verifies. Since each pattern differs in its applicable use cases and implementation complexity, selecting the pattern that fits your organization's requirements is the starting point for system design.

Static routing is an approach in which task types are defined in advance and processing destinations are fixed according to a rule table. Its greatest strengths are low implementation cost and high predictability of behavior, owing to the simplicity of the decision logic.

Basic Routing Logic

• Examples of tasks routed to the SLM: Structured form auto-completion, FAQ responses, short-text sentiment classification, keyword extraction in offline environments
• Examples of tasks routed to the cloud LLM: Long-form summarization, cross-document analysis spanning multiple files, multilingual translation, code generation

The classification axes most commonly used are a combination of three factors: input token count, task category ID, and user role. For example, a rule can be written such that if the input is 256 tokens or fewer and the category is "FAQ," the request goes to the SLM; otherwise, it goes to the cloud LLM.

Implementation Considerations

Static routing depends on the accuracy of the classification defined at design time. If task category granularity is too coarse, processing that an SLM could handle adequately will flow to the cloud LLM, causing costs to balloon. Conversely, if classification is too fine-grained, the maintenance burden on the rule table increases.

After going live, it is advisable to use AI observability tools to continuously measure latency and quality scores per route, and to periodically revisit the classification rules.

Static routing is most effective when task types are stable and quality requirements are clearly documented. If requirements are in flux, it is worth considering combining it with the dynamic routing approach introduced next.

Confidence-based dynamic routing (Cascade) is an approach that uses the confidence score of an SLM's output as a threshold to automatically determine whether to escalate to a cloud LLM. Unlike static routing, it uses "how certain that inference is" as its criterion rather than task type, allowing it to handle unexpected inputs flexibly.

How It Works

1. The SLM executes inference and calculates a confidence score from the token probability distribution
2. If the score exceeds the threshold (e.g., 0.85), the SLM's answer is returned as-is
3. Only if the score falls below the threshold is the same prompt forwarded to the cloud LLM
4. The cloud LLM's response is returned as the final output

Benefits and Considerations

• Cost efficiency: High-frequency, simple queries are handled entirely by the SLM, which tends to reduce cloud API calls
• Quality assurance: Only ambiguous or complex queries are automatically routed to the higher-tier model, making it easier to suppress hallucination risk
• Latency doubling risk: When escalation occurs, the inference times of both the SLM and LLM are added together, so timeout design requires careful attention

Implementation Notes

Rather than using a fixed threshold value, it is advisable to continuously adjust it based on real-world operational logs collected via AI observability tools. In addition, combining the confidence score with an output consistency check (a technique that samples the same input multiple times and examines the variance) can compensate for cases where the score becomes overconfident.

The "SLM draft → cloud LLM verification" pattern introduced in the next section can be positioned as a further evolution of this Cascade architecture.

This is a two-stage pattern in which an on-device SLM rapidly generates a draft, which a cloud LLM then verifies and supplements. It is particularly effective in situations where latency, cost, and quality need to be optimized simultaneously.

How It Works

1. The SLM receives user input and generates an initial draft within a few hundred milliseconds
2. Based on the draft's confidence score, character count, and complexity, it determines whether to send the draft to the cloud LLM
3. Only when transmission is deemed necessary is the draft passed to the cloud LLM as context for verification and augmentation

Scenarios Where This Pattern Is Suitable

• Tasks such as contract summarization that require high accuracy but also demand fast response times
• Customer support first-response generation where only complex complaints need to be escalated to the higher-tier model
• Environments with unstable network bandwidth where the SLM alone should handle processing when offline

Cost Impact

By pre-filtering requests to the cloud LLM through the SLM, the volume of tokens transmitted tends to decrease. Since simple inquiries and templated responses are handled entirely by the SLM, the number of cloud API calls can be reduced.

Design Considerations

• If the SLM's draft quality is too low, the transfer rate to the cloud LLM increases, diminishing the cost-reduction effect
• Including the draft as-is in the prompt consumes the context window, so preprocessing via summarization or compression is effective
• Incorporate hallucination detection logic as a guardrail to ensure that misinformation does not flow downstream

By combining this with the implementation details in the next section and comparing the operational costs of each pattern, you can assess how well each fits your own environment.

To not only "design" a routing strategy but also "keep it running," it is necessary to understand the implementation complexity and operational overhead in advance. The static, dynamic, and hybrid patterns each differ significantly in initial build cost and ongoing maintenance effort. Identifying which pattern is compatible with your team's size and technology stack is the starting point for a sustainable design.

Static routing is a method that classifies task types in advance using rules and fixes the processing destination (SLM or cloud LLM). Its greatest strength lies in its simple branching logic, which results in low implementation cost and high predictability of behavior.

Basic Implementation Structure

• Assign a task label at input time (e.g., task_type: summarize / translate / reason)
• Manage the mapping table between labels and models in code or a configuration file
• The router performs conditional branching only. Since no LLM is used, additional latency is nearly zero

Suitable Scenarios

Static routing excels in cases where task types are determined in advance within a business workflow.

• Manufacturing and field applications: Primary analysis of equipment alerts is processed offline by the SLM, with only anomaly-detection escalations sent to the cloud
• Customer support: FAQ responses are handled by the SLM, while complaints and complex inquiries are routed to the cloud LLM
• Industries with clear compliance requirements: Inputs containing personal information are always fixed to on-device processing, structurally preventing external data transmission

Considerations

When inputs with ambiguous task boundaries are introduced, misrouting tends to occur. It is essential to always define a fallback destination for cases that "don't fit either category." Additionally, designs that rely on user input for labeling carry the risk of unintended manipulation, so it is recommended to implement a mechanism that automatically assigns labels on the system side. With an eye toward migrating to the dynamic routing covered in the next section, recording task labels and actual processing results in logs will be useful for later accuracy evaluation.

Dynamic routing is a mechanism that evaluates an SLM's confidence score in real time and escalates to the cloud LLM only when the score does not exceed the threshold. The core of the implementation lies in two elements: the "confidence determination logic" and the "fallback trigger."

Basic Implementation Flow

1. The SLM executes inference and calculates a confidence score from the softmax output or log probabilities
2. If the score falls below the configured threshold (e.g., 0.85), the same prompt is forwarded to the cloud LLM
3. The cloud LLM response is cached to suppress re-escalation for similar queries

Note that the specific threshold value varies significantly depending on system configuration and task characteristics, so validation in your own environment is necessary. In practice, it is realistic to set thresholds separately by task type. Tasks where the impact of errors is small, such as summarization or classification, should have a lower threshold, while tasks requiring high accuracy, such as contract review or medical summarization, should have a higher one.

Key Metrics to Monitor

• Escalation rate: The proportion of queries forwarded to the cloud. A sudden increase is a sign of SLM degradation or data drift
• Latency distribution: Measure response times for SLM-only processing and post-escalation processing separately
• Cost-accuracy tradeoff: Multiply the escalation rate by token consumption and review AI ROI on a weekly basis
• Hallucination detection rate: Incorporate grounding checks to compare the output quality of both the SLM and the cloud LLM

It is advisable to introduce an AI observability tool and design it to automatically trigger an alert when the escalation rate exceeds a baseline value over a given period. The baseline value must be configured and validated according to your own use case. Periodically recalibrating the threshold itself and keeping it aligned with model version upgrades and changes in domain data is the key to sustained operation.

Before actually implementing a hybrid design, organizing several decision criteria in advance can reduce rework in later stages. Selecting a routing policy that simultaneously satisfies cost estimates, latency targets, and data protection requirements is what determines design quality. The next H3 section dives deeper into a critical yet often overlooked perspective: alignment with existing guardrails and governance policies.

When introducing a hybrid design, failing to verify alignment with existing guardrails and governance frameworks in advance tends to cause serious compliance issues after deployment. Because the scope of applicable policies differs between cloud LLMs and on-device SLMs, a centralized management mechanism is essential.

Key Points to Verify

• Alignment with data classification policies: Explicitly document routing rules that correspond to internally defined confidentiality levels (e.g., top secret, confidential, public). Reflect in the router's configuration that data with high confidentiality levels is sent only to the on-device SLM.
• Compliance with the EU AI Act and NIST guidelines (NIST AI RMF): Tasks classified as high-risk may require audit log retention even when routed through a cloud LLM. Design the log storage location and access permissions in advance.
• Reporting lines to the AI governance committee: Changes to routing decision criteria should be incorporated into the governance committee's approval workflow. Neglecting change management risks creating a situation akin to shadow AI.
• Dual application of guardrails: Installing prompt firewalls and grounding checks on both the SLM and LLM increases processing costs. Placing a common guardrail layer upstream of the router to minimize duplication is considered an effective design approach.

Alignment work done earlier in the design phase results in less rework. Documenting the routing logic while referencing existing AI TRiSM frameworks and internal security policies will significantly simplify future audit responses.

When actually considering and implementing a hybrid design, questions arise one after another—"How do you build the router?" and "What do you do when the SLM makes a wrong judgment?" This section addresses questions that are particularly common in design and operational settings, providing concise answers. Clarifying these questions before getting into detailed implementation helps streamline subsequent decision-making.

Router implementation approaches fall broadly into two categories: "rule-based" and "LLM-based." Since each is suited to different situations, there is no need to decide on one universally.

Rule-Based Router

• Routes requests using conditional branching on token count, endpoint, keywords, and similar criteria
• Lightweight to implement, with router latency approaching nearly zero
• Conditions are fixed, requiring manual updates to accommodate new task types

LLM-Based Router

• Uses a small classification model or SLM to estimate the intent, complexity, and sensitivity of the input before routing
• Can flexibly handle unknown task types
• The router itself introduces inference cost and latency, making the selection of a lightweight model important

In practice, a two-stage approach—first performing a rough sort with rule-based routing, then passing only difficult cases to an SLM—is considered effective. For example, inputs that satisfy conditions such as "token count below a certain threshold and no confidentiality flag" are sent immediately to the on-device SLM, while all others are evaluated by an SLM-based classifier for intent before being forwarded to the cloud LLM.

The following table summarizes selection guidelines.

It is also important to include the router itself as a monitoring target within AI observability. Since accumulated misclassifications can lead to increased costs and quality degradation, incorporating regular reviews of routing logs into the operational workflow is advisable.

A hybrid design combining cloud LLMs and on-device SLMs is a practical approach for simultaneously optimizing across three axes: cost, latency, and compliance. A configuration that relies on only one or the other will inevitably require compromise on at least one of these axes.

Looking back at the routing strategies covered in this article, the options can be broadly organized into three categories.

• Static routing: Cloud or on-device assignment is fixed in advance by task type. Simple to operate and low in implementation cost.
• Dynamic routing (Cascade): Escalates to the cloud LLM based on the SLM's confidence score. Automatically balances accuracy and cost.
• SLM draft → cloud LLM verification: Suited to generation tasks where speed is needed without sacrificing quality.

As a starting point for design, it is recommended to first identify which tasks handle sensitive data. Once compliance requirements are clearly defined, the scope of on-device processing naturally becomes apparent, and the volume of tokens sent to the cloud can be reduced accordingly.

Next, incorporate guardrails and AI governance policies upstream of the router. Since the routing decisions themselves can become a new risk surface, a continuous monitoring framework using AI observability to track decision logs is indispensable.

A hybrid configuration is not something you build once and consider finished. Building a continuous review cycle for routing rules into the design phase from the outset—one that adapts to model updates and evolving business requirements—is what drives long-term improvement in AI ROI.