大模型服务集成：从裸调 API 到企业级 AI 后端架构的演进之路

一、Token 账单与毫秒响应的双重夹击——大模型落地的工程痛点

当企业将大语言模型（LLM）从 POC 阶段推向生产环境时，最先暴露的往往不是模型能力不足，而是后端工程的系统性缺陷。裸调 OpenAI 或国产大模型的 HTTP API，在流量低时一切正常，但一旦面对真实业务流量，三大痛点便接踵而至。

第一，Token 成本失控。没有缓存机制的重复请求、没有限流的突发调用、没有 Prompt 长度管控的超长上下文，都会导致 Token 消耗在几天内飙升数倍。某智能客服系统上线首周，仅因重复问题未命中缓存，Token 支出就超出预算 300%。

第二，响应延迟不可控。大模型推理的 P99 延迟通常在 3-10 秒之间，且波动极大。前端 HTTP 连接超时、网关重试风暴、用户重复提交，这些在传统微服务中已有成熟方案的问题，在 LLM 调用链路中被急剧放大。

第三，模型服务单点故障。单一模型供应商的 API 限流、宕机或响应劣化，会直接导致业务中断。缺乏多模型路由和降级策略的架构，在生产环境中是不可接受的。

本文将围绕这三个痛点，构建一套面向生产环境的 AI 后端架构方案。

二、AI 后端架构的核心分层——请求路由、语义缓存与模型网关

一个成熟的企业级 AI 后端架构，需要在"业务层"与"模型层"之间建立三层中间设施：模型网关层、语义缓存层和请求编排层。这三层共同解决成本、延迟和可用性问题。

flowchart TB
    subgraph 业务层
        A[智能客服] --> B[文档问答] --> C[代码助手]
    end

    subgraph 请求编排层
        D[Prompt 模板引擎]
        E[Token 预算管控]
        F[流式响应适配器]
    end

    subgraph 语义缓存层
        G[向量相似度检索]
        H[缓存命中策略]
        I[TTL 与淘汰机制]
    end

    subgraph 模型网关层
        J[负载均衡路由]
        K[限流与熔断]
        L[多模型降级链]
    end

    subgraph 模型服务层
        M[GPT-4o]
        N[DeepSeek-V3]
        O[Qwen-Max]
    end

    业务层 --> 请求编排层
    请求编排层 --> 语义缓存层
    语义缓存层 -->|缓存未命中| 模型网关层
    语义缓存层 -->|缓存命中| 业务层
    模型网关层 --> 模型服务层

请求编排层负责 Prompt 的标准化组装、Token 预算的预计算和流式响应的适配。所有业务请求必须经过编排层，确保进入缓存层和网关层的请求格式统一。

语义缓存层是成本控制的核心。不同于传统 KV 缓存，语义缓存通过向量相似度匹配来判断"语义等价"的请求。当用户提问"Java 怎么创建线程"和"Java 中如何新建线程"时，语义缓存应识别为同一意图，直接返回缓存结果。

模型网关层解决可用性问题。通过加权路由将流量分配到多个模型供应商，配合熔断器在某个供应商响应劣化时自动切换，实现模型级别的容灾。

三、生产级代码：语义缓存与多模型网关的实现

3.1 基于向量检索的语义缓存

/**
 * 语义缓存服务：通过向量相似度匹配语义等价的请求
 * 核心思路：将用户 query 转为 embedding 向量，
 * 在向量库中检索相似度超过阈值的缓存条目
 */
@Service
public class SemanticCacheService {

    private final EmbeddingService embeddingService;
    private final VectorStore vectorStore;
    private final CacheConfig cacheConfig;

    /**
     * 查询语义缓存
     * @param query 用户原始问题
     * @param similarityThreshold 相似度阈值，默认 0.92
     * @return 缓存命中则返回结果，未命中返回 empty
     */
    public Optional<String> query(String query, double similarityThreshold) {
        float[] queryVector = embeddingService.embed(query);

        // 在向量库中检索 Top1 最相似条目
        List<CacheEntry> results = vectorStore.search(
            queryVector, 1, (float) similarityThreshold
        );

        if (results.isEmpty()) {
            MetricsCollector.increment("cache.miss");
            return Optional.empty();
        }

        CacheEntry hit = results.get(0);
        // 检查缓存是否过期（语义缓存同样需要 TTL）
        if (hit.isExpired()) {
            vectorStore.delete(hit.getId());
            MetricsCollector.increment("cache.expired");
            return Optional.empty();
        }

        MetricsCollector.increment("cache.hit");
        return Optional.of(hit.getResponse());
    }

    /**
     * 写入语义缓存
     * 控制缓存条目总量，避免向量库膨胀
     */
    public void put(String query, String response) {
        float[] vector = embeddingService.embed(query);
        CacheEntry entry = CacheEntry.builder()
            .query(query)
            .response(response)
            .vector(vector)
            .ttl(cacheConfig.getDefaultTtl())
            .createdAt(Instant.now())
            .build();

        vectorStore.upsert(entry);

        // 超过容量上限时触发异步淘汰：按 LRU 策略删除最久未访问条目
        if (vectorStore.size() > cacheConfig.getMaxEntries()) {
            CompletableFuture.runAsync(() ->
                vectorStore.evictOldest(cacheConfig.getEvictBatchSize())
            );
        }
    }
}

3.2 多模型网关与降级路由

/**
 * 模型网关路由器：基于权重和熔断状态的多模型路由
 * 核心策略：优先路由到低成本模型，高复杂度任务路由到高能力模型，
 * 任意模型熔断时自动降级到备选模型
 */
@Service
public class ModelGatewayRouter {

    private final Map<String, ModelEndpoint> endpoints;
    private final CircuitBreakerRegistry breakerRegistry;

    /**
     * 路由选择：根据任务复杂度和模型健康状态选择最优模型
     * @param request 包含 prompt 和复杂度评估的请求对象
     */
    public ModelEndpoint route(ChatRequest request) {
        // 按复杂度分级：简单任务用轻量模型，复杂任务用旗舰模型
        List<String> candidateModels = resolveCandidates(
            request.getComplexity()
        );

        for (String modelId : candidateModels) {
            CircuitBreaker breaker = breakerRegistry.circuitBreaker(modelId);
            // 熔断器处于关闭或半开状态时，尝试路由
            if (breaker.tryAcquirePermission()) {
                return endpoints.get(modelId);
            }
            // 熔断器打开，跳过该模型，尝试下一个
            log.warn("模型 {} 熔断中，尝试降级", modelId);
        }

        // 所有候选模型均不可用，返回兜底模型（本地小模型或规则引擎）
        log.error("所有模型不可用，启用兜底策略");
        return endpoints.get("fallback-local");
    }

    /**
     * 根据复杂度确定候选模型列表
     * 复杂度评估基于 Prompt 长度、任务类型和历史准确率
     */
    private List<String> resolveCandidates(TaskComplexity complexity) {
        return switch (complexity) {
            case SIMPLE -> List.of("qwen-turbo", "deepseek-lite", "fallback-local");
            case MEDIUM -> List.of("deepseek-v3", "qwen-max", "fallback-local");
            case COMPLEX -> List.of("gpt-4o", "deepseek-v3", "qwen-max", "fallback-local");
        };
    }
}

3.3 Token 预算管控拦截器

/**
 * Token 预算拦截器：在请求进入模型网关前，预估 Token 消耗并校验预算
 * 防止单次请求消耗过多 Token，也防止租户级预算超支
 */
@Component
public class TokenBudgetInterceptor implements HandlerInterceptor {

    private final TokenCounter tokenCounter;
    private final BudgetManager budgetManager;

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        String tenantId = extractTenantId(request);
        String prompt = extractPrompt(request);

        // 预估本次请求的 Token 消耗（含输入 + 输出估算）
        int estimatedTokens = tokenCounter.estimate(prompt);
        int maxOutputTokens = extractMaxTokens(request);
        int totalEstimate = estimatedTokens + maxOutputTokens;

        // 校验租户剩余预算
        long remaining = budgetManager.getRemainingBudget(tenantId);
        if (remaining < totalEstimate) {
            response.setStatus(429);
            response.getWriter().write(
                "{\"error\":\"Token budget exceeded\",\"remaining\":" + remaining + "}"
            );
            MetricsCollector.increment("budget.rejected", "tenant=" + tenantId);
            return false;
        }

        // 预扣预算，请求完成后按实际消耗调整
        budgetManager.preDeduct(tenantId, totalEstimate);
        request.setAttribute("estimatedTokens", totalEstimate);
        return true;
    }
}

四、语义缓存的精度陷阱与网关降级的延迟代价

1. 语义缓存的误命中风险

相似度阈值设置过高（如 0.98），缓存命中率极低，成本节省效果微弱；阈值过低（如 0.85），会将语义相近但意图不同的请求误判为等价。例如"如何删除用户"和"如何删除订单"的向量相似度可能达到 0.90，但答案完全不同。

解决方案：结合意图分类做二级过滤。先通过向量检索召回候选，再用轻量分类模型判断意图是否一致，只有意图一致才返回缓存。

2. 降级路由的延迟叠加

当首选模型熔断后，请求被路由到备选模型，但备选模型的首次请求需要重新建立连接和预热，P99 延迟可能从 3 秒飙升到 8 秒。在连续降级场景下，延迟会进一步叠加。

解决方案：对备选模型维护预热连接池，定期发送心跳请求保持连接活跃；同时在前端实现流式渲染，让用户感知到"正在生成"而非"卡住了"。

3. 向量库的运维成本

语义缓存依赖向量数据库（如 Milvus、Qdrant），这引入了额外的存储和计算开销。对于 QPS 低于 100 的低流量场景，语义缓存的成本收益可能为负——缓存命中率不足以覆盖向量检索本身的延迟和资源消耗。

决策维度	适合语义缓存	不适合语义缓存
QPS	> 500	< 100
问题重复率	> 30%	< 10%
延迟容忍度	秒级可接受	毫秒级要求
运维能力	有向量库经验	无专职运维

五、总结

企业级 AI 后端架构的核心价值，在于将大模型从"可用的 API"升级为"可控的基础设施"。语义缓存通过向量检索实现意图级别的请求去重，是 Token 成本控制的关键手段；多模型网关通过权重路由和熔断降级保障服务可用性；Token 预算管控则在租户维度建立了成本防线。

落地路线建议：第一步，在现有 LLM 调用链路中引入模型网关层，实现多供应商路由和熔断降级，这是投入产出比最高的第一步；第二步，对高频重复场景（如 FAQ、标准问答）引入语义缓存，优先覆盖 Token 消耗 Top 10 的接口；第三步，建立 Token 预算管控体系，按租户和接口维度设置配额与告警；第四步，持续优化缓存阈值和降级策略，通过 A/B 测试验证命中率与准确率的平衡点。