vLLM
面向大语言模型高吞吐推理的服务框架，在本文中承担把 Ornith-1.0-35B 部署成 OpenAI 兼容接口的角色，使 Hermes Agent 与 Supermemory 能像调用云端模型一样调用本地模型。
简介
vLLM 是一个用于部署和服务大语言模型的推理框架，常见用法是把开源模型包装成 OpenAI API 兼容服务，供上层应用、Agent 框架或内部系统调用。在这篇素材中，vLLM 的具体形态是 vllm/vllm-openai:latest Docker 容器：用户把 Hugging Face 模型缓存挂载到容器内，再通过一组启动参数把 Ornith-1.0-35B MoE 暴露为 http://localhost:8000/v1/chat/completions。
vLLM 在本地 Agent 系统里的价值不只是“跑得快”。如果一个模型只是能在命令行里回答问题，它还不能直接成为 Hermes Agent 的后端；Agent 需要稳定的接口协议、模型名、上下文长度、工具调用解析、reasoning 解析、显存占用控制、prefix caching 和并发请求管理。vLLM 提供的 OpenAI 兼容容器正好把这些工程问题集中在服务层解决。
本文的部署案例还说明，本地模型工程化的关键在“服务参数”。例如 --served-model-name Ornith-1.0-35B 决定上层应用填写的模型名，--max-model-len 131072 决定长任务上下文上限，--tool-call-parser qwen3_xml 和 --reasoning-parser qwen3 决定 Agent 工具调用能否被正确解析。也就是说，vLLM 是本地 LLM 从“模型文件”升级为“可被 Agent 使用的基础设施”的桥梁。
关键信息
- 类型：大模型推理服务框架 / OpenAI 兼容模型服务
- 本文使用形态：
vllm/vllm-openai:latestDocker 容器 - 服务端口：示例映射到
localhost:8000 - API 形态：
/v1/chat/completions - 部署模型：Ornith-1.0-35B
- 关键能力：GPU 推理、长上下文、显存利用率控制、prefix caching、OpenAI API 兼容、tool call parser、reasoning parser
- 相关概念：Ornith 1.0、Hermes Agent、Supermemory、AI编程开发
核心特性
1. OpenAI 兼容服务接口
素材中的 Python 测试脚本直接向 http://localhost:8000/v1/chat/completions 发送请求，payload 中使用 model: "Ornith-1.0-35B" 和标准 messages 数组。这使 Hermes Agent、Supermemory 等原本面向 OpenAI 兼容接口设计的工具，可以不改核心代码就切换到本地模型。
2. Docker 化部署降低环境复杂度
示例部署使用 docker pull vllm/vllm-openai:latest 和 docker run ... --gpus all -p 8000:8000。对本地 Agent 使用者而言，Docker 把 CUDA、Python、vLLM 运行环境和服务入口封装起来，只需挂载模型缓存目录并传入模型 handle，减少“能在笔记本跑一次”和“能长期服务 Agent”之间的运维差距。
3. 长上下文与缓存支持项目型 Agent
--max-model-len 131072 为 Hermes 的长任务提供上下文空间，--enable-prefix-caching 则有助于复用长上下文前缀，降低连续对话或重复系统提示带来的开销。对于会反复读代码、跑工具、回传结果的 Agent，长上下文和缓存比单次问答速度更关键。
4. 显存与批处理控制
示例参数包含 --gpu-memory-utilization 0.8、--max-num-batched-tokens 4096、--tensor-parallel-size 1。这些参数决定服务如何使用 GPU、如何处理批量 token，以及是否跨卡切分。后续作者为了增加同时使用者，又改用 Ornith 35B FP8 并把 memory-utilization 调到 0.55，再给 Qwen VL 3B 分配 0.12，这说明显存分配是本地 Agent 多组件共存的核心运维变量。
5. 工具调用和 reasoning parser
本地 Agent 最大的风险之一是模型会输出“看似工具调用、实际框架无法解析”的文本。本文特别提醒 Ornith 35B 基于 Qwen 3.5 建置，因此 tool call parser 与 reasoning parser 都要使用 qwen；示例为 --tool-call-parser qwen3_xml 与 --reasoning-parser qwen3。这类 parser 配置决定了 Hermes 能否让模型自动选择工具、正确解析调用参数，并进入后续执行链路。
不同素材中的观点
- 2026-07-08-vocus-hermes-ornith-local-llm-agent：这篇素材把 vLLM 定位为本地 Hermes Agent 的模型服务层。作者不是简单说“用 vLLM 跑模型”，而是给出完整 Docker 参数，强调 served model name、长上下文、prefix caching、tool call parser、reasoning parser 和显存利用率共同决定本地 Agent 是否可用。文章还用 OpenAI 兼容 Python 请求验证模型服务是否正常，再接入 Hermes 与 Supermemory。
实用信息
- 快速上手步骤：先拉取
vllm/vllm-openai:latest，用docker run挂载模型目录、开启 GPU、映射 8000 端口，并传入 Hugging Face 模型 handle 与服务参数。 - 常用命令/配置：
--served-model-name要与 Hermes / Supermemory 中填写的模型名一致；--enable-auto-tool-choice、--tool-call-parser和--reasoning-parser是 Agent 工具调用场景的关键参数。 - 测试方式：用 Python
requests.post访问/v1/chat/completions，确认返回 JSON 中有choices[0].message.content。 - 适用场景：本地 GPU 服务器、私有化 Agent、内网模型服务、希望把开源模型接入 OpenAI 兼容应用的场景。
- 注意事项：模型基座不同会影响 parser 选择；FP8、AWQ、GGUF 等格式可能改变显存占用与功能支持，尤其是 image input、tool call 和 reasoning 输出需要逐项实测。