429 Too Many Requests是最直接的答案：不加限流，模型服务在真实流量下几秒内会被击穿，因GPU显存OOM、缓存击穿、第三方API配额超限、模型冷启动反复打断等多环节叠加失效，且限流阈值须基于实测性能反推。
429 Too Many Requests 是最直接的答案：不加限流，模型服务在真实流量下大概率会在几秒内被击穿。
这不只是“请求太多”的问题，而是模型推理链路上多个脆弱环节的叠加失效。
GPU显存瞬间被打满导致OOM
大模型或复杂pipeline（如预处理+推理+后处理）对显存敏感。一个batch size=1的请求可能占1.2GB显存；若并发突增到20，torch.cuda.OutOfMemoryError 就不是报错，是直接kill进程。限流不是限制QPS，是在给GPU留出安全缓冲区。
Redis缓存击穿引发数据库雪崩
很多生产系统用Redis缓存特征或中间结果。当限流缺失时，高频请求会集中穿透缓存，大量打到PostgreSQL或MySQL——而数据库连接池通常只有10–30个空闲连接。psycopg2.OperationalError: FATAL: remaining connection slots are reserved 这类错误往往出现在压测第3分钟。
第三方API调用配额被超额消耗
如果你的服务依赖外部能力（如语音识别、地理编码、支付验签），它们的X-RateLimit-Limit响应头不会骗人。未做客户端限流时，哪怕只部署单实例，requests.exceptions.HTTPError: 429 Client Error 也会让整个链路失败。更糟的是，有些厂商会封IP而非仅限流，恢复需人工申诉。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
模型warmup和冷启动被反复打断
PyTorch/Triton模型加载后需要“热身”：首次推理慢、后续才稳定。但无节制请求会让模型反复加载/卸载，torch.jit.load() 或 tritonclient.http.InferenceServerClient 初始化耗时跳变从200ms到2s+，监控图表上会看到锯齿状延迟尖峰——这不是模型问题，是流量没控住。
立即学习“Python免费学习笔记（深入）”；
真正容易被忽略的点是：**限流阈值不能靠拍脑袋定**。它必须基于实测的P95推理耗时、GPU利用率曲线、以及下游依赖的SLA来反推。比如某BERT服务实测单请求均值380ms，GPU显存占用78%，那么按1000 / 380 ≈ 2.6，再留30%余量，上限设为2 req/sec比设10更真实。 
