什么是性能优化闭环闭环第一步从链路洞察发现优化点闭环第二步制定改造方案闭环第三步代码改造实战闭环第四步灰度验证与指标回归闭环第五步沉淀为常态化机制大模型链路常见优化点清单1. 什么是性能优化闭环上一篇我们用三件套定位了线上大模型超时故障但定位只是闭环的起点。真正的性能优化闭环是**观测发现瓶颈 → 制定改造方案 → 代码落地 → 灰度验证 → 指标回归确认 → 沉淀为机制**。它把一次性的救火变成可复用、可度量的工程能力。闭环的核心特征是可度量每一次改造都必须能回到 SkyWalking / Grafana 看到指标变化确认优化有效否则就是凭感觉改代码。下图是闭环的状态流转观测(指标/链路/日志)│ 发现瓶颈▼制定方案 ── 代码改造 ── 灰度发布│ ││ ▼└──── 指标回归 ─── 验证效果│有效? ──否── 回到制定方案│是▼沉淀机制(告警/埋点/规范)2. 闭环第一步从链路洞察发现优化点基于第 18 篇的故障链路洞察给出的明确优化点有两个方向**方向 A重试治理**LLM.Infer 存在短超时 立即重试 无熔断高峰放大延迟。**方向 B资源隔离**VectorSearch 受离线索引重建干扰且 rag-pool 与 llm-pool 共用线程池相互拖累。此外链路还暴露一个隐性优化点大量 Trace 中 ReRank 与 VectorSearch 是串行的而 ReRank 其实只依赖 VectorSearch 的部分结果可并行化同时 LLM.Infer 在拿到首 token 前后处理 空等可改为流式SSE边生成边返回。用 SkyWalking 的 Endpoint 拓扑与 Slow Span 排行可以系统化地列出优化候选优化候选来源(Span)当前 P99目标------------重试退避熔断LLM.Infer3.2s(含重试)≤1 次退避重试线程池隔离RAG 编排阻塞传播rag/llm 池分离向量检索错峰VectorSearch4.2s≤300ms流式首字后处理760ms 空等首字 500ms3. 闭环第二步制定改造方案针对四个候选方案如下**重试治理**用 Sentinel 做熔断 退避重试超时从 3000ms 提到 8000ms最大重试 1 次退避 200ms。**线程池隔离**llm-gateway 拆为 ragExecutor核心 8最大 16与 llmExecutor核心 16最大 32避免相互阻塞。**资源错峰**vector-db 索引重建移到凌晨并以 K8s resources.limits 限定其 CPU。**流式改造**LLM.Infer 改用流式 SDK拿到首 token 即向客户端推送 SSE后处理改为消费流。评估优先级用收益 × 风险矩阵重试治理高收益低风险的代码改动优先资源错峰需协调运维中收益中风险次之流式改造改动面大高收益高风险放最后灰度。4. 闭环第三步代码改造实战**4.1 重试治理Sentinel 退避**import com.alibaba.csp.sentinel.annotation.SentinelResource;import com.alibaba.csp.sentinel.slots.block.BlockException;public class LlmClient {private static final int MAX_RETRY 1;private static final long BACKOFF_MS 200;SentinelResource(value llm-infer, blockHandler onBlock)public String infer(String prompt) {int attempt 0;while (true) {try {return doInvoke(prompt, 8000); // 超时 8s} catch (TimeoutException e) {if (attempt MAX_RETRY) throw e;attempt;try { Thread.sleep(BACKOFF_MS * attempt); } // 指数退避catch (InterruptedException ie) { Thread.currentThread().interrupt(); throw e; }}}}public String onBlock(String prompt, BlockException ex) {throw new LlmBlockedException(触发熔断/限流, ex);}private native String doInvoke(String p, int timeoutMs);}Sentinel 规则降级策略慢调用比例比例阈值 0.5慢调用阈值 3000ms熔断 10sDegradeRule rule new DegradeRule(llm-infer).setGrade(CircuitBreakerStrategy.SLOW_REQUEST_RATIO.getType()).setCount(0.5).setTimeWindow(10);DegradeRuleManager.loadRules(Collections.singletonList(rule));**4.2 线程池隔离**Configurationpublic class ExecutorConfig {Bean(ragExecutor)public Executor ragExecutor() {return new ThreadPoolTaskExecutorBuilder().corePoolSize(8).maxPoolSize(16).queueCapacity(64).threadNamePrefix(rag-).build();}Bean(llmExecutor)public Executor llmExecutor() {return new ThreadPoolTaskExecutorBuilder().corePoolSize(16).maxPoolSize(32).queueCapacity(128).threadNamePrefix(llm-).build();}}**4.3 流式首字SSE**// 拿到首 token 即推送避免后处理空等public void streamInfer(String prompt, ConsumerString onToken) {llmStreamClient.invoke(prompt, token - {onToken.accept(token); // 首字即可返回客户端MDC.put(firstToken, sent); // 埋点记录首字时间});}每个改造点都配套 SkyWalking 埋点重试打 retry_count tag流式打 first_token_ms tag方便后续验证。5. 闭环第四步灰度验证与指标回归改造后走灰度5% 流量3 天对比同高峰时段的指标指标改造前灰度后回归结论------------P99 延迟8.5s1.8s达标重试率12%1.2%显著下降平均首字时间760ms430ms改善熔断触发/日08(正常保护)符合预期线程池打满是否隔离生效灰度期间通过 SkyWalking 抽样 retry_count0 的 Trace确认重试从立即 x3变为退避 x1且熔断触发时返回友好降级而非雪崩。验证通过后再全量。PromQL 验证重试率下降# 重试率 带重试的链路 / 总链路自定义埋点计数器sum(rate(llm_retry_total[5m])) / sum(rate(llm_invoke_total[5m]))6. 闭环第五步沉淀为常态化机制验证有效的改造要沉淀为机制避免问题复发**告警规则化**在 Grafana 加重试率 5%告警比延迟告警更早预警。**埋点规范化**团队约定大模型调用必须打 model/retry_count/first_token_ms/token_cost 四个 tag。**发布规范**任何涉及 LLM 调用超时的变更必须灰度且观察 P99 重试率两个指标。**容量规范**离线任务与在线服务错峰并在 K8s 用 requests/limits 做资源隔离。把这些写成团队 Wiki 的大模型性能优化 checklist新需求上线前逐项核对。7. 大模型链路常见优化点清单优化点观测信号改法---------短超时重试风暴LLM.Infer 重试 tag 多退避熔断限重试次数线程池混用非相关 Span 互相变慢按业务隔离线程池串行可并行RAG 多步串行CompletableFuture 并行首字慢后处理空等流式 SSE 边生成边返回向量检索抖动VectorSearch P99 高索引错峰 资源 limitPrompt 过大token_cost 高Prompt 压缩/缓存摘要重复调用相同 Prompt 多次结果缓存 (语义缓存)**小结**性能优化不是改完就走而是观测→方案→改造→验证→沉淀的闭环。链路追踪提供的可度量性是这个闭环能运转的关键。下一篇我们做第 46 阶段的总复盘把整套大模型链路追踪体系与落地最佳实践串起来。