AI代码助手性能优化：上下文瘦身与推断加速实战

做 AI 代码助手性能优化这块快两年了，从最初“能跑就行”的 demo，到后来扛住线上真实请求，最大的感悟就一句话：瓶颈往往不在模型本身，而在你如何看待上下文和处理推断过程。很多团队一开始觉得“效果不行就换更大的模型”，实测下来发现，大模型带来的显存压力和延迟增长，反而把产品体验拖垮了。今天这篇就围绕我自己在项目里的重构经历，讲讲上下文窗口优化和推断加速这两条主线到底怎么落地，哪些做法有效，哪些是弯路。

先说结论：面向代码场景的助手，对延迟敏感度极高。用户敲完代码，一两秒没反应就开始怀疑工具坏了。所以你的优化目标，不是把某个指标刷到好看，而是让“从请求发出到有用的代码补全返回”这条路径尽可能短、尽可能稳。要做到这一点，上下文怎么管理、KV Cache怎么处理、推断过程怎么加速、缓存怎么复用，每一项都得抠细节。

1. 性能瓶颈到底出在哪：先讲清楚“卡”在哪里

1.1 代码助手的延迟构成拆解

如果你把一个代码补全请求从发出到返回拆开看，通常包含这几段耗时：

• 网络传输与网关处理
• 请求排队等待
• 输入 Token 的预填充（Prefill）阶段
• 输出 Token 的逐字生成（Decode）阶段
• 结果后处理与回传

其中真正大头在模型本身的 Prefill 和 Decode。Prefill 阶段要并行处理整个输入序列，计算密集但好在可以批量并行；Decode 阶段每个 Token 都要依赖前一个 Token 的结果，串行执行，这也是为什么长输出的响应时间会近似线性增长。

我复盘了线上数据，发现一个很典型的场景：某个请求携带了约 8000 Token 的上下文（代码库片段、历史对话、相关文件），模型需要先生成约 300 Token 的补全结果。整个请求的耗时分布里，Prefill 占了 70% 以上。原因很直接——上下文越长，Prefill 需要处理的矩阵乘法规模越大，而且这个请求的 batch 又小，GPU 利用率很低。

这就是第一个核心认知：在单请求逐条推理的模式下，长上下文对性能的杀伤力远大于长输出。不少团队把优化重点放在 Decode 的流式输出上，反而忽略了 Prefill 阶段那几秒的等待，其实用户的体感已经从第一帧就开始计时了。

1.2 显存墙、带宽墙与“算力充足但速度很慢”的假象

实际调优过程中，我还遇到过一个很迷惑的现象：GPU 算力看起来完全够用，但推断速度就是上不去。用监控工具一看，SM 占用率不到 20%，显存带宽却接近打满。这是因为 Decode 阶段每个 Token 只需要读取整个模型权重和 KV Cache，做一次矩阵向量乘，本质上是访存密集而非计算密集。模型越大、上下文越长，KV Cache 占用的显存和访问带宽就越高，Decode 速度就被卡在带宽上。

这也是为什么“堆算力卡”不一定能线性提速。你换了张更强的新卡，计算能力翻倍，但如果显存带宽没有同步大幅提升，Decode 瓶颈依旧存在。所以做优化时别只盯着 FLOPS，还要看带宽利用率。

另一个隐蔽问题是显存墙。上下文窗口拉长之后，KV Cache 会吃掉大量显存。以某个开源代码模型的配置为例，它的层数较多、头数较多，单个请求 16K 上下文的 KV Cache 就能占据接近 2GB 显存。如果并发请求数一高，显存直接撑爆，要么 OOM，要么触发反复的显存换入换出，整体吞吐反而下降。

1.3 为什么“直接换大模型”常常是伪优化

很多产品经理会提一个需求：“效果不好，换个更大的模型吧。”但更大模型意味着权重参数量增加、推理耗时变长、KV Cache 占用更多。如果不先做工程侧的优化，即使换了模型，延迟和成本双双失控，体验照样不达标。

我自己在项目里有段时间被线上延迟逼急了，尝试切换到一个参数规模更大的候选模型，结果在相同上下文长度下，首 Token 延迟高了一倍以上，显存占用暴涨，单机并发能力直接减半。后来我做了上下文压缩和缓存优化之后，小模型的延迟反而比之前大模型原始状态更低。这里我想强调的是：模型能力是一个维度，工程效率是另一个维度，两者必须同时抓，先做工程优化再评估模型升级，顺序不能反。

2. 上下文窗口优化：让模型看该看的，而不是看所有

2.1 全量塞入的弊端与“上下文瘦身”的大方向

初期版本里，代码助手的上下文管理很简单：把当前文件、相关文件、历史对话、项目说明一股脑全塞进 Prompt。这样做的代价很快显现——请求 Token 数飙升，Prefill 变慢，而且关键信息被海量无关内容淹没，模型生成质量反而不稳定，甚至出现“该遵循的约束忘了”的情况。

后来我定下一条原则：上下文不是越多越好，而是越准越好。要做上下文瘦身，核心思路是分级和取舍。比如当前编辑文件附近的代码属于“核心上下文”，必须完整保留；项目里其他相关文件属于“扩展上下文”，可以只保留关键函数签名和注释；历史对话中较旧的轮次属于“背景上下文”，压缩成摘要即可。

实际操作中我维护了一个预算机制：给核心、扩展、背景三个层级分配不同的 Token 配额（比如 2K / 6K / 4K），每次构建 Prompt 时按层级填充，超出配额的部分降级处理。这个机制上线后，上下文平均长度从 8000 多压到 4000 左右，Pre-fill 时间明显下降，效果还更稳定了。

2.2 三种可落地的上下文裁剪策略

策略一：滑动窗口裁剪

适合流式对话和增量代码分析。维护一个按时间或位置排序的窗口，窗口内的内容完整保留，窗口外的内容逐步丢弃或压缩。比如某次代码修改相关的会话，我们只保留最近 20 轮对话和当前改动涉及的代码块，再往前的讨论直接折叠成一句摘要。该策略的优点是实现简单、延迟稳定，缺点是可能丢失“很久之前提到但依然有效的关键约束”。

策略二：结构化摘要压缩

对要丢弃的内容，先用一个轻量模型或规则方法生成结构化摘要，把“结论”和“待办”保留下来。这里要注意，摘要不能只写一句话，最好拆成：目标、约束、已做决策、遗留问题四段式。我实验过，四段式摘要被后续轮次有效引用的概率远高于自由文本摘要。虽然摘要本身会消耗一点预处理时间，但省下的 Prefill 时间足以覆盖成本。

策略三：检索增强式上下文构建

不依赖用户手动指定哪些文件相关，而是基于当前光标位置和对话意图，从项目代码库中检索最相关的几个片段。这部分可以借助向量化的代码索引，也可以用简单的关键词与符号匹配。检索式构建的好处是上下文始终聚焦，缺点是第一次建立索引有成本，而且检索质量会直接影响效果。建议检索模块做成可以随时关闭的开关，方便线上做 Ablation 测试。

2.3 KV Cache 的精打细算：共享前缀与缓存复用

上下文窗口优化不止是减少输入 Token，还包括对 KV Cache 的管理。每个请求都会计算 Prompt 对应的 Key 和 Value 矩阵。如果两个请求的前缀高度相似，它们的 KV Cache 完全可以复用。代码场景天然适合这么做——同一个项目的请求经常携带相同的“系统提示词+项目说明”，这些前缀占了几千 Token。

我落地了两层 KV Cache 复用：

• 第一层，固定前缀缓存。将系统提示词、全局项目规范、用户偏好等固定内容拼成一个固定前缀，单独计算好 KV 并常驻显存。每次请求只要命中这一前缀，直接跳过这一段 Prefill。
• 第二层，检索缓存。在固定前缀后加入“相关代码片段”的公共部分，比如多个请求会引用同一个核心模块时，命中后可以直接续算后面的对话内容。

这块的收益非常明显。因为固定前缀在我们场景里往往占整个上下文的 30% 到 50%，缓存之后 Prefill 时间平均降了 25% 左右。需要提醒的是，KV Cache 极耗显存，做缓存时一定要记得设过期策略，否则缓存堆积会把显存吃满，得不偿失。

2.4 一个可参考的上下文构建流程

我在实际工程里把上下文构建拆成了四个步骤，顺序很重要：

1. 采集：收集当前请求涉及的输入，包括当前文件、选中代码、错误信息、历史对话。
2. 过滤与分级：用规则判断哪些是核心，哪些可压缩，哪些直接不进入 Prompt。例如无关注释、空行、超长日志都应该被过滤。
3. 压缩与摘要：对扩展级和历史级内容执行结构化摘要，注意保留关键符号名和调用链。
4. 组装与预算校验：按模板组装成最终 Prompt，校验 Token 预算，超出部分按优先级丢弃或进一步压缩。

这个流程写成一个独立的中间件后，不仅优化了延迟，调试也方便很多——每次请求都能输出一张“上下文构成卡片”，告诉我们哪些内容占了多少 Token。上线之后我发现不少用户会主动配合这个机制，把代码拆成更清晰的小函数，因为这样上下文裁剪的准确率会更高。

3. 推断加速算法选型：从投机解码到量化与批处理

3.1 投机解码：用“小模型先写，大模型审核”的思路

投机解码（Speculative Decoding）是我重点尝试的一个方向，原理说起来并不复杂：用一个轻量的草稿模型快速生成候选 Token 序列，再交给主模型进行并行验证，验证通过的 Token 直接复用，不通过的则回退重来。因为验证过程可以一次处理多个 Token，Decode 阶段原本逐字串行的方式变成了“小步快跑+批量确认”，整体吞吐能提升不少。

落地时有两个关键点。第一，草稿模型和主模型的词表必须一致，否则需要额外的映射层，代价会抵消收益。第二，草稿模型的接受率决定了加速效果。如果草稿模型太弱，生成的候选大部分被驳回，反而浪费算力。经验法则是草稿模型至少要有主模型七成以上的“对话和补全能力”，速度还要快三倍以上，这个组合才划算。

我在某次实验中，用主模型和一个参数量小得多的同系列草稿模型搭配，输出速度提升了大约 1.8 倍，而生成质量在基准测试上没有明显下降。不过要注意，投机解码不适合所有场景，如果用户请求主要以短输出为主（比如简单补全几个 token），草稿模型的预生成成本会占不到便宜，建议做一次耗时分布统计再决定是否开启。

3.2 量化压缩：INT8 与 INT4 的取舍之道

量化是另一个绕不开的话题。把模型权重从 FP16 压缩到 INT8 或 INT4，可以显著减少显存占用，同时让访存带宽压力下降，解码速度因此变快。但我必须泼一盆冷水：代码生成任务对量化精度比一般对话更敏感，因为代码里的符号、数字、缩进稍有偏差，就可能导致编译失败或语义错误。

我的实践经验是把量化级别和上下文长度强关联起来。短上下文、低并发时优先保留 FP16，保证质量；长上下文、高并发时切到 INT8，显存省下来之后可以用更大的批处理。INT4 我只推荐在内部评测不太意的场景使用，或者和投机解码联合使用，让草稿模型扛精度风险，主模型用 INT4 放大吞吐。

另外要留意，有些推理框架的量化算子并没有针对代码场景做优化，量化的本地加速收益可能是假的。建议上线前做一次逐算子 benchmark，对比同一批代码补全请求在量化前后的耗时和通过率。

3.3 动态批处理与算子融合：吃满硬件红利

批处理是拉升吞吐最直接的手段。多用户请求并发到达时，动态批处理会把长度相近的请求拼成一个 batch，一次前向计算应对多个请求。这个做法对 Prefill 阶段的收益尤其明显，因为矩阵运算的本质就是批量并行。

踩坑提示：批处理不是越大越好。当 batch 内请求的上下文长度差异过大时，按最长序列补齐会让大量算力浪费在 padding 上。我做了个简单策略：根据上下文长度把请求分成几个桶，不同桶用不同批处理线程处理，同时设置每批最大 Token 总数而不仅是最大请求数。这样明显提升了资源利用率。

算子融合就是另一层优化了。常规的做法是把 Attention 里的 Q、K、V 投影合并成一个大的矩阵乘，把 LayerNorm 融合进前一个算子，减少中间张量的读写开销。多数成熟的推理库已经内置了这些融合，但如果你在用自研推理管线，建议重点检查两个算子：GEMM 和 Attention。这两块的中间显存读写最频繁，也最值得融合。

3.4 三大加速算法的收益对比与选型建议

这里面我最想强调选型顺序：先做 KV Cache 复用，再做上下文压缩，这两项几乎零风险和零额外硬件成本，却能拿到最稳定的收益；之后才是量化和投机解码这类“改变生成方式”的手段。最后再考虑批处理和算子级优化，因为它们对调度层的影响最大，需要配合压测回归。

4. 工程落地：从算法到系统的不止一步

4.1 合理的架构分层：接入层、调度层、推理层

算法能够跑起来，和能够稳定跑在线上，是两码事。我把整个系统分成了三层：

• 接入层：负责请求校验、用户鉴权、上下文采集与压缩。这一层可以做成无状态服务，方便横向扩容。
• 调度层：维护请求队列、KV Cache 索引、批处理调度策略。它需要感知当前显存余量、缓存命中和各推理实例的负载。
• 推理层：执行真正的模型前向计算，同时暴露指标，比如 Prefill 耗时、Decode 耗时、缓存命中率等。

这个分层的好处是每层可以独立优化。比如我们在调整批处理策略时，只改调度层逻辑，推理层完全不动；后来 KV Cache 复用升级也只动了调度层。项目接手的人不会因为一次优化就搞不清全貌。

4.2 缓存策略设计：显存、磁盘与冷热数据

KV Cache 存在显存里时，访问速度最快，但容量有限。对于代码助手这种场景，固定前缀缓存可以常驻显存，检索缓存则要有淘汰策略。我用的是类似 LRU 的思路，但过期时间更激进——超过 10 分钟不命中的缓存优先淘汰，因为代码项目的上下文变化快，过了太久再命中可能反而干扰生成。

同时我也把上下文构建过程中的检索结果做成了磁盘缓存。重复请求同一个项目片段时，不需要反复执行向量检索和文件读取，直接读缓存拼接 Prompt。这部分磁盘缓存命中率能到 40% 以上，单请求的上下文准备时间减少了近一半。

一种可行的存储分配方案：显存里放最热的固定前缀和最近常用的项目片段，磁盘里放全量检索缓存，两者通过调度层联动。要严格限制显存缓存总量，预留至少 20% 的余量给突发请求，否则一旦显存打满，触发换页反而会让延迟恶化。

4.3 关键性能指标与监控体系

优化做得再好，没有监控就是盲人摸象。我们最终建立了以下监控指标，每个指标都对应一项用户体验或资源成本：

• TTFT（首 Token 延迟）：用户发出请求到收到第一个 Token 的时间。这个指标直接决定“工具响应快不快”的主观感受。
• TPOT（每输出 Token 耗时）：可以换算成“每秒生成多少 Token”，影响长补全体验。
• Prefill 占比：若 Prefill 耗时占总耗时比例过高，说明上下文可能过于冗长，或者缓存命中率不足。
• 缓存命中率：监控各级缓存的命中情况，这是定位 Prefill 慢的第一线索。
• 显存水位：提示是否需要扩容或优化缓存策略。

我还给监控配了一个简易看板，里面最核心的一张图是“TTFT 与上下文长度的散点图”。从这个图可以直观看到上下文从 2K 涨到 8K 时，延迟是如何爬升的。任何上下文压缩优化上线后，都能马上从这个图看到分布是否左移。

4.4 压测到底怎么测才不会被“压”倒

很多团队压测做得太理想化，全用长度相同、内容相似的请求，结果线上完全不是一回事。我做压测时坚持三原则：

1. 使用真实或接近真实的请求分布，而不是单一的固定长度。
2. 混合不同类型请求：短补全、长补全、多轮对话、代码解释，按线上比例混合。
3. 压测长时间运行，不仅看平均延迟，还要看长尾和显存稳定性。部分优化刚开始没问题，跑几个小时后缓存膨胀，性能就开始劣化。

有一次我们发现一个量化方案在 30 分钟压测中表现很好，但追上 3 小时之后每分钟延迟逐步上升，查下来是量化算子在特定显存布局下产生了内存碎片。如果只压 10 分钟，这个问题根本不会被发现。所以压测时间一定要够长，最好持续到显存水位进入稳态之后，再记录最终性能数据。

5. 实测效果与避坑清单

5.1 优化前后的数据对比

上面这组数据来自一个模拟项目，用同一模型在相同硬件环境下对比。可以看到，收益最明显的是上下文压缩和 KV Cache 复用阶段，这两个操作不需要改模型权重，纯粹靠工程手段就能把延迟打下来一半。量化与投机解码进一步提升了吞吐，但对少数极端代码片段会有轻微质量下降，所以我在配置中把它们设为按需开启。

5.2 高频踩坑问题速查

5.3 一些可以“偷”的工程经验

最后分享几个很小的但很有用的经验。第一个，上下文压缩时不要只压缩旧对话，也要压缩“当前文件的历史版本”。很多助手会把用户反复修改的代码片段完整保留，其实保留最新版本加一句“在此之前用户进行了多次修改”就够了，能省不少 Token。

第二个，投机解码里的草稿模型不一定要单独跑一个实例。你可以让它和主模型共享同一块 GPU，但用更低的显存优先级。只要调度层控制好并发，草稿模型引入的额外延迟通常小于它带来的加速。

第三个，对于极短输出请求，可以绕过部分加速逻辑。比如如果用户只是要补全一个变量名，预处理阶段的摘要压缩其实没必要执行，直接走最短路径返回，延迟反而更低。这个“按请求类型分路径”的思路，很多通用框架不会替你设计，值得自己实现。

第四个，所有优化都要做 A/B 回归，尤其是代码补全的正确率。我见过有人把延迟从 2 秒降到 1 秒，但同个测试集上编译通过率掉了 15 个百分点，这种优化上线就是事故。所以每次改动都要配一份质量回归集，里面放典型代码场景和对应产出结果，跑完再看延迟收益。

结尾：与其追求极致参数，不如先把链路理顺

我做这些优化之前，一直在纠结该用哪个量化位宽、该不该上投机解码。后来发现，真正让体验质变的是把上下文管理和缓存复用这两件基础事做好。它们不炫，但每一步都扎扎实实地减少了重复计算和无效计算。算力就像钱，花在刀刃上才是关键。如果看完这篇，你第一件事是把当前助手的上下文构建流程画出来，看看到底有多少 Token 是重复和无用的，那这次分享就没白写。后面等 KV Cache 复用的命中数据积累差不多了，我会再写一篇关于缓存淘汰策略和显存动态调度的经验，到时候我们再继续聊。