流式输出接了安全审核，先想清楚谁在等谁

流式输出和安全过滤放在一条链路上，冲突点不在“要不要审”，而在于你让谁等谁。网关每收到一个 chunk 就要决定：立刻转发给客户端，还是先攒着等安检回话。这个决定一落地，TTFT、违规暴露窗口、拒答体验三件事就同时被改变了。

三条可选路径，代价各不相同

NVIDIA NeMo Guardrails 在流式模式下把 LLM 输出切成 chunk，每个块过一遍轻量规则，比如 PII 检查和内容安全 NIM。它的解法是滑动窗口缓冲：默认 context_size 保留近期 50 个 token，块大小按 chunk_size 配置，官方建议 200 左右给幻觉检测这类轨道留上下文，128 则降延迟但可能漏掉跨块违规。

关键开关是 stream_first。置为 True，token 一生成就先发给用户，同时并行缓冲送检；缓冲攒够一个 chunk 才开始判定。这换来的是低 TTFT，但官方文档自己写明了：一旦某条 rail 被触发，可能已经向用户发送了令人不快的文本。此时守卫服务会吐一个 JSON 错误对象，形如 {"error": {"code": "content_blocked"}}，但错误对象追不上已经漂出去的内容，调用方得自己处理这个已经撕裂的流。

第二条路是先审后发：等缓冲区满、判定通过再往下推。首字延迟至少多出一个 chunk 的生成时间加一次安检外呼，常见落在几百毫秒量级。适合强合规场景，代价是用户盯着加载转圈。

第三条是折中，按内容类型分流。比如前 N 个 chunk 必须过审再发，之后触发风险概率低的段落放开直通。这条路的难点不在实现，在说服审核方接受“审一部分”的定义。

网关做，还是各应用做

Higress 的方案是把这件事整体搬到网关侧，配合自托管的 Qwen3Guard，走 Chat Completions 协议，业务代码不改，上游模型服务也不动。审核覆盖请求进入前的用户输入、非流式 JSON 返回、以及 SSE 流式输出，风险阈值和拒答文案统一在网关配置。

这么做的好处很直接：阈值和拒答逻辑只有一份，模型切换或多业务上线不用逐仓库改审核 SDK。弊端也明摆着——网关成了数据面链路上的单点，内容提取、安检外呼、风险决策、流式缓冲都在这里串联，安检模型一抖动，整条链路一起抖动。自托管安全模型意味着你要多管一套扩缩容，但比起依赖外部云审核服务，网络边界的账更好算。

我倾向于网关方案，前提是给安检外呼单独做超时和降级。安检超时不等于放行，默认该往阻断方向走；如果你想配置成放行，这等于宣称审核是“尽力而为”，得先跟合规说清楚。

SSE 协议细节会让审核变复杂

流式返回遵循 SSE 协议，正文在 choices[0].delta.content 里，客户端逐块拼接，以 data: [DONE] 结束。这个结构带来两个审核侧的麻烦：一是你审核的单元是 delta 片段，句法上碎片化，一条违规表述可能被 delta.content 的切分恰好劈开；二是用量信息默认不返回，OpenAI 兼容协议要在请求里加 stream_options={"include_usage": true}，最后一个含 usage 的 chunk 常常不带 choices，写复盘代码时判断条件别只认 choices。

按照阿里云百炼的说明，流式的计费规则和非流式完全一致，按输入输出 token 计；请求中断时只算服务端收到终止请求前已生成的部分。这条直接决定了中段拦截的经济含义：越早拦下越省钱，但你攒 chunk 等审核，等于主动让模型先跑完这一段再决定是否拦——中间那道弦绕不开。

跨块语义违规：缓冲窗口的真实成本

单块判定过不了跨块的劫。用户分成两三条消息喂上下文、模型拆在两三个 chunk 里输出，都容易绕过单块规则。NeMo 的滑动窗口就是为此设计的，但窗口越大延迟越高，越小越漏。工程上没有免费答案，只有一笔账：

• 窗口 50 token：延迟友好，多分部违规检出率下降；
• 窗口 200-256 token：幻觉检测和上下文攻击识别有内容可用，但首块安检回包晚约一两百毫秒；
• 禁用流式：审核最完整，延迟最差，复杂 Agent 多次模型调用的场景首感觉尤其明显。

还有一种成本不被算，就是用户已经读了半个屏幕再戛然而止。拒答一定伴随上下文，理想状态不是把错误对象塞进流就完事。有产品经验的人更细，比如前端识别 content_blocked 后收掉已经渲染内容，换成统一提示再配一句可以直接追问的描述。这件事比审核本身要多花一些迭代时间。

流式的价值是降低感知延迟；审核的价值是减小暴露面积。这两个目标只能在缓冲窗口上谈判，谈不拢的理由早点写进设计文档。

一个能先跑起来的分法

对延迟敏感型应用（客服、助手类），启用流式加 stream_first，接受少量的早发风险，但保持 buffer 里的风险标记一起向后承，让下游接口和运营大盘都能看到。对需要强合规的部分业务，对 PII、政区属性、涉密数据等类型提高门槛，用先审后发加更小的 window。分类在请求级按渠道或业务线指定，不要让判定逻辑自己发挥。

接下来才是大头——把安检超时、错误块语义、用户已读内容追回这些非正常路径实现完。没实现完的流式审核不是审核，是一个乐观过滤器。