Perplexity 公布 pplx-embed 背后的 GPU 服务栈：Ivy、Tulip 与 ROSE
Perplexity 工程团队撰文说明了搜索引擎背后的嵌入与排序模型是如何被服务的。整套栈由 Ivy、Tulip 与 ROSE 三个部件组成。核心结论是，小型嵌入模型的时延取决于 token 数量，而不是序列条数。
Perplexity 工程团队在 9 月 4 日发表的《Fast Embeddings on GPUs》一文中，说明了搜索引擎背后的嵌入与排序模型是如何被服务的。文章描述了三部件服务栈：Ivy、Tulip 与 ROSE。核心结论是，小型嵌入模型的时延取决于 token 数量而非序列条数；在十亿参数以下的模型上，大约 512 个 token 就足以让 GPU 饱和。
这套栈
- Ivy：用 Rust 写成的 HTTP 网关，负责 JSON 解析、分词、输入模板化以及拆分批量请求，再把请求转成自定义 gRPC 协议并在副本之间做负载均衡。该公司称，其自研的 unigram 分词器相比现成分词器显著降低了时延。
- Tulip：用 Rust 加 tokio 与 tonic 写成的 gRPC 服务端，按先到先服务的顺序调度请求，组批后交给 ROSE。
- ROSE（Runtime-Optimized Serving Engine）：推理引擎，主体用 Python 写成。嵌入服务不建 KV 缓存，使用无需填充的 ragged 注意力核；按该公司的说法，pplx-embed 的服务与 Qwen3.5 的解析走同一批核。
收益从哪里来
小批量下 CPU 侧的核启动开销可能重于 GPU 上的实际计算，于是团队把整个前向过程捕获为一张 CUDA graph，用一次调用启动。由于配置网格很大，会产生数千张图，捕获可能耗时数分钟，因此改为在服务时惰性捕获：首次命中预热，第二次命中才捕获，之后重放。LazyTensor 则不等待结果，而是跟踪一次到页锁定主机内存的异步拷贝，下一批无须等上一批结束就能入队。
测评
对比使用 vLLM v0.22.0、BF16 与真实模型权重，共四种场景。Perplexity 报告了更低的时延与更高的吞吐，但数字只出现在图里，正文没有给出数值。目前没有独立测试。
对企业读者而言
对自建搜索或 RAG 基础设施的机构来说，收益更多来自模型外面的那层壳：分词、组批，以及 CPU 与 GPU 工作的重叠。小型嵌入模型上把批量做大并不会提升吞吐，阈值大约 512 个 token。文章写明了测评设置，可在自己的负载上复现。文中没有关于这套栈开源的说明。
来源
- Perplexity Engineering，《Fast Embeddings on GPUs》，9 月 4 日：perplexity.ai/hub/blog/fast-embeddings-on-gpus
- MarkTechPost 的转述，9 月 5 日。
