Rails 后台任务开始用 Fiber：LLM 调用不一定需要更多线程
作者：林岚｜OC 开发者生态编辑
作者：林岚｜OC 开发者生态编辑
Rails 的数据库队列 Solid Queue 在 v1.6.0 中加入 Fiber 执行模式。Worker 不再只能把任务交给线程池，也可以在一个 Fiber Reactor 线程上并发运行多个 Fiber。发布说明直接把等待 LLM 调用列为适用场景。
一句话结论：Fiber 不会让模型更快，也不会给 Ruby 增加 CPU 核心；它减少的是大量任务等待网络响应时的线程成本，前提是整条调用链都愿意把控制权交回事件循环。
配置方式很短：在 worker 中把 threads 换成 fibers: 100。Solid Queue 底层使用 Async，因此项目要加入对应依赖，并将 Rails 的隔离级别设为 config.active_support.isolation_level = :fiber。这些不是可选细节，线程本地状态如果没有正确迁移到 Fiber 隔离，可能在并发任务间串数据。
为什么 LLM 调用适合？一次 API 请求可能大部分时间都在等 DNS、TLS、模型排队和流式输出。线程阻塞时，操作系统仍要保留栈和调度状态；Fiber 在等待兼容的非阻塞 I/O 时可以主动让出，同一线程继续处理其他任务。连接数很多而每个任务计算很少时，内存和切换成本可能更低。
但只要任务执行阻塞数据库驱动、同步 HTTP 客户端、文件操作或长时间 CPU 计算，整个 Reactor 线程就可能一起停住。Fiber 并发不是“把 100 个线程改成 100 个 Fiber”这么简单，依赖库必须支持调度器，超时、取消和连接池也要按新的并发度重新检查。
数据库尤其容易成为下一处瓶颈。Solid Queue 自己依赖数据库轮询和锁，业务 Job 也可能访问 Active Record。100 个 Fiber 不代表应该准备 100 个数据库连接，但若大量任务同时进入阻塞查询，连接池和事务隔离必须有明确上限。LLM 限流也一样，提高本地并发可能只是更快撞上供应商的 429。
v1.6.0 仍保留线程路径，Fiber 是按 worker 选择的执行模式，不是全局强制迁移。更稳妥的采用方式，是先挑网络等待占比高、无本地重计算的队列，比较吞吐、P95 延迟、内存、错误率和取消行为，再决定是否扩大。
关键事实
- 新能力：Solid Queue v1.6.0 支持单 Reactor 线程上的 Fiber Worker
- 配置要求：安装 Async，并启用 Rails Fiber 隔离级别
- 适合负载：LLM API、外部 HTTP 请求等 I/O 等待占比高的任务
- 不适合负载：长时间 CPU 计算或包含不兼容阻塞 I/O 的任务
OC 判断
先别把 Fiber 数量当成新的线程数量旋钮。团队应从依赖兼容性和背压开始：确认 HTTP、数据库和日志客户端是否支持调度器，设置每个外部服务的并发上限，并验证任务取消后连接与事务能否清理。吞吐变高但下游被压垮，不叫优化。
为什么重要
- 对 Rails 开发者：I/O 密集队列可以减少线程开销，但要逐个审核阻塞依赖。
- 对 AI 产品：大量并行模型请求需要限流、超时和成本预算，执行器只解决本地等待效率。
- 对运维团队：新增监控应覆盖 Reactor 卡顿、连接池等待和供应商 429，而不只看 Job 数量。
评论
围绕这篇文章补充信息、提出问题或分享观察。