InferFlow：Go语言构建的LLM推理路由器，支持五种智能路由策略

InferFlow是一个基于Go的LLM推理路由器，支持轮询、最少待处理、KV感知、成本感知等五种路由策略，在AWS EKS上实测显示least_pending策略P95延迟最低（4860ms），比random策略快37%。

随着大语言模型（LLM）在生产环境中的广泛应用，如何高效地路由推理请求成为了一个关键问题。简单的轮询（Round-Robin）策略虽然公平，但忽略了后端服务的实际负载状态；而完全随机的路由则可能导致某些后端过载，产生长尾延迟。

更严重的是，KV缓存的重复计算问题。在Transformer架构中，每次生成token都需要重新计算之前所有token的注意力权重。如果相同的提示词被路由到不同的后端，每个后端都需要从头计算KV缓存，造成大量计算浪费。

InferFlow正是为解决这些问题而设计的——一个轻量级、可观测、支持多种智能路由策略的LLM推理路由器。

InferFlow的架构设计非常清晰，核心是一个用Go编写的控制平面，前端配合Streamlit仪表盘，后端连接多个llama.cpp推理服务。

负载生成器 / Streamlit UI / curl
            │
            ▼ OpenAI兼容HTTP
    ┌─────────────────────┐
    │     Go Router       │
    │  POST /v1/chat/...  │
    │  GET|PUT /strategy  │
    │  GET /metrics       │
    └──────────┬──────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
轮询    最少待处理   KV感知 ◄── Redis
随机    成本感知   (亲和缓存)
    │          │          │
    └──────────┼──────────┘
               │
    ┌──────────┼──────────┐
    ▼          ▼          ▼
┌───────┐  ┌───────┐  ┌───────┐
│worker-0│  │worker-1│  │worker-2│
│ :9000 │  │ :9000 │  │ :9000 │
└───────┘  └───────┘  └───────┘

技术栈：

• 路由器：Go 1.21，net/http，零外部依赖
• 后端：llama.cpp服务Qwen2.5-0.5B-Instruct-GGUF
• 缓存：Redis（EKS）或进程内TTL存储（本地）
• 基础设施：AWS EKS，Terraform，GitHub Actions CI
• 可观测性：Prometheus指标，OpenTelemetry脚手架
• UI：Streamlit仪表盘

InferFlow支持五种可运行时切换的路由策略：

策略	算法	适用场景
round_robin	原子计数器循环	基线/最简单的公平分发
least_pending	路由到待处理请求最少的后端	通用负载均衡
random	均匀随机选择	无状态，避免惊群效应
kv_aware	SHA256(model+prompt) → Redis → 优先缓存命中后端	重复提示，降低重计算延迟
cost_aware	跟踪估计token成本，路由到最低成本后端	优化总成本而非队列深度

KV感知策略是InferFlow的一大亮点。它通过计算模型名称和提示词的SHA256哈希，在Redis中查找之前处理过该提示的后端。如果找到，就将请求路由到该后端，利用已缓存的KV状态；否则回退到least_pending策略。

实测数据显示，当50%的请求是重复提示时：

• round_robin：重复提示平均延迟6042ms，唯一提示4657ms
• kv_aware：重复提示平均延迟4708ms，与唯一提示持平

这是因为round_robin将重复提示分散到三个后端，每个后端都需要重新计算KV缓存；而kv_aware将相同提示固定到一个后端，该后端已缓存KV状态，重复提示的延迟与首次计算相当。

InferFlow团队在AWS EKS上进行了负载测试（3个c5.xlarge节点，llama.cpp + Qwen2.5-0.5B-Instruct）：

策略	P50 (ms)	P95 (ms)	min (ms)	max (ms)
round_robin	4693	5296	4548	7995
least_pending	4757	4860	4630	4995
kv_aware	4812	6906	4642	8930
random	5949	7789	4560	9046

关键发现：

1. least_pending在大规模下表现最佳——P95延迟最低（4860ms），最大延迟也最低（4995ms）。在3个并发请求跨3个后端的场景下，它能有效避免单个后端过载。

2. round_robin是次优选择——P50表现接近，但尾延迟较高（最大7995ms），当后端落后时会出现延迟尖峰。

3. random明显最差——P50比round_robin慢近1.3秒，最大延迟超过9秒，这是由于随机后端碰撞导致的。

4. kv_aware实现了100%的Redis缓存命中率，但尾延迟较高（P95 6906ms）。这是因为它将重复提示集中在单个后端（backend-2获得了46%的流量），造成了热点。

InferFlow支持在不重启服务的情况下切换路由策略：

curl -X PUT http://localhost:8080/strategy \
  -H "Content-Type: application/json" \
  -d '{"strategy": "kv_aware"}'

每个响应都包含以下头部信息：

• X-Inferflow-Backend：处理请求的后端标识
• X-Inferflow-Strategy：当前活跃的路由策略
• X-Inferflow-Cache-Hit：是否命中Redis缓存（仅kv_aware）

InferFlow提供了一个功能丰富的Streamlit仪表盘，支持：

• 实时后端健康状态监控
• 路由策略动态切换
• 聊天界面测试不同策略
• 路由日志显示每个请求由哪个后端处理

仪表盘地址：https://inferflow-final.streamlit.app

API端点：http://k8s-default-inferflo-b7faaa4fda-434516550.us-east-1.elb.amazonaws.com n