LLMPod 是什么？把自有算力变成可调用的模型 API
如果你手上有一台带 GPU 的机器，或者已经有一个能用的推理服务，想把它变成团队里谁都能调用、还能按人分账的模型 API，LLMPod 做的就是这件事。它自己不做推理，负责的是推理外面那一圈工程。
LLMPod 管的是哪一段
把链路拆成三层就很清楚：
- 模型与推理引擎：vLLM、SGLang、llama.cpp 这类，真正加载权重、算 token
- LLMPod：把引擎跑起来、把服务发布成对外的模型名、发 API Key、限流、记用量
- 你的应用：拿一个 OpenAI 兼容的地址和 Key 去调
所以它既不训练模型，也不优化推理速度。它解决的是「模型跑起来之后，怎么变成团队可以持续用的服务」。
一套安装会起哪几个组件
标准 Docker Compose 安装在管理服务器上启动四个容器：webserver、proxyserver、PostgreSQL 和 Redis。计算节点在管理端就绪后，用控制台生成的引导命令单独接入。
| 组件 | 主要职责 | 默认端口 |
|---|---|---|
| 控制面 webserver（含 Manager） | 控制台、/api/v1 管理 API、节点连接、部署编排 |
8080 |
| 推理网关 proxyserver | /v1/* 鉴权、模型选路、上游转发、计量 |
8090 |
| 计算节点 node | 上报资源、接收任务、运行本地模型的推理容器 | 由管理员引导安装 |
| 推理引擎容器 | 加载模型执行推理，为网关提供服务端点 | 由部署任务创建 |
| PostgreSQL / Redis | 平台资源与持久记录 / 运行期状态与限流协调 | 内部服务 |
表里是安装脚本的默认值。端口可以在安装向导里改，实际以安装完成时脚本输出的访问地址为准。
另一个容易误解的点：Manager 不是第五个进程，它是 webserver 里的编排能力，和控制台、管理 API 共用控制面端口。
三个角色用的是同一套 LLMPod 应用镜像，靠不同启动命令区分 webserver、proxyserver 和 node。
一次调用要经过什么
应用带着 API Key 请求推理网关，网关依次检查 Key、租户、模型可见性和用量限制，再按发布路由挑一个同协议的可用端点，通过 HTTP 把请求送到节点上的推理服务或者外部上游。
请求本身由网关直接转发到端点，不走 Manager。Manager 与 Node 之间的 WebSocket 连接只用于管理任务和状态上报。调用统计和日志用于追踪，但在准入阶段就被拒绝的请求不会写推理调用日志。
四种典型用法
- 企业内部共享模型服务：把自有算力上的模型发布成内部 API，平台集中管资源和权限，业务团队只管调
- 私有化项目交付：在客户环境里接入节点、部署模型、发布 API，交付一套可持续管理的服务
- MaaS 按需交付：按租户开放指定模型，配置访问权限与调用额度
- 统一模型网关：只把已有的模型服务和外部 API 接进来，统一管路由、鉴权与配额
第四种常被忽略。不部署本地模型也能用 LLMPod——只接入已有外部服务时，可以省去节点和本地推理容器。
它不是什么
- 不是推理引擎。你要跑模型，仍然需要 vLLM、SGLang 或 llama.cpp 其中之一，LLMPod 负责把它跑在节点上
- 不是公有云 API 的转售。它面向的是自有算力，把算力变成可交付的服务
- 不是必须从零建集群。单机部署时管理服务和模型可以共享一台机器；只做网关时连节点都不用装
节点侧支持 NVIDIA GPU 与昇腾 NPU 接入，纯 CPU 场景可以走 llama.cpp 这类能跑 CPU 的引擎。
什么情况下不该用它
有三种情况，直接用更轻的方案就行：
- 只有一两个人偶尔调模型，没有分权限、计量的需求
- 没有自有算力，也不打算有
- 只是想在一台机器上把模型跑通——vLLM 起一条命令就够了
真正值得上 LLMPod 的，是需要把模型服务交付给别人用的时候：多个团队、多个租户、要发 Key、要看用量、要能追日志。
下一步
- 安装与初始化：安装与初始化
- 已有推理服务怎么接进来：添加来源端点
- 站内接着看：部署第一个模型：三步向导里真正需要确认的东西、API Key 该在平台端发还是租户端发