AI PM Playbook

Appearance

Falcon 案例：大模型推理优化与服务平台产品拆解 ​

2026-05 更新版：本文将 Falcon 从“量化 + 推理引擎平台”的旧叙述，更新为面向 2026 年 AI 应用团队的 Inference Control Plane 案例。重点关注模型路由、成本治理、KV Cache、批处理、专属容量、可观测性与企业级推理治理。

一、背景 ​

1.1 行业背景 ​

2023-2025 年，大语言模型从“能用”进入“规模化可运营”阶段。到 2026 年，推理优化的核心问题已经不只是“如何把一个模型跑快”，而是：

  • 多模型、多供应商、多区域如何统一接入；
  • 高级推理模型、mini 模型、专用模型如何动态路由；
  • 长上下文、RAG、Agent、多模态任务如何控制成本；
  • 企业客户如何获得专属容量、数据驻留、审计与 SLA；
  • 模型价格和能力持续变化时，产品如何保持可替换性。

早期优化主要围绕 vLLM、TGI、TensorRT-LLM、量化、连续批处理、PagedAttention 等技术展开。现在，AI 应用团队更需要一个统一的 推理控制平面：既能接入模型，又能管成本、延迟、容量、合规和版本风险。

1.2 项目起源 ​

Falcon 项目由一家 AI 基础设施创业公司启动。最初目标是帮助团队部署和优化开源模型，但在客户实践中发现，真正阻碍 AI 产品规模化的不是单一模型性能，而是推理链路的运营复杂度：

  1. 同一个产品会同时使用旗舰模型、mini 模型、embedding、reranker、图像模型和代码模型；
  2. 成本不仅来自 token，还来自缓存、工具调用、Agent 重试和日志审计；
  3. 企业客户需要不同的数据区域、权限边界、审计日志和账单拆分；
  4. 模型供应商不断变动，产品必须避免被某个 API 或模型名锁死；
  5. 开发团队缺少“每个功能、每个客户、每个 Agent run 到底花了多少钱”的视图。

因此，Falcon 从“推理优化平台”升级为“AI 推理控制平面”。

二、产品定位 ​

2.1 核心价值主张 ​

Control every model call: quality, latency, cost, safety, and governance.

Falcon 的定位是面向 AI 应用和企业 AI 平台团队的推理控制层，提供：

  1. 统一模型网关：兼容主流 API 格式，接入多供应商、开源模型和私有模型；
  2. 智能路由：按任务复杂度、用户套餐、风险等级、延迟预算和成本预算选择模型；
  3. 成本治理：按用户、组织、产品功能、Agent run 追踪成本并设置预算；
  4. 推理优化：缓存、批处理、KV Cache、投机解码、量化、并发控制；
  5. 企业治理：数据驻留、审计日志、SLA、专属容量、权限与账单拆分；
  6. 评估闭环：线上 trace 回流到评估集，用于模型切换和 Prompt 回归测试。

2.2 目标客户 ​

客户类型核心痛点Falcon 价值
AI SaaS 公司多模型成本失控、质量不稳定模型路由 + 成本预算 + 灰度
企业 AI 平台团队安全、审计、数据驻留、统一接入企业网关 + 审计 + 策略控制
Agent 产品团队Agent step、工具调用、重试成本不可控run budget + trace + 工具治理
模型开发团队新模型部署和评估成本高部署管线 + benchmark + 影子流量
出海团队多区域延迟和供应商可用性区域路由 + fallback + SLA

2.3 竞品格局 ​

维度Falcon自建 vLLM / TGI云厂商托管模型单一模型 API
多模型统一路由强需自建中弱
成本治理强需自建中弱
企业审计强需自建中强中
私有部署强强取决于厂商弱
推理性能优化强强黑盒黑盒
供应商可替换性强中弱弱
Agent run 级治理强弱弱弱

三、核心设计 ​

3.1 系统架构 ​

text
┌──────────────────────────────────────────────────────────┐
│                    应用接入层                              │
│  OpenAI-compatible API | SDK | Batch API | Agent Runtime  │
├──────────────────────────────────────────────────────────┤
│                    推理控制平面                            │
│  路由 | 限流 | 鉴权 | 预算 | 灰度 | 降级 | 策略 | 审计       │
├──────────────────────────────────────────────────────────┤
│                    模型与工具网关                          │
│  LLM | Embedding | Reranker | Vision | Audio | Code | Tools │
├──────────────────────────────────────────────────────────┤
│                    推理运行时                              │
│  vLLM | TGI | TensorRT-LLM | 云模型 API | 私有模型服务       │
├──────────────────────────────────────────────────────────┤
│                    优化与缓存层                            │
│  Prompt Cache | KV Cache | Batch | Speculative Decoding   │
├──────────────────────────────────────────────────────────┤
│                    可观测性与成本层                        │
│  Trace | Token | Latency | Cost | Quality | Safety | Billing│
├──────────────────────────────────────────────────────────┤
│                    企业治理层                              │
│  SSO | RBAC | Data Residency | Audit Log | SLA | DPA       │
└──────────────────────────────────────────────────────────┘

3.2 智能模型路由 ​

Falcon 的核心不是“总是使用最强模型”，而是让每次调用都匹配最合适的模型和策略。

text
请求进入 → 意图分类 → 风险分级 → 成本预算 → 延迟预算 → 模型选择 → 响应评估
路由维度示例
任务复杂度简单分类走 mini 模型，复杂分析走高级推理模型
用户套餐免费层限制高成本模型，企业层可使用专属容量
风险等级高风险请求进入保守模型和人工审批路径
延迟预算交互式任务优先低延迟，离线任务可进批处理
成本预算接近预算上限时自动降级或暂停
数据区域按客户数据驻留要求选择区域和供应商
历史表现基于线上质量和失败率动态调整路由权重

3.3 成本控制设计 ​

Falcon 将成本拆到可运营的粒度：

粒度典型用途
用户级防止个人滥用
组织级企业预算控制
功能级看哪个 AI 功能最烧钱
模型级比较模型 ROI
工具级分析搜索、代码执行、OCR 等成本
Agent run 级控制多步任务和重试成本
客户级企业账单与成本归因

成本公式：

text
总成本 = 输入 token + 缓存输入 token + 输出 token
      + embedding / rerank / 图像 / 音频成本
      + 工具 API 成本
      + Agent step 与重试成本
      + 日志、审计、存储和专属容量成本

3.4 推理优化能力 ​

能力作用产品价值
Continuous Batching合并并发请求，提高吞吐降低单位成本
PagedAttention / KV Cache 管理降低长上下文显存浪费支持长文档和多轮会话
Prompt Cache缓存重复系统提示和文档前缀显著降低输入成本
Speculative Decoding小模型草稿 + 大模型验证降低解码延迟
QuantizationINT8 / INT4 / FP8 等降低部署成本
Batch API / 离线队列非实时任务低优先级处理用延迟换成本
多区域路由就近访问和灾备降低延迟，提高可用性
Fallback模型失败自动切换提高稳定性

3.5 评估与灰度 ​

Falcon 把“模型切换”视为产品发布：

  1. 离线评估：固定 benchmark 对比质量、格式、安全；
  2. 影子流量：新模型后台生成，不影响用户；
  3. 小流量灰度：按用户、组织或功能分桶；
  4. 成本观察：比较 P50 / P95 单任务成本；
  5. 失败样例回流：进入回归集；
  6. 自动回滚：质量、成本或安全指标越界时回滚。

四、产品关键决策 ​

决策 1：从“模型部署”转向“推理控制” ​

早期客户关心模型能不能跑起来，成熟客户更关心：

  • 成本能不能归因；
  • 质量能不能评估；
  • 风险能不能控制；
  • 模型能不能替换；
  • 企业审计能不能过。

因此，Falcon 的产品重心从部署工具转向控制平面。

决策 2：模型名不进入业务逻辑 ​

系统内部不直接写 gpt-x、claude-y 这类模型名，而是抽象为能力层级：

yaml
model_policy:
  default: standard_text
  simple_tasks: mini_text
  complex_reasoning: premium_reasoning
  pii_sensitive: private_region_model
  batch_jobs: low_priority_batch

这样模型供应商和版本变化时，业务逻辑不需要重写。

决策 3：Agent run 必须有预算 ​

Agent 是推理成本的放大器。Falcon 为每个 run 设置：

  • 最大 step 数；
  • 最大工具调用次数；
  • 最大运行时长；
  • 最大 token / credit；
  • 高风险动作审批；
  • 失败重试上限。

决策 4：企业能力单独产品化 ​

企业客户愿意为以下能力付费：

  • 专属容量；
  • 数据驻留；
  • 私有部署；
  • 审计日志；
  • 用量报表；
  • SSO / SCIM；
  • SLA；
  • 安全与合规支持。

这些不是“附属功能”，而是企业版的核心价值。

五、指标体系 ​

指标类别指标
质量任务成功率、幻觉率、格式合规率、引用正确率
延迟TTFT、P50、P95、P99、超时率
成本单任务成本、P95 用户成本、缓存命中率、重试放大系数
稳定性错误率、fallback 率、供应商失败率
Agent平均 step、工具失败率、run 成功率、人工接管率
安全越权拦截率、敏感数据泄露率、策略命中率
商业企业席位数、承诺用量、毛利率、扩容率

六、踩坑与教训 ​

6.1 只优化推理速度不够 ​

客户最终关心的是端到端任务成功率。单模型速度变快，如果工具调用失败、RAG 片段错误或输出格式不稳定，产品体验仍然失败。

6.2 成本不是平均值问题，而是尾部问题 ​

少数重度用户、长上下文任务、Agent 循环和失败重试会贡献大部分成本。必须监控 P95 / P99 成本，而不是只看平均成本。

6.3 缓存必须和权限绑定 ​

RAG 和企业知识库场景中，缓存如果不绑定用户权限、组织、文档版本和数据区域，可能造成严重数据泄露。

6.4 模型切换必须产品化 ​

模型升级不是工程配置变更，而是产品体验变更。必须有灰度、评估、回滚和客户沟通机制。

七、PM 可复用清单 ​

设计推理平台或模型网关时，PM 应确认：

  • [ ] 是否支持多模型、多供应商、多区域；
  • [ ] 是否有任务级模型路由；
  • [ ] 是否能按用户、组织、功能、模型拆成本；
  • [ ] 是否支持预算、限额和熔断；
  • [ ] 是否支持 prompt cache 和 RAG cache；
  • [ ] 是否记录完整 trace；
  • [ ] 是否支持模型灰度和回滚；
  • [ ] 是否支持企业数据驻留和审计；
  • [ ] 是否有 Agent run 预算；
  • [ ] 是否能把线上失败样例回流到评估集。

八、结论 ​

Falcon 的案例说明：2026 年的推理优化不再只是“让模型跑得更快”，而是围绕 质量、成本、延迟、安全、合规、可替换性 建立完整控制平面。

对 AI PM 来说，最重要的产品判断是：不要把模型调用当成黑盒 API，而要把每一次推理视为一个可路由、可预算、可观测、可回滚的产品行为。

MIT License

Copyright © 2026 prodthinkpm