1. 为什么2026年还要把AI API安全当回事先说一个我自己的真实经历。去年帮一个做智能客服的团队做架构复盘他们上线三个月账单从每月两千多飙到一万七。一开始以为是业务量涨了查了日志才发现有一个测试用的密钥被硬编码在了一个前端仓库里被人扒出来之后拿去跑批量任务每天凌晨两点到五点稳定消耗掉几百万token。更离谱的是他们连限流都没配那个密钥的调用频率是完全没有上限的。这件事之后我就一直在想AI API的安全和传统后端接口的安全压根不是一回事。传统接口你防的是数据泄露、防的是越权访问AI API你还要多防一层——钱。因为AI API的计费模式是按token或者按调用次数来的每一次调用都是真金白银。你一个密钥泄露别人拿去刷刷的是你的余额。你一个限流没配好一个死循环的Agent能把你的月度预算在一个下午烧完。所以到了2026年AI API接口的安全我认为核心就三块成本控制、限流策略、密钥管理。这三块搞定了80%的常见事故你都能挡住。剩下的20%是什么是模型输出内容的安全过滤、是prompt注入的防护、是数据隐私的合规处理那些是另一个层面的问题今天先不展开。这篇文章适合谁看如果你是后端开发、运维、技术负责人或者你正在做一个跟AI API对接的产品那这篇内容你应该能直接用上。我会把这三块拆开讲每一块都给出具体的配置思路、参数选择的理由以及我自己踩过的坑。不堆概念只讲能落地的东西。2. 成本控制别等账单来了才后悔2.1 先搞清楚你的钱到底花在哪了很多人做成本控制的第一步就错了——他们直接去看总账单然后想着怎么把总数降下来。这个思路不对。你得先知道钱花在哪些维度上。AI API的成本通常由这几个因素决定输入token数、输出token数、模型单价、调用次数、缓存命中率。不同厂商的计价方式略有差异但大体上离不开这几个变量。你要做的第一件事是把这些维度拆开按天、按接口、按密钥、按业务线分别统计。我一般会建议团队在接入层做一个简单的埋点每次调用AI API的时候记录下这几个字段——时间戳、密钥ID、调用的模型名、输入token数、输出token数、请求来源哪个业务模块、响应耗时。这些数据落到一张表里不用多复杂一张宽表就够了。有了这张表你才能回答下面这些问题哪个业务线最费钱哪个密钥的消耗量异常输入token和输出token的比例是多少有没有大量重复的请求本可以走缓存注意埋点本身不要引入太多性能开销。我见过有团队在埋点里做同步写数据库结果接口延迟直接翻倍。建议用异步队列或者本地缓冲批量写入。2.2 模型分级不是所有请求都值得用最贵的模型这是成本优化里最立竿见影的一招。很多团队不管什么请求都往最贵的模型上打这是最大的浪费。我的做法是把请求分成三档简单档意图识别、文本分类、格式转换、简单问答。这类请求用轻量模型就够了单价可能只有旗舰模型的十分之一甚至更低。标准档常规的文本生成、摘要、翻译、代码补全。用中档模型性价比最高。复杂档需要深度推理、长上下文理解、多步骤规划的请求。这类才用旗舰模型。怎么判断一个请求该走哪一档可以在接入层做一个轻量的路由判断。最简单的做法是基于请求的token长度和业务标签来路由。比如token数小于500且业务标签是“分类”的直接走轻量模型token数超过4000或者业务标签是“推理”的走旗舰模型。我实测下来光是做模型分级这一件事就能把整体成本压下来40%到60%。而且大部分场景下用户根本感知不到差别因为简单请求用轻量模型和旗舰模型的结果差异很小。2.3 缓存策略同样的请求不要付两次钱AI API的缓存和传统HTTP缓存不太一样因为同样的输入不一定产生同样的输出取决于temperature等参数。但有一类请求是天然可缓存的temperature设为0的请求。这类请求的输出是确定性的同样的输入永远得到同样的输出完全可以缓存。具体怎么做在接入层对请求做hashkey是“模型名输入内容关键参数”value是模型的输出。下次同样的请求进来直接返回缓存结果不调API。缓存的有效期可以根据业务场景来定一般设24小时到7天都合理。还有一类是语义缓存。用户问“今天天气怎么样”和“今天天气如何”字面不同但语义相同。这种可以用embedding做相似度匹配相似度超过阈值的直接返回缓存结果。不过语义缓存的实现复杂度高一些误判率也需要控制建议先在低风险场景试点。实操心得缓存一定要设上限和淘汰策略。我见过有团队缓存只写不删三个月后缓存文件占了200G磁盘查询性能反而被拖垮了。建议用LRU策略并且给缓存总量设一个硬上限。2.4 预算熔断给每个密钥设一条红线这是最后一道防线。不管前面的优化做得多好你都需要一个硬性的预算控制机制。具体做法是给每个密钥或者每个业务线设一个日预算和周预算。当消耗达到预算的80%时触发告警达到100%时自动降级或者直接拒绝请求。降级的意思是把请求从旗舰模型切到轻量模型或者返回一个兜底结果。拒绝就是直接返回错误码让业务方知道预算用完了。这个机制听起来简单但关键时刻能救命。我那个客服团队的朋友如果当初设了一个日预算熔断最多损失一天的预算不至于三个月烧掉好几万。预算的粒度建议至少做到按密钥维度。如果业务线比较多可以再细一层按“密钥业务标签”来设。这样即使某个业务线出问题也不会影响其他业务线的正常使用。3. 限流保护你的接口也保护你的钱包3.1 限流不只是防DDoS更是防自己人很多人一听到限流就想到防攻击觉得只有面向公网的服务才需要。但AI API的限流更多时候防的是自己人——防的是一个写错的循环、一个失控的Agent、一个忘记加退避的重试逻辑。我遇到过最典型的情况一个开发同学在调试的时候写了一个while循环每次调用AI API判断结果是否满足条件不满足就重试。结果因为prompt写得有问题模型一直返回不满足条件的结果那个循环跑了三千多次才被手动停掉。如果没有限流这个循环能跑到天亮。所以限流的第一个原则是所有调用AI API的地方都要有限流不分内外。3.2 限流策略怎么选令牌桶还是滑动窗口常见的限流算法有几种我简单说一下各自适合的场景。令牌桶适合允许突发流量的场景。桶里按固定速率放令牌请求来了拿一个令牌拿不到就拒绝或者排队。它的特点是允许一定程度的突发比如你设了每秒10个请求但桶容量是50那短时间内可以承受50个请求的突发。滑动窗口适合对速率要求比较严格的场景。它统计的是一个时间窗口内的请求总数超过阈值就拒绝。相比固定窗口滑动窗口不会出现窗口边界处的流量翻倍问题。漏桶适合需要平滑输出的场景请求按固定速率被处理多余的排队或丢弃。对于AI API的限流我一般推荐令牌桶因为AI请求的耗时本身就不固定允许一定的突发更符合实际使用模式。具体的参数怎么定我的经验是这样先统计正常业务情况下的QPS峰值比如是每秒5个请求。把限流阈值设成峰值的1.5到2倍也就是每秒8到10个请求。桶容量设成阈值的3到5倍用来吸收短时突发。这样既能挡住异常流量又不会误伤正常的业务波动。3.3 多维度限流别只盯着QPS只按QPS限流是不够的。AI API还需要考虑这几个维度Token维度有些请求QPS不高但每次请求的token数巨大消耗的成本反而更高。所以除了限制请求数还要限制单位时间内的token消耗总量。并发维度限制同时进行的请求数量。AI API的响应时间通常比较长如果并发数不控制很容易把连接池打满。用户维度如果是多租户的系统每个用户或者每个租户要有独立的限流配额。防止一个用户把整个系统的配额用完。模型维度不同模型的成本和响应时间不同限流策略也应该不同。旗舰模型的限流应该更严格轻量模型可以宽松一些。这几个维度可以叠加使用。比如一个请求进来先检查用户维度的配额再检查模型维度的配额最后检查全局的QPS和token配额。任何一层不通过就拒绝。3.4 限流之后的降级和排队限流不是简单地返回429就完事了。你需要考虑被限流的请求怎么处理。对于实时性要求高的场景比如对话式交互被限流了就直接返回一个友好的提示让用户稍后重试。对于实时性要求不高的场景比如批量处理任务可以把请求放到队列里排队等配额释放了再处理。排队的时候要注意队列的长度和超时时间。队列太长会导致请求积压用户等太久超时时间太短又会导致大量请求被丢弃。我一般建议队列长度不超过限流阈值的10倍超时时间设在30秒到60秒之间。注意降级策略要和业务方对齐。我见过有团队自己决定了降级方案结果业务方完全不知情出了问题互相甩锅。降级方案一定要提前沟通好最好写进接口文档里。4. 密钥管理最容易被忽视的重灾区4.1 密钥泄露的常见途径我梳理了一下我见过或者听说过的密钥泄露案例大概有这么几种途径硬编码在前端代码里这是最蠢但也最常见的一种。前端代码是公开的任何人打开开发者工具都能看到。提交到了代码仓库开发同学本地调试的时候把密钥写在了配置文件里然后一不小心commit上去了。即使后来删掉了git历史里还能找到。日志里打印了密钥调试的时候把完整的请求头打到了日志里日志又被收集到了日志平台访问日志平台的人都能看到。在聊天工具里传阅为了图方便把密钥直接发在群里或者私聊里。聊天记录一旦泄露密钥就跟着泄露了。第三方依赖泄露用的某个开源库或者第三方服务出了安全漏洞密钥被窃取。这几种途径里前三种是可以通过流程和工具来防范的后两种更多是靠意识。4.2 密钥的生命周期管理一个密钥从创建到销毁应该有一个完整的管理流程。我建议至少包含这几个环节创建密钥的创建应该走审批流程不能谁想创建就创建。创建的时候要明确用途、负责人、预计的调用量和预算。分发密钥不能明文分发。应该通过密钥管理服务来下发应用启动的时候从密钥管理服务拉取而不是从配置文件里读。轮换密钥要定期轮换建议至少每90天换一次。轮换的时候要支持双密钥并行也就是新旧密钥同时有效一段时间等所有调用方都切换到新密钥之后再禁用旧密钥。监控每个密钥的调用量、调用来源、消耗成本都要有监控。一旦发现异常比如调用量突然暴涨、调用来源出现陌生IP要能及时告警。销毁不再使用的密钥要及时禁用和删除。我见过有团队创建了几十个密钥实际在用的只有几个剩下的都在“裸奔”。4.3 密钥的存储和传输密钥的存储有几个原则不落盘、不进代码、不进日志。不落盘的意思是密钥尽量不要写在配置文件里。如果一定要写那配置文件本身要加密而且解密密钥要通过环境变量或者密钥管理服务来注入。不进代码的意思是密钥绝对不能出现在代码仓库里。可以用.gitignore来防止误提交但更可靠的做法是在CI/CD流程里加一个密钥扫描的步骤一旦发现疑似密钥的内容就直接阻断构建。不进日志的意思是日志里涉及密钥的部分要做脱敏处理。比如只打印密钥的前4位和后4位中间用星号代替。传输方面密钥的传输必须走加密通道。应用和密钥管理服务之间的通信要用TLS密钥本身在存储的时候也要加密。4.4 最小权限原则每个密钥只授予它需要的最小权限。比如一个只做文本分类的密钥就不应该给它调用旗舰模型的权限。一个只在测试环境使用的密钥就不应该在生产环境生效。具体怎么做大多数AI API平台都支持给密钥设置权限范围。你可以限制密钥可以调用的模型列表、可以使用的功能、每天的调用上限、甚至可以的调用来源IP范围。我一般会建议至少做这几层限制按环境隔离测试环境的密钥和生产环境的密钥完全分开不能混用。按功能隔离不同业务模块用不同的密钥一个模块出问题不会影响其他模块。按模型隔离只给密钥开通它需要的模型权限不需要的模型一律不开。按来源隔离如果调用方的IP是固定的可以设置IP白名单。实操心得我习惯给每个密钥起一个有意义的名字格式是“环境-业务-用途”比如“prod-customer-service-chat”。这样一看名字就知道这个密钥是干什么的审计的时候也方便。5. 三块怎么配合一个完整的防护体系5.1 分层防护的思路成本控制、限流、密钥管理这三块不是孤立的它们应该组成一个分层的防护体系。最外层是密钥管理它决定了谁能调用。密钥泄露了后面的防护再强也没用。所以密钥管理是基础是入口。中间层是限流它决定了调用频率的上限。即使密钥泄露了限流能把损失控制在一定范围内。限流是刹车是保险丝。最内层是成本控制它决定了最终花多少钱。成本控制是兜底是最后一道防线。前面的防护都失效了成本控制还能保证你不会倾家荡产。这三层要同时生效不能只做其中一层。我见过有团队只做了密钥管理觉得密钥没泄露就万事大吉结果一个死循环把预算烧完了。也见过有团队只做了限流结果密钥泄露之后攻击者用分布式的方式绕过限流照样把预算刷爆。5.2 监控和告警的配置防护体系建好之后你需要一套监控来确保它正常工作。我建议至少监控这几个指标监控指标告警阈值建议告警方式单密钥日消耗超过日预算的80%邮件即时消息单密钥调用频率超过限流阈值的90%即时消息全局日消耗超过日预算的80%邮件即时消息密钥调用来源异常出现新的IP或地区即时消息电话限流触发次数5分钟内超过10次即时消息缓存命中率低于30%邮件这些阈值不是固定的要根据你的业务特点来调整。比如你的业务有明显的波峰波谷那告警阈值也要跟着调整不然每天波峰的时候都在告警很快就没人看了。5.3 应急响应流程万一真的出了事故比如密钥泄露或者预算被刷爆你需要一个应急响应流程。我建议至少包含这几步确认确认事故是否真实发生影响范围有多大。止损立即禁用涉事密钥或者把限流阈值调到最低先止血。排查查日志找出泄露的途径和攻击的来源。恢复创建新密钥更新调用方配置恢复正常服务。复盘分析事故原因修补流程漏洞更新防护策略。这个流程要提前演练不能等出了事再临时想。我一般建议每季度做一次演练模拟一个密钥泄露的场景看看团队能不能在30分钟内完成止损。6. 常见问题与排查技巧实录6.1 限流误伤了正常业务怎么办这是最常见的问题。限流阈值设得太低正常业务请求被挡住了。排查思路是这样先看被限流的请求特征。是集中在某个时间段还是均匀分布是集中在某个业务线还是所有业务线都有如果是集中在某个时间段那可能是业务本身的波峰需要调整限流阈值或者做动态限流。如果是集中在某个业务线那可能是那个业务线的调用逻辑有问题需要单独排查。动态限流的意思是限流阈值不是固定的而是根据历史流量自动调整。比如你可以取过去7天同一时间段的QPS均值乘以一个系数作为当前时间段的限流阈值。这样波峰的时候阈值自动调高波谷的时候自动调低。6.2 密钥轮换的时候怎么做到不停机密钥轮换最大的风险是旧密钥禁用了但还有调用方在用导致服务中断。要做到不停机关键是双密钥并行。具体步骤是这样先创建新密钥把新密钥分发给所有调用方。调用方更新配置同时支持新旧两个密钥。等确认所有调用方都切换到新密钥之后再禁用旧密钥。禁用之前可以先观察一段时间比如一周确认旧密钥的调用量降到了零。如果调用方比较多可以用配置中心来管理密钥这样切换的时候只需要改配置中心不需要每个调用方都改代码。6.3 成本突然暴涨怎么快速定位成本暴涨的排查我一般按这个顺序来第一步看是哪个密钥的消耗涨了。如果是一个密钥那问题大概率出在那个密钥对应的业务上。如果是所有密钥都涨了那可能是全局性的问题比如某个基础服务被大量调用。第二步看是哪个模型的消耗涨了。如果是一个模型那可能是那个模型的调用逻辑出了问题。如果是所有模型都涨了那可能是请求量整体上涨。第三步看是输入token涨了还是输出token涨了。输入token涨了可能是请求的内容变长了输出token涨了可能是模型的输出变啰嗦了或者max_tokens设得太大了。第四步看调用来源。有没有陌生的IP或者陌生的业务标签如果有那可能是密钥泄露了。这套排查流程走下来一般十分钟内就能定位到问题。6.4 常见问题速查表问题现象可能原因排查方法解决方案接口返回429触发限流查看限流日志确认是哪个维度触发调整限流阈值或优化调用逻辑账单突然上涨密钥泄露或死循环按密钥、模型、来源维度拆解消耗禁用涉事密钥修复调用逻辑密钥无效密钥被禁用或过期检查密钥状态和有效期创建新密钥并更新配置缓存命中率低缓存key设计不合理分析请求的重复率优化缓存key或引入语义缓存模型响应变慢并发过高或模型侧限流查看并发数和响应时间分布降低并发或切换到轻量模型最后分享一个小技巧我习惯在接入层加一个“紧急开关”一旦发现异常可以一键把所有AI API的调用切到一个兜底逻辑上比如返回预设的静态结果。这个开关平时不用但关键时刻能给你争取几分钟的排查时间。
AI API安全实战：成本控制、限流策略与密钥管理
1. 为什么2026年还要把AI API安全当回事先说一个我自己的真实经历。去年帮一个做智能客服的团队做架构复盘他们上线三个月账单从每月两千多飙到一万七。一开始以为是业务量涨了查了日志才发现有一个测试用的密钥被硬编码在了一个前端仓库里被人扒出来之后拿去跑批量任务每天凌晨两点到五点稳定消耗掉几百万token。更离谱的是他们连限流都没配那个密钥的调用频率是完全没有上限的。这件事之后我就一直在想AI API的安全和传统后端接口的安全压根不是一回事。传统接口你防的是数据泄露、防的是越权访问AI API你还要多防一层——钱。因为AI API的计费模式是按token或者按调用次数来的每一次调用都是真金白银。你一个密钥泄露别人拿去刷刷的是你的余额。你一个限流没配好一个死循环的Agent能把你的月度预算在一个下午烧完。所以到了2026年AI API接口的安全我认为核心就三块成本控制、限流策略、密钥管理。这三块搞定了80%的常见事故你都能挡住。剩下的20%是什么是模型输出内容的安全过滤、是prompt注入的防护、是数据隐私的合规处理那些是另一个层面的问题今天先不展开。这篇文章适合谁看如果你是后端开发、运维、技术负责人或者你正在做一个跟AI API对接的产品那这篇内容你应该能直接用上。我会把这三块拆开讲每一块都给出具体的配置思路、参数选择的理由以及我自己踩过的坑。不堆概念只讲能落地的东西。2. 成本控制别等账单来了才后悔2.1 先搞清楚你的钱到底花在哪了很多人做成本控制的第一步就错了——他们直接去看总账单然后想着怎么把总数降下来。这个思路不对。你得先知道钱花在哪些维度上。AI API的成本通常由这几个因素决定输入token数、输出token数、模型单价、调用次数、缓存命中率。不同厂商的计价方式略有差异但大体上离不开这几个变量。你要做的第一件事是把这些维度拆开按天、按接口、按密钥、按业务线分别统计。我一般会建议团队在接入层做一个简单的埋点每次调用AI API的时候记录下这几个字段——时间戳、密钥ID、调用的模型名、输入token数、输出token数、请求来源哪个业务模块、响应耗时。这些数据落到一张表里不用多复杂一张宽表就够了。有了这张表你才能回答下面这些问题哪个业务线最费钱哪个密钥的消耗量异常输入token和输出token的比例是多少有没有大量重复的请求本可以走缓存注意埋点本身不要引入太多性能开销。我见过有团队在埋点里做同步写数据库结果接口延迟直接翻倍。建议用异步队列或者本地缓冲批量写入。2.2 模型分级不是所有请求都值得用最贵的模型这是成本优化里最立竿见影的一招。很多团队不管什么请求都往最贵的模型上打这是最大的浪费。我的做法是把请求分成三档简单档意图识别、文本分类、格式转换、简单问答。这类请求用轻量模型就够了单价可能只有旗舰模型的十分之一甚至更低。标准档常规的文本生成、摘要、翻译、代码补全。用中档模型性价比最高。复杂档需要深度推理、长上下文理解、多步骤规划的请求。这类才用旗舰模型。怎么判断一个请求该走哪一档可以在接入层做一个轻量的路由判断。最简单的做法是基于请求的token长度和业务标签来路由。比如token数小于500且业务标签是“分类”的直接走轻量模型token数超过4000或者业务标签是“推理”的走旗舰模型。我实测下来光是做模型分级这一件事就能把整体成本压下来40%到60%。而且大部分场景下用户根本感知不到差别因为简单请求用轻量模型和旗舰模型的结果差异很小。2.3 缓存策略同样的请求不要付两次钱AI API的缓存和传统HTTP缓存不太一样因为同样的输入不一定产生同样的输出取决于temperature等参数。但有一类请求是天然可缓存的temperature设为0的请求。这类请求的输出是确定性的同样的输入永远得到同样的输出完全可以缓存。具体怎么做在接入层对请求做hashkey是“模型名输入内容关键参数”value是模型的输出。下次同样的请求进来直接返回缓存结果不调API。缓存的有效期可以根据业务场景来定一般设24小时到7天都合理。还有一类是语义缓存。用户问“今天天气怎么样”和“今天天气如何”字面不同但语义相同。这种可以用embedding做相似度匹配相似度超过阈值的直接返回缓存结果。不过语义缓存的实现复杂度高一些误判率也需要控制建议先在低风险场景试点。实操心得缓存一定要设上限和淘汰策略。我见过有团队缓存只写不删三个月后缓存文件占了200G磁盘查询性能反而被拖垮了。建议用LRU策略并且给缓存总量设一个硬上限。2.4 预算熔断给每个密钥设一条红线这是最后一道防线。不管前面的优化做得多好你都需要一个硬性的预算控制机制。具体做法是给每个密钥或者每个业务线设一个日预算和周预算。当消耗达到预算的80%时触发告警达到100%时自动降级或者直接拒绝请求。降级的意思是把请求从旗舰模型切到轻量模型或者返回一个兜底结果。拒绝就是直接返回错误码让业务方知道预算用完了。这个机制听起来简单但关键时刻能救命。我那个客服团队的朋友如果当初设了一个日预算熔断最多损失一天的预算不至于三个月烧掉好几万。预算的粒度建议至少做到按密钥维度。如果业务线比较多可以再细一层按“密钥业务标签”来设。这样即使某个业务线出问题也不会影响其他业务线的正常使用。3. 限流保护你的接口也保护你的钱包3.1 限流不只是防DDoS更是防自己人很多人一听到限流就想到防攻击觉得只有面向公网的服务才需要。但AI API的限流更多时候防的是自己人——防的是一个写错的循环、一个失控的Agent、一个忘记加退避的重试逻辑。我遇到过最典型的情况一个开发同学在调试的时候写了一个while循环每次调用AI API判断结果是否满足条件不满足就重试。结果因为prompt写得有问题模型一直返回不满足条件的结果那个循环跑了三千多次才被手动停掉。如果没有限流这个循环能跑到天亮。所以限流的第一个原则是所有调用AI API的地方都要有限流不分内外。3.2 限流策略怎么选令牌桶还是滑动窗口常见的限流算法有几种我简单说一下各自适合的场景。令牌桶适合允许突发流量的场景。桶里按固定速率放令牌请求来了拿一个令牌拿不到就拒绝或者排队。它的特点是允许一定程度的突发比如你设了每秒10个请求但桶容量是50那短时间内可以承受50个请求的突发。滑动窗口适合对速率要求比较严格的场景。它统计的是一个时间窗口内的请求总数超过阈值就拒绝。相比固定窗口滑动窗口不会出现窗口边界处的流量翻倍问题。漏桶适合需要平滑输出的场景请求按固定速率被处理多余的排队或丢弃。对于AI API的限流我一般推荐令牌桶因为AI请求的耗时本身就不固定允许一定的突发更符合实际使用模式。具体的参数怎么定我的经验是这样先统计正常业务情况下的QPS峰值比如是每秒5个请求。把限流阈值设成峰值的1.5到2倍也就是每秒8到10个请求。桶容量设成阈值的3到5倍用来吸收短时突发。这样既能挡住异常流量又不会误伤正常的业务波动。3.3 多维度限流别只盯着QPS只按QPS限流是不够的。AI API还需要考虑这几个维度Token维度有些请求QPS不高但每次请求的token数巨大消耗的成本反而更高。所以除了限制请求数还要限制单位时间内的token消耗总量。并发维度限制同时进行的请求数量。AI API的响应时间通常比较长如果并发数不控制很容易把连接池打满。用户维度如果是多租户的系统每个用户或者每个租户要有独立的限流配额。防止一个用户把整个系统的配额用完。模型维度不同模型的成本和响应时间不同限流策略也应该不同。旗舰模型的限流应该更严格轻量模型可以宽松一些。这几个维度可以叠加使用。比如一个请求进来先检查用户维度的配额再检查模型维度的配额最后检查全局的QPS和token配额。任何一层不通过就拒绝。3.4 限流之后的降级和排队限流不是简单地返回429就完事了。你需要考虑被限流的请求怎么处理。对于实时性要求高的场景比如对话式交互被限流了就直接返回一个友好的提示让用户稍后重试。对于实时性要求不高的场景比如批量处理任务可以把请求放到队列里排队等配额释放了再处理。排队的时候要注意队列的长度和超时时间。队列太长会导致请求积压用户等太久超时时间太短又会导致大量请求被丢弃。我一般建议队列长度不超过限流阈值的10倍超时时间设在30秒到60秒之间。注意降级策略要和业务方对齐。我见过有团队自己决定了降级方案结果业务方完全不知情出了问题互相甩锅。降级方案一定要提前沟通好最好写进接口文档里。4. 密钥管理最容易被忽视的重灾区4.1 密钥泄露的常见途径我梳理了一下我见过或者听说过的密钥泄露案例大概有这么几种途径硬编码在前端代码里这是最蠢但也最常见的一种。前端代码是公开的任何人打开开发者工具都能看到。提交到了代码仓库开发同学本地调试的时候把密钥写在了配置文件里然后一不小心commit上去了。即使后来删掉了git历史里还能找到。日志里打印了密钥调试的时候把完整的请求头打到了日志里日志又被收集到了日志平台访问日志平台的人都能看到。在聊天工具里传阅为了图方便把密钥直接发在群里或者私聊里。聊天记录一旦泄露密钥就跟着泄露了。第三方依赖泄露用的某个开源库或者第三方服务出了安全漏洞密钥被窃取。这几种途径里前三种是可以通过流程和工具来防范的后两种更多是靠意识。4.2 密钥的生命周期管理一个密钥从创建到销毁应该有一个完整的管理流程。我建议至少包含这几个环节创建密钥的创建应该走审批流程不能谁想创建就创建。创建的时候要明确用途、负责人、预计的调用量和预算。分发密钥不能明文分发。应该通过密钥管理服务来下发应用启动的时候从密钥管理服务拉取而不是从配置文件里读。轮换密钥要定期轮换建议至少每90天换一次。轮换的时候要支持双密钥并行也就是新旧密钥同时有效一段时间等所有调用方都切换到新密钥之后再禁用旧密钥。监控每个密钥的调用量、调用来源、消耗成本都要有监控。一旦发现异常比如调用量突然暴涨、调用来源出现陌生IP要能及时告警。销毁不再使用的密钥要及时禁用和删除。我见过有团队创建了几十个密钥实际在用的只有几个剩下的都在“裸奔”。4.3 密钥的存储和传输密钥的存储有几个原则不落盘、不进代码、不进日志。不落盘的意思是密钥尽量不要写在配置文件里。如果一定要写那配置文件本身要加密而且解密密钥要通过环境变量或者密钥管理服务来注入。不进代码的意思是密钥绝对不能出现在代码仓库里。可以用.gitignore来防止误提交但更可靠的做法是在CI/CD流程里加一个密钥扫描的步骤一旦发现疑似密钥的内容就直接阻断构建。不进日志的意思是日志里涉及密钥的部分要做脱敏处理。比如只打印密钥的前4位和后4位中间用星号代替。传输方面密钥的传输必须走加密通道。应用和密钥管理服务之间的通信要用TLS密钥本身在存储的时候也要加密。4.4 最小权限原则每个密钥只授予它需要的最小权限。比如一个只做文本分类的密钥就不应该给它调用旗舰模型的权限。一个只在测试环境使用的密钥就不应该在生产环境生效。具体怎么做大多数AI API平台都支持给密钥设置权限范围。你可以限制密钥可以调用的模型列表、可以使用的功能、每天的调用上限、甚至可以的调用来源IP范围。我一般会建议至少做这几层限制按环境隔离测试环境的密钥和生产环境的密钥完全分开不能混用。按功能隔离不同业务模块用不同的密钥一个模块出问题不会影响其他模块。按模型隔离只给密钥开通它需要的模型权限不需要的模型一律不开。按来源隔离如果调用方的IP是固定的可以设置IP白名单。实操心得我习惯给每个密钥起一个有意义的名字格式是“环境-业务-用途”比如“prod-customer-service-chat”。这样一看名字就知道这个密钥是干什么的审计的时候也方便。5. 三块怎么配合一个完整的防护体系5.1 分层防护的思路成本控制、限流、密钥管理这三块不是孤立的它们应该组成一个分层的防护体系。最外层是密钥管理它决定了谁能调用。密钥泄露了后面的防护再强也没用。所以密钥管理是基础是入口。中间层是限流它决定了调用频率的上限。即使密钥泄露了限流能把损失控制在一定范围内。限流是刹车是保险丝。最内层是成本控制它决定了最终花多少钱。成本控制是兜底是最后一道防线。前面的防护都失效了成本控制还能保证你不会倾家荡产。这三层要同时生效不能只做其中一层。我见过有团队只做了密钥管理觉得密钥没泄露就万事大吉结果一个死循环把预算烧完了。也见过有团队只做了限流结果密钥泄露之后攻击者用分布式的方式绕过限流照样把预算刷爆。5.2 监控和告警的配置防护体系建好之后你需要一套监控来确保它正常工作。我建议至少监控这几个指标监控指标告警阈值建议告警方式单密钥日消耗超过日预算的80%邮件即时消息单密钥调用频率超过限流阈值的90%即时消息全局日消耗超过日预算的80%邮件即时消息密钥调用来源异常出现新的IP或地区即时消息电话限流触发次数5分钟内超过10次即时消息缓存命中率低于30%邮件这些阈值不是固定的要根据你的业务特点来调整。比如你的业务有明显的波峰波谷那告警阈值也要跟着调整不然每天波峰的时候都在告警很快就没人看了。5.3 应急响应流程万一真的出了事故比如密钥泄露或者预算被刷爆你需要一个应急响应流程。我建议至少包含这几步确认确认事故是否真实发生影响范围有多大。止损立即禁用涉事密钥或者把限流阈值调到最低先止血。排查查日志找出泄露的途径和攻击的来源。恢复创建新密钥更新调用方配置恢复正常服务。复盘分析事故原因修补流程漏洞更新防护策略。这个流程要提前演练不能等出了事再临时想。我一般建议每季度做一次演练模拟一个密钥泄露的场景看看团队能不能在30分钟内完成止损。6. 常见问题与排查技巧实录6.1 限流误伤了正常业务怎么办这是最常见的问题。限流阈值设得太低正常业务请求被挡住了。排查思路是这样先看被限流的请求特征。是集中在某个时间段还是均匀分布是集中在某个业务线还是所有业务线都有如果是集中在某个时间段那可能是业务本身的波峰需要调整限流阈值或者做动态限流。如果是集中在某个业务线那可能是那个业务线的调用逻辑有问题需要单独排查。动态限流的意思是限流阈值不是固定的而是根据历史流量自动调整。比如你可以取过去7天同一时间段的QPS均值乘以一个系数作为当前时间段的限流阈值。这样波峰的时候阈值自动调高波谷的时候自动调低。6.2 密钥轮换的时候怎么做到不停机密钥轮换最大的风险是旧密钥禁用了但还有调用方在用导致服务中断。要做到不停机关键是双密钥并行。具体步骤是这样先创建新密钥把新密钥分发给所有调用方。调用方更新配置同时支持新旧两个密钥。等确认所有调用方都切换到新密钥之后再禁用旧密钥。禁用之前可以先观察一段时间比如一周确认旧密钥的调用量降到了零。如果调用方比较多可以用配置中心来管理密钥这样切换的时候只需要改配置中心不需要每个调用方都改代码。6.3 成本突然暴涨怎么快速定位成本暴涨的排查我一般按这个顺序来第一步看是哪个密钥的消耗涨了。如果是一个密钥那问题大概率出在那个密钥对应的业务上。如果是所有密钥都涨了那可能是全局性的问题比如某个基础服务被大量调用。第二步看是哪个模型的消耗涨了。如果是一个模型那可能是那个模型的调用逻辑出了问题。如果是所有模型都涨了那可能是请求量整体上涨。第三步看是输入token涨了还是输出token涨了。输入token涨了可能是请求的内容变长了输出token涨了可能是模型的输出变啰嗦了或者max_tokens设得太大了。第四步看调用来源。有没有陌生的IP或者陌生的业务标签如果有那可能是密钥泄露了。这套排查流程走下来一般十分钟内就能定位到问题。6.4 常见问题速查表问题现象可能原因排查方法解决方案接口返回429触发限流查看限流日志确认是哪个维度触发调整限流阈值或优化调用逻辑账单突然上涨密钥泄露或死循环按密钥、模型、来源维度拆解消耗禁用涉事密钥修复调用逻辑密钥无效密钥被禁用或过期检查密钥状态和有效期创建新密钥并更新配置缓存命中率低缓存key设计不合理分析请求的重复率优化缓存key或引入语义缓存模型响应变慢并发过高或模型侧限流查看并发数和响应时间分布降低并发或切换到轻量模型最后分享一个小技巧我习惯在接入层加一个“紧急开关”一旦发现异常可以一键把所有AI API的调用切到一个兜底逻辑上比如返回预设的静态结果。这个开关平时不用但关键时刻能给你争取几分钟的排查时间。