大模型混合推理架构：云端大模型与端侧小模型的协同调度策略
一、混合推理的核心命题
大模型推理面临一个现实困境：云端大模型能力虽强，但网络延迟可达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不是锦上添花而是基本要求。
