StartHub - 将 LLM 服务改为非阻塞式，使吞吐量提升 10 倍 - 朴珉圭

详细内容

概述
- StartHub 是一个 AI 创业支持平台，为解决创业者面临的问题，从零自建 RAG 系统，通过定制化扶持公告推荐、基于用户活动的 AI 聊天机器人、商业模式画布生成、竞品分析等功能，为创业的全过程提供支持。
- 韩国初创企业的存活率仅为 33.8%，低于 OECD 平均水平（45.4%），其中约 90% 的失败源于资金不足（38%）、市场性不足（35%）、商业模式有误（20%）等因素。本项目正是从这一问题出发。
- 对于竞品分析等需要实时联网检索的功能，则通过接入 Perplexity API 来处理。
问题 — 流量增加时基于 LLM 的服务出现请求耗时与失败率上升
- 当时基于 LLM 的各项功能采用阻塞式的线程池结构来处理。
- 在 Perplexity API 漫长的响应延迟期间，线程会一直处于 I/O 等待状态。
- 流量增加时，线程池随之扩张，内存占用呈线性增长。
- 未能发挥出 WebFlux 基于非阻塞的高并发处理这一优势。
解决方法 1 — 将基于线程的异步迁移到 Kotlin 协程
- 将 Spring @Async 与 CompletableFuture 替换为 CoroutineScope 和 Deferred。
- 通过 kotlinx-coroutines-reactor 与 WebFlux 集成，构建了异步处理架构。
解决方法 2 — 将阻塞式 I/O 改造为非阻塞
- 将 Perplexity API 调用中的 .block() 改为 .awaitSingle()。
- 将重复请求处理中的 CompletableFuture.get() 改为 Deferred.await()，使线程在 I/O 等待期间得以让出。
成果 — 并发吞吐量提升 10 倍以上，内存占用降低约 90%
- 搭建 Grafana 监控服务器后，执行并分析了基于 K6 的负载测试。
- 实现了全链路非阻塞，在相同资源下将并发吞吐量提升 10 倍以上，内存占用降低约 90%。
- 大幅改善了虚拟用户（VU）达到阈值后因过载而导致请求失败的现象。
引入非阻塞之前
- 当 VU 达到阈值时，Failure Rate 会骤增，进而引发服务故障。
引入非阻塞之后
- 并发吞吐量大幅提升，并实现了 HTTP Failures 为 0。

详细内容

概述
- StartHub 是一个 AI 创业支持平台，为解决创业者面临的问题，从零自建 RAG 系统，通过定制化扶持公告推荐、基于用户活动的 AI 聊天机器人、商业模式画布生成、竞品分析等功能，为创业的全过程提供支持。
- 韩国初创企业的存活率仅为 33.8%，低于 OECD 平均水平（45.4%），其中约 90% 的失败源于资金不足（38%）、市场性不足（35%）、商业模式有误（20%）等因素。本项目正是从这一问题出发。
- 对于竞品分析等需要实时联网检索的功能，则通过接入 Perplexity API 来处理。
问题 — 流量增加时基于 LLM 的服务出现请求耗时与失败率上升
- 当时基于 LLM 的各项功能采用阻塞式的线程池结构来处理。
- 在 Perplexity API 漫长的响应延迟期间，线程会一直处于 I/O 等待状态。
- 流量增加时，线程池随之扩张，内存占用呈线性增长。
- 未能发挥出 WebFlux 基于非阻塞的高并发处理这一优势。
解决方法 1 — 将基于线程的异步迁移到 Kotlin 协程
- 将 Spring @Async 与 CompletableFuture 替换为 CoroutineScope 和 Deferred。
- 通过 kotlinx-coroutines-reactor 与 WebFlux 集成，构建了异步处理架构。
解决方法 2 — 将阻塞式 I/O 改造为非阻塞
- 将 Perplexity API 调用中的 .block() 改为 .awaitSingle()。
- 将重复请求处理中的 CompletableFuture.get() 改为 Deferred.await()，使线程在 I/O 等待期间得以让出。
成果 — 并发吞吐量提升 10 倍以上，内存占用降低约 90%
- 搭建 Grafana 监控服务器后，执行并分析了基于 K6 的负载测试。
- 实现了全链路非阻塞，在相同资源下将并发吞吐量提升 10 倍以上，内存占用降低约 90%。
- 大幅改善了虚拟用户（VU）达到阈值后因过载而导致请求失败的现象。
引入非阻塞之前
- 当 VU 达到阈值时，Failure Rate 会骤增，进而引发服务故障。
引入非阻塞之后
- 并发吞吐量大幅提升，并实现了 HTTP Failures 为 0。