为什么需要共享 Token 供给池
单机部署的本地模型只能服务单个用户,无法充分利用硬件资源。通过将 Ollama 和 vLLM 组合成多用户共享池,团队可以集中管理模型、分配配额,并实现零边际成本的 Token 供给。
架构概览
- 推理后端:Ollama 用于轻量模型和快速原型,vLLM 用于高吞吐生产模型。
- API 网关:使用 LiteLLM 或 One API 统一代理,提供 OpenAI 兼容端点、鉴权和限流。
- 资源配额:通过网关为每个用户或团队设置每分钟请求数(RPM)和 Token 配额。
- 监控与计量:使用 Prometheus + Grafana 收集指标,或利用网关内置日志。
操作步骤
1. 部署推理后端
Ollama 安装与配置(Linux):
```bash
curl -fsSL https://ollama.com/install.sh | sh
# 修改服务配置以允许局域网访问
sudo systemctl edit ollama.service
# 添加:Environment="OLLAMA_HOST=0.0.0.0"
sudo systemctl restart ollama
```
拉取模型:
```bash
ollama pull llama3.2:3b
ollama pull qwen2.5:7b
```
vLLM 安装与启动:
```bash
pip install vllm
# 启动 OpenAI 兼容服务器
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--served-model-name qwen2.5-7b \
--host 0.0.0.0 \
--port 8000
```
2. 部署 API 网关(以 LiteLLM 为例)
```bash
pip install litellm[proxy]
```
创建配置文件 config.yaml:
```yaml
model_list:
- model_name: ollama-llama3.2
litellm_params:
model: ollama/llama3.2:3b
api_base: http://localhost:11434
- model_name: vllm-qwen2.5
litellm_params:
model: openai/qwen2.5-7b
api_base: http://localhost:8000/v1
api_key: dummy
general_settings:
master_key: sk-1234
```
启动网关:
```bash
litellm --config config.yaml --port 4000
```
3. 配置多用户与配额
在 LiteLLM 中创建用户和密钥,并设置预算与速率限制:
```bash
curl -X POST http://localhost:4000/user/new \
-H "Authorization: Bearer sk-1234" \
-H "Content-Type: application/json" \
-d '{"user_id": "team-a", "max_budget": 10, "rpm_limit": 60}'
```
返回的密钥即可分发给团队成员,用于访问统一端点 http://<server-ip>:4000。
4. 监控与计量
启用 LiteLLM 的日志和 Prometheus 指标:
```yaml
# 在 config.yaml 中添加
litellm_settings:
drop_params: true
success_callback: ["prometheus"]
```
访问 http://localhost:4000/metrics 获取指标,并配置 Grafana 仪表板。
注意事项
- 硬件要求:7B 模型推理建议至少 16GB GPU 显存;vLLM 需要 CUDA 环境。
- 网络与安全:生产环境应配置 HTTPS 和防火墙,避免公网暴露。
- 模型许可:确保所选开源模型允许商业使用(如 Apache 2.0、MIT 等)。
- 并发限制:根据 GPU 能力调整 vLLM 的
--max-num-seqs和--gpu-memory-utilization参数。 - 配额管理:LiteLLM 的预算单位是美元,需根据实际成本(此处为零)调整;速率限制需结合硬件性能设置。
适用场景
- 中小团队内部使用,希望统一管理模型访问并控制成本。
- 开发测试环境,需要快速切换不同开源模型。
- 教育或研究机构,为多个项目提供共享推理资源。
限制
- 本地部署的 Token 供给受限于硬件性能,无法无限扩展。
- 需要维护服务器和更新模型,有一定运维成本。
- 不适合对延迟极其敏感或需要超大模型(如 70B+)的场景,除非有相应硬件。