LLM网关流式内容安全实战：如何让敏感词拦截不中断SSE

1. 项目背景与核心痛点：为什么一个网关要花两周时间反复推倒重来？

最近三个月，我接手了公司内部大模型服务的统一接入层重构任务。表面看就是搭个“LLM网关”——把散落在不同部门的模型调用（OpenAI、Qwen、GLM、本地部署的Llama3）收口管理，加个鉴权、限流、日志、成本统计。听起来很常规，对吧？但真正动手才发现，这根本不是搭个Nginx反向代理就能完事的事。我们踩的第一个深坑，就出在“流式响应”和“内容安全”这两个词的交叉地带。

提示：流式响应（streaming）不是锦上添花的功能，而是前端体验的生命线。用户输入“写一封辞职信”，如果等3秒才吐出第一个字，体验直接崩盘；而内容安全也不是事后扫描，它必须在token逐个生成、逐个返回的过程中实时拦截——这意味着安全策略必须嵌入到流式数据的每一帧里，而不是等整段输出完成后再做判断。

我们最初选了One API，因为它开箱即用，Web UI漂亮，支持几十种模型后端，配置简单。上线第一天，测试同学就报了个诡异问题：“为什么我用curl调用流式接口，返回的JSON格式总在中途断掉？”查日志发现，One API在流式模式下会把原始模型返回的SSE（Server-Sent Events）格式，强行转换成一种自定义的JSON流结构，但这个转换过程在遇到敏感词触发拦截时，会直接中断整个HTTP连接，导致前端收到不完整的JSON，解析失败。这不是bug，是设计选择——它把“安全拦截”放在了流式响应组装完成之后，相当于等一锅汤烧好了再尝咸淡，咸了就全倒掉。

后来切到LiteLLM，它原生支持SSE透传，理论上更“干净”。但问题来了：它的内容安全模块是插件式的，需要自己写filter，而官方文档里只给了一个同步校验的demo。我们按例子里的写法，在completion函数里调用check_content_safety()，结果发现——流式响应的第一帧还没发出去，整个请求就被卡住了。因为同步校验在等待全部文本生成完毕，彻底废掉了流式的意义。

这就是标题里那个“坑”的本质：绝大多数LLM网关工具，其内容安全机制与流式传输架构是割裂的。它们要么牺牲流式体验保安全，要么牺牲安全保流式，没有第三条路。我们最终花了14天，不是在选工具，而是在理解每种方案底层的数据流走向、内存缓冲策略、错误传播路径。这篇文章，就是把这14天里画满草稿纸的流程图、被推翻三次的架构草稿、以及线上灰度时抓包看到的每一个TCP包，浓缩成一份可复用的选型决策地图。如果你正面临类似需求——需要统一接入多个模型、要求流式响应、且必须在流中实时过滤违规内容——那这篇记录里的每个参数、每行代码、每个抓包截图背后的逻辑，都值得你花20分钟读完。

2. 三大候选方案深度拆解：不只是功能对比，更是数据流架构的博弈

选型不是比谁功能多，而是看谁的数据流设计能天然兼容你的核心约束。我把One API、LiteLLM、以及我们最后手写的轻量方案，放在同一个显微镜下观察：当一个用户发起/v1/chat/completions?stream=true请求时，数据从客户端进来，到模型推理，再到响应返回，中间经过哪些关键节点？每个节点对流式和安全的处理方式，决定了整个链路的成败。

2.1 One API：优雅的封装，代价是流式控制权的让渡

One API的设计哲学是“一站式管理”，它把模型路由、负载均衡、API Key管理、审计日志全打包进一个Go二进制里。这种封装带来极致的易用性，但也埋下了流式安全的隐患。

它的流式响应处理流程是这样的：

1. 客户端发送流式请求 → One API接收并解析
2. One API将请求转发给后端模型（如OpenAI），并开启SSE监听
3. 后端返回SSE事件（data: {...}）→ One API逐条读取、解析、缓存到内存
4. 在内存中，它会把原始SSE的data:字段提取出来，拼装成一个自定义JSON对象：{"id":"...","object":"chat.completion.chunk","choices":[{"delta":{"content":"..."}}]}
5. 只有当这个拼装后的JSON对象完整生成后，One API才将其序列化为字符串，通过writer.Write()发送给客户端
6. 内容安全检查（如果启用）就发生在这一步之后——即整个chunk JSON生成完毕，准备写入socket之前

这个设计的好处是：响应格式高度统一，前端不用适配不同模型的SSE差异。坏处是致命的：安全检查成了流式传输的“闸门”，一旦触发拦截，整个HTTP连接会被http.Error()强制关闭，导致客户端收到不完整的JSON流，必然解析失败。我们实测过，在返回第5个token时触发敏感词，客户端收到的是一串残缺的JSON，Chrome开发者工具里显示“Unexpected end of JSON input”。

注意：One API的--disable-streaming启动参数并不能解决这个问题。它只是禁用流式转发，转而用非流式方式调用后端，再把完整响应切成chunk返回——这完全违背了流式设计的初衷，延迟反而更高。

2.2 LiteLLM：灵活的管道，但安全插件默认走错车道

LiteLLM的核心优势在于它的“Adapter”模式。它不自己实现模型调用，而是作为一层薄薄的协议转换器，把OpenAI格式的请求，翻译成对应模型（如Ollama、vLLM、Azure）能理解的格式。这种设计让它天生支持SSE透传——只要后端模型返回SSE，LiteLLM就原样转发，不做任何中间解析。

它的标准流式流程是：

1. 客户端请求 → LiteLLM接收
2. LiteLLM调用litellm.completion()，传入stream=True
3. completion()函数内部，会根据model参数选择对应的async_streaming实现（如openai_chat_completions_stream）
4. 这个实现会创建一个AsyncIterator，逐个yield从后端SSE流中解析出的ChatCompletionChunk对象
5. 外层FastAPI路由（或Flask）接收到这个iterator，用StreamingResponse包装后直接返回给客户端

问题出在第4步。LiteLLM的content_filter插件，默认是注册在completion()函数的顶层，也就是在async_streaming执行之前被调用。这意味着它试图对整个请求体（prompt）做校验，而不是对流式返回的每个chunk做校验。我们曾天真地以为，只要在litellm_settings.yaml里配置content_filter: "my_safe_filter"，就能自动生效。结果发现，my_safe_filter函数压根没被调用——因为LiteLLM的插件系统，对流式场景的支持是“弱耦合”的，它需要你手动在async_streaming的yield循环里插入校验逻辑。

我们试过修改源码，在openai_chat_completions_stream的for循环里加入if not is_safe(chunk.delta.content): raise ValueError("blocked")。这确实能拦截，但后果严重：raise ValueError会中断整个async generator，导致StreamingResponse收到一个空迭代器，客户端连接直接断开，效果和One API一样糟糕。

2.3 自研轻量方案：放弃“通用”，拥抱“可控”

当我们意识到，所有现成网关都在用“同步思维”处理“异步流式”问题时，决定退一步：不追求支持50种模型，只聚焦我们实际用的3种（OpenAI、Qwen、本地vLLM），把流式安全做成一个可插拔的、与数据流深度绑定的组件。

我们的核心设计原则就一条：安全校验必须发生在数据离开网关内存缓冲区、写入socket之前的最后一刻，且必须是非阻塞的。这意味着不能用if-else判断，而要用状态机+缓冲区管理。

具体实现是一个SafeStreamBuffer类：

• 它接收一个原始的AsyncIterator[ChatCompletionChunk]
• 维护一个滑动窗口（默认大小32 token），持续累积最近生成的文本
• 每当新chunk到来，将其delta.content追加到窗口，并触发一个轻量级的DFA（确定性有限自动机）敏感词匹配
• 匹配成功时，不中断流，而是立即向客户端发送一个特殊的{"type":"safety_block","reason":"xxx"}chunk，然后继续转发后续合法内容
• 窗口内容超过阈值（如1024字符），自动滚动清除最老的部分，保证内存占用恒定

这个设计让安全和流式第一次真正共存：前端收到的是标准OpenAI流式JSON，其中可能夹杂着我们自定义的安全事件，解析逻辑只需增加一行if chunk.get("type") == "safety_block": handle_block(chunk)，完全不影响现有业务代码。

3. 流式内容安全的底层原理：为什么90%的方案都倒在缓冲区设计上？

很多团队在选型时，会把“是否支持内容安全”当成一个布尔开关——开了就行。但实际落地时，你会发现，开关背后藏着一个精密的工程学问题：数据在网关内存中，是以什么形态存在？缓冲区有多大？何时刷新？错误如何传播？这些细节，直接决定了安全策略是锦上添花，还是雪上加霜。

3.1 缓冲区（Buffer）是流式安全的命门

想象一下，网关就像一条高速公路的收费站。流式响应是连续不断的车流（token），内容安全检查是收费站的安检门。如果安检门设在高速入口（请求阶段），它只能检查“司机身份证”（prompt），无法知道车上运的是什么货（生成内容）。如果安检门设在出口（响应完成），那所有车都得排队等最后一辆出来，再统一检查——这等于废掉了高速公路。

真正的流式安全，必须把安检门设在收费亭的传送带上——车（token）一上带，就开始扫描，有问题立刻打标（不是拦停），让后续车辆照常通行。这个“传送带”，就是网关的缓冲区。

One API的缓冲区是“块状”的：它等一整块（一个chunk）数据拼装好，再送检。LiteLLM默认没有缓冲区概念，它的AsyncIterator是“管道式”的，数据流经即走，没有地方插安检门。而我们自研的SafeStreamBuffer，则实现了“滑动窗口式”缓冲区——它像一个32格的传送带，新token进来，老token被挤出去，安检设备始终扫描当前带上的全部内容。

为什么窗口大小是32？这是实测出来的平衡点：

• 太小（如8）：无法覆盖常见敏感短语（如“炸药制作步骤”有7个汉字，但英文“how to make bomb”有16个字符），漏检率高
• 太大（如128）：内存占用飙升，且延迟增加（要等更多token才能触发匹配）
• 32：在中文场景下，能覆盖99%的敏感词组合，单个chunk平均内存占用<2KB，对网关GC压力极小

3.2 安全策略的传播方式：中断 vs 打标，是体验分水岭

几乎所有开源网关的文档，都把“拦截”描述成一个原子操作：匹配→阻断→返回错误。但在流式场景下，“阻断”这个词本身就是个陷阱。

HTTP/1.1的流式响应，依赖于TCP连接的持续打开。一旦网关调用writer.Close()或抛出未捕获异常，内核就会发送FIN包，客户端立刻断连。用户看到的，就是聊天框突然卡死，光标不动，没有任何提示。

我们选择的“打标”（Tagging）策略，本质是把安全事件降级为业务数据的一部分。当检测到敏感内容时，网关不是终止连接，而是构造一个标准JSON chunk：

{ "id": "chatcmpl-xxx", "object": "chat.completion.chunk", "created": 1717023456, "model": "gpt-4-turbo", "choices": [ { "index": 0, "delta": { "content": "" }, "finish_reason": null } ], "safety": { "type": "block", "trigger": "violence", "matched_token": "bomb" } }

这个chunk和普通响应chunk共享同一套解析逻辑，前端SDK只需在onMessage回调里增加几行判断：

if (chunk.safety?.type === 'block') { showWarningToast(`检测到不适宜内容：${chunk.safety.trigger}`); return; // 跳过渲染content } // 否则正常append chunk.choices[0].delta.content

这种设计带来了三个关键收益：

1. 零感知降级：即使安全策略触发，对话界面依然流畅滚动，用户知道“有东西被拦了”，但不会觉得“系统坏了”
2. 审计友好：所有安全事件都以结构化JSON形式落库，可精确追溯到哪个prompt、哪个模型、哪个token位置触发
3. 策略可演进：未来想把“block”改成“rewrite”（自动替换敏感词），只需改后端逻辑，前端完全不用动

3.3 敏感词匹配引擎：为什么不用正则，而选Aho-Corasick？

在SafeStreamBuffer里，我们没有用Python内置的re.search()，而是集成了ahocorasick库。这不是为了炫技，而是正则在流式场景下的根本性缺陷。

正则表达式是“贪婪匹配”的。当你用re.search(r'bomb|explosive|weapon', text)去扫描一段文本时，它会从头开始，逐个字符尝试所有可能的匹配路径。在滑动窗口里，每次新token进来，都要对整个窗口文本重新执行一遍正则——窗口越大，耗时越长。我们实测过，窗口长度128时，单次匹配平均耗时12ms，而流式响应要求每个chunk的处理延迟<5ms，否则会拖慢整体流速。

Aho-Corasick算法则完全不同。它把所有敏感词构建成一棵“自动机树”，文本扫描时，只需要一次遍历，就能同时匹配所有关键词。它的复杂度是O(n)，n是文本长度，与关键词数量无关。更重要的是，它可以增量更新——当新token进来，只需在自动机上走一步，就能得到最新匹配结果。

我们构建的敏感词树包含：

• 一级词库：国家网信办《网络信息内容生态治理规定》明确列出的23类违规词（如涉政、暴恐、色情）
• 二级词库：行业定制词（如金融场景的“稳赚不赔”、“内幕消息”）
• 三级词库：客户白名单（允许特定场景使用“加密货币”等词）

三者通过权重叠加，最终输出一个综合风险分值。当分值>阈值，才触发safety_block。这种分级机制，让安全策略既有刚性底线，又有业务弹性。

4. 实操落地全流程：从环境搭建到灰度发布，附真实配置与抓包分析

选型结束，只是万里长征第一步。真正考验功力的，是把理论方案变成稳定运行的服务。下面是我亲手操作、全程录像的落地步骤，包括所有容易被忽略的细节、那些文档里绝不会写的坑，以及线上灰度时最关键的三个监控指标。

4.1 环境准备与依赖锁定：为什么必须用Poetry而不是pip

我们放弃了Docker Compose一键部署的诱惑，选择用Poetry管理Python依赖。原因很简单：LiteLLM和One API的底层HTTP库（httpx、aiohttp）版本冲突，会导致流式响应出现随机乱码。用pip install无法精确锁定传递依赖。

Poetry的pyproject.toml核心配置如下：

[tool.poetry.dependencies] python = "^3.11" litellm = {version = "^1.32.0", extras = ["proxy"]} fastapi = "^0.111.0" uvicorn = {version = "^0.29.0", extras = ["standard"]} ahocorasick = "^2.0.0" # 关键：强制指定httpx版本，避免litellm自动升级到1.0+ httpx = {version = "^0.27.0", allow-prereleases = false}

注意：LiteLLM 1.32.0默认依赖httpx>=0.25.0，但httpx 1.0.0引入了新的连接池行为，在高并发流式场景下，会出现RemoteProtocolError: Server disconnected。我们实测0.27.0是最稳定的版本，必须显式锁定。

安装命令不是poetry install，而是：

poetry env use 3.11 # 显式指定Python版本 poetry install --no-dev # 生产环境不装dev依赖 poetry export -f requirements.txt > requirements.txt # 导出供Docker使用的txt

4.2 核心代码实现：SafeStreamBuffer的127行真相

SafeStreamBuffer类是整个方案的灵魂，下面贴出精简后的核心逻辑（已脱敏，可直接复用）：

from typing import AsyncIterator, Dict, Any, Optional, List import ahocorasick from litellm.types.completion import ChatCompletionChunk class SafeStreamBuffer: def __init__(self, iterator: AsyncIterator[ChatCompletionChunk], safety_rules: Dict[str, List[str]] = None, window_size: int = 32): self.iterator = iterator self.window_size = window_size self.buffer = [] # 存储最近window_size个token self.ac_automaton = self._build_automaton(safety_rules or {}) def _build_automaton(self, rules: Dict[str, List[str]]) -> ahocorasick.Automaton: automaton = ahocorasick.Automaton() for category, words in rules.items(): for word in words: # 中文需按字符切分，英文按单词 if len(word) > 1 and all('\u4e00' <= c <= '\u9fff' for c in word): for char in word: automaton.add_word(char, (category, char)) else: automaton.add_word(word.lower(), (category, word)) automaton.make_automaton() return automaton async def __aiter__(self): async for chunk in self.iterator: # 提取content，处理None情况 content = chunk.choices[0].delta.content or "" # 更新滑动窗口 self.buffer.append(content) if len(self.buffer) > self.window_size: self.buffer.pop(0) # 构建当前窗口文本 window_text = "".join(self.buffer) # Aho-Corasick匹配 matches = [] for end_index, (category, matched_word) in self.ac_automaton.iter(window_text): matches.append({ "category": category, "word": matched_word, "position": end_index - len(matched_word) + 1 }) # 如果匹配，注入safety字段 if matches: chunk_dict = chunk.model_dump() chunk_dict["safety"] = { "type": "block", "matches": matches[:3], # 只返回前3个匹配，防爆 "timestamp": int(time.time()) } yield ChatCompletionChunk(**chunk_dict) else: yield chunk

这段代码的关键点：

• __aiter__方法必须是async的，否则无法在FastAPI的StreamingResponse中使用
• model_dump()是Pydantic v2的推荐方法，比dict()更安全，能处理嵌套模型
• matches[:3]限制返回数量，防止恶意构造超长敏感词列表导致JSON体积爆炸

4.3 FastAPI路由集成：三行代码接入现有服务

有了SafeStreamBuffer，集成到FastAPI只需三行：

from fastapi import APIRouter, Request, Depends from litellm import completion from my_safe_buffer import SafeStreamBuffer router = APIRouter() @router.post("/v1/chat/completions") async def chat_completions(request: Request): body = await request.json() # 标准litellm调用，返回AsyncIterator stream_iter = completion( model=body.get("model"), messages=body.get("messages"), stream=True, **{k: v for k, v in body.items() if k not in ["model", "messages", "stream"]} ) # 包装成安全流 safe_iter = SafeStreamBuffer(stream_iter, safety_rules=get_safety_rules()) # 返回StreamingResponse return StreamingResponse( safe_iter, media_type="text/event-stream", headers={"Cache-Control": "no-cache", "Connection": "keep-alive"} )

注意：headers里的Connection: keep-alive至关重要。Nginx默认会缓存SSE响应，加这个头告诉它不要缓冲，直接透传。我们在灰度时发现，没加这个头，前端收到的流会有2-3秒延迟。

4.4 灰度发布与监控：三个必须盯死的指标

上线不是终点，而是观测的开始。我们设置了三个黄金监控指标，全部接入Prometheus+Grafana：

灰度策略是分阶段的：

• 第1天：1%流量，只监控disconnect_rate，确保不崩
• 第3天：10%流量，加入safety_block_rate，观察误伤率，动态调整敏感词权重
• 第7天：50%流量，全量开启，重点看stream_latency_ms，优化缓冲区大小

最惊险的一次，是在第5天，disconnect_rate突然跳到0.8%。抓包分析发现，是某个客户上传了超长system prompt（>10KB），导致SafeStreamBuffer的window_text字符串过大，触发Python的MemoryError。解决方案很简单：在__init__里加一行self.max_window_text_len = 2048，超过就截断。这个细节，所有文档都不会告诉你。

5. 常见问题与避坑指南：那些让我们加班到凌晨三点的“小问题”

选型和落地过程中，我们整理了一份高频问题清单。这些问题看似琐碎，但每一个都曾让我们在深夜对着日志发呆。这里不讲大道理，只说怎么快速解决。

5.1 “为什么我的流式响应在Postman里能跑，前端却报错？”

这是最经典的跨域+SSE组合坑。Postman不校验CORS，但浏览器会。很多人以为加个Access-Control-Allow-Origin: *就行，但SSE要求更严格：

• 必须设置Access-Control-Allow-Credentials: true（如果前端带cookie）
• 必须设置Access-Control-Expose-Headers: Content-Type, X-Request-ID（暴露自定义头）
• 最关键的是：SSE要求响应头Content-Type必须是text/event-stream，且不能有任何额外空格

我们曾被一个空格坑了6小时：Nginx配置里写了add_header Content-Type "text/event-stream ";，末尾多了一个空格。Chrome直接拒绝解析，报错Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': InvalidAccessError: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': The value is not structured cloneable.。解决方案：用curl -I检查响应头，确认Content-Type值完全匹配。

5.2 “LiteLLM的fallback功能在流式下失效，怎么办？”

LiteLLM的fallbacks参数，允许配置备用模型（如["gpt-4", "gpt-3.5-turbo"]），当主模型失败时自动切换。但在流式场景下，这个功能默认不生效，因为async_streaming的异常处理路径和非流式不同。

正确用法是显式捕获litellm.Timeout和litellm.APIError：

try: stream_iter = completion(model="gpt-4", messages=..., stream=True) return StreamingResponse(SafeStreamBuffer(stream_iter)) except (litellm.Timeout, litellm.APIError) as e: # 降级到备用模型 stream_iter = completion(model="gpt-3.5-turbo", messages=..., stream=True) return StreamingResponse(SafeStreamBuffer(stream_iter))

注意：不能用fallbacks=["gpt-4", "gpt-3.5-turbo"]参数，因为LiteLLM的fallback逻辑在completion()顶层，而流式调用会绕过它。

5.3 “One API的Web UI里看不到流式日志，怎么调试？”

One API的UI日志只显示非流式请求。要查看流式请求的详细过程，必须看它的stdout日志。启动时加--log-level debug，然后用journalctl -u one-api -f实时跟踪。

关键日志字段：

• DEBUG级别会打印[Proxy] Forwarding request to https://api.openai.com/...，确认请求是否发出
• INFO级别会显示[Proxy] Response status: 200, streaming: true，确认后端返回了流式响应
• 如果看到[Proxy] Error forwarding response: write tcp ...: broken pipe，说明客户端提前断连，不是网关问题

5.4 “安全策略更新后，旧的敏感词还在命中，缓存没清？”

ahocorasick.Automaton对象是不可变的。每次更新敏感词库，必须重建整个automaton实例，并替换SafeStreamBuffer中的引用。我们最初的代码是全局单例，导致热更新后，新请求还是用旧的automaton。

解决方案：用functools.lru_cache缓存automaton，但key要包含规则版本号：

@lru_cache(maxsize=128) def get_automaton(rules_hash: str) -> ahocorasick.Automaton: # 根据rules_hash加载规则，构建automaton pass

每次规则变更，生成新的rules_hash = hashlib.md5(json.dumps(rules).encode()).hexdigest()，调用get_automaton(rules_hash)即可。

5.5 “为什么vLLM后端的流式响应，比OpenAI慢一倍？”

vLLM默认的--enable-prefix-caching会提升吞吐，但首次响应延迟增加。我们实测发现，关闭前缀缓存后，首token延迟从1200ms降到650ms。

正确启动命令：

python -m vllm.entrypoints.api_server \ --host 0.0.0.0 \ --port 8000 \ --model Qwen/Qwen2-7B-Instruct \ --tensor-parallel-size 2 \ --enable-prefix-caching=False \ # 关键！ --max-num-seqs 256

这个参数在vLLM文档里藏得很深，但它对流式体验的影响是决定性的。

6. 经验总结：关于LLM网关，我们最终悟出的三条铁律

做完这个项目，我撕掉了之前写的十几页技术方案PPT，把最核心的体会，浓缩成三条写在笔记本首页。它们不是教科书结论，而是被线上事故反复捶打出来的认知。

第一条铁律：永远假设你的网关是链路中最脆弱的一环。
我们曾以为模型服务才是瓶颈，结果发现，90%的流式超时，根源在网关的缓冲区设计。一个没考虑内存增长的滑动窗口，会在高并发下吃光所有RAM；一个没处理好连接复用的HTTP客户端，会让TIME_WAIT堆积如山。网关不是管道，它是需要精心养护的“活体”。每次上线新功能，第一件事不是测功能，而是用ab -n 10000 -c 100压测内存和连接数。

第二条铁律：流式安全的本质，是状态管理，不是规则匹配。
刚接手时，我满脑子都是“怎么写更精准的正则”。后来才明白，真正的难点在于：如何在一个无限生成的token流里，维护一个有限的、可预测的状态窗口？如何让安全事件的传播，不破坏流式协议的语义？这已经超出了文本匹配的范畴，进入了分布式系统状态一致性的领域。SafeStreamBuffer里的滑动窗口、自动机、打标机制，本质上是在构建一个轻量级的状态机。

第三条铁律：不要迷信“开箱即用”，真正的生产就绪，永远在文档之外。
One API的文档说“支持流式”，LiteLLM的文档说“支持内容过滤”，但它们都没告诉你：当两者相遇时，会发生什么。这些“边缘情况”，恰恰是线上最常出问题的地方。我们最终的方案，70%的代码是处理这些文档没写的细节：Nginx的SSE透传配置、FastAPI的StreamingResponse生命周期管理、vLLM的GPU显存碎片化应对……所谓架构能力，就是把所有“应该工作”的地方，都变成“一定工作”的地方。

现在，这个网关已经稳定运行了87天，日均处理23万次流式请求，安全拦截准确率99.2%，首token P95延迟稳定在720ms。它没有华丽的UI，没有炫酷的Dashboard，只有一个简洁的Prometheus监控面板，上面三条曲线平稳如初。有时候，最好的技术选型，不是选最热门的工具，而是选那个你能把它每一行代码都读懂、每一个字节都掌控的方案。