[Bug]: gzip response middleware compresses up to 1 MiB on the event loop: an 824 KB embeddings response stalls the worker ~165 ms

快速结论：当 LiteLLM Proxy 客户端发送 Accept-Encoding: gzip 且响应体达到 500 B 以上时，小于 1 MiB 的响应会在事件循环上做 gzip 压缩；824 KB 的 embeddings 响应会把 worker 卡住约 165 ms，导致同一 worker 上其他请求（如 /health/liveliness）延迟飙升。优先排查是不是开了 gzip 的 embeddings 大响应卡住了事件循环。

适用环境：LiteLLM v1.105.0（以及 main at b581ebc405）；代理以 --num_workers 1 运行；后端为 Azure OpenAI text-embedding-3-small；客户端使用 OpenAI SDK 默认的 encoding_format: base64。Issue 未确认 Python、CUDA、显卡等信息。

最快修复方案：升级到包含 #46362（merged 2026-10-15，b025681bef）的 LiteLLM 版本，该 PR 将 gzip 的 off-loop 阈值从 1 MiB 下调，使这类大响应不再在事件循环上压缩。

注意事项：Issue 中提出的“关闭 gzip middleware 的开关”和“跳过压缩效果差的响应体”两项诉求在讨论里没有落地，不要假设已有对应配置项。若暂时无法升级，Issue 提到过在前置 gateway 中剥离 Accept-Encoding 的方式，但这是绕过而非修复，且会失去 gzip 收益。

问题场景

用户在单 worker 的 LiteLLM Proxy 上运行 Azure OpenAI embedding 模型，客户端（OpenAI SDK 默认 encoding_format: base64）并发发送 100 输入的 embeddings 请求，并带 Accept-Encoding: gzip。每个响应约 824 KB，代理会对其做 gzip；同时另一个客户端持续调用 GET /health/liveliness，观察到存活探针延迟明显升高。

报错原文

[Bug]: gzip response middleware compresses up to 1 MiB on the event loop: an 824 KB embeddings response stalls the worker ~165 ms

原因分析

自 v1.105.0（#44052）起，代理会对 500 B 以上的完整响应体做 gzip。小于 OFF_LOOP_SIZE_BYTES（1 MiB）的响应体是在事件循环上内联压缩的，因此这类压缩会直接阻塞 worker。压缩耗时取决于响应体的可压缩性而不只是体积：Issue 实测 824 KB 的 base64 embeddings 响应用 gzip.compress level 6 约需 165 ms，而此时该 worker 上其他请求都在等待。多个大响应同时进行时，压缩会接连执行，进一步放大延迟。

对照数据：同样的 100 输入 float 格式 embeddings（2.9 MB）因为在 worker 线程上压缩，约 185 ms；1 输入 float（30 KB）约 1.6 ms 在循环上；/model/info（1.1 MB）约 15 ms 在线程上。也就是说问题集中在“体积未超 1 MiB 但压缩很慢”的响应上。Issue 还提到这可能与 #46276 中报告的部分开销有关。

环境排查

确认 LiteLLM 版本：v1.105.0 或 main at b581ebc405 属于受影响范围；是否已包含 b025681bef（#46362）。
确认启动参数：是否使用 --num_workers 1（单 worker 时阻塞影响最明显）。
确认客户端是否发送 Accept-Encoding: gzip，以及 embedding 请求是否使用 encoding_format: base64（OpenAI SDK 默认）。
确认响应体大小：base64 的 100 输入 embeddings 约 824 KB，float 约 2.9 MB，两者是否落在 1 MiB 阈值两侧。
后端是否为 Azure OpenAI text-embedding-3-small，以及部署方式（Issue 中为 Azure Container Apps，2 replicas × 1 worker）。
Issue 未提供 Python、CUDA、PyTorch、显卡或其他依赖信息，无需据此排查。

解决步骤

先复现确认：单 worker 启动代理，用 8 个并发循环发送带 Accept-Encoding: gzip 的 100 输入 base64 embeddings 请求，同时每 50 ms 调一次 GET /health/liveliness，记录其 p90/p99/max 延迟。
升级 LiteLLM 到包含 #46362（merged 2026-10-15，b025681bef）的版本，该修复下调了 off-loop 阈值，使 824 KB 这类响应改在 worker 线程上压缩。
升级后再按同一方法压测，对比 liveliness 的 p90/p99/max 是否回落到毫秒级，并观察 embeddings 吞吐是否恢复。
若暂时不能升级，可优先尝试在前置 gateway 中剥离 Accept-Encoding，避免 gzip middleware 被触发；注意这只是绕过，且会同时失去 gzip 带来的带宽收益。
关于“增加关闭 gzip middleware 的开关”：Issue 中明确说当时没有该配置，评论区也未确认已加入，因此不要依赖环境变量或 general_settings 来关闭它。

验证方法

在包含 #46362 的版本上重复同一压测：liveliness 的 p99 和 max 应从数百毫秒降到毫秒级（Issue 中 16 KiB 阈值下实测为 12 / 34 / 74 ms），同时 embeddings 吞吐不再因客户端接受 gzip 而下降。Issue 另给出单核 taskset -c 3 下的参考：824 KB 响应体相关数值从 1,322 ms 降到 0.2 ms。需要说明的是，Issue 中“max 仍接近 300 ms”的描述属于作者对同段数据的备注，验证时应以自己环境的 p90/p99/max 变化为准。