83.3 工具与产品清单
一句话
清单不是排行榜，是**「在什么约束下选谁」：每个条目必须带主场章节 + 主线版本 + 淘汰条件**；给不出淘汰条件的推荐，本质是广告。
五条选型纪律（比清单本身更重要）
| 纪律 | 具体做法 | 违反的后果 |
|---|---|---|
| 版本锚定 | 每个版本都标「核对日期」，本表为 2026-10；版本是时间戳，不是永久事实 | 半年后有人照表选了已 EOL 的版本 |
| 一个能力域一个主选 | 主选 + 一个备选，第三个只在迁移期存在 | 三套并存 = 三套运维 + 三套招聘要求 |
| N-1 上生产 | 新大版本等第一个 patch 或第二个小版本再上核心链路 | 首周踩到已修复的回归 |
| 退出成本先算 | 先问「怎么走」，再问「多好用」 | 数据模型绑定后，迁移成本是引入成本的 10 倍 |
| 托管优先，除非 | 除非 TCO 更低、合规要求、或该能力就是你的竞争力 | 自建中间件养一个团队，只为省下云账单的 20% |
🔑 一句判据：「如果我明天要换掉它，代价是什么？」 答不出，就不是选型，是绑定。
一、版本锚点表（2026-10 核对）
这张表的作用是校准时间感：如果你的印象还停在「K8s 1.28 / PG 15 / Redis 7」，说明你的知识落后了 3–4 个大版本。
| 产品 | 主线版本 | 关键事实 | 备注 |
|---|---|---|---|
| Kubernetes | 1.37（1.36/1.35 仍在支持期） | 每年 3 个版本，支持约 14 个月 | 客户端与服务端版本偏差 ≤ 1 个小版本 |
| containerd | 2.4 | 2.x 起镜像与运行时分离更彻底 | CRI 实现的主流选择 |
| Docker Engine | 29 | 开发机用它，生产用它跑容器要慎重 | 生产直接用 containerd 更省一层 |
| Envoy | 1.40 | 数据面事实标准；Gateway API 是配置入口 | 见 47.1 反向代理 的转发语义 |
| Gateway API | 1.6 | Ingress 的继任者，按角色分资源 | 新项目直接上，不要再写 Ingress |
| Cilium | 1.20 | eBPF 数据面，NetworkPolicy + 可观测性一体 | 内核版本要够新，老内核功能受限 |
| Istio | 1.31 | ambient 模式（无 sidecar）已可用 | 见 30.5 Service Mesh 与 Sidecar |
| etcd | 3.7 | K8s 的默认协调层 | 见 48.6 产品 (etcd / Consul / ZooKeeper / Nacos) |
| Helm | 4.3 | 4.x 起与服务端交互方式变化 | 与 Kustomize 二选一，别混用 |
| Argo CD | 3.5 | GitOps 拉模式的标准实现 | 与 Flux 二选一 |
| Flux | 2.9 | 更「云原生」的 controller 组合 | 团队熟悉 Helm 时 Argo CD 更直观 |
| KEDA | 2.21 | 事件驱动伸缩（队列长度、Kafka lag） | HPA 只管 CPU/内存，KEDA 补上业务指标 |
| Kyverno | 1.19 | YAML 表达的策略引擎 | 比 OPA/Rego 学习曲线低 |
| Terraform | 1.16 | BSL 许可 | 见下方「许可证」表 |
| OpenTofu | 1.13 | Terraform 的 MPL 分支，Linux Foundation | 新项目在意许可就选它 |
| Harbor | 2.15 | 镜像仓库 + 签名 + 扫描 | 云上直接用托管 registry |
| PostgreSQL | 18.6（18 于 2025-09 发布） | 默认 OLTP 首选 | 扩展生态是它的护城河 |
| MySQL | 8.4 LTS 线（创新线版本号近年改为年份制） | 生态与运维人才最多 | 具体版本以官网 EOL 表为准 |
| Redis | 8.10 | 8.x 起把多种数据结构统一进核心 | 许可变更见下表 |
| Valkey | 9.1 | Redis 的 Linux Foundation 分支 | 云厂商大规模采用 |
| Kafka | 4.x | 4.0 起只支持 KRaft，ZooKeeper 已移除 | 老集群升级前先迁元数据 |
| Pulsar | 5.0 | 存算分离、多租户 | 运维复杂度高于 Kafka |
| NATS | 2.15 | 轻量、JetStream 持久化 | 适合边缘与内部 RPC |
| RabbitMQ | 4.3 | 4.x 起 Khepri 元数据存储可选 | 复杂路由仍是它的主场 |
| ClickHouse | 26.9（年份制版本号） | 单表聚合的性价比标杆 | 不适合高频点更新 |
| Elasticsearch | 9.5 | 检索 + 向量混合查询 | 许可与成本要提前算 |
| OpenSearch | 3.9 | ES 7.11 分支，Apache 2.0 | 云厂商托管普遍 |
| MongoDB | 9.0 | 文档模型 + 聚合管道 | SSPL，云上多为托管版 |
| Ceph | 20.2 | 统一块/文件/对象存储 | 自建对象存储的常见底座 |
| Prometheus | 3.15 | 3.x 起原生支持 OTLP 摄入 | 长期存储仍需远端写 |
| Grafana | 13.2 | 可视化 + Loki/Tempo/Mimir 全家桶 | AGPLv3 |
| OpenTelemetry SDK | 1.45 | 埋点与协议的事实标准 | 见 50.9 OpenTelemetry 标准 |
| Jaeger | 2.22 | 2.x 基于 OTel Collector 重构 | 新项目直接用 OTel + Tempo |
| Keycloak | 26.8 | 开源 IdP 的默认选项 | 定制主题与多租户要评估工作量 |
| OpenBao | 2.7 | Vault 的 MPL 分支 | 在意许可时的替代 |
| Dapr | 1.18 | 多运行时：状态、发布订阅、工作流 | 见 33.4 多运行时 |
| PyTorch | 2.14 | 训练与推理的通用底座 | 推理侧通常再套 vLLM/SGLang |
| vLLM | 0.32 | PagedAttention + continuous batching | 通用 GPU 推理的首选 |
| SGLang | 0.5 | RadixAttention，前缀共享强 | 多轮/共享 system prompt 场景优势明显 |
| LangGraph | 1.2 | 有状态图执行，持久化 checkpoint | 只有 1–2 步时别用 |
| MCP 规范 | 2026-07-28 版 | 工具/资源/提示的标准化连接 | 见 83.2 参考文献 第六节 |
| A2A | v1.0 | Agent 间任务协作 | Linux Foundation 治理 |
⚠️ 这张表只用来校准，不用来抄版本号。真正选型时打开官网的 release / EOL 页面，看当天的支持矩阵。
二、按层选型：主选、备选与淘汰条件
2.1 L0 运行时与云原生
| 能力域 | 主选 | 备选 | 什么时候别用主选 |
|---|---|---|---|
| 容器编排 | Kubernetes | K3s / Talos / 云托管 K8s | 团队 < 5 人、服务 < 10 个：单机 + systemd + 容器更省心 |
| 容器运行时 | containerd | CRI-O | 需要 Docker 特有功能（buildx、compose）时用 Docker 开发，不上生产 |
| 强隔离沙箱 | Firecracker / gVisor | Kata Containers | 跑不可信代码（AI 生成代码、多租户函数）才需要 |
| 入口 | Gateway API + Envoy | Traefik / Nginx Ingress | 只有 3 条路由时，Ingress 足够 |
| 服务网格 | Istio ambient | Linkerd / Cilium Service Mesh | 没有专职 SRE：先上重试/超时/熔断的库，别上网格 |
| 网络与策略 | Cilium | Calico | 内核 < 4.19 时 eBPF 能力受限 |
| GitOps | Argo CD | Flux | 只有一个集群、一天发一次：CI 直推更简单 |
| IaC | OpenTofu / Terraform | Pulumi / Crossplane | 全部资源都在一个云、且用托管控制台：先别引入 IaC 债 |
| 策略即代码 | Kyverno | OPA Gatekeeper | 团队没人维护策略：先上 CI 检查，别上准入控制 |
| 伸缩 | KEDA + HPA | Karpenter（节点层） | 负载平稳的系统：固定副本更便宜 |
| 镜像仓库 | Harbor | 云托管 registry | 单地域、小团队：云托管省事且更便宜 |
2.2 数据与消息
| 能力域 | 主选 | 备选 | 什么时候别用主选 |
|---|---|---|---|
| OLTP | PostgreSQL 18 | MySQL 8.4 | 需要极致简单的主从 + 全球最多 DBA：MySQL |
| 分布式 SQL | TiDB | CockroachDB / YugabyteDB | 单表 < 1 亿行：单机 PG 分库都比分布式数据库便宜 |
| 缓存 | Redis 8 / Valkey 9 | KeyDB / 云托管 | 只需要 KV + TTL：云托管省运维 |
| 消息 | Kafka 4 | Pulsar / RocketMQ / NATS / RabbitMQ | 消息量 < 10 万/天：数据库 outbox + 定时任务更简单 |
| 延迟/定时消息 | RocketMQ / Kafka + 调度器 | 数据库轮询 | 精度要求秒级以下：别用消息队列硬做 |
| 事务与长流程 | Temporal | Dapr Workflow / 自研状态机 | 流程只有 3 步且不会变：状态机表更可控 |
| OLAP | ClickHouse | StarRocks / Doris / DuckDB | 需要高频点更新：ClickHouse 不擅长 |
| 湖仓 | Iceberg + Trino/Spark | Delta Lake / Hudi | 数据量 < 1TB：直接进 PG/CH |
| 搜索 | Elasticsearch 9 | OpenSearch 3 | 只做前缀匹配：B+ 树索引的延迟更低（微秒级） |
| 向量检索 | pgvector（规模 < 千万） | Milvus / Qdrant / Weaviate / LanceDB | 已有 PG 且 < 500 万向量：别再引一个库 |
| 文档 | MongoDB 9 | PG JSONB | 需要事务与关联：PG JSONB 更省 |
| 时序 | TimescaleDB / VictoriaMetrics | InfluxDB 3 | 指标量 < 100 万/天：Prometheus 足够 |
| 对象存储 | S3 兼容（云）/ MinIO / Ceph RGW | — | 需要 POSIX 语义：用文件存储，别硬套对象存储 |
| CDC | Debezium | Flink CDC | 只在同库内同步：触发器/物化视图更简单 |
2.3 工程效能与可观测性
| 能力域 | 主选 | 备选 | 什么时候别用主选 |
|---|---|---|---|
| CI | GitHub Actions / GitLab CI | Tekton / Dagger | 构建需要 GPU 或特殊硬件：自建 runner |
| 构建缓存 | BuildKit + registry cache | Bazel / Nx / Turborepo | 单仓库、构建 < 3 分钟：别引入远程缓存 |
| 测试 | Testcontainers + Playwright | Pact（契约）/ k6（压测） | 见 53.1 测试金字塔 |
| 发布 | Argo Rollouts | Flagger | 见 55.1 发布策略 |
| 指标 | Prometheus 3 + Grafana 13 | VictoriaMetrics / Mimir | 指标基数 > 100 万：先治理标签，再换存储 |
| 日志 | Loki | ClickHouse / ELK | 需要全文检索与复杂聚合：ClickHouse 更合适 |
| 链路 | OTel + Tempo | Jaeger / SigNoz | 采样率 100% 且量大：先算成本 |
| 持续剖析 | Pyroscope / Parca | 云厂商 profiler | 见 34.3 性能分析方法 |
| 安全扫描 | Trivy + Syft + Cosign | Grype / Snyk | 见 38.10 供应链安全 |
| 密钥 | OpenBao / 云 KMS + External Secrets | Vault | 只有几个静态密钥：K8s Secret + 加密静态数据 |
| 值班与事件 | PagerDuty / Grafana OnCall | incident.io | 见 56.3 on-call (值班 / 升级路径 / runbook) |
2.4 AI 原生栈（2024–2026 新增的一层）
这一层的判据和传统中间件不同：它的输出是概率性的，所以「评测」和「可观测」不是可选项，是入场券。
| 能力域 | 主选 | 备选 | 什么时候别用主选 |
|---|---|---|---|
| 模型接入 | 托管 API（多家并行） | 自建开源权重（Qwen / Llama / DeepSeek 系列） | 数据不能出域、或单位成本高于自建盈亏点：才自建 |
| 推理引擎 | vLLM | SGLang / TensorRT-LLM / llama.cpp（边缘） | 峰值 QPS < 1：直接用托管 API，别养 GPU |
| 推理网关 | LiteLLM / Envoy AI Gateway | 云厂商 AI 网关 | 只接一家模型：SDK 直调更简单 |
| Agent 框架 | LangGraph（有状态图） | OpenAI Agents SDK / Claude Agent SDK / Pydantic AI | 大多数场景不需要框架：1–3 步的流程直接写代码 + 一次工具调用 |
| 长流程编排 | Temporal | Dapr Workflow | 见 24.5 Saga (编排 / 协同 / 补偿) 的补偿思路 |
| RAG 索引 | LlamaIndex / 自研切分 | Haystack / DSPy | 语料 < 1000 页：全文塞进上下文可能更准 |
| 向量库 | pgvector / Qdrant | Milvus / Weaviate / LanceDB | 规模够小就别引新库，见「数据与消息」一节 |
| 重排 | BGE / Cohere Rerank | 自训练 cross-encoder | 候选 < 20 条：省掉 rerank |
| 评测 | promptfoo / DeepEval / ragas | LangSmith / Langfuse 数据集 | 只有 demo、没有验收标准：先写 eval 再写功能 |
| LLM 可观测 | Langfuse / LangSmith + OTel GenAI | 自建 trace 表 | 单机内部工具：结构化日志足够 |
| 沙箱 | E2B / Firecracker / gVisor / WASM | Docker + 无网络 + 只读 FS | 任何「模型能执行代码」的场景都必须有沙箱 |
| 微调 | PEFT (LoRA) + TRL | 全参微调 / 托管微调 | 需求是「补知识」：用 RAG，不要微调 |
| 训练编排 | Ray + FSDP/DeepSpeed | Kubeflow / 托管训练 | 单卡能跑完：别上分布式 |
💡 关于 Agent 框架，我的判断是：2025 年之后，框架的价值从「帮你调模型」转向「帮你管状态」。如果它不能给你持久化、可恢复、可观测的执行图，那它就只是语法糖——而语法糖在需求变化时最先被删掉。
三、选型决策表（按场景）
| 你的场景 | 主选 | 备选 | 淘汰条件（什么情况下不选） |
|---|---|---|---|
| 10 人团队，单体 + 一个库 | PG + 单体 + 云托管 | 模块化单体 + 读写分离 | 上 K8s：运维成本超过收益 |
| 要做多活 | 单元化 + 双向同步 + 冲突收敛 | 两地三中心（冷/温备） | 业务 RTO > 30 分钟：多活是过度设计 |
| 要降 30% 云成本 | 存储分级 + 弹性 + 预留 | 架构级降本（缓存/批处理） | 成本不能归因到团队：先做标签治理 |
| 要接大模型做知识问答 | RAG（切分 + 混合检索 + rerank + 引用） | 长上下文直塞（小语料） | 语料每天变、且要求引用：必须 RAG |
| 要做 Agent 平台 | 网关 + 沙箱 + 状态机 + eval + trace | 单 Agent + 人工确认 | 任务无法用规则验收：先做 copilot，不做 autopilot |
| 要过等保三级 | 基线加固 + 日志留存 + 边界隔离 | 云等保合规包 | 见 3.1 等级保护与网络安全法 |
| 要治理发布事故 | 灰度 + 自动回滚 + 变更审计 | 特性开关 + 影子流量 | 没有 SLO：先有指标，再谈发布策略 |
| 团队没有 SRE | 全托管（云数据库/云 K8s/云可观测） | 托管 + 一个懂行的人 | 自建中间件：没人值班就是定时炸弹 |
| 要从 0 搭数据平台 | Iceberg + Trino + 调度 | 云数仓（Snowflake/BigQuery/湖仓一体） | 数据量 < 1TB：云数仓更省 |
| 要接多个模型供应商 | LLM 网关 + 统一评测集 | SDK 直调 + 抽象层 | 只接一家且短期不换：别提前抽象 |
四、许可证与治理：选型前必须查的一张表
开源不等于免费，许可证变更会在一夜之间改变你的成本结构。
| 产品线 | 变更 | 对你的影响 | 替代 |
|---|---|---|---|
| Terraform | 2023-08 改为 BSL 1.1 | 与 Terraform 竞品提供服务可能违约 | OpenTofu（MPL，Linux Foundation） |
| Redis | 2024-03 改为 RSALv2 / SSPLv1 | 云厂商不能直接售卖托管版 | Valkey（BSD，Linux Foundation） |
| Elasticsearch | 7.11 起 SSPL / Elastic License；8.16 起增加 AGPL 选项 | 自建可，托管售卖受限 | OpenSearch（Apache 2.0） |
| MongoDB | 2018 起 SSPL | 云上自建需评估条款 | PostgreSQL JSONB / 云托管 |
| Grafana | 2021 起 AGPLv3 | 分发修改版需开源 | 自建/托管均可用，注意分发场景 |
| HashiCorp 系（Vault 等） | BSL；2025 年被 IBM 收购 | 长期路线存在不确定性 | OpenBao |
| Kafka | Apache 2.0（未变） | 注意 Confluent 的商业组件 | — |
| Kubernetes / OTel / Cilium | Apache 2.0（CNCF） | 无 | — |
| vLLM / SGLang / PyTorch | Apache 2.0 / BSD 系 | 无 | — |
| MCP / A2A / Agent Skills | 开放规范，AAIF（Linux Foundation）治理 | 规范仍在演进，实现要跟版本 | — |
⚠️ 许可证结论会过期。合并前让法务看一眼 SPDX 标识，比自己读三遍 LICENSE 靠谱。
五、算一遍：托管 API 与自建推理的盈亏平衡
清单里最贵的那个选择是「要不要自建推理」。它不该靠感觉，它是一道固定成本 vs 变动成本的算术题。
#!/usr/bin/env python3
"""托管 API vs 自建推理：月度成本、盈亏平衡点、利用率敏感性。
单价都是占位值，跑之前换成你合同里的价格与实测吞吐。
用法：python3 llm-cost.py
"""
# ---------- 可改参数 ----------
DAILY_REQ = 200_000 # 日请求量
IN_TOKENS = 1_500 # 平均输入 token（system prompt + 检索片段 + 问题）
OUT_TOKENS = 400 # 平均输出 token
USD_PER_M_IN = 3.00 # 托管：输入单价 / 百万 token
USD_PER_M_OUT = 15.00 # 托管：输出单价 / 百万 token
GPU_MONTH_USD = 2_000 # 自建：每卡每月（含机器、机房、人力摊销）
GPU_TOK_S = 2_000 # 自建：实测输出吞吐 token/s（同模型、同精度）
def api_month(n_req: float) -> float:
"""托管：按 token 线性计费，没有固定成本。"""
return (n_req * IN_TOKENS * USD_PER_M_IN + n_req * OUT_TOKENS * USD_PER_M_OUT) / 1e6
def gpu_capacity(util: float) -> float:
"""单卡每月的输出 token 产能 = 秒数 × 利用率 × 吞吐。"""
return 30 * 86400 * util * GPU_TOK_S
def breakeven_daily() -> int:
"""二分找「托管月成本 = 一张卡月成本」的日请求量。"""
lo, hi = 1, 10_000_000
while lo < hi:
mid = (lo + hi) // 2
if api_month(mid * 30) < GPU_MONTH_USD:
lo = mid + 1
else:
hi = mid
return lo
if __name__ == "__main__":
n_month = DAILY_REQ * 30
api = api_month(n_month)
print(f"月请求 {n_month:,}｜月 token：入 {n_month * IN_TOKENS / 1e6:.1f}M，出 {n_month * OUT_TOKENS / 1e6:.1f}M")
print(f"托管：${api:,.0f}/月")
print(f"一张卡 ${GPU_MONTH_USD:,}/月 ↔ 托管 {breakeven_daily():,} 请求/天；低于这条线，托管一定更便宜")
for util in (0.10, 0.35, 0.70):
cards = -(-n_month * OUT_TOKENS // int(gpu_capacity(util)))
print(f"自建 @ 利用率 {util:.0%}：{cards} 张卡 → ${cards * GPU_MONTH_USD:,.0f}/月")
本机跑出来的结果（2026-10，参数如上）：
月请求 6,000,000｜月 token：入 9000.0M，出 2400.0M
托管：$63,000/月
一张卡 $2,000/月 ↔ 托管 6,350 请求/天；低于这条线，托管一定更便宜
自建 @ 利用率 10%：5 张卡 → $10,000/月
自建 @ 利用率 35%：2 张卡 → $4,000/月
自建 @ 利用率 70%：1 张卡 → $2,000/月
三个读法，比数字本身重要：
| 读法 | 含义 | 决策含义 |
|---|---|---|
| 盈亏平衡线与利用率无关 | 单卡月成本是固定的，所以「一张卡 ↔ 多少请求」只取决于托管单价 | 别拿「我们利用率低」论证自建更贵——利用率影响的是需要几张卡，不是单卡这条线 |
| 量小托管赢，量大自建赢 | 托管是纯变动成本（0 请求 = $0），自建是高固定成本 | 日请求低于盈亏平衡线时，自建省下的钱还不够养一个值班的人 |
| 利用率决定卡数，卡数决定成本 | 10% 与 70% 相差 5 倍卡数 | 自建的隐性成本是低利用率；如果你的流量有强峰谷，先算清峰值要几张卡 |
⚠️ 三个最容易被算错的数：① 利用率（真实常在 10%–40%，不是 80%）；② 输出 token 长度（长输出线性放大成本，还拖长 TPOT）；③ prefill 没折算（RAG 场景 1.5k 输入 token 的预填充并不便宜，本脚本把输入成本算进了托管、却把自建侧的输入算力折进了吞吐——真实估算必须用自己的负载压测出 tokens/s）。
反模式
| 反模式 | 后果 |
|---|---|
| 按 GitHub star 选型 | star 反映热度，不反映你的负载、团队与运维能力 |
| 新版本首发就上核心链路 | 用生产环境替社区做回归测试 |
| 同一能力域并存三套（两套 MQ、两套缓存） | 运维、监控、招聘、故障排查全部 ×3 |
| 把开源当免费 | 人力、合规、安全响应成本往往超过商业授权 |
| 只看功能对比，不看退出成本 | 数据模型绑定后无法迁移 |
| 用 demo 的观感替代 eval | 演示样本是挑过的，线上长尾立刻暴露 |
| 无视配额与限流（托管服务） | 突发流量被云厂商限流，故障排查方向完全错 |
| 版本表不写核对日期 | 半年后照表选型，选到已 EOL 的版本 |
| 为了「技术先进」引入组件 | 每个组件都是一份 7×24 的运维责任 |
自检
Q1 一个 8 人团队要做一个内部知识库问答，第一版就计划上「K8s + Milvus + LangGraph + vLLM 自建」。请指出至少三处过度设计，并给出替代路径。
▸ 答案：① K8s——内部工具、用户几十人，单机 Docker Compose 或一个托管容器服务足够；② Milvus——文档量在百万 token 级，pgvector 甚至内存里的向量索引就够，且省掉一套分布式运维；③ vLLM 自建——QPS 低时托管 API 的单位成本更低，还没有 GPU 空闲成本；④ LangGraph——问答是「检索 → 生成」两步，直接写代码更清楚。替代路径：托管 API + pgvector + 100 行代码 + 一个 eval 集，先验证「答得准不准」，再谈扩展性。
Q2 团队说「我们要用 Terraform，但许可改成 BSL 了，怎么办？」请给出判断依据，而不是直接给答案。
▸ 答案：判断依据是使用方式：BSL 限制的是「用 Terraform 提供与 HashiCorp 竞争的服务」；如果只是内部管理自己的基础设施，通常仍在允许范围内（但要以当时的许可证文本与法务意见为准）。真正需要迁移的信号是：① 你要做对外售卖的平台；② 你依赖的 provider 生态开始分裂；③ 公司合规要求只用 OSI 许可。迁移成本要算：state 文件、provider 版本、模块库、CI 集成。结论：先确认使用方式，再决定是否迁移；迁移不是「许可变了就必须做」的条件反射。
Q3 有人主张「Kafka 4 移除了 ZooKeeper，所以我们升级只是换个版本」。请指出升级路径上最容易被忽略的两件事。
▸ 答案：① 元数据迁移不可逆——从 ZK 模式切到 KRaft 需要专门的迁移流程，且回退窗口有限，必须先演练；② 客户端与工具链——依赖 ZK 的老工具（监控、管理台、自定义脚本）会直接失效，ACL/配额模型也有差异。另外要确认版本跳跃跨度：Kafka 的升级通常要求逐个大版本走，跨版本直接升会触发协议不兼容。判据：升级方案里有没有「回滚到 ZK 模式」的步骤，没有就是没想清楚。
Q4 为什么「LLM 网关」不能简单等同于「API 网关加个转发」？请给出至少三个它必须做的事。
▸ 答案：① token 计量与成本归因——按团队/功能/租户拆分 token 消耗，API 网关只统计请求数；② 模型路由与降级——同一请求按成本/延迟/质量要求路由到不同模型，并在主模型故障时降级；③ 语义缓存与去重——相同或相近请求复用结果，需要 embedding 与阈值；④ prompt/响应审计——留存输入输出用于评测与合规，涉及脱敏。这些都不是「转发」能覆盖的，本质是把概率性依赖纳入治理。
Q5 请用一句话说明：为什么这份清单里「什么时候别用」这一列比「主选」更重要？
▸ 答案：因为主选可以抄，淘汰条件不能抄——别人的主选是在他的团队规模、负载特征、合规约束下成立的；而「什么时候别用」是这些约束的显式表达，读者可以拿自己的约束去比对。没有淘汰条件的清单只能制造从众，不能帮助决策。
关联
- 前置：83.1 术语表、83.2 参考文献与经典论文
- 并列：83.4 学习路径索引
- 下游：4.3 技术选型的评估维度（清单给候选，评估维度给判据）