[Bug]: case-sensitive header lookup in _get_extra_header_tags drops configured spend tags

快速结论：在 LiteLLM Proxy 中通过 litellm_settings.extra_spend_tag_headers 配置了 spend tag 请求头，但客户端发送的请求头大小写与配置不一致时，_get_extra_header_tags 按大小写敏感的字典键查找会取不到值，导致配置的 spend tags 被静默丢弃。优先排查配置中的请求头名称与实际请求头的大小写是否完全一致。

适用环境：LiteLLM（含 LiteLLM Proxy）；具体版本、操作系统、Python 版本、依赖版本在 Issue 中未明确列出。

最快修复方案：升级到包含 PR #48620 修复的 LiteLLM 版本；Issue 讨论中维护者已确认该问题由该 PR 修复。若暂时无法升级，可优先尝试让客户端请求头的大小写与 extra_spend_tag_headers 配置完全一致，作为临时绕行方案。

注意事项：客户端自行统一大小写只能规避问题，无法从根本上保证所有调用方一致；Issue 中提出的“查找前将 header key 统一转小写”属于正文里的修复建议，实际代码改动以 PR #48620 为准。升级后建议复查历史 spend log 中缺失的 tag 不会自动补全。

问题场景

在使用 LiteLLM Proxy 时，于 config.yaml 的 litellm_settings.extra_spend_tag_headers 中配置了自定义请求头（例如 x-customer-id），用于把请求头写入 spend tracking 的 request_tags。当客户端（如 Python requests、curl、Go 或浏览器客户端）发送的请求头大小写与配置不同（如 X-Customer-Id）时，StandardLoggingPayloadSetup._get_extra_header_tags 在 litellm/litellm_core_utils/litellm_logging.py 中对请求头做大小写敏感的 dict.get() 查找，取不到对应值，最终 LiteLLM_SpendLogs 中的 request_tags 缺少已配置的 tag。Issue 正文指出的代码位置为 litellm_logging.py 第 6524–6547 行。

报错原文

[Bug]: case-sensitive header lookup in _get_extra_header_tags drops configured spend tags

原因分析

最可能的原因是 _get_extra_header_tags 使用 request_headers.get(header_name) 做精确匹配的字典查找，而 HTTP 头字段名按 RFC 7230 / RFC 9110 本应大小写不敏感。配置值与客户端实际发送值只要大小写不同，查找结果即为 None，该请求头对应的 tag 就被静默跳过，不会报错，因此表现为花费日志中 tag 丢失。

环境排查

确认 LiteLLM / LiteLLM Proxy 版本是否已包含 PR #48620 的修复。
确认 config.yaml 中 litellm_settings.extra_spend_tag_headers 的具体写法与大小写。
确认客户端实际发送的请求头名称及大小写（可通过抓包或代理日志查看）。
确认请求确实经过 LiteLLM Proxy，且 proxy_server_request 中存在 headers 字典。
Issue 未提供操作系统、Python、CUDA、显卡或节点版本信息，这些项目无需作为本问题的排查重点。

解决步骤

核对 config.yaml 中的 extra_spend_tag_headers 与客户端发送的请求头名称，确认仅存在大小写差异。
升级到包含 PR #48620 修复的 LiteLLM 版本，这是 Issue 讨论中确认的修复方式。
若暂时无法升级，可优先尝试统一客户端请求头的大小写，使其与配置完全一致，以临时恢复 tag 采集。
重启 LiteLLM Proxy，使新配置或新版本生效。
重新发起一次携带自定义头的请求，检查 spend log 中的 request_tags。

验证方法

按 Issue 复现步骤发送请求，例如配置 x-customer-id 后使用 X-Customer-Id: cust_98765 调用 /v1/chat/completions，然后查看 LiteLLM_SpendLogs 中该请求的 request_tags，确认出现 x-customer-id: cust_98765。建议再用不同大小写组合（如 X-Session-ID、x-session-id）各测一次，确认均能被采集。