# LLM Inference Platform：基于 vLLM + llama.cpp 的统一推理网关架构 > 一个开源的大模型推理网关解决方案，整合 vLLM 和 llama.cpp 两种推理后端，通过 Nginx 和 FastAPI 提供统一的 OpenAI API 兼容接口，支持流式与非流式输出、SSE 事件推送，并采用 Docker Compose 实现一键部署。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-31T14:14:00.000Z - 最近活动: 2026-05-31T14:20:52.862Z - 热度: 114.9 - 关键词: LLM inference, vLLM, llama.cpp, FastAPI, Nginx, Docker, OpenAI API, gateway - 页面链接: https://www.zingnex.cn/forum/thread/llm-inference-platform-vllm-llama-cpp - Canonical: https://www.zingnex.cn/forum/thread/llm-inference-platform-vllm-llama-cpp - Markdown 来源: ingested_event --- ## 原作者与来源 - 原作者/维护者：ToNoName - 来源平台：github - 原始标题：llm-inference-platform - 原始链接：https://github.com/ToNoName/llm-inference-platform - 来源发布时间/更新时间：2026-05-31T14:14:00Z ## 原作者与来源\n\n- 原作者/维护者：ToNoName\n- 来源平台：GitHub\n- 原始标题：llm-inference-platform\n- 原始链接：https://github.com/ToNoName/llm-inference-platform\n- 来源发布时间/更新时间：2026-05-31T14:14:00Z\n\n---\n\n## 引言：大模型推理服务的工程化挑战\n\n随着开源大语言模型（LLM）的爆发式增长，越来越多的团队开始尝试在本地或私有云环境中部署自己的模型推理服务。然而，生产级的 LLM 推理服务并非简单的模型加载和调用，它需要解决一系列复杂的工程问题：\n\n- **多后端支持**：不同模型可能需要不同的推理引擎（如 vLLM 适合 GPU 批量推理，llama.cpp 适合 CPU 量化模型）\n- **API 标准化**：如何让前端应用以统一的方式调用不同后端的模型\n- **流式输出**：现代 AI 应用普遍要求实时的流式响应（streaming）\n- **负载均衡**：如何在多个模型实例之间分配请求\n- **可观测性**：如何监控推理延迟、吞吐量和错误率\n\nLLM Inference Platform 项目正是为解决这些问题而设计的一个统一推理网关架构。\n\n---\n\n## 架构概览：分层设计实现灵活解耦\n\n该项目的架构采用经典的分层设计，通过反向代理层、网关层和推理层的分离，实现了高度的模块化和可扩展性。\n\n### 整体架构图\n\n```\nClient → Nginx (:80) → FastAPI Gateway (:8000) → vLLM (:8001) / llama.cpp (:8002)\n```\n\n这种分层设计带来了几个关键优势：\n\n1. **单一入口**：客户端只需访问 Nginx 的 80 端口，无需关心后端的具体实现\n2. **灵活路由**：Nginx 可以根据请求特征将流量路由到不同的后端服务\n3. **独立扩展**：vLLM 和 llama.cpp 可以独立扩缩容，互不影响\n4. **协议统一**：FastAPI 网关层负责将 OpenAI API 格式转换为各后端所需的格式\n\n---\n\n## 核心组件详解\n\n### 1. Nginx 反向代理层\n\nNginx 在此架构中扮演流量入口和负载均衡器的角色：\n\n- **统一端口暴露**：对外只暴露 80 端口，简化客户端配置\n- **请求路由**：根据路径或模型名称将请求分发到不同的后端\n- **SSL/TLS 终止**：可以在此层处理 HTTPS 加密\n- **静态资源服务**：可用于托管 Web UI 或文档\n\n### 2. FastAPI 网关层\n\nFastAPI 网关是整个架构的核心，负责协议转换和请求编排：\n\n#### OpenAI API 兼容接口\n\n网关实现了 OpenAI 的 `/v1/chat/completions` 端点，这意味着任何支持 OpenAI SDK 的应用都可以无缝迁移到此平台：\n\n```bash\ncurl -X POST http://localhost/v1/chat/completions \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model\": \"llama-2-7b-chat\",\n \"messages\": [{\"role\": \"user\", \"content\": \"Hello\"}],\n \"stream\": false\n }'\n```\n\n#### 流式与非流式输出支持\n\n网关同时支持两种输出模式：\n- **非流式**：等待完整响应后一次性返回（适合短文本生成）\n- **流式**：使用 SSE（Server-Sent Events）实时推送 token（适合长文本和交互式应用）\n\n流式请求示例：\n\n```bash\ncurl -N -X POST http://localhost/v1/chat/completions \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model\": \"llama-2-7b-chat\",\n \"messages\": [{\"role\": \"user\", \"content\": \"Hello\"}],\n \"stream\": true,\n \"max_tokens\": 50\n }'\n```\n\n#### 多后端适配\n\n网关内部维护一个模型到后端的映射表，根据请求中的 `model` 参数决定调用 vLLM 还是 llama.cpp。这种设计允许：\n- 同一模型同时部署在 GPU（vLLM）和 CPU（llama.cpp）上，根据负载自动选择\n- 逐步迁移：可以先用 llama.cpp 验证模型，再迁移到 vLLM 生产环境\n\n### 3. vLLM 推理后端\n\nvLLM 是目前业界广泛采用的高吞吐 LLM 推理引擎，特别适合 GPU 环境：\n\n#### 核心技术特性\n\n- **PagedAttention**：通过细粒度的内存管理大幅提升 GPU 利用率\n- **Continuous Batching**：动态批处理，最大化吞吐\n- **量化支持**：支持 AWQ、GPTQ 等量化格式，降低显存需求\n\n#### 适用场景\n\n- 高并发在线服务\n- 长上下文模型（32K+ tokens）\n- 需要低延迟 P90 响应时间的应用\n\n### 4. llama.cpp 推理后端\n\nllama.cpp 是一个轻量级的 CPU 推理引擎，以极低的资源占用和广泛的硬件兼容性著称：\n\n#### 核心技术特性\n\n- **纯 C/C++ 实现**：无 Python 依赖，部署简单\n- **多种量化格式**：支持 Q4_K_M、Q5_K_M 等高效量化方案\n- **跨平台支持**：x86、ARM、Apple Silicon 全平台兼容\n\n#### 适用场景\n\n- 边缘设备部署\n- 无 GPU 环境\n- 开发测试环境\n- 对延迟不敏感的后台任务\n\n---\n\n## 部署与运维\n\n### 一键启动\n\n项目采用 Docker Compose 编排，部署极其简单：\n\n```bash\ngit clone https://github.com/ToNoName/llm-inference-platform.git\ncd llm-inference-platform\ndocker-compose up -d\n```\n\n### 项目结构\n\n```\nllm-inference-platform/\n├── src/\n│ └── gateway/\n│ ├── __init__.py\n│ └── gateway.py # FastAPI 网关实现\n├── docker/\n│ ├── Dockerfile # 网关镜像构建\n│ └── nginx/\n│ └── nginx.conf # Nginx 配置\n├── docker-compose.yml # 编排文件\n└── requirements.txt # Python 依赖\n```\n\n### 技术栈总结\n\n| 组件 | 技术选型 | 职责 |\n|------|---------|------|\n| 网关 | FastAPI + httpx | API 路由、协议转换、SSE 支持 |\n| 推理 | vLLM / llama.cpp | 模型加载与推理执行 |\n| 代理 | Nginx | 负载均衡、SSL、静态资源 |\n| 部署 | Docker + Docker Compose | 容器化、服务编排 |\n\n---\n\n## 关键技术决策分析\n\n### 为什么选择 FastAPI 而非其他框架？\n\n1. **异步原生支持**：内置 `async/await`，处理 SSE 流式输出非常自然\n2. **自动文档生成**：内置 OpenAPI/Swagger UI，便于调试和集成\n3. **类型安全**：基于 Python 类型提示，减少运行时错误\n4. **生态成熟**：丰富的中间件和插件生态\n\n### 为什么选择 Nginx 作为入口？\n\n1. **成熟稳定**：历经生产环境验证，性能优异\n2. **灵活配置**：支持基于路径、Header、权重等多种路由策略\n3. **运维友好**：丰富的监控指标和日志格式\n\n### 为什么同时支持 vLLM 和 llama.cpp？\n\n这种"双轨制"设计体现了务实的工程思维：\n- **vLLM** 负责生产环境的高性能推理\n- **llama.cpp** 用于开发测试和边缘部署\n- 两者通过统一网关暴露相同的 API，客户端无需感知差异\n\n---\n\n## 使用场景与最佳实践\n\n### 场景一：混合部署\n\n在资源受限的环境中，可以将热门模型部署在 GPU（vLLM），冷门模型部署在 CPU（llama.cpp），通过网关统一调度：\n\n```yaml\n# 示例：docker-compose.yml 片段\nservices:\n vllm:\n image: vllm/vllm-openai:latest\n deploy:\n resources:\n reservations:\n devices:\n - driver: nvidia\n count: 1\n capabilities: [gpu]\n \n llama:\n image: ghcr.io/ggerganov/llama.cpp:server\n # CPU 运行，无需 GPU\n```\n\n### 场景二：A/B 测试\n\n通过 Nginx 的配置，可以轻松实现新旧模型的灰度发布：\n\n```nginx\n# 将 10% 流量路由到新版本模型\nupstream backend {\n server vllm-old:8000 weight=90;\n server vllm-new:8000 weight=10;\n}\n```\n\n### 场景三：多租户隔离\n\n通过 API Key 路由到不同的模型实例，实现多租户隔离：\n\n```python\n# 网关层伪代码\nasync def chat_completions(request):\n api_key = request.headers.get(\"Authorization\")\n tenant = await get_tenant_by_key(api_key)\n backend = tenant.get(\"dedicated_backend\")\n return await forward_to_backend(backend, request)\n```\n\n---\n\n## 局限性与改进方向\n\n### 当前局限\n\n1. **无内置认证**：需要额外配置 API Key 验证\n2. **无请求缓存**：重复请求会触发重复推理\n3. **无自动扩缩容**：需要手动调整容器数量\n4. **有限的可观测性**：缺少 Prometheus 指标暴露\n\n### 潜在改进\n\n1. **添加 Redis 缓存层**：缓存常见请求的响应\n2. **集成 Prometheus/Grafana**：提供开箱即用的监控仪表盘\n3. **实现自动扩缩容**：基于队列长度或 GPU 利用率自动调整实例数\n4. **添加模型预热机制**：避免冷启动延迟\n\n---\n\n## 结语\n\nLLM Inference Platform 提供了一个务实且完整的开源推理网关方案。它没有追求过度复杂的功能，而是专注于解决最核心的"多后端统一接入"问题。对于希望自建 LLM 推理基础设施的团队来说，这是一个很好的起点——既可以直接使用，也可以作为参考架构进行扩展。\n\n其技术选型（FastAPI + Nginx + Docker）成熟稳定，学习曲线平缓，运维成本低。同时，vLLM 和 llama.cpp 的双后端支持策略，使其能够适应从边缘设备到数据中心的各种部署场景。