​
Q601：为什么内容完全相同的并发请求没有命中 Prompt Cache？

核心原因是 Prompt Cache 遵循“先写入、后读取（Write-then-Read）”的机制。 当多条完全相同的请求在同一瞬间高并发同时到达时：
  • 由于首个请求的缓存尚未完成计算与写入，此时到达的并发请求均会被判定为冷缓存（Cache Miss），从而各自执行全额输入的完整计算；
  • 优化建议：在执行批量或高并发任务前，先发送 1 次单请求完成缓存预热（Warm-up），待其返回成功并写入缓存后，后续并发请求即可稳定命中缓存。
排查常规 Prompt Cache 未命中的其他常见原因：
  1. 前缀动态污染：System Prompt 或上下文开头动态拼接了时间戳、随机 UUID 或动态会话 ID，破坏了从首字开始的严格前缀匹配（Prefix Matching）；
  2. 未达 Token 门槛：模型对缓存有最小 Token 阈值要求（通常需达到 1024 或 2048 Tokens 以上），短文本不会触发缓存；
  3. 缓存 TTL 超时：两次调用间隔超过了模型的缓存保留周期；
  4. 指标核对：真实命中情况以控制台 调用明细 记录的 cached_tokens 指标为准。

​
Q602：模型自称是其他版本，能否据此判断发生了模型降级？

不能。大语言模型的“自我介绍”仅由其预训练语料和提示词决定，并不具备实时感知底层物理硬件与 API 路由的能力。真实调用的模型版本以非线智能控制台 调用明细 中的 Model ID 记录为依据。

​
Q603：使用 Python 脚本每次独立调用，为什么多轮内容没有命中 Prompt Cache？

独立 Python 请求只要满足前缀一致性即可命中缓存，无需依赖持久连接。若未命中，请重点检查每次请求是否保持了完全相同的 System Prompt 和前置历史顺序。业务层多轮交互需保证 Payload 前缀稳定。

​
Q604：频繁切换模型会对 Prompt Cache 有什么影响？

不同大模型之间无法共享底层 Prompt Cache 缓存池。频繁在不同模型间来回切换会导致每个模型均需重新执行缓存预热。建议按任务阶段（如架构规划、常规编码）固定使用对应模型。

​
Q605：模型的“上下文上限（Context Window）”与“单次最大输出长度（Max Output Tokens）”是一回事吗？

不是。
  • 上下文上限：指单次请求中「系统提示词 + 历史输入 + 工具消息 + 本次模型输出」的总 Token 上限（如 200K / 1M）；
  • 最大输出长度：指模型单次推理能够生成的最大 Token 数量（如 8K / 64K）。 在客户端配置中，切勿将单次输出上限配置过小，以免导致长文本生成或深度思考过程被意外截断。