（第四篇）Spring AI 架构设计与优化：真实生产环境复盘，从 100ms 到 10ms 的响应提速全流程

摘要

大家好，我是深耕 Spring AI 落地的后端开发。上个月我们团队接到了一个紧急优化需求：线上跑了 3 个月的智能问答服务，平均响应耗时稳定在 100ms，业务高峰期 P99 延迟直接飙升到 500ms，大量用户反馈 "问个问题要等半天"，老板直接下了死命令：2 周内把平均延迟压到 20ms 以内，同时不能降低问答准确率。

接到需求的时候我头都大了，100ms 到 20ms，相当于要把性能提升 5 倍，还要保证效果不打折。我们团队花了 3 天做全链路压测、用 JProfiler 抓火焰图定位瓶颈，针对性做了 3 大核心优化，外加一堆细节调优，最终不仅完成了目标，还把平均响应压到了10ms 以内，P99 延迟稳定在 30ms，单机 QPS 从 1000 提升到了 5000，CPU 利用率反而下降了 30%。

这篇文章我会完整复盘整个优化过程，从瓶颈定位的方法、三大核心优化方案的落地细节、踩过的坑，到最终的全维度数据对比，所有内容都是生产环境实打实验证过的干货，附完整可复用的代码和示意图，看完就能直接落地到你的 Spring AI 项目里。

1. 引言：优化前的线上困境，100ms 响应为什么用户还说卡？

先给大家看一下我们优化前的服务架构，就是最经典的 Spring AI RAG 架构：

用户请求 → Spring Boot 服务 → 问题 Embedding 向量化 → Milvus 向量库检索相似文档 → 拼接 Prompt 调用大模型 → 返回结果给用户

上线初期用户量少，这个架构跑得很稳，平均响应 100ms 左右。但随着业务推广，用户量涨到了日均 10 万，高峰期 QPS 冲到了 800，问题就全暴露了：

平均响应虽然标着 100ms，但大量用户反馈卡顿，查日志才发现，高峰期 P99 延迟直接冲到了 500ms，10 个用户里就有 1 个要等半秒以上；

单机 QPS 上限只有 1000，再压就会出现大量超时，Milvus 的 CPU 利用率直接拉满；

服务重启后，前几百个请求的延迟直接到 1s 以上，被用户疯狂投诉。

当时我们做了个用户调研，用户对问答响应的容忍阈值是 50ms 以内，超过这个时间就会明显感觉到 "卡顿"。这也是为什么 100ms 的平均响应，用户还是说卡 ------ 因为长尾延迟太高了，大量用户的请求落在了 P99 区间。

老板给的目标很明确：2 周内，平均延迟≤20ms，P99≤50ms，问答准确率波动不能超过 1%。接下来，我们就开始了全链路的瓶颈定位和优化。

2. 性能瓶颈全链路分析：用 JProfiler 揪出耗时元凶

性能优化的第一步，永远是先定位瓶颈，再动手优化，而不是上来就瞎调参数。我们花了 3 天时间，1:1 复刻了线上环境，做了全链路压测和瓶颈分析。

2.1 压测环境搭建：1:1 模拟线上真实流量

要拿到真实的瓶颈数据，压测环境必须和线上一致，我们做了这几个关键配置：

服务器配置：和线上完全一致，8C16G 云服务器，Milvus 集群 3 节点，16C32G；
数据量：把线上的 1000 万条 1536 维向量全量同步到压测环境，保证数据量和线上一致；
流量模型：用线上 7 天的用户请求日志，做了压测脚本，完全模拟真实的用户提问分布，包括热点问题的占比；
压测工具：用 JMeter 做压测，从 100 QPS 逐步加压到 1000 QPS，采集每个环节的耗时数据。

2.2 JProfiler 火焰图分析：耗时占比一目了然

压测的同时，我们用 JProfiler 挂载了服务进程，采集了 CPU 耗时和方法调用火焰图，这是定位瓶颈最直观的方式。

2.3 三大核心瓶颈定位：每 1ms 都花在了哪里？

结合压测数据和火焰图，我们最终定位了三大核心瓶颈，占了整个请求链路 95% 的耗时：

向量检索是最大的耗时元凶：单次查询平均耗时 60ms，占了整个请求 60% 的耗时，高峰期 Milvus CPU 拉满，查询耗时直接冲到 200ms 以上。根源是我们为了保证召回率，用了 FLAT 暴力搜索索引，数据量到 1000 万条后，性能直接雪崩；
ModelClient 懒加载的隐形耗时：Spring AI 的 ChatClient 和 EmbeddingClient 默认是懒加载，Spring 容器启动后，第一次调用才会初始化 Http 客户端、连接池、模型配置，导致第一次调用耗时直接到 1s 以上。而且我们的线程池核心线程没有预热，请求过来才创建线程，又增加了额外的耗时；
热点问题重复调用模型，浪费大量资源：我们分析线上日志发现，Top1000 的热点问题占了总请求量的 90%，但每次都要重新走向量检索 + 模型调用的全流程，不仅耗时高，还浪费了大量的 API Token 和服务器资源。

除此之外，还有一些细节问题：比如 Http 连接池配置不合理，每次调用都要重新建立连接；Embedding 模型每次调用都要重新加载；序列化开销大等等。

找到了瓶颈，接下来就是针对性的优化，我们把优化分为三大核心方案，逐个击破。

3. 核心优化方案一：向量检索优化，从 60ms 到 3ms 的极致压缩

向量检索是 RAG 架构的核心，也是我们优化前最大的耗时点。这个环节的优化，我们的核心原则是：在保证召回率波动不超过 1% 的前提下，极致压缩查询耗时。

3.1 先搞懂：Milvus 索引类型到底怎么选？

很多人用 Milvus，上来就随便选个索引，根本不知道不同索引的适用场景。优化前我们就是踩了这个坑，为了 100% 的召回率，用了 FLAT 暴力搜索索引，数据量小的时候没问题，到了 1000 万条，性能直接崩了。

给大家整理了 Milvus 主流索引的适用场景，看完就知道怎么选：

索引类型	核心原理	召回率	查询性能	适用场景
FLAT	暴力搜索，全量向量比对	100%	极差，百万级数据就会卡顿	小数据量、对召回率要求 100% 的场景
IVF_FLAT	倒排文件，分桶搜索	高	中，千万级数据毫秒级返回	高召回率、中高 QPS 场景
HNSW	层次化导航小世界，图索引	较高	极好，亿级数据毫秒级返回	高 QPS、对延迟敏感的场景，我们最终的选择
IVF_SQ8	标量量化，压缩向量体积	中	好，比 IVF_FLAT 快	对内存占用敏感、可接受少量精度损失的场景

我们的场景是：1000 万条 1536 维向量，高峰期 QPS 1000+，对延迟极其敏感，召回率要求≥99%。综合对比下来，HNSW 索引是唯一能满足我们需求的选择。

3.2 索引参数调优：平衡精度与性能的核心

选对了索引只是第一步，参数调优才是核心。HNSW 索引有三个核心参数，直接决定了查询性能和召回率：

M：每个节点在图中的邻居数量，默认 16。M 越大，图的连通性越好，召回率越高，但是构建索引的时间和内存占用越高；
ef_construction：构建索引时，每个节点探索的邻居数量，默认 200。值越大，索引构建越慢，但是索引质量越高；
ef_search：查询时探索的邻居数量，默认 10。值越大，召回率越高，但是查询耗时越长。

我们做了几十组对照测试，最终找到了适合我们场景的最优参数：

bash 复制代码

# Milvus 集合创建参数（优化后）
{
  "fields": [
    {"name": "id", "data_type": "Int64", "is_primary_key": true},
    {"name": "content", "data_type": "VarChar", "max_length": 2000},
    {"name": "vector", "data_type": "FloatVector", "dim": 1536}
  ],
  "indexes": [
    {
      "field_name": "vector",
      "index_type": "HNSW",
      "metric_type": "COSINE",
      "params": {
        "M": 16,
        "ef_construction": 200
      }
    }
  ]
}

查询时，我们把 ef_search 设为 64，而不是默认的 10。

给大家看一下优化前后的向量检索性能对比：

指标	优化前（FLAT）	优化后（HNSW）	提升幅度
平均查询耗时	60ms	3ms	20 倍
P99 查询耗时	200ms	10ms	20 倍
单机 QPS 上限	1000	8000	8 倍
Milvus CPU 利用率	90%+	30%	下降 67%
召回率	100%	99.5%	仅下降 0.5%，完全符合业务要求

3.3 配套优化：向量数据分片 + 缓存预热

除了索引优化，我们还做了两个配套优化，进一步提升了向量检索的稳定性：

向量数据分片：把 1000 万条向量按业务场景分成了 8 个分片，每个分片单独建索引，查询时只查对应的分片，进一步缩小了检索范围，查询耗时又降了 0.5ms；
向量缓存预热：把高频检索的热点向量，提前加载到 Milvus 的内存缓存里，避免查询时从磁盘加载数据，高峰期的查询耗时波动从 ±50ms 降到了 ±2ms。

3.4 踩坑实录：索引换了，召回率掉了怎么办？

我们一开始直接把 FLAT 索引换成了 HNSW，用默认参数，结果线上召回率直接掉了 5 个百分点，产品经理拿着用户的投诉追着我们骂。

后来我们才发现，HNSW 的默认参数 ef_search=10，对于 1536 维的高维向量来说，这个值太小了，导致召回率严重下降。我们做了几十组测试，最终把 ef_search 设为 64，M=16，ef_construction=200，既保证了召回率≥99.5%，又把查询耗时压到了 3ms 以内。

这里给大家一个调优经验：ef_search 的值，至少要和你查询的 TopK 值一致，TopK 越大，ef_search 就要设的越大。比如你查 Top10，ef_search 至少设为 16；查 Top50，ef_search 至少设为 64。

4. 核心优化方案二：模型预热，消除懒加载的隐形耗时

优化完向量检索，我们接下来解决第二个瓶颈：Spring AI ModelClient 的懒加载初始化耗时，以及服务重启后的 "冷启动" 问题。

4.1 为什么 ModelClient 会有初始化耗时？

很多人不知道，Spring AI 的 ChatClient 和 EmbeddingClient，默认是懒加载的：

Spring 容器启动时，只会创建 Bean 的代理对象，不会初始化底层的 Http 客户端、连接池、模型配置；

只有第一次调用 ChatClient 的 chat () 方法时，才会执行完整的初始化流程，包括创建 OkHttp 客户端、建立连接池、加载模型配置、校验 API Key 等，这个过程在生产环境要 20-50ms，如果是本地 Embedding 模型，初始化耗时甚至要几百毫秒；

再加上我们的线程池没有预热，核心线程是请求过来才创建的，又增加了额外的耗时。

这就导致了一个问题：服务每次重启后，前几百个请求的延迟直接到 1s 以上，用户一打开服务就卡顿，投诉量直接飙升。

4.2 全链路预热实现：从客户端到连接池的完整预热

我们的解决方案是：在服务启动完成后，主动执行一次完整的预热调用，把所有懒加载的组件全部初始化完成，再让服务对外提供流量。

具体实现用 Spring 的ApplicationRunner，在 Spring 容器完全启动后，执行预热逻辑，代码如下：

java 复制代码

@Component
@Slf4j
public class ModelPreheatRunner implements ApplicationRunner {

    @Autowired
    private ChatClient chatClient;
    @Autowired
    private EmbeddingModel embeddingModel;
    @Autowired
    private VectorStore vectorStore;
    @Autowired
    private ThreadPoolTaskExecutor aiTaskExecutor;

    // 预热用的固定Prompt，不会产生实际业务影响
    private static final String PREHEAT_PROMPT = "你好，只需要回复"OK"两个字即可";
    private static final String PREHEAT_QUESTION = "什么是Java";

    @Override
    public void run(ApplicationArguments args) {
        log.info("开始执行Spring AI 模型预热...");
        long startTime = System.currentTimeMillis();

        try {
            // 1. 预热线程池：提前启动所有核心线程，避免请求时创建线程
            aiTaskExecutor.prestartAllCoreThreads();
            log.info("线程池预热完成，核心线程数：{}", aiTaskExecutor.getCorePoolSize());

            // 2. 预热Embedding模型：初始化模型、加载配置、初始化连接池
            embeddingModel.embed(PREHEAT_QUESTION);
            log.info("Embedding模型预热完成");

            // 3. 预热向量检索：初始化Milvus连接、加载索引缓存
            vectorStore.similaritySearch(PREHEAT_QUESTION);
            log.info("向量检索预热完成");

            // 4. 预热ChatClient：初始化Http客户端、连接池、模型配置
            chatClient.prompt().user(PREHEAT_PROMPT).call().content();
            log.info("ChatClient大模型客户端预热完成");

            long endTime = System.currentTimeMillis();
            log.info("Spring AI 全链路预热完成，总耗时：{}ms", endTime - startTime);
        } catch (Exception e) {
            log.error("Spring AI 预热失败，请检查模型配置和连接！", e);
            // 预热失败直接终止服务启动，避免带病上线
            System.exit(1);
        }
    }
}

这段代码会在服务启动后，依次预热线程池、Embedding 模型、向量检索、ChatClient，把所有懒加载的组件全部初始化完成。如果预热失败，直接终止服务启动，避免服务带病上线。

4.3 进阶优化：Embedding 模型常驻内存预热

如果你的服务用的是本地 Embedding 模型（比如 BGE、M3E），而不是远程 API，那模型加载的耗时会更长，甚至要几百毫秒。这时候可以用@PostConstruct注解，在 Bean 初始化的时候就把模型加载到内存里，常驻内存，避免调用时再加载：

java 复制代码

@Component
@Slf4j
public class LocalEmbeddingPreheat {

    @Autowired
    private EmbeddingModel localEmbeddingModel;

    @PostConstruct
    public void preloadModel() {
        log.info("开始预加载本地Embedding模型到内存...");
        long startTime = System.currentTimeMillis();
        // 提前执行一次向量化，把模型加载到内存
        localEmbeddingModel.embed("预加载");
        long endTime = System.currentTimeMillis();
        log.info("本地Embedding模型预加载完成，耗时：{}ms", endTime - startTime);
    }
}

4.4 踩坑实录：预热导致服务启动超时怎么办？

我们一开始把预热逻辑写在了@PostConstruct里，结果服务启动的时候，K8s 的就绪探针超时了，直接把 Pod 杀死了，陷入了 "启动→预热→超时被杀→重启" 的死循环。

后来我们改成了用ApplicationRunner执行预热，同时调整了 K8s 的就绪探针初始延迟时间，从原来的 20 秒改成了 60 秒，给预热留足了时间。同时我们给预热逻辑加了超时控制，如果预热超过 30 秒，直接终止，避免服务启动超时。

还有一个坑：预热用的 API Key 如果有权限限制，一定要提前开通，不然预热失败，服务直接起不来，我们测试环境就踩过这个坑。

预热优化完成后，我们的服务重启后，第一个请求的延迟从原来的 1s 以上，降到了 10ms 以内，彻底解决了冷启动的卡顿问题。

5. 核心优化方案三：热点问题缓存，90% 的请求直接毫秒级返回

优化完前两个点，我们的平均延迟已经降到了 30ms 以内，离老板要求的 20ms 还差一点。这时候我们发现，线上 90% 的请求，都是用户反复问的 Top1000 个热点问题，每次都要走全流程，不仅耗时，还浪费 Token。

于是我们做了第三个核心优化：热点问题缓存，让 90% 的请求直接从缓存里返回，耗时从 30ms 降到 1ms 以内。

5.1 AI 服务的缓存和普通业务缓存的核心区别

很多人做 AI 服务的缓存，直接用用户的问题字符串做 key，答案做 value，存到 Redis 里。但这样做有个致命的问题：用户的问法千变万化，但是答案是一样的。比如 "Java 是什么？"、"给我讲讲 Java 是啥"、"Java 的定义是什么"，这三个问题的答案完全一样，但字符串不一样，缓存就命中不了。

所以 AI 服务的缓存，不能用简单的字符串匹配，必须做语义级缓存：只要两个问题的语义是一样的，不管问法怎么变，都能命中缓存。

5.2 语义级缓存设计：解决 "问法不同，答案相同" 的问题

我们的语义级缓存核心思路是：用 SimHash 算法对用户的问题做语义哈希，计算海明距离，只要海明距离小于阈值，就认为是同一个问题，直接返回缓存的结果。

SimHash 是谷歌推出的算法，专门用来做文本的相似度计算，它可以把一段文本转换成一个 64 位的哈希值，两个文本的语义越相似，它们的 SimHash 值的海明距离就越小。海明距离≤3，就可以认为两个文本的语义是一致的。

给大家看一下 SimHash 的实现代码，可直接复用：

java 复制代码

@Component
public class SimHashUtil {

    // 分词器，用Hutool的分词器，也可以用IK分词器
    private final TokenizerEngine tokenizer = TokenizerEngine.create();

    // 生成64位SimHash值
    public long simHash(String text) {
        if (StrUtil.isBlank(text)) {
            return 0;
        }
        // 1. 分词，去除停用词
        List<String> words = tokenizer.segment(text).stream()
                .map(Token::getText)
                .filter(word -> !StopWordUtil.isStopWord(word))
                .toList();

        // 2. 初始化权重数组
        int[] weight = new int[64];

        // 3. 对每个分词计算哈希，累加权重
        for (String word : words) {
            long wordHash = HashUtil.murmur64(word.getBytes());
            for (int i = 0; i < 64; i++) {
                long bitMask = 1L << i;
                if ((wordHash & bitMask) != 0) {
                    weight[i] += 1; // 对应位为1，权重+1
                } else {
                    weight[i] -= 1; // 对应位为0，权重-1
                }
            }
        }

        // 4. 生成最终的SimHash值
        long simHash = 0;
        for (int i = 0; i < 64; i++) {
            if (weight[i] > 0) {
                simHash |= (1L << i);
            }
        }
        return simHash;
    }

    // 计算两个SimHash值的海明距离
    public int hammingDistance(long hash1, long hash2) {
        return Long.bitCount(hash1 ^ hash2);
    }
}

5.3 多级缓存策略：本地缓存 + Redis 的两级架构

为了极致的性能，我们设计了两级缓存架构：

L1 本地缓存：用 Caffeine，缓存 Top1000 的热点问题，直接在应用内存里，访问耗时 < 1ms，设置最大容量和过期时间；
L2 分布式缓存：用 Redis，缓存全量的问题和答案，供集群里的所有实例共享，过期时间设为 12 小时。

缓存的查询流程是：

用户提问，先对问题做 SimHash，生成语义哈希值；
先查 L1 本地缓存，用哈希值做 key，如果命中，直接返回答案；
如果 L1 未命中，查 L2 Redis 缓存，计算 Redis 里的哈希值和当前哈希值的海明距离，如果≤3，命中缓存，返回答案，同时更新 L1 缓存；
如果都未命中，走向量检索 + 模型调用的全流程，生成答案后，写入 L1 和 L2 缓存，返回给用户。

给大家看一下缓存的实现代码：

java 复制代码

@Service
@Slf4j
public class AiAnswerCacheService {

    @Autowired
    private SimHashUtil simHashUtil;
    @Autowired
    private StringRedisTemplate redisTemplate;
    // L1本地缓存，最大容量1000，写入后12小时过期
    private final Cache<Long, String> localCache = Caffeine.newBuilder()
            .maximumSize(1000)
            .expireAfterWrite(12, TimeUnit.HOURS)
            .recordStats()
            .build();

    // Redis缓存的key前缀
    private static final String CACHE_KEY_PREFIX = "ai:answer:hash:";
    // 海明距离阈值，≤3认为语义一致
    private static final int HAMMING_THRESHOLD = 3;

    // 从缓存中获取答案
    public String getFromCache(String question) {
        long currentHash = simHashUtil.simHash(question);
        // 1. 先查L1本地缓存
        String localAnswer = localCache.getIfPresent(currentHash);
        if (localAnswer != null) {
            log.info("L1本地缓存命中，问题：{}", question);
            return localAnswer;
        }
        // 2. 查L2 Redis缓存，获取所有缓存的哈希值
        Set<String> keys = redisTemplate.keys(CACHE_KEY_PREFIX + "*");
        if (CollUtil.isEmpty(keys)) {
            return null;
        }
        // 3. 遍历所有缓存，计算海明距离
        for (String key : keys) {
            long cacheHash = Long.parseLong(key.replace(CACHE_KEY_PREFIX, ""));
            int distance = simHashUtil.hammingDistance(currentHash, cacheHash);
            if (distance <= HAMMING_THRESHOLD) {
                // 命中缓存，获取答案
                String answer = redisTemplate.opsForValue().get(key);
                if (StrUtil.isNotBlank(answer)) {
                    // 更新L1缓存
                    localCache.put(currentHash, answer);
                    log.info("L2 Redis缓存命中，海明距离：{}，问题：{}", distance, question);
                    return answer;
                }
            }
        }
        // 未命中缓存
        return null;
    }

    // 写入缓存
    public void putToCache(String question, String answer) {
        long hash = simHashUtil.simHash(question);
        // 写入L1本地缓存
        localCache.put(hash, answer);
        // 写入L2 Redis缓存，12小时过期
        redisTemplate.opsForValue().set(CACHE_KEY_PREFIX + hash, answer, 12, TimeUnit.HOURS);
        log.info("缓存写入完成，问题：{}", question);
    }
}

5.4 缓存三大问题解决方案：穿透 / 击穿 / 雪崩

做缓存，必须解决缓存穿透、缓存击穿、缓存雪崩三大问题，我们针对 AI 服务的场景，做了对应的解决方案：

缓存穿透：用户问的问题缓存里没有，每次都要走全流程，甚至有人用恶意问题攻击服务。我们的解决方案：用布隆过滤器，把所有有答案的问题的 SimHash 值存到布隆过滤器里，查询时先查布隆过滤器，如果不存在，直接返回默认答案，不走全流程；
缓存击穿：某个热点 key 过期，大量请求同时过来，直接打到模型 API。我们的解决方案：用互斥锁，当缓存过期时，只有一个线程能去调用模型生成答案，其他线程等待，缓存更新后再返回；
缓存雪崩：大量 key 同时过期，大量请求打到模型 API。我们的解决方案：给过期时间加随机值，比如 12 小时的基础过期时间，加上 0-2 小时的随机值，避免大量 key 同时过期。

缓存优化完成后，我们的缓存命中率达到了 92%，90% 的请求直接从缓存返回，耗时 < 1ms，平均延迟直接从 30ms 降到了 10ms 以内，完美达成了老板的目标。

6. 辅助优化：那些被忽略的 1ms 级耗时细节

除了三大核心优化，我们还做了很多细节调优，把那些被忽略的 1ms 级耗时一点点抠出来，积少成多：

Http 客户端优化：把 Spring AI 默认的 JDK HttpClient 换成了 OkHttp，配置了连接池，最大连接数设为 100，连接存活时间设为 5 分钟，避免每次调用都重新建立 TCP 连接，模型调用耗时又降了 3ms；
线程池优化 ：重新调整了异步线程池的参数，核心线程数设为 2CPU 核数 + 1，最大线程数设为 4CPU 核数，队列容量设为 500，预热所有核心线程，减少了线程创建和上下文切换的开销；
序列化优化：把 JSON 序列化从 Jackson 换成了 Fastjson2，序列化和反序列化的耗时降了 50%；
JVM 参数优化 ：调整了 JVM 的堆内存参数，用 G1 垃圾收集器，设置-XX:MaxRAMPercentage=75.0，-XX:+UseContainerSupport，适配容器环境，减少了 GC 的频率和耗时；
向量检索结果缓存：把高频检索的向量结果缓存到 Redis 里，避免重复向量化和检索，又降了 2ms。

7. 优化前后全维度对比：用真实数据说话

经过 2 周的优化，我们最终完成了目标，甚至超出了预期。给大家看一下优化前后的全维度数据对比，全部来自线上真实环境：

给大家整理成表格，更清晰：

核心指标	优化前	优化后	提升幅度
平均响应延迟	100ms	10ms	提升 10 倍
P99 响应延迟	500ms	30ms	提升 16 倍
单机 QPS 上限	1000	5000	提升 5 倍
向量检索平均耗时	60ms	3ms	提升 20 倍
缓存命中率	0%	92%	-
Milvus CPU 利用率	90%+	30%	下降 67%
服务冷启动首包延迟	1000ms+	10ms 以内	提升 100 倍
大模型 API Token 消耗	日均 1000 万	日均 80 万	下降 92%，成本大幅降低

优化完成后，用户的卡顿投诉直接清零，老板在周会上专门表扬了我们团队，而且大模型 API 的成本直接降了 92%，省了一大笔钱。

8. 踩坑总结：Spring AI 性能优化的 7 条避坑指南

整个优化过程，我们踩了无数的坑，给大家总结了 7 条避坑指南，避免大家走弯路：

性能优化的第一步永远是定位瓶颈，而不是上来就瞎调参数。我们见过太多人，上来就调 JVM 参数、换序列化框架，结果最大的瓶颈在向量检索，调了半天也没效果；
向量索引的选择，一定要匹配你的数据量和场景。千万不要为了极致的召回率，用 FLAT 暴力索引，数据量超过 100 万条，性能直接雪崩；
Spring AI 的客户端一定要做预热，不然服务重启后的冷启动问题会被用户骂死，而且预热一定要放在服务启动完成后，不要影响服务启动的探针检测；
AI 服务的缓存一定要做语义级缓存，不要用简单的字符串匹配。不然用户换个问法就命中不了缓存，缓存命中率上不去，优化效果大打折扣；
缓存优化一定要解决三大问题：穿透、击穿、雪崩，不然缓存不仅没用，还会给你的服务带来风险，比如恶意请求穿透缓存，把你的 API 额度打满；
性能优化要平衡效果和性能，不能为了提速，牺牲了问答的准确率和召回率。我们一开始为了提速，把 ef_search 设的太小，结果召回率掉了 5 个百分点，被产品经理追着骂；
优化完成后一定要做全量回归测试，不能只看性能指标，还要保证业务功能正常，问答效果符合要求，不然优化的再好，业务用不了也是白搭。

9. 总结与展望

总结

这篇文章里，我完整复盘了我们 Spring AI 服务从 100ms 到 10ms 的全流程优化，从瓶颈定位的方法，到三大核心优化方案的落地细节，再到踩过的坑和最终的效果数据，所有内容都是生产环境实打实验证过的干货。

整个优化过程，我们核心做了三件事：

向量检索优化：把 Milvus 的索引从 FLAT 换成 HNSW，调优参数，把检索耗时从 60ms 降到 3ms，这是整个优化的基础；
模型预热：消除了 Spring AI 客户端懒加载的隐形耗时，解决了服务冷启动的卡顿问题，首包延迟从 1s 降到 10ms 以内；
语义级缓存：用 SimHash 实现了语义缓存，两级缓存架构，缓存命中率达到 92%，90% 的请求直接毫秒级返回，同时大幅降低了 API 成本。

最终我们不仅完成了老板要求的 20ms 以内的目标，还把平均延迟压到了 10ms 以内，P99 延迟稳定在 30ms，单机 QPS 提升了 5 倍，API 成本下降了 92%，完美达成了业务目标。

展望

未来我们还会在性能优化上做进一步的探索：

引入本地轻量大模型：把高频的简单问答，用本地轻量模型处理，不用调用远程 API，进一步降低延迟；
向量检索的进一步优化：用 Milvus 的标量过滤 + 分区键，进一步缩小检索范围，把查询耗时降到 1ms 以内；
智能缓存预热：用用户的访问日志，预测热点问题，提前预热到缓存里，进一步提升缓存命中率；
流式响应的性能优化：针对流式问答的场景，优化 SSE 推送的性能，降低首包响应时间。

10. 参考文献

结语：以上就是 Spring AI 服务从 100ms 到 10ms 的完整优化复盘，所有的代码和方案都可以直接复制到你的项目里落地。如果大家有任何问题，或者需要完整的代码工程，欢迎在评论区留言，我会一一回复。如果觉得这篇文章对你有帮助，别忘了点赞、收藏、转发三连，后续我还会分享更多 Spring AI 架构优化的实战干货，感谢大家的支持！