大模型混合推理架构：云端大模型与端侧小模型的协同调度策略

一、混合推理的核心命题

大模型推理面临一个现实困境：云端大模型能力虽强，但网络延迟可达200-800ms，且成本高昂；端侧小模型延迟低至10ms以内，但能力边界明显。混合推理架构试图在二者之间建立动态平衡——让简单任务在端侧快速完成，复杂任务上云获取深度推理能力。

这个命题的工程难点在于：什么算"简单"、什么算"复杂"的判定逻辑需要足够精准，误判的代价可能是用户体验的显著劣化。一个本应在端侧完成的意图分类任务被错误路由到云端，用户会感知到不必要的延迟；一个需要复杂推理的任务被端侧模型草率处理，结果质量无法接受。

graph TD
    A[用户请求] --> B[任务路由器]
    B --> C{复杂度评估}
    C -->|简单任务| D[端侧小模型]
    C -->|复杂任务| E[云端大模型]
    C -->|不确定| F[影子推理模式]
    F --> G[端侧+云端并行]
    G --> H[结果比对]
    H --> I[选择最优]
    D --> J[结果返回]
    E --> J
    I --> J
    
    style B fill:#4A90D9,color:#fff
    style D fill:#7CB342,color:#fff
    style E fill:#F57C00,color:#fff
    style F fill:#9C27B0,color:#fff

二、任务路由的分级策略

分级路由是混合推理架构的心脏。设计分级策略时，我们考虑了三个维度的信号：任务类型、输入复杂度、历史路由准确率。

第一级：基于规则的前置过滤。对于明确的轻量级任务——文本纠错、关键词提取、简单分类——直接走端侧。这类任务的共同特征是输入token数少（<128）、输出空间有限、不需要多步推理。

第二级：基于轻量分类模型的动态判断。在端侧部署一个BERT级别的分类器，对输入进行复杂度打分（1-10分）。1-4分走端侧，7-10分走云端，5-6分进入影子推理模式——同时发往两端，以云端结果为准但记录端侧表现，用于持续校准分类器。

/**
 * 任务路由器核心实现
 * 基于复杂度评分的三级路由策略
 */
public class HybridRouter {
    
    private final ComplexityClassifier classifier;
    private final EdgeModelClient edgeClient;
    private final CloudModelClient cloudClient;
    private final RouterMetrics metrics;
    
    private static final int EDGE_THRESHOLD = 4;   // 端侧处理上限
    private static final int CLOUD_THRESHOLD = 7;  // 云端处理下限
    
    /**
     * 路由决策主入口
     * @param request 用户请求，包含prompt和历史上下文
     * @return 路由结果及推理响应
     */
    public RouteResult route(InferenceRequest request) {
        long startNs = System.nanoTime();
        
        try {
            // 第一级：规则前置过滤
            if (isTrivialTask(request)) {
                InferenceResponse response = edgeClient.infer(request);
                metrics.recordEdgeHit(startNs);
                return new RouteResult(RouteLevel.EDGE_RULE, response);
            }
            
            // 第二级：轻量分类模型打分
            int complexityScore = classifier.score(request);
            request.setComplexityScore(complexityScore);
            
            if (complexityScore <= EDGE_THRESHOLD) {
                InferenceResponse response = edgeClient.infer(request);
                metrics.recordEdgeHit(startNs);
                return new RouteResult(RouteLevel.EDGE_CLASSIFIED, response);
            }
            
            if (complexityScore >= CLOUD_THRESHOLD) {
                InferenceResponse response = cloudClient.infer(request);
                metrics.recordCloudHit(startNs);
                return new RouteResult(RouteLevel.CLOUD_CLASSIFIED, response);
            }
            
            // 第三级：影子推理——端云并行，持续学习
            return shadowInference(request, startNs);
            
        } catch (EdgeModelException e) {
            // 端侧故障时自动降级到云端
            metrics.recordEdgeFailure();
            log.warn("Edge model failed, falling back to cloud. requestId={}", 
                     request.getRequestId(), e);
            InferenceResponse response = cloudClient.infer(request);
            return new RouteResult(RouteLevel.CLOUD_FALLBACK, response);
        }
    }
    
    private boolean isTrivialTask(InferenceRequest request) {
        return request.getMaxTokens() <= 64
            && request.getPrompt().length() <= 512
            && !request.requiresReasoning();
    }
    
    private RouteResult shadowInference(InferenceRequest request, long startNs) {
        // 并行调用端侧和云端
        CompletableFuture<InferenceResponse> edgeFuture = 
            CompletableFuture.supplyAsync(() -> edgeClient.infer(request));
        CompletableFuture<InferenceResponse> cloudFuture = 
            CompletableFuture.supplyAsync(() -> cloudClient.infer(request));
        
        // 以云端结果为主返回，端侧结果用于对比分析
        InferenceResponse cloudResponse = cloudFuture.join();
        edgeFuture.thenAccept(edgeResponse -> {
            metrics.recordShadowComparison(request.getComplexityScore(), 
                                          edgeResponse, cloudResponse);
        });
        
        metrics.recordShadowMode(startNs);
        return new RouteResult(RouteLevel.SHADOW, cloudResponse);
    }
}

三、端侧模型的部署优化

端侧模型需要在有限资源下实现低延迟推理，ONNX Runtime和TensorRT是两条主流路径。ONNX Runtime的优势在于跨平台兼容性好，CPU推理优化成熟；TensorRT在NVIDIA GPU上可以实现3-5倍的推理加速，但部署复杂度更高。

实际落地中，我们采用了两阶段优化策略：

第一阶段，模型导出与量化。将PyTorch训练的模型通过ONNX导出，再使用INT8量化将模型体积压缩到原始的1/4。对于参数量在1B以下的小模型，INT8量化对精度的影响通常控制在1%以内。

第二阶段，推理引擎配置。关键配置项包括：线程数（设为物理核心数而非逻辑核心数）、图优化级别（生产环境使用ORT_ENABLE_ALL）、内存分配策略（使用Arena分配器减少碎片）。以下是一个ONNX Runtime的优化配置示例：

/**
 * ONNX Runtime端侧推理引擎配置
 * 针对延迟敏感场景的优化参数
 */
public class OptimizedONNXEngine {
    
    private final OrtEnvironment env;
    private final OrtSession session;
    private final OrtSession.SessionOptions options;
    
    public OptimizedONNXEngine(String modelPath, int numThreads) {
        this.env = OrtEnvironment.getEnvironment();
        this.options = new OrtSession.SessionOptions();
        
        // 线程数设置为物理核心数，避免超线程带来的上下文切换开销
        options.setIntraOpNumThreads(numThreads);
        options.setInterOpNumThreads(2);
        
        // 开启所有图优化：常量折叠、算子融合、冗余消除
        options.setGraphOptimizationLevel(
            OrtSession.GraphOptimizationLevel.ORT_ENABLE_ALL);
        
        // 使用Arena分配器减少内存碎片
        options.setMemoryPatternOptimization(true);
        
        // 设置执行模式为并行以充分利用多核
        options.setExecutionMode(OrtSession.ExecutionMode.PARALLEL);
        
        try {
            this.session = env.createSession(modelPath, options);
        } catch (OrtException e) {
            throw new InferenceEngineException(
                "Failed to initialize ONNX session: " + modelPath, e);
        }
        log.info("ONNX engine initialized. model={}, threads={}", 
                 modelPath, numThreads);
    }
    
    /**
     * 带预热和超时控制的推理方法
     */
    public float[] infer(float[] inputEmbedding, long timeoutMs) {
        long startTime = System.currentTimeMillis();
        
        try (var inputTensor = OnnxTensor.createTensor(env, 
                new long[]{1, inputEmbedding.length}, 
                FloatBuffer.wrap(inputEmbedding))) {
            
            var inputs = Map.of("input", inputTensor);
            var results = session.run(inputs);
            
            long elapsed = System.currentTimeMillis() - startTime;
            if (elapsed > timeoutMs) {
                log.warn("Inference exceeded timeout. elapsed={}ms, threshold={}ms", 
                         elapsed, timeoutMs);
            }
            
            try (var output = (OnnxTensor) results.get(0)) {
                float[] result = new float[(int) output.getTensorInfo().getShape()[1]];
                output.getFloatBuffer().get(result);
                return result;
            }
        } catch (OrtException e) {
            throw new InferenceEngineException("ONNX inference failed", e);
        }
    }
}

四、一致性保证与延迟权衡

混合推理架构面临的一个核心挑战是：同一类问题在不同路由路径下能否给出一致的答案？如果用户连续两次问相似问题，一次走了端侧、一次走了云端，得到的答案质量差异过大会严重损害信任。

我们采用了三层一致性保证机制：

第一层：答案置信度校验。每次端侧推理后，模型输出一个0-1的置信度分数。置信度低于0.7的结果自动升级到云端重新推理。这个机制可以有效拦截端侧模型的"不确定"输出。

第二层：会话级路由绑定。同一会话中的连续请求倾向于走同一路径，避免频繁切换带来的体验不一致。具体做法是维护一个会话级别的复杂度滑动窗口，取最近3次评分的均值做决策。

第三层：影子模式持续校准。对于5-6分区间进入影子模式的任务，持续记录端侧结果与云端结果的语义相似度，动态调整分类器的阈值边界。

延迟方面，实测数据表明：纯端侧路径的P99延迟为12ms，纯云端路径的P99延迟为680ms，混合模式通过影子推理在准确率和延迟之间取得了折中——整体P99延迟约350ms，但复杂任务的准确率比纯端侧方案提升了23个百分点。

五、总结

混合推理架构的核心价值不在于技术本身的新颖性，而在于工程上的务实权衡。它承认一个基本前提：没有一种模型在所有场景下都是最优的。云端大模型和端侧小模型各有擅长，混合推理的目标是让每个请求找到它最合适的执行路径。

落地过程中的关键经验有三点：一是分类器的持续校准比初始精度更重要，影子推理模式提供了宝贵的数据飞轮；二是端侧部署的性能优化投入产出比极高，量化+图优化带来的延迟降低通常远超模型本身的改进；三是故障降级机制必须纳入初始设计，端侧模型的稳定性远不如云端，graceful degradation不是锦上添花而是基本要求。