产品经理 Wiki

Appearance

术语表 · AI 技术认知 ​

本文件聚合 技术认知/05-AI与Agent/ 主题下的高频术语精简卡片，便于快速查询。深度内容请跳转到对应原文。

QPS（Queries Per Second） ​

定义：每秒查询数，衡量服务的请求处理能力。计算公式：总请求数 / 时间窗口（秒）。

与相邻术语区分：

  • RPS（Requests Per Second）：业内常与 QPS 混用，几乎同义
  • TPS（Transactions Per Second）：每秒事务数，含完整业务流程，量级通常 < QPS
  • Token throughput：LLM 场景下真正的成本单位。1 个请求可能消耗 200~5000 token，QPS 看不到这个差异

典型量级（RAG 链路，2026-05 时点参考）：

链路段单实例 QPS
embedding（CPU 节点）几千
向量召回（Faiss/Milvus 单机）几百~千
rerank（GPU 单卡）几十
LLM 生成（GPU 单卡）个位数

常见误用：把入口 nginx RPS 当 LLM 限流单位 → 长 query 把 GPU 队列堆爆。LLM 限流应按 token 维度，不按 QPS。

本仓库相关文档：

RPS（Requests Per Second） ​

定义：每秒请求数，衡量服务在入口侧每秒接收/处理的 HTTP 请求数量。计算公式：总请求数 / 时间窗口（秒）。

与相邻术语区分：

  • QPS（Queries Per Second）：在 Web/API 场景下与 RPS 几乎同义；在数据库语境里 QPS 更偏"查询请求"，RPS 更偏"网关层 HTTP 请求"，但工程实践中常互换
  • TPS（Transactions Per Second）：每秒事务数，1 笔 transaction 可能包含多个 RPS（如下单 = 鉴权 + 库存 + 支付多个请求）
  • Token throughput：LLM 后端真正的成本单位，与 RPS 不可线性换算——1 个 RPS 可能对应 200~5000 token

典型应用位置：

位置作用
网关 / nginx 限流按 RPS 挡爬虫、DDoS、异常突发流量
负载均衡器容量规划估算单实例能承接的入口压力
SLA 监控业务侧通用流量指标，便于跨服务横向对比

常见误用：

  • 用入口 RPS 给 LLM 限流：入口 1 个 RPS 到 LLM 可能烧 5000 token，按 RPS 配阈值要么太严（拒掉便宜请求）要么太松（GPU 队列爆）→ LLM 必须按 token 限流，不按 RPS
  • RPS 与 QPS 混着用但语义不一致：跨团队对齐时先约定单位，避免一边按"数据库 query"算、一边按"HTTP request"算

本仓库相关文档：

TPS（Transactions Per Second） ​

定义：每秒事务数，衡量系统每秒能够完成的"完整业务事务"数量。一笔 transaction 通常对应一个有完整业务语义、可成功/失败判定的端到端流程。

与相邻术语区分：

  • QPS / RPS：单位是"请求"，1 笔 transaction 可能由多个 QPS/RPS 组成（如下单事务 = 鉴权 + 库存 + 支付 + 通知 共 4 次请求）
  • 量级关系：通常 TPS < QPS < 单接口 RPS，TPS 是更"重"的指标
  • LLM 场景下的 TPS（Tokens Per Second）：完全不同的概念！这里的 TPS 是 token 生成速率，单位 token/秒，用于度量 LLM 推理速度，不要与"事务"TPS 混淆

典型应用场景：

场景TPS 含义
数据库 / 交易系统每秒提交的事务数（含 commit / rollback）
支付 / 电商每秒成交订单数
银行核心每秒清算笔数（行业 SLA 核心指标）
性能压测（JMeter/Locust）每秒完成的"业务流程数"，区别于单接口 RPS

常见误用：

  • TPS 与 QPS/RPS 混报：例如压测报告里写"QPS 1000"，实际是统计的端到端事务，应该叫 TPS——单位错了会让团队误判扩容方向
  • LLM 场景下的歧义：在 LLM 推理上下文里说 TPS 时，绝大多数指的是 Tokens Per Second（推理吞吐），与传统事务 TPS 含义完全不同，跨团队沟通时务必明示单位
  • 用 TPS 给 LLM 限流：LLM 推理本身没有"事务"概念，限流应按 token 维度，TPS（事务）和 RPS 都不合适

本仓库相关文档：

TPM（Tokens Per Minute） ​

定义：每分钟 token 数，LLM API 服务的核心限流单位之一。统计窗口为 1 分钟内所有调用消耗的 token 总量（通常 input + output 合并计算）。

与相邻术语区分：

  • RPM（Requests Per Minute）：同一限流体系的孪生指标，统计调用次数而非 token 量。LLM API 通常 TPM + RPM 双闸口同时配
  • TPS（Tokens Per Second）：分钟 vs 秒的时间窗口差异，60 秒粒度更平滑、便于配额；秒级粒度更适合推理速度度量
  • QPS / RPS：单位是"请求数 / 秒"，不反映 token 实际成本——这是为什么 LLM 限流要切到 TPM 而非 QPS 的根本原因

典型限流配置（行业惯例参考，2026-05 时点）：

维度示例配额
个人开发者 Tier 130K~50K TPM / 500 RPM
企业账号 Tier 4+数百万 TPM / 数千~数万 RPM
计算公式input_tokens + max_output_tokens 累加扣额
重置周期滚动 60 秒窗口（非整点重置）

典型应用位置：

  • LLM Gateway 前置限流（自研 / Portkey / LiteLLM）
  • 按 user_id × model 维度配置二维配额（不同模型 TPM 上限不同）
  • 配合 Redis 令牌桶实现，超额返回 429

常见误用：

  • 只配 RPM 不配 TPM：短 query 还行，遇到长 context 单请求烧 8000 token，几次就把 GPU 队列堆爆
  • input 和 output token 分开算：实际计费 / 限流通常合并扣，output 用预估值（如 max_tokens=800）先扣，请求完成后按真实值结算
  • 窗口边界对齐错误：把"每分钟"理解为整点重置而非滚动窗口，导致突发流量在分钟切换时连续打满两次配额

本仓库相关文档：

RPM（Requests Per Minute） ​

定义：每分钟请求数，LLM API 服务限流体系中与 TPM 配对使用的次数维度阈值。统计窗口为 1 分钟内的调用次数总数。

与相邻术语区分：

  • TPM（Tokens Per Minute）：同一限流体系的成本维度阈值，两者通常双闸口同配——任一打满即拒
  • RPS（Requests Per Second）：秒级粒度版本，量级关系约为 RPM ≈ RPS × 60，但 LLM API 普遍用分钟粒度（容忍突发更友好）
  • QPS：业务侧通用流量指标，与 RPM 单位可换算但语境不同（QPS 是入口/数据库侧，RPM 是 LLM API 配额侧）

为什么 LLM 同时需要 TPM 和 RPM：

仅配 TPM仅配 RPMTPM + RPM 双闸口
大量短请求虽不烧 token，但会打爆调度/连接长 context 请求虽次数少，但 GPU 队列直接爆短请求被 RPM 挡、长请求被 TPM 挡，两边都覆盖

典型配置组合：

  • 个人 Tier 1：30K TPM + 500 RPM
  • 企业 Tier：数百万 TPM + 数千 RPM
  • 双闸口比例经验值：TPM / RPM ≈ 60~200（平均单请求 60~200 token，太高则可能存在恶意大 context 流量）

常见误用：

  • 只用 RPM 限流不配 TPM：见 TPM 卡片的同名误用，是 LLM 限流最高频的踩坑
  • RPM 和 QPS 混算：例如把 "1000 QPS" 当成 "1000 RPM"——前者是后者的 60 倍，配额会差两个量级
  • 不区分 model 维度：Sonnet 和 Haiku 用同一份 RPM 配额，导致便宜模型挤占贵模型的预算 / 反之亦然

本仓库相关文档：

P99（99th Percentile Latency） ​

定义：百分位延迟指标，"P99 = N ms" 表示 99% 的请求延迟 ≤ N ms，只有最慢的 1% 请求超过这个值。把所有请求按延迟升序排列，取第 99 个百分位的那个值。

与相邻百分位区分：

指标含义关注点
P50（中位数）50% 请求 ≤ 该值典型用户体验，反映"大多数情况"
P9595% 请求 ≤ 该值普通 SLA 阈值，覆盖大部分场景
P9999% 请求 ≤ 该值长尾用户体验，反映"最差 1%"
P999（P99.9）99.9% 请求 ≤ 该值极端长尾，金融 / 高频交易场景关注
Avg（平均值）总延迟 / 总请求数不要单独看，会被极端值或大批短请求拉偏

为什么必须看 P99 而不是平均延迟：

  • 平均延迟 = 200ms 看似良好，但可能 P99 = 5s——意味着每 100 个用户就有 1 个等 5 秒，体验直接崩
  • 大型服务每秒数千请求时，P99 的 1% 是几十个真实用户在受影响
  • 长尾问题（GC 暂停、缓存击穿、慢查询、batch 等队友）只在 P99/P999 暴露

典型应用场景：

场景关注百分位
C 端 Web/AppP95（普通 SLA） + P99（用户感知红线）
LLM 推理服务P99 必须盯——continuous batching 会拉长尾
金融 / 支付P999 + 最大值（监管要求）
离线批处理看 Avg / 吞吐即可，P99 不敏感

经验阈值判断：

  • P99 / P50 < 3 倍：分布健康
  • P99 / P50 = 3~5 倍：有长尾，需关注
  • P99 / P50 > 5 倍：长尾严重，必须排查（在 LLM 场景常是 continuous batching 把短请求拖累了）

常见误用：

  • 只看平均延迟做 SLA：平均值掩盖长尾，真实用户体验在 P99
  • P99 当瞬时值看：百分位指标必须配统计窗口（如 1 分钟、5 分钟滚动），单点 P99 没意义
  • 优化 P99 时砍掉慢请求样本：把超时请求直接丢弃统计，P99 数值好看了但实际用户体验更差，属于自欺欺人

本仓库相关文档：

本体论（Ontology，业务语义层） ​

定义：把企业的"业务对象 + 关系 + 状态 + 动作 + 规则"显式建模为一张可被 AI 与人共同理解的语义网络，让 AI 不再面对一堆零散文档与字段，而是面对一个结构化的世界模型。源头是哲学/知识表示领域，在 AI 工程语境下特指 Palantir Foundry / AIP 的 Ontology 层——把"客户 / 订单 / 产线 / 合同"等业务实体一次性建好，所有上层 Agent、报表、决策都基于同一份本体推理。

Palantir Ontology 的七类核心组件：

#组件作用
1对象类型（Object Type）客户、订单、设备等业务实体
2链接类型（Link Type）对象之间的关系（客户—订单—产品）
3属性（Property）每个对象的字段
4动作类型（Action Type）可被触发的业务操作（创建/审批/调度）
5函数（Function）业务规则与计算逻辑
6状态机（State Machine）对象生命周期阶段
7反馈回路（Feedback Loop）结果回流校准本体

与相邻术语区分：

  • 知识图谱（Knowledge Graph）：知识图谱关注"事实存储与查询"（三元组），本体论关注"业务运行结构"——本体可以驱动动作，知识图谱通常只能被查询
  • 数据中台：数据中台解决"数据可用"，本体论解决"业务可被 AI 理解"；数据中台是底料，本体论是骨架
  • 领域模型（Domain Model）：DDD 中的领域模型是软件工程内部概念，本体论是跨系统、跨 AI/人/工具的共享语义层
  • 业务操作系统：本体论是骨架，业务操作系统是骨架 + 执行层（动作/规则/反馈）的完整产品形态

为什么 AI 时代本体论重新升值：

  • LLM 擅长生成内容，但对企业内部对象与关系一无所知——必须靠本体喂结构
  • 没有本体的 AI 应用 = 把 LLM 套在一堆字段上，每个场景都要重新对齐语义
  • 有本体的 AI 应用 = 一次建模，所有 Agent / 报表 / 工作流复用同一份"世界观"

常见误用 / 踩坑：

  • 把本体论当 ER 图升级版：本体论的核心是"动作 + 状态 + 规则 + 反馈"，只画对象关系等于只搭了骨架的一半
  • 以为买 Foundry 就有本体：本体是"建出来的"，不是"装出来的"——核心工作是业务建模师与 SME 一起把领域知识结构化
  • 本体颗粒度过细：把每个字段都建成对象，最后本体本身比业务还复杂；正确做法是从结果倒推，只建影响决策的关键对象
  • 本体一次性建完不迭代：本体应随业务演化，配套"反馈回路"持续修正

本仓库相关文档：

MaaS（Model-as-a-Service，模型即服务） ​

定义：把大模型推理能力封装成 API / SDK 形式按调用量计费的云服务模式，类比 IaaS / PaaS / SaaS——客户不拥有模型权重，不维护算力，只为"调用一次推理"付费。代表厂商：OpenAI / Anthropic / 阿里云百炼 / 火山方舟 / 字节豆包 API。

与 IaaS / PaaS / SaaS 的层级关系：

层级卖什么计费单位代表
IaaS算力 / 网络 / 存储实例·小时 / GBAWS EC2、阿里云 ECS
PaaS运行时 / 数据库 / 中间件实例·小时 / 请求数RDS、K8s 托管
SaaS完整业务应用席位·月Salesforce、钉钉
MaaS大模型推理能力Token（input + output）OpenAI API、Anthropic API、豆包 API

Token 经济产业链中的定位（五环架构）：

  1. 算力层（GPU / CPO 光模块）→ 卖算力
  2. 基座模型层（OpenAI / Anthropic 等）→ 卖训练成果
  3. MaaS 层（API 服务）→ 卖推理调用，token 是计量单位
  4. 应用层（Agent / Copilot / 垂直产品）→ 卖业务价值
  5. 数据/知识层（向量库 / Ontology）→ 卖企业适配能力

与相邻术语区分：

  • LLM API：LLM API 是 MaaS 的实现形态，MaaS 是更广义的商业模式（涵盖 LLM + 多模态 + 嵌入 + 重排等）
  • 私有化部署：MaaS 是"调云端 API"，私有化部署是"模型权重下沉到客户机房"——两者是数据主权场景下的对立选择
  • AIaaS / Agent-as-a-Service：AIaaS 更广义，包括视觉/语音等传统 AI 服务；Agent-as-a-Service 是 MaaS 之上的更高层封装（含规划/工具/记忆）

典型商业特征：

  • 边际成本不趋零：每次调用都消耗 GPU 算力，与传统 SaaS 完全不同
  • 定价权回归基座厂商：上层应用议价能力弱，价格战由基座层主导（豆包 0.0008 元/千 token 案例）
  • 杰文斯悖论：单价下降反而拉升总支出（见杰文斯悖论卡片）

常见误用 / 踩坑：

  • 把 MaaS 当 SaaS 估值：MaaS 边际成本不趋零，毛利结构与 SaaS 差异巨大，按 SaaS PSR 估值会严重高估
  • 应用层定价照搬订阅制：底层 MaaS 按 token 计费，上层若按席位订阅，重度用户会把毛利吃光——必须设置用量上限或按效果分成
  • 多模型混用不分账：Sonnet 和 Haiku 都走同一份预算，无法追踪哪个场景烧了多少 token

本仓库相关文档：

杰文斯悖论（Jevons Paradox） ​

定义：技术效率提升 / 单位成本下降时，总消耗量不降反升的反直觉现象。19 世纪经济学家 William Stanley Jevons 研究蒸汽机效率提升后煤炭消耗反而暴涨，提出该悖论。在 AI 时代特指：单 token 推理成本暴跌 → 调用次数与上下文长度爆炸式增长 → 企业总 AI 支出反而大幅上升。

AI 时代的典型量化：

维度变化来源
单 token 推理成本2023→2026 累计下降 约 280×行业普遍数据
企业 AI 总支出同期上升 约 2.4×同期对比
单次调用平均 token 量上下文从 4K→200K，单次消耗 数十倍长上下文普及
调用频率Agent 化后单任务调用 数十~数百次Agent 范式

为什么会出现悖论：

  • 场景下沉：单价高时只有高价值场景用得起，单价低后客服 / 摘要 / 翻译 / 代码补全全部接入
  • 使用范式升级：从"一问一答"升级到"Agent 多轮 + 工具调用 + 反思"，单任务 token 量翻数十倍
  • 上下文膨胀：长上下文窗口（128K / 1M）普及，单次调用塞入大量参考资料
  • 能力上瘾：用过就回不去，团队对 AI 的依赖与日俱增

与相邻概念区分：

  • 规模效应（Scale Effect）：规模效应是"单位成本下降"，杰文斯悖论是"单位成本下降导致总成本上升"——前者是因，后者是连锁反应
  • 回弹效应（Rebound Effect）：杰文斯悖论是回弹效应的极端形式——常规回弹效应只是"部分抵消节约"，杰文斯悖论是"完全反转"
  • 诱导需求（Induced Demand）：交通领域的"扩路反堵"，与杰文斯悖论同源逻辑

对 AI PM / CFO 的启示：

  • 不要用单价下降做预算预测：基座厂商每年降价 50%，CFO 按线性外推预算会严重低估实际支出
  • 必须按 token 维度而非席位维度计费：用户人数稳定，但人均消耗 token 会指数级增长
  • 降本工程的真正价值在于压住总支出曲线：不是省单价，而是控总量（缓存 / 路由小模型 / 工作流分层）

常见误用 / 踩坑：

  • 以为降价 = 省钱：模型降价时不做用量管控，结果总账单不降反升
  • 把杰文斯悖论当负面：对基座厂商和云厂商是正面（市场扩大），对企业客户是预算挑战——视角不同结论相反
  • 只用单价压供应商：忽略 token 用量优化，相当于只看油价不看油耗

本仓库相关文档：

MIT License

Copyright © 2026 Derek