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

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

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-19T16:08:56.000Z
- 最近活动: 2026-04-19T16:22:01.067Z
- 热度: 155.8
- 关键词: LLM推理, 负载均衡, Go语言, Kubernetes, KV缓存, 开源工具
- 页面链接: https://www.zingnex.cn/forum/thread/inferflow-gollm
- Canonical: https://www.zingnex.cn/forum/thread/inferflow-gollm
- Markdown 来源: ingested_event

---

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

## LLM推理服务的路由挑战

随着大语言模型（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感知路由：缓存亲和性的价值

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支持在不重启服务的情况下切换路由策略：

```bash
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）

## Streamlit仪表盘：实时监控

InferFlow提供了一个功能丰富的Streamlit仪表盘，支持：
- 实时后端健康状态监控
- 路由策略动态切换
- 聊天界面测试不同策略
- 路由日志显示每个请求由哪个后端处理

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

API端点：http://k8s-default-inferflo-b7faaa4fda-434516550.us-east-1.elb.amazonaws.com
n
## 部署与使用

### 本地开发

```bash
# 终端1 - 启动模拟后端
go run ./cmd/mock-backend

# 终端2 - 启动路由器
export INFERFLOW_BACKENDS="http://localhost:9000"
go run ./cmd/router

# 发送测试请求
curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"mock-llm","messages":[{"role":"user","content":"Hello from InferFlow"}]}'
```

### AWS EKS部署

```bash
cd terraform/environments/aws
terraform init
terraform apply

kubectl apply -f k8s/redis.yaml
kubectl apply -f k8s/vllm-worker.yaml
kubectl apply -f k8s/router.yaml
```

## 工程价值与启示

InferFlow的价值在于它提供了一个**可观测、可实验、可生产化**的LLM推理路由解决方案。通过对比五种策略的实测数据，它为运维人员提供了清晰的选择依据：

- 追求最低尾延迟？选择**least_pending**
- 有大量重复提示？选择**kv_aware**（但要注意热点问题）
- 追求简单可靠？选择**round_robin**
- 追求成本优化？选择**cost_aware**

此外，InferFlow的代码结构清晰、文档完善、CI/CD流程完整，是一个优秀的开源工程范例。

## 未来路线图

团队计划的功能包括：
- 流式SSE响应
- Kubernetes端点自动发现
- 更丰富的Prometheus/Grafana仪表盘
- KEDA自动扩缩容

## 总结

InferFlow通过系统化的路由策略对比，证明了**智能路由对LLM推理服务的重要性**。least_pending策略在实测中展现了最佳的延迟稳定性，而kv_aware策略则为重复提示场景提供了显著的延迟优化。对于正在构建LLM推理基础设施的团队来说，InferFlow提供了一个值得参考的架构设计和实现方案。

项目地址：https://github.com/isakshay007/InferFlow