人的影响短暂而微弱，书的影响则广泛而深远。——普希金

LLM Monitoring：一张“本地化监控面板”，专门盯着第三方大模型接口别摸鱼

GitHub - Gozei/llmonitoring: 一个用于监控第三方大模型服务延迟和可用性的本地化监控面板。 · GitHub

如果你把第三方大模型服务当作“同事”，那它们其实都挺像人。

有的上班准点、说话干脆，首 token 来得飞快；
有的看起来在线，实际像在工位上发呆——请求发过去了，它半天不回；
还有的更绝：时好时坏、情绪不稳定，今天 99% 成功率，明天一半超时，问就是“网络波动”。

你当然可以靠感觉：
“这家模型最近好像慢了”“那个供应商好像不太稳”“今天调用成本怎么突然上去了”。
但感觉这东西，最怕的就是：事故发生后才发现自己早就闻到味道，只是没把证据攥在手里。

Gozei/llmonitoring 就像一个认真到有点偏执的“值班工程师”，坐在你本机里，盯着第三方大模型接口的状态与延迟——不吵不闹，但每一笔都记账。

它是一套 本地化监控面板，用来监控第三方大模型服务的 延迟 与 可用性：
定时或手动测试多个模型接口，记录：

  • 首 token 时间（TTFT）
  • 总耗时
  • 成功率
  • 历史延迟数据

它内置了 智谱 AI、京东言犀，以及一个非常关键的角色：通用 OpenAI 兼容接口适配。
也就是说，只要你的服务长得像 OpenAI API，它就能把你纳入“值班清单”。

它会做什么：把“接口表现”变成可追溯的历史

llmonitoring 的性格很简单：不信嘴、只信数据。

它的核心功能也因此很聚焦：

  • 多平台、多模型延迟监控
  • 支持 TTFT、总耗时、成功率 统计
  • 支持 手动测试：
    • 单个模型
    • 单个平台
    • 全部模型
  • 支持 平台和模型管理：新增、编辑、启停、删除
  • 支持 历史记录查看
  • 本地 SQLite 持久化，不依赖外部数据库
  • 支持通过环境变量指定 数据库文件位置，方便服务器和 Docker 挂载

你可以把它理解为：
“我不只是要知道它现在活没活着，我还要知道它过去一周是怎么活着的。”

它站在哪：技术栈像一台利落的工作台

它的技术栈挺现代，也挺实用——更像“为了长期值班”搭出来的配置：

  • Next.js 16 App Router
  • React 19 + TypeScript
  • Tailwind CSS v4
  • shadcn/ui + Radix UI
  • Recharts
  • SQLite + better-sqlite3
  • pnpm

前端用得顺手，图表能画出来；后端不搞复杂依赖���SQLite 直接落地，开箱即用，适合单机部署与轻量运维。

本地启动：让它先在你电脑里上岗

安装依赖

1
pnpm install

启动开发服务

1
pnpm dev

默认访问地址：

1
http://localhost:5000

如果你这台机器的 5000 端口已经被占了，让它换个座位就行：

1
PORT=5001 pnpm dev

然后访问：

1
http://localhost:5001

数据库：它把记忆写进 SQLite，且默认很克制

项目默认使用 SQLite，启动时会自动创建数据库文件和数据表。

默认数据库位置：

1
data/llmmonitoring.db

你也可以通过环境变量给它一个“更适合值班”的存储位置，比如专门挂载到持久化目录：

1
SQLITE_DATABASE_PATH=/data/llmmonitoring.db pnpm dev

它还留了一个备用变量名，像是担心你在不同环境下叫错：

1
DATABASE_PATH=/data/llmmonitoring.db pnpm dev

部署建议非常实际：
如果你要上服务器或者用 Docker，把数据库目录挂载到宿主机或持久化卷。
因为这个项目最重要的资产其实不是页面，而是它积累的历史数据——那是你判断供应商稳定性、评估接口质量的“证据仓库”。

常用命令：它的日常像一个标准工程项目

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 开发
pnpm dev

# 类型检查
pnpm ts-check

# 代码检查
pnpm lint

# 构建
pnpm build

# 生产启动
pnpm start

它不花里胡哨，就像一位靠谱的同事：每天按流程走，但每一步都能对齐质量。

生产部署：它对“本地化”很认真，但也考虑了服务器场景

直接部署到服务器时：

1
2
3
pnpm install
pnpm build
SQLITE_DATABASE_PATH=/data/llmmonitoring.db pnpm start

如果你使用 Docker，它反复强调的重点只有一个：

1
SQLITE_DATABASE_PATH=/data/llmmonitoring.db

并将容器内 /data 挂载到宿主机目录。

它像是在提醒你：
“我愿意在任何地方值班，但你得给我一个不会被重启冲掉记忆的抽屉。”

项目结构：从页面到 API，再到适配器与数据库层，一路清清楚楚

1
2
3
4
5
6
7
8
9
10
11
12
src/
├── app/                         # 页面和 API 路由
│   ├── api/                     # 监控、平台、模型、历史接口
│   ├── history/[id]/            # 模型历史记录页面
│   └── page.tsx                 # 首页监控面板
├── components/
│   ├── monitoring/              # 监控业务组件
│   └── ui/                      # shadcn/ui 基础组件
├── lib/
│   └── monitoring/              # 适配器、注册表、数据库操作层
└── storage/
    └── database/                # SQLite 客户端和共享类型

结构像一条清晰的责任链：

  • app 负责页面与 API
  • components 负责 UI 与业务呈现
  • lib/monitoring 负责“怎么测、测什么、怎么记”
  • storage/database 负责数据库与类型共享

它的“监控脑子”主要在 lib/monitoring，这也是后面扩展新平台时要动手的地方。

主要接口：它把“监控动作”变成一套可操作的 API

平台管理

1
2
3
4
5
GET    /api/platforms
POST   /api/platforms
GET    /api/platforms/[id]
PUT    /api/platforms/[id]
DELETE /api/platforms/[id]

模型管理

1
2
3
4
5
GET    /api/models
POST   /api/models
GET    /api/models/[id]
PUT    /api/models/[id]
DELETE /api/models/[id]

监控测试

1
2
3
POST /api/ping
POST /api/ping/models/[id]
POST /api/ping/platforms/[id]

状态和历史

1
2
GET /api/status
GET /api/history/[modelId]

初始化默认平台和模型

1
POST /api/init

这一套接口像是把“监控面板的手和脚”都暴露出来了：
你既可以用 UI 点点点，也可以把它当成服务，在自己的运维体系里用 API 驱动它做事。

它不止监控延迟：还有一套“接口稳定性 + 模型验真”的综合评估逻辑

很多监控系统到“接口能不能通、快不快”就停了。
但 llmonitoring 明显更不放心——它像一个疑心重的质检员，除了测速，还要验真。

它内置一套面向 “接口稳定性 + 模型验真” 的综合评估流程：

  • 对同一个模型执行 多轮真实调用
  • 每个维度先计算 0-100 子分
  • 再汇总成总分
  • 页面上每个评估卡片不仅展示分数，还保留成功次数、平均延迟、超时率等原始指标，让你能区分：
    • “服务不稳”
    • “能力不真”

当前主要维度包括：

  • 连通性：请求成功率 + 是否能稳定按要求返回指定短句
  • 身份一致：严格输出 JSON、校验字段结构，多次调用对模型名/知识截止时间/函数调用能力的稳定性检查（同时检查自…）
  • JSON 严格输出：不仅 JSON.parse，还校验结构与目标值是否完全命中，识别“看起来像 JSON 但不够严格”
  • 代码能力：要求输出结构化 JSON，包含可执行的 JavaScript 解法；系统会提取代码并运行隐藏测试用例，再结合复杂度声明评分
  • 长推理：以流式请求（stream: true）执行长回答测试，看关键需求覆盖、结构完整性、内容深度
  • 同题稳定：同一问题重复调用多次，结合成功率、输出长度稳定性、关键概念覆盖打分

它像是在说：

“你告诉我你是某某模型、你说你会函数调用、你说你能严格 JSON……
我不听你说，我让你现场演示，演不好就扣分。”

添加新的模型平台：它欢迎新人，但要求你按规矩来

如果你要扩展平台，它给的流程很像一个成熟项目的 onboarding：

  1. 在 src/lib/monitoring/ 下创建新的适配器文件
  2. 实现现有适配器接口
  3. 在 src/lib/monitoring/registry.ts 注册适配器
  4. 如需内置默认平台，在 src/app/api/init/route.ts 添加初始化配置

也就是说，它的适配层不是散装的——它有注册表，有规范，有初始化入口，你加新平台不是“加一段 if-else”，而是接入一个体系。

注意事项：它很坦诚，也很现实

  • 平台 API Key 存在本地 SQLite 数据库中，请保护好数据库文件
  • SQLite 适合单机部署。如果未来需要多实例并发部署，建议迁移到 PostgreSQL
  • 当前项目使用 pnpm，preinstall 会阻止 npm/yarn 安装

它像是在告诉你：

“我现在的定位就是本地化、单机友好、轻量部署。
你要把我变成多实例监控平台，那就别让 SQLite 扛着，你得给我换更适合的底座。”

结语：它不是来“看热闹”的，它是来“当证据”的

llmonitoring 最像人的地方是：它特别爱记账。

你的模型供应商说“我们稳定”，它不争辩，它记录；
你的接口今天 TTFT 很快，它不激动，它记录；
你怀疑某个平台偶发超时，它不猜测，它记录。

然后当你需要做决策的时候——
要不要切换供应商？要不要加降级？要不要把这条链路从强依赖变成可替换？
它把一叠干干净净的历史数据推到你面前。

它不替你做选择，但它让你的选择不再靠感觉。

如果你正好在用第三方大模型服务，且你也正好经历过：

  • “为什么今天这么慢？”
  • “怎么又超时？”
  • “到底是我这边的问题还是对方的问题？”
  • “这个模型到底是真本事还是幻觉型稳定？”

那这张本地化监控面板，可能正是你一直缺的那位“值班同事”。