Vessel:本地LLM可观测性代理,请求捕获与跨模型回放对比

在本地运行大语言模型(LLM)已经成为越来越多开发者的选择,但随之而来的一个痛点是:当你用多个 AI Agent 同时调用 Ollama 时,你根本不知道它们究竟发送了什么内容、消耗了多少 token、响应速度如何。近日,一位开发者在 Reddit 上分享了他的开源项目 Vessel——一个专为本地 LLM 打造的可观测性代理工具,试图从根本上解决这个「黑盒」问题。

为什么本地LLM需要可观测性代理
项目作者(GitHub 用户 spenceclark)介绍了自己遇到的真实场景:他有一个项目在 Ollama 上运行了一堆 Agent,但完全无法直观地看到这些 Agent 到底在做什么——完整的 prompt 是什么、token 数量多少、每秒生成多少 token(tok/s)、首个 token 的响应时间(time to first token)是多少。
Ollama 是目前最流行的本地大语言模型运行框架之一,它将模型下载、量化、推理服务封装为类似 Docker 的简洁体验,用户只需一条命令即可拉取并运行模型。Ollama 底层基于 llama.cpp 推理引擎,支持 GGUF 格式的量化模型,能够在消费级硬件上高效运行从 7B 到 70B 参数规模的各类开源模型。它提供的 RESTful API(包括 /api/chat 和 /api/generate 端点)兼容 OpenAI 的 API 格式,这使得很多基于 OpenAI SDK 开发的应用可以零成本迁移到本地运行。然而,Ollama 自身并不提供丰富的监控和日志能力,这正是 Vessel 试图填补的空白。
传统做法是在每一处调用点手动添加日志埋点,这不仅繁琐,而且难以维护。作者的思路更加巧妙:在 Ollama 前面架设一个代理层,所有经过的请求都会被自动捕获并存储到本地的 SQLite 文件中,再配上一个 Web UI 界面进行可视化管理。
这种「透明代理拦截」的设计模式在软件工程中有着悠久的历史。透明代理(Transparent Proxy)是一种经典的网络架构模式,代理服务器位于客户端和目标服务器之间,转发所有请求和响应,同时可以对流量进行记录、分析甚至修改。类似的思路在 Web 开发中已被广泛采用——Charles Proxy 和 mitmproxy 用于 HTTP 调试,Envoy 和 Nginx 在服务网格中进行流量管理。这种模式的最大优势是对客户端和服务端完全透明,无需修改任何业务代码,只需更改连接地址即可接入。Vessel 将这一成熟的架构模式引入 LLM 可观测性领域,意味着开发者无需修改任何现有代码,只需要把请求地址指向 Vessel 代理即可获得全链路的可观测性。这对于调试复杂的多 Agent 系统来说,是一个相当务实的方案。
这里值得补充一下「可观测性」这一概念的背景。可观测性(Observability)源自控制理论,指通过系统的外部输出来推断其内部状态的能力。在现代分布式系统中,可观测性通常包含三大支柱:日志(Logs)、指标(Metrics)和链路追踪(Traces)。与传统监控侧重于"已知的未知"不同,可观测性更强调帮助开发者发现"未知的未知"问题。在 LLM 应用场景中,可观测性尤其关键——大语言模型的行为具有非确定性,同一个 prompt 在不同上下文下可能产生截然不同的输出,如果没有完整的请求记录和性能指标,调试几乎无从下手。
Vessel核心功能:请求捕获、搜索与跨模型回放
全量LLM请求捕获与精确统计
Vessel 会读取 Ollama 原生的 /api/chat 和 /api/generate 接口的统计数据,因此它报告的 tok/s 和模型加载时间都是精确值,而非估算。作者特别提到一个实用细节:工具会标记「冷加载」(cold loads)的情况——他自己一半的「为什么这么慢」的谜团,最后发现只是模型在冷启动加载而已。
理解「冷加载」对于本地 LLM 用户至关重要。在 Ollama 的运行机制中,模型并非始终驻留在显存(VRAM)或内存中。当一个模型长时间未被调用,或者当其他模型需要占用显存资源时,Ollama 会将当前模型从显存中卸载。当再次收到该模型的推理请求时,系统需要重新将数 GB 甚至数十 GB 的模型权重从磁盘加载到显存中,这个过程就是「冷加载」。对于 7B 参数的量化模型,冷加载可能需要数秒;对于 70B 级别的大模型,等待时间可能长达数十秒。如果开发者不了解这一机制,很容易将冷加载造成的延迟误判为模型本身推理速度慢,从而做出错误的模型选型决策。Vessel 对冷加载状态的显式标记,帮助开发者准确区分模型加载延迟和实际推理延迟,这在性能调优中具有很高的实用价值。
捕获到的数据支持搜索、过滤,还可以按 Agent 打标签(per-agent tags),方便在众多请求中快速定位目标。
跨模型回放对比功能
这是 Vessel 最值得关注的差异化功能:你可以选取任意一条已捕获的请求,将它回放(replay)到另一个不同的模型上,然后把两个模型的响应结果和性能指标并排展示。
作者在演示视频中展示了将一个 qwen3.5 的请求回放给 hermes3 的效果。这个功能对于模型选型、效果对比和成本评估非常有价值——你不再需要手动复制粘贴 prompt 去逐个测试模型,而是可以基于真实生产流量直接做 A/B 对比。在传统的模型评估流程中,开发者往往需要构建专门的评测数据集、编写测试脚本、手动收集和比对结果,这一过程耗时且容易遗漏边界情况。而 Vessel 的回放功能让开发者能够直接利用真实业务场景中的请求数据进行对比,评测结果更贴近实际使用效果。
广泛的兼容性与集成能力
虽然 Vessel 最初是为 Ollama 设计的,但它的适用范围远不止于此:
-
兼容多种推理后端:支持 OpenAI 和 Anthropic 的兼容端点,也支持 LM Studio、llama.cpp、vLLM 等本地推理框架。作者的原话是「Anything with an API」——只要有 API,理论上都能接入。这些推理后端各有侧重:LM Studio 提供了友好的 GUI 界面,适合入门用户;llama.cpp 是底层推理引擎,提供最大的灵活性和最优的性能调优空间;vLLM 则以 PagedAttention 等技术著称,擅长高并发的批量推理场景。Vessel 的多后端兼容性使得开发者可以在统一的可观测性平台下自由切换和比较不同推理方案。
-
内置 MCP 服务器:Vessel 还托管了一个 MCP(Model Context Protocol)服务器,这意味着你可以让你的编程 Agent 实时查询这些捕获到的可观测性数据。MCP 是由 Anthropic 于 2024 年底推出的开放协议,旨在标准化 AI 模型与外部数据源、工具之间的交互方式。它采用客户端-服务器架构,定义了资源(Resources)、工具(Tools)和提示模板(Prompts)三种核心原语,使 AI Agent 能够以统一的方式发现和调用外部能力。Vessel 内置 MCP 服务器意味着 AI Agent 可以主动查询自身和其他 Agent 的运行指标——例如一个"监督者"Agent 可以实时了解其他 Agent 的 token 消耗和响应延迟,从而动态调整任务分配策略。这实现了一种"AI 监控 AI"的元认知能力,在自主化的多 Agent 系统中具有重要意义。
-
单一二进制文件,零依赖部署:整个工具打包为单个二进制文件,无需安装任何依赖,部署门槛极低。
开源免费、无遥测、隐私安全
作者在开头就做了明确的声明:这是他自己的项目,完全免费,采用 MIT 许可证,不需要注册账号,没有任何遥测(telemetry)或数据回传。对于注重隐私和数据安全的本地 LLM 用户来说,这一点尤为重要——毕竟本地部署的初衷之一就是不希望数据外泄。
「无遥测」这一承诺在当下的开发者工具领域显得尤为珍贵。近年来,不少开源工具因被发现暗中收集用户数据而引发信任危机。MIT 许可证作为最宽松的开源许可之一,允许用户自由使用、修改和分发代码,这意味着对安全性有更高要求的团队可以自行审计代码、确认不存在数据外传行为。所有捕获的请求数据都以 SQLite 文件的形式存储在本地磁盘上,不经过任何第三方服务器,数据主权完全掌握在用户手中。
项目地址位于 GitHub 的 spenceclark/Vessel。作者也很坦诚地在帖子结尾表示:「我真心想知道还缺什么功能」,欢迎社区反馈。
填补本地LLM工具链中可观测性的空白
随着本地 LLM 生态的成熟,模型推理、Agent 框架、UI 前端等工具层出不穷,但可观测性这一环节相对薄弱。云端 API 有各家平台自带的 Dashboard,而本地部署往往只能靠开发者自己搭建监控。
在云端 LLM 可观测性领域,已经涌现出一批成熟的工具:LangSmith(由 LangChain 团队开发)提供了全面的 LLM 应用追踪和评测能力;Helicone 专注于 API 调用的日志记录和成本分析;Langfuse 则以开源姿态提供类似 LangSmith 的功能。然而,这些工具大多面向云端 API 调用场景设计,默认需要将数据发送到云端进行分析。对于选择本地部署 LLM 的用户而言,使用这些云端可观测性工具在一定程度上违背了本地化部署的初衷。
Vessel 的价值在于用「透明代理 + 本地存储 + Web UI」这套轻量组合,为本地 LLM 提供了类似专业 APM(应用性能监控)的能力,同时保持了本地优先、隐私安全的原则。APM 在企业级软件开发中是核心基础设施,Datadog、New Relic、Dynatrace 等产品通过在应用层植入探针或使用代理拦截的方式,自动采集请求延迟、吞吐量、错误率等关键指标,并提供可视化 Dashboard 和告警能力。Vessel 将这种经过验证的监控范式带入了本地 LLM 生态,尤其是「跨模型回放对比」和「MCP 集成」两个功能,超出了普通日志工具的范畴,展现了对实际开发痛点的深刻理解。
对于正在构建多 Agent 系统、或需要频繁进行模型选型对比的开发者而言,Vessel 是一个值得尝试的工具。当然,作为一个新项目,它的稳定性、大规模数据下的性能表现,以及社区生态还有待时间检验。
相关推荐

AI模型迭代速度有多快?10小时就成"熊市"
AI模型迭代速度快到令人瞠目结舌,一个模型从最先进到过时可能只需几小时。本文分析AI模型快速迭代的原因、对开发者和企业的影响,以及如何理性应对这种技术加速度。

AI产品界面重复标签失误:细节质量为何不容忽视
某AI产品界面将Claude Sonnet 5重复列出两次,这一低级失误引发社区热议。本文从迭代压力、配置管理角度分析原因,并分享AI产品UI质量把控的实用经验。

Gemini学生免费一年能否开发App?实测对比Claude和ChatGPT
谷歌向学生提供一年免费Gemini Advanced,它的编程能力能否胜任App开发并上架App Store?本文对比Gemini、Claude、ChatGPT的代码生成能力,给出初学者实用建议。