devgo.cn给 AI Agent 提供基于内容的准确回答，背后要跑好几种模型：读取文档、OCR 识别、向量化嵌入、重排序，每一步都在给用户增加等待时间。Elastic 托管了 Jina 系列小模型，提供 Jina API 和 Elastic Inference Service（EIS，预配置好、与 Elasticsearch 原生集成的 GPU 加速推理端点）两种托管服务。最近他们把服务从 NVIDIA L40 GPU 迁移到 NVIDIA RTX Pro 6000 Blackwell Server Edition GPU，迁移后部分模型的最慢嵌入请求（99 分位延迟）快了约 8 倍，重排序快 4 倍以上，OCR 页面转换速度约 3.7 倍。最值得注意的是，客户什么都不用改，速度提升是自动生效的。
先交代一下背景。Jina 的模型主打小尺寸、强能力。Reader 和 OCR 模型能把包含图片、表格、公式的复杂文档和网页转成带 markdown/HTML 结构和 LaTeX 公式的干净文本；jina-ocr-v1 单次前向同时解析布局、文本、表格和结构，支持 100 多种语言，在 olmOCR-bench 基准上是 6 亿参数以下活跃参数模型的领先者。Embedding 模型把多语言多模态内容映射到同一向量空间，jina-embeddings-v5-omni-small 是 MTEB 上 20 亿参数以下最强的开源权重全模态模型。Reranker 模型对检索结果按原始查询重新打分排序，jina-reranker-v3.5 只有 6 亿参数，在 STaRK 结构化数据基准上击败了 40 亿参数的 Qwen3-Reranker-4B。
但模型小不等于容量规划简单。Jina API 和 EIS 是共享服务，大任务和小请求跑在同一批 GPU 上。一个重排序请求可能携带一长串候选文档，而排在它后面的查询可能只需要一个快速答案。当大任务占住 GPU 时，小请求就得排队，延迟飙升。这正是 Elastic 在评估 RTX Pro 6000 时最关心的场景：混合负载下，小请求还能保持快吗？
他们对比了迁移前后的生产流量，并做了生产环境无法隔离的受控测试。结果如下：嵌入请求的 99 分位延迟从 5.86 秒降到 0.73 秒，约 8 倍提升；重排序在平均请求量增加约 40% 的情况下，90 分位延迟从 732 毫秒降到 171 毫秒，提升 4.3 倍；大型重排序任务在受控测试中，从三块 L4 上的 702 毫秒降到单块 RTX Pro 6000 上的 160 毫秒，提升 4.4 倍；混合流量测试中，大任务旁边的小重排序请求延迟从 708 毫秒降到 66 毫秒，提升 10.7 倍；OCR 的首 token 输出时间从 0.50 秒降到 0.20 秒，页面转换速度从 454 页/小时提升到 1671 页/小时，约 3.7 倍。
最让我意外的是混合负载下 10.7 倍的提升。这说明 RTX Pro 6000 的调度和并发能力让大任务不再轻易饿死小请求，对共享推理服务来说，这比单纯峰值吞吐更有价值。对做推理服务的人来说，这个案例的启发是：评估新 GPU 不能只看单模型跑分，要拿真实混合流量去压测，看长尾延迟（99 分位）而不是平均值——慢请求才是用户能感知到的。另外，模型小不代表容量规划简单，请求混合模式（大 job 和小 query 的比例）对 GPU 需求的影响可能比模型参数量更大。目前 Elastic 还在继续迁移 Jina API 和 EIS 的更多模型，迁移是逐个模型进行的，所以不同模型看到提速的时间点会不一样。
内容与图片版权归原作者所有 · 原文: https://www.elastic.co/blog/jina-model-inference-nvidia-rtx-gpus