把大模型 API 从开发环境推到线上说起来简单其实是从“能调通”到“稳稳跑”的一大步。很多团队上线之后才发现问题鉴权有漏洞Key 被人盗刷了并发请求一多后端直接扛不住更惨的是连个告警都没有等到发现故障黄金修复时间早就过了。与其事后着急忙慌地救火不如上线前踏踏实实过一遍检查清单。这篇文章主要围绕鉴权与安全、并发与限流、监控指标与数据采集、告警策略与分级响应这四个核心方面帮你把最容易忽略的环节补上。一、鉴权与安全管好 API Key别让它裸奔大模型 API 的调用凭证一旦泄露轻则多花冤枉钱重则被人拿去搞事情生成些不该有的内容。所以上线前下面这些事儿一定得确认清楚。1. API Key 的生成和分发得有点讲究权限能最小就最小每个接入方——不管是服务、客户端还是测试环境——都应该用独立的 API Key别大家共用一个。如果平台支持生成子 Key别犹豫赶紧用上。密钥得够长够随机生成的 Key 至少得是 32 字节的随机字符串别用什么好猜的格式。说白了越乱越好。传输必须加密所有 API 请求一律走 HTTPS别让 Key 在明文里裸奔。对了记得检查一下 SDK 或者客户端是不是默认关了证书验证这坑不少人踩过。2. 密钥轮换和失效要有预案定期轮换别懒定个周期比如每 90 天换一次 Key。上线前最好先测试一下怎么平滑切换——先下发新 Key确认旧的没人在用了再撤销。操作流程要跑通。能随时吊销控制台或者管理 API 得支持立即吊销某个 Key一旦发现泄露马上动手。建议提前演练一遍看看从操作到生效到底要多久通常几秒到几分钟。预览 Key 和生产 Key 严格分开预览或者测试用的 Key配额设低点过期时间设短点别让它们混到线上环境里。3. 认证协议怎么选看场景目前常见的有三种API Key、Bearer TokenJWT、OAuth 2.0。API Key实现起来最简单服务端对服务端调用够用了。但缺点也很明显——Key 本身就是全部凭证一旦泄露就得立刻吊销。JWTJSON Web Token可以把用户身份、过期时间、权限范围都塞进去适合需要细粒度鉴权的场景。注意签名算法别用none或者弱加密过期时间别设太长建议一小时以内。OAuth 2.0适合第三方应用代理用户来调用流程复杂一些但安全性更高。上线前得确认 access token 有效期、refresh token 存哪儿、scope 限制有没有到位。这么说吧如果只是简单的后端集成API Key 加上 IP 白名单基本够了。但如果要开放给多租户或者前端那还是考虑 JWT 或者 OAuth 吧。4. 请求来源限制和审计日志一个不能少IP 白名单/黑名单在 API 网关层限制允许调用的源 IP 段就算 Key 被偷了从不受信任的网络也发不了请求。频率异常检测盯着单个 Key 的调用频率要是远超正常范围自动降权或者临时封禁。审计日志每次调用都得记下来——哪个 Key、什么时间、从哪个 IP 来的、请求参数摘要、响应码。日志至少保留 90 天而且要能检索。注意别把完整的 prompt 和 response 里的敏感信息记进去可以脱敏处理或者只保存 Token 数之类的元数据。二、并发与限流别让流量把后端冲垮大模型 API 按 Token 计费而且单次推理动不动就好几秒甚至几十秒。高并发一来后端负载和成本都嗖嗖往上涨。上线前这些事儿必须搞清楚。1. 先摸清并发上限搞清楚你的配额确认平台给你分配了多少并发比如每分钟请求数、每分钟 Token 数、并发连接数。如果平台没给明确数字最好自己压测一下看看服务实际能扛多大并发然后留出 20%30% 的余量。区分用户和租户如果 API 要给多个业务方用每个租户的并发得分开统计别让一个租户的突发流量把全部额度都占光了。2. 限流策略推荐令牌桶常见的限流算法有令牌桶、漏桶、滑动窗口计数。我个人推荐令牌桶因为它允许一定程度的突发流量桶里攒了令牌就能突突一下同时又能限制平均速率。客户端限流在 SDK 或者调用方本地实现排队和重试。比如设一个本地令牌桶每秒补充几个令牌请求消耗令牌之后再发出去。超时了要么排队等着要么直接返回错误。服务端限流在 API 网关或者反向代理层比如 Nginx、Kong、APISIX配置限流规则。返回 429 Too Many Requests 的时候客户端得解析Retry-After头部乖乖等一下再重试。动态限流当 API 后端的响应延迟变高比如 p99 超过阈值自动降低入口速率防止雪崩。3. 排队和降级得有后手队列缓冲区对于非实时场景比如批量摘要、数据分析可以把请求写到消息队列像 RabbitMQ、Kafka让 Worker 异步消费别让用户在那儿干等。降级预案并发超了或者后端异常了怎么办比如返回缓存结果、返回默认回复、或者告诉用户“服务繁忙”。这些降级逻辑得上线前写好并且测试通过。熔断机制接入熔断器比如 Hystrix、Resilience4j当连续失败率达到一定阈值比如 5 秒内 50% 的请求都失败了直接断掉后续请求一段时间让后端缓口气。4. 超时控制别拖太久连接超时建议 5 秒以内别占着连接池不放。读取超时根据模型响应速度来设一般 30 到 120 秒。如果是流式输出SSE得用 TCP 级别的心跳检测不能光靠读超时。总超时把重试的时间也算进去设个总时限避免重试堆成山。三、监控指标与数据采集不光看 QPS还得盯 Token大模型 API 的监控不能只看 QPS 和错误率还得关注 Token 消耗速率、首包延迟、Token 间延迟这些特有指标。很多文章都忽略了这部分。1. 核心指标按优先级排维度指标说明调用量每分钟请求数RPM按 API Key、模型、端点分别统计调用量每分钟 Token 数TPM输入 Token 输出 Token用来算成本成功率请求成功率区分 HTTP 错误4xx/5xx和业务错误比如内容安全拦截延迟端到端延迟整体请求耗时关注平均值、p95、p99延迟首 Token 延迟从发出请求到收到第一个输出 Token 的时间反映模型冷启动和网络质量延迟Token 间延迟TBT流式输出中相邻 Token 的时间间隔越稳定用户体验越好资源上下文窗口占用每次请求的 prompt Token 数接近模型上限时容易被截断2. 数据怎么采三种方式客户端埋点在 SDK 或者业务代码里记录每次调用的指标通过 Prometheus 客户端或者 Telegraf、StatsD上报。这是最灵活的方式可以抓到业务层面的自定义信息比如用户 ID、场景标签。API 网关层如果用了统一的 API 网关比如 Kong、APISIX 或者云厂商的网关网关本身会记录请求延迟、状态码、请求体大小等基础指标。但 Token 数、首 Token 延迟这些大模型特有的指标网关通常拿不到还得靠客户端打点。服务端日志采集如果 API 返回的响应里带了 Token 使用量比如 OpenAI 兼容格式里的usage字段可以解析日志来算。建议用 Fluentd 或者 Logstash 把日志流式写到时序数据库里。3. 可视化仪表盘两个视图不能少Grafana是最常见的选择。如果技术栈受限用云厂商的监控服务也行比如阿里云 SLS 仪表盘、腾讯云 Prometheus 监控。仪表盘至少得有两个视图一是实时视图最近 1 小时或者 24 小时用来排查问题二是趋势视图最近 7 天或者 30 天用来做容量规划和成本分析。四、告警策略与分级响应别让“狼来了”变成日常有了指标还得有告警。但告警不是越多越好太多了容易让人麻木最后真的出问题反而没人当回事。上线前一定要定好分级规则。1. 告警分级参考 P0/P1/P2级别含义举个例子响应时间通知方式P0核心功能挂了所有用户受影响整个 API 的 5xx 错误率超过 10%持续 3 分钟立即响应电话 短信 IM 群聊 所有人P1部分功能降级或者影响了部分付费用户某个 Key 被限流429超过 20% 的请求或者 p99 延迟超过基线的 2 倍15 分钟内IM 群聊 邮件P2潜在问题暂时不影响体验Token 消耗异常增长超过日均 2 倍或者单条告警触发工作时间内处理邮件 看板注释2. 告警规则怎么写举个 PromQL 的例子用 Prometheus 的话常用规则有错误率过高sum(rate(http_requests_total{status~5..}[5m])) / sum(rate(http_requests_total[5m])) 0.05延迟异常histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) 30Token 消耗激增rate(token_usage_total[10m]) rate(token_usage_total[1d]) * 2需要每天的基线数据首 Token 延迟持续高avg_over_time(first_token_latency_seconds[5m]) 5注意所有阈值都要根据生产环境的历史数据来调。刚上线的时候可以设得宽松一点运行稳定了再收紧。3. 告警渠道和抑制别炸锅多渠道通知至少覆盖 IM比如飞书、钉钉、企业微信和邮件。P0 级别的建议再加上电话告警可以用 PagerDuty、OpsGenie 之类的工具。告警抑制避免告警风暴。比如某个 API 整体不可用了就别同时触发下面每个子 Key 的单独告警。可以用 Prometheus Alertmanager 的分组和抑制规则来搞定。静默期对于已知的维护窗口或者业务低峰期可以临时关掉部分告警比如夜间非核心批处理任务的失败告警就不需要半夜吵醒人。五、补充几项灰度、成本与预案除了上面四大块还有几个工程实践里容易被忽略的要点。1. 灰度上线慢慢来流量逐步切分先引流 1%5% 到新的 API 接口或者新模型版本观察监控指标稳定了再扩大到 50%、100%。明确灰度终止条件得清楚哪些指标达标了才能全量比如 P0 告警一次都没触发p99 延迟比旧系统低 10% 以上。一键回滚做好 API 版本回滚或者切回旧 Key 的预案确保 5 分钟内能搞定。2. 成本控制心里有数设置预算告警通过 API 统计每天 Token 消耗预估费用。当当天费用超过阈值比如月预算的 5%时触发告警。限制上下文长度尽量对 prompt 做预压缩或者截断别因为上下文太长白花 Token。合理选择模型不是复杂场景就用轻量模型比如 Claude API 的 Haiku 这些低成本版本高精度场景再用旗舰模型。按业务场景路由别一刀切。3. 文档和演练不上战场才慌维护上线检查文档把上面所有检查项整理成表格每次上线前开发跟运维双方逐条确认、签字。定期攻防演练模拟 Key 泄露、并发攻击、后端宕机这些场景看看告警能不能触达降级逻辑有没有生效。上线不是一个动作而是一个过程。与其“能调通就上”不如花半天时间对着这份清单逐项检查一遍能省去后面好几周的故障排查时间。鉴权、并发、监控、告警——这四个东西缺一不可它们就是大模型 API 的“安全护栏”。当线上流量真正涌过来的时候有准备的团队才能从容应对。