双轨大模型路由实战：从端侧Ollama边缘推理到云端大模型容灾降级架构深度拆解

目录

1. 为什么单一模型架构难以满足企业级诉求

2. 双轨大模型路由引擎核心架构设计

2.1. 动态探活与分级路由状态机

2.2. 核心路由与熔断降级代码实现

3. 生产环境真实故障复现与熔断排查

3.1. 熔断与平滑降级机制闭环

4. 结构化 JSON 提示词工程与防幻觉实战

前言：

在企业级 AI 应用落地过程中，高昂的商业 API 调用成本、公网网络抖动以及私有化信创场景下的数据隐私隔离，始终是横亘在开发者面前的三大难题。

本文结合全国软件杯国奖项目实战经验，深度拆解一套基于 Spring Boot 的端云双轨大模型智能路由引擎，详解端侧轻量化边缘推理、心跳探活判定、云端 API 无缝容灾降级以及严格结构化 JSON 提示词工程的工业级落地方案。

个人主页：艺杯羹

1. 为什么单一模型架构难以满足企业级诉求

在智慧招聘与人才画像等复杂业务场景中，单一的大模型接入方案往往暴露出显著的短板。

如果系统完全依赖云端商业大模型接口，一旦遭遇公网波动、API 服务限流或者凭证失效，整个系统的人才匹配与简历解析业务将瞬间瘫痪。

同时，在信创涉密局域网或离线比赛评测等断网环境下，纯云端架构直接丧失了基本可用性。

反之，如果系统完全采用本地部署的端侧轻量化模型，虽然具备出色的隐私隔离与毫秒级低延迟特性，但在处理复杂的多轮职业规划推理与深度模拟面试时，其推理精度与上下文理解深度又相对有限。

因此，构建一套具备“端侧极速优先、云端高智保底、故障自动熔断降级”的双轨智能路由架构，成为保障系统高可用与高性能的最佳工程解法。

2. 双轨大模型路由引擎核心架构设计

双轨路由引擎的核心思想在于解耦业务调用与底层模型供应商，通过统一的路由代理层实现智能化流量分发。

2.1. 动态探活与分级路由状态机

路由中心在接收到业务侧的推理请求时，首先根据全局配置的路由策略评估本地端侧节点的状态。

本地推理节点通常采用 Ollama 托管轻量级量化模型（例如 Qwen2.5-1.5B 或 Qwen2.5-7B），系统通过定期的轻量级 HTTP 心跳探测接口监听本地守护进程的存活状态。

当本地节点响应正常且配置为端侧优先时，请求将直接走内网本地环回地址完成推理，实现零 Token 成本与极致的响应吞吐。

一旦本地节点出现端口未监听、显存溢出或响应超时，路由状态机立即捕获异常并毫秒级触发降级逻辑，将同一份结构化请求无缝重定向至云端高精度接口（如智谱 GLM-4 系列），确保业务调用方感知不到底层故障。

2.2. 核心路由与熔断降级代码实现

在 Spring Boot 架构下，通过封装独立的路由服务实现类，将本地 Ollama 通信协议与云端 OpenAI 兼容协议进行统一抽象。

/**
 * 双轨大模型路由服务：支持本地 Ollama 与云端 API 的智能切换与容灾降级
 */
@Slf4j
@Service
@RequiredArgsConstructor
public class LLMRouterServiceImpl implements LLMRouterService {

    private final RestTemplate restTemplate;
    private final ObjectMapper objectMapper;

    @Value("${llm.prefer-local:true}")
    private boolean preferLocal;

    @Value("${llm.local.url:http://localhost:11434}")
    private String localUrl;

    @Value("${llm.local.model:qwen2.5:1.5b}")
    private String localModel;

    @Value("${llm.cloud.url:https://open.bigmodel.cn/api/paas/v4/chat/completions}")
    private String cloudUrl;

    @Value("${llm.cloud.model:glm-4-flash}")
    private String cloudModel;

    @Value("${llm.cloud.api-key:}")
    private String cloudApiKey;

    @Override
    public String chat(String systemPrompt, String userMessage) {
        // 第一阶段：本地端侧优先策略与探活检测
        if (preferLocal && isLocalOllamaAvailable()) {
            try {
                log.info("【LLM路由】分发至本地端侧模型: {}/{}", localUrl, localModel);
                return invokeLocalOllama(systemPrompt, userMessage);
            } catch (Exception ex) {
                log.warn("【LLM路由】本地端侧模型调用失败，立即触发云端降级: {}", ex.getMessage());
            }
        }

        // 第二阶段：云端大模型兜底保障
        try {
            log.info("【LLM路由】分发至云端高精度模型: {}", cloudModel);
            return invokeCloudLLM(systemPrompt, userMessage);
        } catch (Exception ex) {
            log.error("【LLM路由】云端模型调用异常，执行系统兜底响应: {}", ex.getMessage());
            throw new BusinessException("AI 服务暂时不可用，请稍后重试");
        }
    }

    private boolean isLocalOllamaAvailable() {
        try {
            ResponseEntity<String> response = restTemplate.getForEntity(localUrl + "/api/tags", String.class);
            return response.getStatusCode() == HttpStatus.OK;
        } catch (Exception e) {
            return false;
        }
    }
}

通过上述封装，上层业务模块只需面向统一的接口进行编程，彻底摆脱了与具体模型 SDK 的强耦合。

3. 生产环境真实故障复现与熔断排查

在系统进行高并发压力测试时，端侧 Ollama 进程因物理显存被打满导致 HTTP 端口无响应，系统抛出了以下典型的连接超时异常：

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://localhost:11434/api/generate": Connect to localhost:11434 [localhost/127.0.0.1] failed: Connection refused: connect
    at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:894)
    at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:810)
    at org.springframework.web.client.RestTemplate.postForEntity(RestTemplate.java:551)
    at com.qilin.zhipin.service.impl.LLMRouterServiceImpl.invokeLocalOllama(LLMRouterServiceImpl.java:88)

3.1. 熔断与平滑降级机制闭环

针对此类突发连接中断或超时，如果仅依赖简单的 try-catch，会导致每个进来的请求都在本地耗尽 3 秒超时时间，拖垮整个后端线程池。

团队引入了基于状态机与滑动窗口的熔断器（Circuit Breaker）机制：

当本地节点在 10 秒内连续失败超过 3 次时，熔断器自动置为 OPEN 状态；在接下来的 60 秒内，所有 AI 请求直接跳过本地探活，秒级路由至云端通道；待冷却时间结束后进入 HALF-OPEN 状态尝试恢复，彻底消除了超时阻塞。

4. 结构化 JSON 提示词工程与防幻觉实战

大模型在处理结构化信息提取时，极易产生非标准 JSON 输出（如多余的 Markdown 标记、前后缀说明文字或未转义的双引号），直接导致后端反序列化异常崩溃。

为了确保不同供应商、不同参数规模的模型均能稳定输出严格合规的 JSON 数据，系统在提示词设计与后置清洗阶段构建了双重防线。

/**
 * 大模型结构化响应清洗与 JSON 安全提取器
 */
public class LLMResponseParser {

    private static final Pattern JSON_BLOCK_PATTERN = Pattern.compile("```(?:json)?\s*([\s\S]*?)\s*```");

    public static String extractPureJson(String rawResponse) {
        if (rawResponse == null || rawResponse.isBlank()) {
            return "{}";
        }
        String content = rawResponse.trim();
        
        // 匹配被 Markdown 代码块包裹的 JSON 串
        Matcher matcher = JSON_BLOCK_PATTERN.matcher(content);
        if (matcher.find()) {
            content = matcher.group(1).trim();
        }
        
        // 兜底提取最外层的有效大括号边界
        int firstBrace = content.indexOf('{');
        int lastBrace = content.lastIndexOf('}');
        if (firstBrace != -1 && lastBrace > firstBrace) {
            content = content.substring(firstBrace, lastBrace + 1);
        }
        
        return content;
    }
}

在系统级提示词中，明确定义输出字段的键名类型与约束范例，并在模型请求参数中开启严格的格式化约束，配合后置正则边界截取，彻底杜绝了数据解析阶段的空指针与语法解析异常。