今天的主线判断：“LLM 工程正在进入‘供应链安全 + 实时化（语音/流式）+ 多后端（CUDA/ROCm）’三重叠加期。”

  • 供应链侧：一旦常用中间层（如统一网关/路由器）出事，影响面会比模型本身更大。
  • 实时侧：语音/流式调用链更长（SIP/WebRTC/SDP/媒体网关），任何一环的兼容性抖动都会直接变成线上事故。
  • 推理侧：在 CUDA 之外，ROCm/插件化容器的“组合爆炸”持续出现，逼着团队把可观测性与回滚策略做得更像 SRE。

下面是过去 24h 内最值得工程团队优先处理/关注的更新（偏 Infra & Agent 工程影响）。

1) LiteLLM 疑似供应链投毒：PyPI 版本被指含恶意代码（需立刻止血）

参考：

  • NVIDIA Developer Forums 讨论：https://forums.developer.nvidia.com/t/critical-attack-litellm-compromised-pin1-82-6-now/364638

  • 社区讨论（需自行甄别）：https://www.reddit.com/r/cybersecurity/comments/1s2gf82/litellm_1828_on_pypi_was_compromised_steals_ssh/

  • 事实： 社区与开发者论坛出现高优先级告警：litellm 在 PyPI 的近期版本（讨论中提到 1.82.7/1.82.8）被怀疑被篡改，可能窃取 SSH Key、云凭证、K8s Secrets 并植入持久化后门；建议紧急 pin 回 1.82.6 并排查。

  • 意义： LiteLLM 常被作为“统一模型网关/路由层/计费与限流层”放在核心链路；一旦被投毒，相当于拿到了所有上游模型凭证与下游业务数据的转发中枢。

  • 影响：

    • 生产集群可能存在“凭证被读取→横向移动→持续驻留”的链式风险；
    • 若你把 OpenAI/Anthropic/Bedrock/Groq 等 key 都集中给网关，单点沦陷的损失会被放大。

  • 建议：

    1. 立即在依赖层做版本冻结/回滚（pin 到被认为安全的版本），并锁定构建产物（SBOM/镜像 digest）；
    2. 以“已泄露”假设处理：轮转所有可能接触过的密钥（API key、云 AK/SK、K8s serviceaccount token、CI/CD token）；
    3. 拉取过去 24–72h 的出站流量/进程树/容器层变更记录，重点查异常域名、反向 shell、可疑 cron；
    4. 补齐防线：PyPI 依赖上生产前加“allowlist + hash pin + 私有镜像仓库”。

2) OpenAI gpt-realtime 的 SIP 呼叫被报 “Invalid SDP offer”：实时语音链路的兼容性风险再次暴露

参考：https://community.openai.com/t/invalid-sdp-error-on-new-call-to-sip-endpoint/1377602

  • 事实： 开发者社区报告：向 SIP endpoint 发起新呼叫时收到 400 Bad Request，错误信息指向 Invalid SDP offer，导致新 SIP 呼叫无法建立（“dead in the water”）。
  • 意义： SDP 是实时音视频协商的“契约”；当服务端/网关对 SDP 的校验、支持的 codec/attribute、或 offer/answer 流程发生变化（哪怕是小变更），客户端会直接从“能用”掉到“完全不可用”。
  • 影响：
    • 依赖 SIP/语音外呼/呼叫中心的团队，会遇到“业务侧无退路”的停摆风险；
    • 若你把语音作为 Agent 的输入输出通道（会议助理、电话机器人），可用性与回滚策略必须提升到 P0。
  • 建议：
    1. 客户端侧做好SDP 最小化/规范化（去掉非必需 attribute，固定 codec 优先级），并在灰度环境对比“成功 vs 失败”的 SDP diff；
    2. 建立双栈兜底：SIP ↔ WebRTC（或 PSTN ↔ VoIP）至少保留一条替代路径；
    3. 监控指标不要只看 HTTP：增加“呼叫建立成功率、协商耗时、ICE/DTLS 失败率、媒体首包延迟”。

3) vLLM（ROCm）侧出现“legacy triton_kernels”相关告警与卡住案例：多后端推理栈仍在磨合

参考：https://discuss.vllm.ai/t/gpt-oss-triton-kernels-moe-py-59-using-legacy-triton-kernels-on-rocm/2485

  • 事实： vLLM 论坛有用户报告：ROCm 环境下运行 vLLM（提到 serving Gemma3）出现 “Using legacy triton_kernels on ROCm” 等告警并卡住，表现为容器/进程停在某阶段不再推进。
  • 意义： 当团队从单一 CUDA 走向 CUDA+ROCm（或混合 GPU）时，问题往往不在模型，而在kernel 路径选择、编译缓存、算子支持矩阵、以及运行时探测逻辑。
  • 影响：
    • 线上可能出现“部署成功但吞吐为 0”的隐性故障；
    • 你对同一模型的性能与稳定性评估会被后端差异严重扭曲（benchmark 结果不可直接迁移）。
  • 建议：
    1. 把推理栈当作“有版本契约”的产品：记录 vLLM/ROCm/驱动/MIopen/Triton 的组合矩阵，并为每个组合做可复现的 smoke test；
    2. 遇到卡住先收敛变量：关闭自动 kernel 选择/尝试固定 backend；必要时切回更保守的 kernel 路径换稳定；
    3. 对外提供 SLA 前，优先补齐启动阶段可观测性（加载/编译/缓存命中/首 token）与失败自动回滚。

4) DeepStream 9.0 容器内 “nvvllmvlm plugin not found” 之类问题：插件化推理组件的“封装完整性”在拖慢交付

参考：https://forums.developer.nvidia.com/t/nvvllmvlm-plugin-not-found-in-deepstream-9-0-container/364619

  • 事实： NVIDIA 论坛出现 DeepStream 9.0 容器内找不到特定插件（讨论为 nvvllmvlm）的报错反馈，指向镜像/插件打包与版本对齐问题。
  • 意义： 对“多媒体管线 + LLM/VLM 推理”的产品，依赖往往跨越 GStreamer/驱动/TensorRT/插件二进制；任何一层的封装不完整都会把问题从“模型工程”变成“系统集成”泥潭。
  • 影响：
    • 交付节奏被容器封装问题绑架（你不是在调模型，而是在追缺失的 .so、版本符号、路径与权限）；
    • 生产事故定位困难：同一个 pipeline 在不同镜像 tag/driver 版本下行为不同。
  • 建议：
    1. 镜像构建使用可验证清单（列出必须存在的插件/二进制/符号），CI 里做 ldd/gst-inspect 类的验收；
    2. 以“运行时不可变”为目标：驱动与用户态组件的兼容性写入文档并强制校验；
    3. 对 GPU 多媒体栈，优先考虑“官方基镜像 + 最少增量”，减少自定义层带来的漂移。

5) 追踪模型/API 变更的工程化需求上升：需要一个“变更雷达”而不是靠刷新闻

参考：https://llm-stats.com/llm-updates

  • 事实： LLM Stats 等站点提供“模型版本时间线/组织更新/API provider 变更”聚合入口，强调高频更新与版本语义（快照/大版本/小版本）。
  • 意义： 当模型提供方与推理提供方变更速度提升，单靠人工关注会漏掉关键的价格、限流、模型快照替换、弃用窗口，最终变成不可控的线上漂移。
  • 影响：
    • Prompt/评测与线上模型版本不同步，导致效果回归难追；
    • API 侧小改动（速率、错误码、上下文限制）会在高峰时放大成事故。
  • 建议：
    1. 建一个“模型与提供方变更雷达”：把版本/价格/弃用信息纳入周报与告警；
    2. 所有线上请求写入“model snapshot + provider + 关键参数”到日志，支持事后追责与回放；
    3. 变更治理：对模型升级引入A/B 与回滚阀门，别让“供应商默认更新”直接打到全量。

今日趋势总结（回扣主线：安全 + 实时化 + 多后端）

  1. 供应链攻击正在从“依赖库”瞄准到“LLM 网关/中间层”：越接近凭证与数据中枢，ROI 越高。
  2. 实时语音/流式能力的产业化落地，开始暴露传统 RTC（SIP/SDP）世界的硬兼容问题：LLM 不再只是 HTTP API。
  3. 多后端推理（CUDA/ROCm/插件化容器）进入“工程磨合期”：稳定性与可观测性优先级上升到与吞吐同级。
  4. 版本治理成为 LLM 工程的“基础设施能力”：没有版本/变更/回滚纪律，就会被外部更新节奏牵着走。

我接下来会关注什么（同样回扣主线）

  1. LiteLLM 事件是否有官方通告/复盘（受影响版本、IoC、供应链入口、修复与验证方式）。
  2. 各家实时语音/多模态 API 是否出现协议层 breaking change 的更明确公告（尤其 SIP/SDP、WebRTC 协商相关）。
  3. vLLM/ROCm/Triton 等推理栈是否给出可复现与修复路径（以及更稳的组合矩阵建议）。