距离 2026 年双 11 还有不到一个月财务部门的老王上周五拿着前三季度的 API 账单直接堵在了我工位前。随着我们在智能客服、商品导购和售后工单全面接入大模型调用开销像坐了火箭一样直线上升。尤其是在大促全链路压测期间几轮几十万 QPS 的压测流量灌进去大模型网关的 Token 账单直接让管理层倒吸一口凉气。我们复盘后发现一个极其离谱的现象线上超过 70% 的用户提问其实非常短小比如“退货地址在哪里”、“运费险怎么赔付”、“发货用什么快递”。这种毫无复杂推理逻辑的简单问答系统居然一视同仁地全部路由到了昂贵的高性能旗舰大模型上不仅响应耗时长达两三秒单次请求的成本更是低成本轻量模型的数十倍。为了应对即将来临的双 11 洪峰我们花了一周时间在网关层落地了一套“基于 Token 预估与意图粗筛的智能路由网关”。核心逻辑非常朴素根据 Prompt 复杂度、预估 Token 消耗和高频意图动态将请求分流给高成本旗舰模型或轻量低成本模型。传统大模型网关的痛点与路由考量很多团队做大模型网关最开始都是直接用 Nginx 或者 Spring Cloud Gateway 做简单的负载均衡。但大模型网关和传统微服务网关有着本质区别调用耗时不对称传统 RPC 接口耗时在毫秒级而大模型首字延迟TTFT加上流式输出耗时往往在 1 到 15 秒之间。成本差异巨大调用一次满血版大模型成本可能是轻量小模型的 15 到 30 倍。输入输出极度离散用户输入可能只有 5 个字也可能直接粘贴一段 5000 字的协议文档模型输出同样不可控。如果全部由服务端无脑转发既浪费算力又拖垮整体吞吐。我们需要在网关入口处以极低的 CPU 开销控制在 50 微秒以内快速预估用户的 Token 规模并结合路由规则把请求分派到最经济的模型实例。毫秒级 Token 快速估算器在网关层调用完整的 BPEByte-Pair Encoding分词器例如 TikToken 或 HuggingFace Tokenizer并不划算。大促期间网关 CPU 资源寸土寸金如果每次请求都要把文本拆解成 Token ID 数组JNI 调用和垃圾回收开销会把网关的吞吐量压低 40%。我们针对中文电商场景进行了样本统计设计了一套极轻量的快速估算算法。通过采样 100 万条历史提问数据我们发现中文字符与 Token 的换算比率相对稳定在 0.65 到 0.85 之间而英文单词约为 1.3 个 Token。package com.yali.gateway.router; import org.springframework.stereotype.Component; /** * 轻量级 Token 预估组件避免在网关层执行完整的分词词表遍历 */ Component public class FastTokenEstimator { // 经百万量级样本校准的经验系数 private static final double CHINESE_RATIO 0.72; private static final double ENGLISH_WORD_RATIO 1.33; private static final double PUNCTUATION_RATIO 0.50; public int estimateTokens(String prompt) { if (prompt null || prompt.isBlank()) { return 0; } int chineseChars 0; int englishWords 0; int others 0; boolean inWord false; char[] chars prompt.toCharArray(); for (char c : chars) { // 判断中文字符区间 if (c 0x4E00 c 0x9FA5) { chineseChars; inWord false; } else if ((c a c z) || (c A c Z) || (c 0 c 9)) { if (!inWord) { englishWords; inWord true; } } else { others; inWord false; } } // 综合加权计算 double estimated (chineseChars * CHINESE_RATIO) (englishWords * ENGLISH_WORD_RATIO) (others * PUNCTUATION_RATIO); // 上浮 10% 作为安全缓冲并向上取整 return (int) Math.ceil(estimated * 1.10); } }这段代码在 JDK 24 下利用紧凑字符串与 JIT 循环展开执行一次 1000 字文本的估算仅需约 8 微秒几乎对请求没有额外的延迟惩罚。路由决策树设计与动态阈值得到预估 Token 之后网关层进入路由仲裁环节。我们的仲裁策略由三个维度共同决定预估 Token 阈值Prompt 长度低于 128 Token 且不包含复杂逻辑指示词的优先进入轻量模型队列高于 1024 Token 或包含长上下文对比的直接交由旗舰模型处理。意图特征标签在上游接入层由轻量正则或者布隆过滤器打标诸如“运单查询”、“收货时间”、“好评返现”等模板化问题直接降级。租户与业务优先级VIP 核心店铺的客服请求拥有直通旗舰模型的特权普通试水业务则严格限流。路由核心决策组件代码如下package com.yali.gateway.router; import lombok.extern.slf4j.Slf4j; import org.springframework.stereotype.Service; import java.util.Set; Slf4j Service public class ModelRoutingService { private final FastTokenEstimator tokenEstimator; // 动态配置的阈值支持通过配置中心实时热刷新 private volatile int tokenThreshold 256; private volatile boolean enableCostSaving true; // 强制走高阶模型的关键字黑名单 private static final SetString COMPLEX_INTENTS Set.of( 法律诉讼, 假一赔三, 差价补偿计算, 合并转单, 逻辑分析, 代码审计 ); public ModelRoutingService(FastTokenEstimator tokenEstimator) { this.tokenEstimator tokenEstimator; } public ModelEndpoint route(String tenantId, String prompt) { if (!enableCostSaving) { return ModelEndpoint.PREMIUM_MODEL; } // 1. 命中高复杂度敏感意图强制高级模型 for (String keyword : COMPLEX_INTENTS) { if (prompt.contains(keyword)) { log.info(触发复杂意图[{}], 路由至旗舰模型, keyword); return ModelEndpoint.PREMIUM_MODEL; } } // 2. 计算预估 Token int estimatedTokens tokenEstimator.estimateTokens(prompt); // 3. 超过阈值需要更强语义理解与推理容量 if (estimatedTokens tokenThreshold) { log.debug(Token预估为[{}]超过阈值[{}]分流至旗舰模型, estimatedTokens, tokenThreshold); return ModelEndpoint.PREMIUM_MODEL; } // 4. 常见短文本直接由轻量模型承接 log.debug(短文本输入(预估Token: {})路由至低成本轻量模型, estimatedTokens); return ModelEndpoint.ECONOMY_MODEL; } public void updateTokenThreshold(int newThreshold) { this.tokenThreshold newThreshold; } }网关全局过滤器集成与无感分发在 Spring Cloud Gateway 中我们将路由决策器挂载为GlobalFilter。在读取 Request Body 的同时我们重构了转发逻辑将目标模型的下游 URL 和鉴权密钥在微秒级重写到当前上下文中。package com.yali.gateway.filter; import com.yali.gateway.router.ModelEndpoint; import com.yali.gateway.router.ModelRoutingService; import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.http.server.reactive.ServerHttpRequest; import org.springframework.stereotype.Component; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono; Component public class IntelligentAiRoutingFilter implements GlobalFilter, Ordered { private final ModelRoutingService routingService; public IntelligentAiRoutingFilter(ModelRoutingService routingService) { this.routingService routingService; } Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String prompt exchange.getAttribute(cachedRequestBody); String tenantId exchange.getRequest().getHeaders().getFirst(X-Tenant-Id); if (prompt null || prompt.isBlank()) { return chain.filter(exchange); } ModelEndpoint targetEndpoint routingService.route(tenantId, prompt); // 动态改写目标 URL 与微服务转发地址 ServerHttpRequest mutatedRequest exchange.getRequest().mutate() .header(X-Selected-Model, targetEndpoint.getModelName()) .uri(targetEndpoint.getServiceUri()) .build(); return chain.filter(exchange.mutate().request(mutatedRequest).build()); } Override public int getOrder() { return -50; // 在路由匹配前完成上下文重写 } }线上压测实测表现与总结在昨天的全链路压测第三轮中这套智能分流网关承接了峰值 12,000 QPS 的并发冲击。实际统计数据非常喜人成本骤降 62%近 65% 的常见基础咨询被成功分流到了低成本集群旗舰模型的并发压力直线下降原本捉襟见肘的 GPU 显存和限流配额得到了极大释放。平均响应时间RT大幅缩短轻量小模型的端到端首字耗时从原来的 1.2 秒压缩到了 280 毫秒客服前端的白屏时间肉眼可见地变短了。网关开销微乎其微引入快速 Token 估算器与内存匹配逻辑后网关整体 CPU 消耗仅上涨了不到 1.8%P99 延迟增加控制在 0.3 毫秒以内。技术选型永远不是为了堆砌最贵的技术栈而是为了用最合理的架构实现稳定和成本的最优解。在双 11 这种刺刀见红的高并发战场上省下来的每一分钱、挤出来的每一个毫秒都是我们扛住洪峰的底气。
