# 会话亲和 (/docs/cloud/services/model/concepts/session-affinity)



会话亲和让同一会话后续请求，在条件允许时优先复用之前成功的线路。它是一种选路偏好，不是锁定供应商，也不是替应用保存对话历史。

## 为什么有用 [#为什么有用]

多轮对话常重复系统提示、工具定义和早期消息。重复前缀留在同一条支持缓存的线路上，更有机会命中上游缓存，降低重复输入的费用与延迟。相同会话 ID 不保证命中缓存；内容变化、缓存失效或换线都可能让它失效。

## 如何识别同一会话 [#如何识别同一会话]

客户端可用请求体的 `session_id` 或请求头 `x-session-id` 标识会话；两者同时存在时，请求体优先。没有显式会话 ID 时，还可能使用 `prompt_cache_key` 或从对话前缀推导标识。自动推导受内容变化影响，因此长期多轮对话应保持显式标识一致，不同对话使用不同标识。

## 何时生效 [#何时生效]

缓存亲和要求该线路支持本次模型与协议、输入得到保留，并且缓存读取价格低于普通输入价格。成功完成的调用才更新亲和记录；后续请求仍须通过当前的健康与能力检查。

亲和只在同优先级范围内调整顺序，不绕过冷却或参数要求。距上次成功已空闲 10 分钟、原线路不再合适，或亲和记录不可用时，按正常路由继续；因此应用不能依赖它保证状态永远留在同一上游。

Chat 请求仍应携带需要的消息历史。有状态 Responses 的续写属于独立的协议能力，不能用会话 ID 代替 `previous_response_id`。参数说明见 [Chat API](/docs/api/compatible/openai/createChatCompletion) 与 [Responses API](/docs/api/compatible/openai/createResponse)。

[API 参考 →](/docs/api/native/model) · [Cookbook →](/docs/cookbook)