# LLM推理网关：基于一致性哈希的多工作负载路由方案 > 一个基于Python和FastAPI构建的LLM推理网关项目，实现了智能PR审查代理功能，并通过一致性哈希算法实现了多Ollama工作节点的请求路由，有效保持KV缓存热度。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-06-11T23:44:43.000Z - 最近活动: 2026-06-11T23:50:32.411Z - 热度: 146.9 - 关键词: LLM推理网关, 一致性哈希, FastAPI, Ollama, PR审查, KV缓存优化 - 页面链接: https://www.zingnex.cn/forum/thread/llm-900a7990 - Canonical: https://www.zingnex.cn/forum/thread/llm-900a7990 - Markdown 来源: ingested_event --- ## 原作者与来源 - **原作者/维护者**: Suraj-1207 - **来源平台**: GitHub - **原项目名**: llm-inference-gateway - **原始链接**: https://github.com/Suraj-1207/llm-inference-gateway - **发布时间**: 2026-06-11 --- ## 项目概述：从PR审查到推理网关 这个项目构建了一个完整的LLM应用栈，核心是一个基于FastAPI的推理网关，前端连接GitHub PR审查工作流。项目展示了如何将大语言模型能力集成到实际的软件开发流程中，同时解决多工作节点环境下的请求路由难题。 整个系统包含多个协同组件：GitHub数据获取器、PR摘要生成器、ReAct代理审查器、LLM-as-Judge评估框架，以及核心的推理网关。这种模块化设计使得每个组件可以独立演进，也方便开发者根据需要选择使用部分功能。 --- ## 核心组件解析 ### GitHub数据获取层 `github_fetcher.py`负责与GitHub API交互，获取PR的元数据、标题、描述、文件列表和diff内容。这是整个系统的数据入口，为后续的LLM处理提供原始材料。 ### PR摘要生成 `summarise_pr.py`使用本地Ollama模型对PR进行一次性摘要。这种设计允许开发者在本地环境中快速获得PR的内容概览，无需依赖外部API。 ### ReAct代理审查 `agent.py`实现了ReAct（Reasoning + Acting）代理循环，这是项目的核心智能层。代理能够： - 获取PR的diff内容 - 分析代码变更 - 生成审查意见 - 通过GitHub API发布评论 这里使用了Groq API提供的大模型能力，展现了本地模型和云端API混合使用的架构思路。 ### 评估框架 `eval.py`提供了离线评估工具，采用LLM-as-Judge模式对生成的摘要和审查意见进行质量评分。这种自评估机制对于迭代改进提示词和代理行为至关重要。 --- ## 推理网关：一致性哈希路由 ### 为什么需要智能路由 在多工作节点（worker）的LLM部署中，请求路由是一个关键问题。简单的轮询（round-robin）策略会导致每个请求的KV缓存无法复用，因为不同请求被分发到不同的工作节点。 KV缓存是LLM推理中的关键优化点。如果同一个会话的连续请求能够路由到同一个工作节点，就可以复用之前计算的KV缓存，大幅减少重复计算，提升响应速度。 ### 一致性哈希方案 `gateway.py`实现了一个FastAPI推理网关，采用一致性哈希算法解决这一问题： **路由机制**： - 请求通过`X-Session-ID`头部标识会话 - 相同会话ID的请求总是路由到同一个Ollama工作节点 - 没有会话ID的请求回退到轮询策略 **一致性哈希实现**： - 使用MD5哈希 + 二分查找构建哈希环 - 每个工作节点配置150个虚拟节点 - 这种设计确保添加或移除工作节点时，只有指向该节点的键需要重新分配 **Prometheus监控**： - 网关暴露`/metrics`端点 - 可以监控请求延迟、错误率、各节点负载等指标 --- ## 项目结构与部署 ### 代码组织 ``` github_fetcher.py — GitHub PR数据获取 summarise_pr.py — Ollama本地模型PR摘要 agent.py — ReAct代理：获取diff并发布评论 eval.py — 离线评估框架，LLM-as-Judge评分 gateway.py — FastAPI推理网关，一致性哈希路由 benchmark.py — 延迟基准测试：轮询 vs 一致性哈希 ``` ### 环境要求 - **Groq API Key**: 用于agent.py和eval.py（免费额度可用） - **GitHub Token**: 具有repo读取权限的个人访问令牌 - **Ollama**: 本地运行，需要拉取`llama3.2`模型 ### 启动多工作节点 ```bash # 启动3个Ollama实例 OLLAMA_HOST=127.0.0.1:11434 ollama serve & OLLAMA_HOST=127.0.0.1:11435 ollama serve & OLLAMA_HOST=127.0.0.1:11436 ollama serve & # 启动网关 python gateway.py curl http://localhost:8000/health ``` --- ## 使用场景演示 ### 场景一：PR摘要 ```bash python summarise_pr.py psf/requests 6710 $GITHUB_TOKEN ``` 这条命令会获取psf/requests仓库的第6710号PR，使用本地Ollama模型生成内容摘要。 ### 场景二：自动代码审查 ```bash python agent.py psf/requests 6710 $GITHUB_TOKEN ``` ReAct代理会分析PR的代码变更，自动生成审查评论并发布到GitHub。 ### 场景三：性能基准测试 ```bash python benchmark.py ``` 对比轮询和一致性哈希两种路由策略的延迟表现，量化展示缓存复用带来的性能提升。 --- ## 技术亮点与启示 ### 混合架构设计 项目展示了本地模型（Ollama）和云端API（Groq）的混合使用模式。摘要等轻量级任务使用本地模型降低成本，审查等复杂任务使用云端大模型保证质量。这种分层架构在实际生产环境中非常有价值。 ### 会话亲和性的重要性 一致性哈希路由解决了LLM推理中的会话亲和性问题。这不仅适用于PR审查场景，对于任何需要多轮对话的应用（如客服机器人、编程助手）都是关键优化。 ### 可观测性设计 内置Prometheus指标暴露，体现了云原生应用的设计思维。在LLM应用日益复杂的今天，可观测性不再是可选项，而是必备能力。 --- ## 局限与改进方向 当前实现是一个功能演示和原型，在生产环境中可能需要考虑： - **健康检查**: 工作节点故障时的自动剔除和恢复 - **动态扩缩容**: 根据负载自动调整工作节点数量 - **更细粒度的缓存策略**: 部分KV缓存共享、缓存预热等 - **请求优先级**: 区分实时请求和批量处理请求 尽管如此，这个项目为构建生产级LLM推理网关提供了一个清晰的起点，其一致性哈希路由方案值得在类似场景中借鉴。