文章目录
- 摘要
- 一、为什么推理服务是有状态的
- 二、一致性哈希怎么做亲和
- 三、虚拟节点缓解倾斜
- 四、会话与上下文的粘性
- 五、抖动与均衡的权衡
- 六、失效与迁移处理
- 七、常见坑
- 八、衔接大会专题
- 你会在奇点智能技术大会看到什么
- 落地清单（Checklist）
- 工程取舍速记
- 补充问答
摘要
大模型推理有状态——KV 缓存、会话上下文、预热都绑在实例上。用户请求若每次漂到不同实例，缓存白建、上下文丢失、预热失效。亲和路由用一致性哈希把同一用户稳定映射到同一实例，兼顾负载均衡与状态复用。难点在节点变更的抖动。2026 奇点智能技术大会（11 月 20-21 日·北京万达文华酒店）AI Infra 专题，会从推理路由视角展开这类工程。
▸ 核心结论：推理有状态（KV缓存/会话/预热），亲和路由用一致性哈希把同用户稳落同实例，复用状态又保均衡
▸ 关键权衡：节点增减时哈希环抖动会让部分用户重新映射，要在稳定性与均衡间靠虚拟节点缓解
▸ 适合谁读：做推理服务路由与多实例运营的工程师——被缓存命中低、上下文丢、预热失效困扰的人
本文的结构 状态 一 为什么推理有状态 机制 二~四 一致性哈希/虚拟节点/会话 权衡 五 抖动vs均衡 落地 六~八 失效/坑/衔接大会一、为什么推理服务是有状态的
10 月这波模型有个共同点：上下文越拉越长，Muse Spark Open、Kimi K3.1 Pro 都喊到 100 万 token。上下文一长，会话级的 KV 缓存复成就成了省钱的关键，可要是同一用户的请求每次都被打到不同副本，缓存全冷、命中率暴跌，体验也跟着断。于是「同一会话落到同一实例」这件事变得值钱。一致性哈希加亲和路由怎么配、扩缩容时状态怎么迁，本文讲清楚。
很多人把推理服务当无状态——请求进、结果出。但大模型推理悄悄有状态：KV 缓存绑在实例显存、长会话上下文在实例内存、模型预热和权重换入也是实例局部状态。如果用户请求每次漂到不同实例，KV 缓存白建、上下文丢失要重算、预热反复做，延迟和成本都涨。有状态特性决定了推理路由不能纯随机，得照顾「粘性」。
扩缩容时最怕全量重分布：一致性哈希的好处是把请求按 key 挂在环上，加减节点只动一小部分 key。新实例上线先预热缓存再接流量，老实例下线先把它的 key 挪走，中间就不至于大面积踩空。还要防「亲和变粘连」——用户长期钉在一个实例上，哪怕它已经过载也不迁，反倒成了热点。给亲和加个 TTL 和负载熔断，热点就能自己散开。
二、一致性哈希怎么做亲和
一致性哈希把实例和用户都映射到一个哈希环上，请求按用户 ID 找环上顺时针最近的实例。这样同一用户稳定落同一实例，缓存与会话复用。关键是节点变更时影响最小——传统取模哈希一加节点全乱，一致性哈希只动环上相邻一段，只有部分用户重映射。它天然适合实例会扩缩的推理场景。
三、虚拟节点缓解倾斜
朴素一致性哈希有个毛病：实例在环上分布不均，有的实例扛多有的扛少，负载倾斜。虚拟节点解决——每个物理实例在环上放多个虚拟点，打散分布，负载更均衡。虚拟节点数越多越均衡，但环越大管理略重。实务调虚拟节点数直到负载标准差可接受。它是一致性哈希能真正用于生产的必选项，否则亲和有了均衡没了。
用户ID → 哈希环 → 顺时针最近实例 虚拟节点打散 → 负载均衡 加节点: 只动相邻段, 抖动最小 粘性复用KV/会话 · 外置保安全四、会话与上下文的粘性
亲和路由让同一用户的多次请求到同一实例，会话上下文和 KV 缓存直接复用，不用每次重建。这对长会话尤其值——用户聊到第十轮，前九轮上下文都在本实例，续聊零重建。粘性还要和会话外置配合：实例挂了，上下文能从外置存储恢复，粘性失效也不丢数据。粘性提效、外置保安全，两件事一起做。
五、抖动与均衡的权衡
节点增减时，哈希环上相邻段用户会重映射，这部分请求短暂失去粘性（缓存失效、上下文需重建）。权衡在稳定性与均衡：虚拟节点多均衡好但环变更时抖动面也需管理；实例扩缩频繁的场景要控制变更节奏。实务用平滑扩缩——一次加少量节点、错峰，把抖动摊薄。抖动不可避免，但能靠虚拟节点和节奏控制压到可接受。
六、失效与迁移处理
实例挂了，原本亲和其上的用户要去哪？两种策略：一是快速漂到环上顺时针下一实例，重建状态（靠外置上下文兜底）；二是把用户会话迁移到目标实例再接管。前者简单但短暂重建，后者平滑但工程重。还要健康探测——实例不健康就把它从环上摘掉，流量自动绕开。失效处理决定亲和路由在真实故障下的体验。
七、常见坑
- 把推理当无状态随机路由，缓存命中低上下文丢。
- 用取模哈希，加节点全乱。
- 一致性哈希无虚拟节点，负载倾斜。
- 亲和但不外置会话，实例挂了丢数据。
- 扩缩太猛，抖动面大。
- 无健康探测，坏实例仍接流。
- 粘性过度，个别实例被钉死负载高。
八、衔接大会专题
推理的一致性哈希与亲和路由，解决的是「同一用户落到同一实例」的问题：有状态推理（如带会话 KV 缓存、个性化前缀、长上下文）若每次请求打不同副本，缓存命中率暴跌、体验断裂。一致性哈希把请求按 key（用户/会话）映射到固定实例环，扩缩容时只迁移少量 key，避免全量重分布；亲和路由保证同一会话的请求稳定回到持有其状态的副本。
工程权衡：哈希环的虚拟节点数决定负载均衡粒度，太少易倾斜、太多元数据重；扩缩容要平滑，新实例上线先预热缓存再接流量，下线先把它的 key 迁走。还要处理「状态比实例活得久」——实例挂了状态可从外置存储恢复，路由只是加速而非唯一真相。把缓存命中率、跨实例跳转率当成核心指标，亲和路由才值。
你会在奇点智能技术大会看到什么
- AI Infra：推理路由与有状态服务调度
- 企业级 AI 原生应用与落地：高一致体验的工程
- 大模型技术专题：会话级 KV 缓存与复用
- 智能体应用创新与开发实践：有状态 Agent 的路由
另一个坑是「亲和变粘连」：用户长期落同一实例，该实例过载也不迁移，反而制造热点。工程上给亲和加 TTL 与负载熔断，热点实例的 key 能主动再平衡。有状态推理的亲和路由是隐形骨架，AI Infra 与企业级 AI 原生应用专题会讲清一致性哈希在推理路由中的取舍与故障处理。
哈希环虚拟节点数决定负载均衡粒度：太少易倾斜、太多元数据重；扩缩容要平滑，新实例上线先预热缓存再接流量，下线先把它的 key 迁走，避免全量重分布。
「状态比实例活得久」——实例挂了状态可从外置存储恢复，路由只是加速非唯一真相。把缓存命中率、跨实例跳转率当核心指标，亲和路由才值。别让路由成新瓶颈。
常见坑是「亲和变粘连」：用户长期落同实例，该实例过载也不迁移反而制造热点。给亲和加 TTL 与负载熔断，热点实例的 key 能主动再平衡，有状态推理才真稳。
一致性哈希把请求按 key 映射到固定实例环，扩缩容只迁移少量 key。配合预热与渐进引流，新实例接流量前缓存已热，老实例下线前 key 已迁走，全程不抖。
AI Infra 与企业级 AI 原生应用专题讲清一致性哈希在推理路由中的取舍与故障处理。亲和路由是有状态推理隐形骨架，会话级 KV 缓存复用靠它，体验一致性与成本都受益。
落地清单（Checklist）
做推理亲和路由，逐项核对：
- 承认推理有状态，弃随机路由。
- 用一致性哈希非取模，节点变更只动相邻段。
- 上虚拟节点打散负载防倾斜。
- 会话外置兜底，实例挂不丢数据。
- 平滑扩缩错峰压抖动。
- 健康探测摘坏实例绕开。
- 粘性复用 KV/会话提效、外置保安全，两件事一起做。
工程取舍速记
和随机路由比，亲和复用状态降延迟成本；和取模哈希比，一致性哈希节点变更影响最小。最大权衡是抖动与均衡——虚拟节点多均衡好、变更抖动靠节奏控制摊薄。粘性要和外置会话配合，实例挂不丢数据。把哈希环、虚拟节点、会话外置、失效迁移四块做对，推理有状态特性下路由才既稳又省，也是今年奇点智能技术大会 AI Infra 专题会从路由侧反复展开的主线。
补充问答
问：推理为什么要亲和路由而非随机？
答：推理有状态——KV 缓存、长会话上下文、预热都绑实例。随机路由让同用户每次漂不同实例，缓存白建、上下文重建、预热反复，延迟成本涨。亲和用一致性哈希稳落同实例，复用状态。推理不是真无状态，别当无状态路由。
问：取模哈希为什么不行？
答：取模哈希一加节点，几乎所有用户映射全变，缓存全部失效，亲和崩。一致性哈希只动环上相邻一段，仅部分用户重映射。推理实例常扩缩，取模代价不可接受，一致性哈希才适配。
问：虚拟节点有什么用？
答：朴素一致性哈希实例在环上分布不均，负载倾斜——有的扛多有的扛少。虚拟节点让每实例在环上放多点打散分布，负载更均衡。它是生产必选项，否则亲和有了均衡没了。节点数按负载标准差调。
问：实例挂了亲和用户怎么办？
答：两策——快速漂到环上顺时针下一实例重建状态（靠外置会话兜底不丢数据），或迁移会话再接管（平滑但工程重）。还要健康探测把坏实例摘环，流量绕开。失效处理决定真实故障下的体验，粘性不能牺牲安全。
问：扩缩容的抖动怎么压？
答：节点增减时相邻段用户短暂失粘（缓存失效重建），不可避免但可控。用虚拟节点+平滑扩缩——一次加少量节点、错峰，把抖动摊薄。扩缩太猛抖动面大，节奏控制是关键。抖动压到可接受即可，不必为零。
大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会报名：免费领取大会PPT资料
立即报名，锁定 70+ 场演讲完整资料与一线工程实践！
