前言

在“模型即服务”快速落地的当下，从单卡 Demo 到生产级集群，团队往往先尝到 Ollama/vLLM 一键启动的甜头，再被 Nginx 轮询、K8s HPA、Spring Cloud Gateway 的“组合套餐”拖入泥潭：路由看不懂模型语义，扩容不感知推理延迟，应用端为了对接不同框架还得写三套客户端。

JAiRouter 正是我们在这段“甜蜜到痛苦”的旅程里沉淀的轻量级网关：

• 把负载均衡、熔断、限流做成内置默认项
• 把 Ollama、vLLM、TensorRT 等私有协议归一到 OpenAI 兼容接口
• 让 Spring AI、LangChain 或其他自定义应用只需一次域名切换，即可获得模型感知的流量治理

这篇小文不谈宏大愿景，只记录我们如何用 JAiRouter 在自家 Spring AI + Spring Cloud 平台上：

1. 把“多实例推理”做成“单点配置”
2. 把"扇入扇出"做成"标准 SDK"
3. 把"四个中间件"做成"一个 Jar"

为正在从单卡走向集群的同行提供一份可直接抄作业的参考。

一、从单卡到集群：推理服务的演进痛点

单卡推理阶段的挑战

• 资源瓶颈：单卡推理服务在面对高并发请求时，GPU利用率快速达到100%，请求队列积压严重
• 扩展困难：手动扩容涉及模型文件分发、服务启动、负载配置调整等多个环节，耗时长达数小时
• 版本管理混乱：模型迭代时，需要同时维护多个版本，手动切换风险高

传统网关方案的局限性

二、扇入扇出控制：接口归一化的必要性

原始对接模式的复杂性

// 应用层需要维护多种客户端
public class ModelService {
    private OllamaClient ollamaClient;
    private VllmClient vllmClient;
    private TensorRTClient tensorRTClient;
    
    // 每个客户端都需要实现重试、熔断、限流等逻辑
    // 代码重复度高，维护困难
}

OpenAI接口归一化的价值

• 统一接入：所有推理服务统一通过OpenAI兼容接口访问
• 简化开发：应用层只需集成标准OpenAI客户端
• 降低耦合：推理后端变更无需修改应用代码

三、内置能力：让治理成为默认选项

传统方案的多组件集成

Nginx(负载均衡) + Hystrix(熔断) + Redis(限流) + Prometheus(监控)

• 部署复杂：需要维护多个组件
• 配置分散：每个组件独立配置，一致性难以保证
• 排障困难：问题定位涉及多个组件日志

JAiRouter的集成化设计

model:
  # 全局配置
  load-balance:
    type: random # 支持: random, round-robin, least-connections, ip-hash
    hash-algorithm: "md5" # IP Hash 策略的哈希算法

  # 全局适配器配置 - 如果服务没有指定适配器，将使用此配置
  adapter: gpustack # 支持: normal, gpustack, ollama, vllm, xinference, localai

  # 全局限流配置
  rate-limit:
    enabled: true
    algorithm: "token-bucket"
    capacity: 1000
    rate: 100
    scope: "service"
    client-ip-enable: true  # 启用客户端IP限流

  # 全局熔断配置
  circuit-breaker:
    enabled: true
    failureThreshold: 5
    timeout: 60000
    successThreshold: 2

  # 全局降级配置
  fallback:
    enabled: true
    strategy: default

  services:
    # 聊天服务配置
    chat:
      load-balance:
        type: least-connections
      adapter: gpustack # 使用GPUStack适配器
      # 服务级别限流配置
      rate-limit:
        enabled: true
        algorithm: "token-bucket"
        capacity: 100
        rate: 10
        scope: "service"
        client-ip-enable: true
      instances:
        - name: "qwen3:1.7B"
          base-url: "http://172.16.30.6:9090"
          path: "/v1/chat/completions"
          weight: 1
          # 实例级别限流配置
          rate-limit:
            enabled: true
            algorithm: "token-bucket"
            capacity: 50
            rate: 5
            scope: "instance"

• 单一配置：所有治理能力集中管理
• 统一监控：内置指标暴露，无需额外组件
• 原子操作：配置变更整体生效，避免中间状态

四、生产实践：在Spring AI架构中的集成

集成架构

实际收益

1. 开发效率提升60%

   • 应用层代码量减少：从多客户端维护到单客户端调用
   • 配置复杂度降低：从多组件配置到单一YAML

2. 运维成本下降40%

   • 组件数量减少：从4个核心组件到1个网关
   • 故障定位时间缩短：统一日志格式和追踪ID

3. 系统稳定性提升

   • 自动熔断：异常实例30秒内自动摘除
   • 智能负载：基于负载策略动态路由

五、总结与展望

JAiRouter通过以下设计解决了大模型推理场景的核心痛点：

1. 模型感知的负载均衡：弥补了传统网关无法理解模型语义的缺陷
2. OpenAI接口归一化：降低了应用层与推理服务的耦合度
3. 治理能力内置：将负载均衡、熔断、限流等作为基础能力提供
4. 云原生集成：与Spring AI生态深度整合，简化架构复杂度

对于正在从单卡走向集群、从实验走向生产的团队，JAiRouter提供了一个轻量级但完善的解决方案，让工程师可以专注于业务创新，而非基础设施的拼凑。