银行AI Coding场景首Token时延优化实践：从会话亲和到多级KV缓存背景概述银行AI Coding场景呈“高峰并发+长代码序列”双重特征：高峰期开发者集中使用代码助手导致请求激增，且代码补全与生成任务携带超长上下文（如完整代码文件、历史会话），输入序列远超普通对话场景。原有服务架构采用随机请求分发，无会话亲和能力，同一会话的连续请求被打散到不同后端实例，导致KV缓存无法跨实例复用，每次请求都需重新计算全部上下文KV；同时推理实例的HBM容量有限，难以承载高峰期全量KV数据，最终表现为首Token时延（TTFT）居高不下，代码助手使用者体验非常差。问题现象 1. 前端体验：高并发时段，代码助手页面长时间处于等待状态，开发者输入后迟迟看不到首个补全结果，严重影响编码流畅度； 2. 后台监控：首Token时延监控指标超过1分钟，远超业务可接受范围（代码助手场景通常要求秒级响应）； 3. 资源侧表现：后端实例HBM被零散请求的KV数据挤占，长上下文任务因资源不足排队堆积，形成恶性循环。根因分析 1. 流量随机调度，无会话绑定：负载均衡层按轮询策略分发请求，同一会话的多次请求落在不同实例上，会话前缀在每个新实例上都要重算一遍，长代码序列的重复计算成本被成倍放大； 2. 有限HBM被零散请求挤占：高峰期大量互不相关的请求将HBM切碎，缓存命中率持续走低，同时高并发长序列场景下，推理队列迅速堆积，首Token时延被进一步拉长。解决方案一、基于会话唯一标识，构建亲和路由方案： 1.基于华为云ModelArts proxy实现资源池级别的会话保持能力 a)方案原理：会话id通过请求头header携带，用户自定义全局唯一，采用标准的uuid格式，每次请求都会记录或者刷新会话id和转发后端的对应关系，当下次处理携带相同会话id的请求时，就可以查询历史记录，将请求转发到相同的推理实例处理，命中实例上已有的KV缓存，上下文前缀无需重复计算，直接增量推理； b)配置生效：进入推理部署服务，选择“高级配置”，勾选“智能路由策略”，即可生效，KV Cache亲和性调度支持多种路由策略，建议选择“轮询”。 2.开源方案：LiteLLM session_affinity 会话粘性路由 a)方案原理：请求进来先读请求头里的会话ID，用哈希算法算出固定值映射到某台推理实例。第一次没命中缓存就选实例并记录绑定关系，同一会话后续请求直接查绑定表，强制路由到之前的实例，保证上下文和缓存命中，只有实例故障才触发解绑重选。 b)配置生效：yaml配置文件 -session_affinity: true ：开启会话粘性路由 -session_affinity_header ：指定从哪个HTTP请求头读取会话ID，业务调用方必须传入该header。完整配置示例可参考：https://github.com/BerriAI/litellm 3.落地效果（基于MA智能路由）：同一会话id多次请求路由到相同targetHost节点，KV缓存命中率从2%提升至10%以上，显著削减长序列场景下的重复prefill计算，首Token时延大幅下降，高峰期排队现象有效缓解；二、叠加多级缓存方案：会话亲和方案虽然切中了调度层面的根因，但仍有局限性，仅靠实例绑定，KV缓存的容量上限依然受制于单实例HBM空间，当会话所需KV超过HBM承载能力时，缓存淘汰仍不可避免，因此建议在此基础上进一步演进：将KV缓存从HBM扩展到DDR内存池，形成分级缓存体系，冷数据下沉、热数据常驻，突破单层显存容量瓶颈（如下图所示）； 1.HBM做KV Cache的约束 Prefix-Cache方案介绍vLLM推理引擎在的长序列、多轮对话场景中，Prefix-Cache（前缀缓存）是规避冗余计算、提升TTFT——核心逻辑是缓存历史请求的KV Cache块，当新请求到来时，若其前缀与历史请求的Token序列完全匹配，可复用已计算的KV Cache，跳过该前缀的重复计算过程，过程如下：方案原理 MemCache作为KV Cache的外置存储池，扩大了HBM的容量，解决跨卡、跨实例的访问约束，能有效提升Prefix Cache命中率，降低TTFT的时延。 MemCache包含LocalService和MetaService两大核心组件： ➢LocalService客户端：负责提供—段连续的内存区域作为内存池空间的—部分，其内存可以被其他LocalService实例基于地址直接访问。 ➢MetaService服务端：负责管理整个集群中内存池空间的分配和管理，处理LocalService的加入与退出。逻辑架构图如下： 2.端到端部署过程： a)安装包及镜像下载 ➢下载memcache安装包 https://gitcode.com/Ascend/memcache/releases ➢下载镜像 https://cmc-lfg-artifactory.cmc.tools.huawei.com/artifactory/generic-8166/hw-cr/quay.io/ascend/vllm-ascend/ b）确认vLLM适配： MultiConnector：统—对外暴露kv_consumer消费接口，上层推理引擎只和MultiConnector交互，底层自动分发KV读写请求到子连接器。 MooncakeHybridConnector： HBM的KV传输层 AscendStoreConnector：昇腾外置KV存储传输 C）确认版本配套关系项值 Modelarts版本 8.6.0 HDK 25.2.2 CAN 9.0.0 Memcache 1.2.2 裸机OS的内存页 4K vLLM-Ascend V0.21.0rc1 d) Dockerfile如下： e)脚本准备主要修改user_config_default.json和start.sh user_config_default.json: ➢user_config_default.json配置： ➢start.sh: 重要修改文件路径 f)完整版配置及部署指导 Memcache官方介绍：https://gitcode.com/Ascend/memcache 完整配置示例部署可参考： https://gitcode.com/Ascend/memcache/wiki/MMC%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5%E2%80%94GLM-5.1+A3-4%E6%9C%BAPD%E5%88%86%E7%A6%BB%EF%BC%88%E6%9C%80%E4%BD%B3%E6%80%A7%E8%83%BD%E7%89%88%EF%BC%89.md 3. 叠加后效果提升：智能调度+多级缓存的组合方案，能够大幅提升KV缓存命中率至70%以上，降低首Token时延至秒级，兼顾成本与体验。建议与总结 1. 会话ID格式前置适配：ModelArts会话路由要求会话ID为16位UUID格式，当前Code Agent业务默认为通用String字符串格式，需软件研发部门完成格式映射转换，作为调度生效的前置条件； 2. Memcache部署测试经验：提前约束，vllm的参数配置、HDK版本、宿主机内存页大小，Mem-Cache依赖较多，提前对齐测试工具，以及随机种子，预热，重复前缀等参数； 3. 智能路由演进路径：智能路由从随机分发升级到会话亲和，只是流量优化的第一步，还需突破HBM内存瓶颈，通过多级缓存与调度策略组合演进，才能更好的支撑高并发长上下文任务场景。