sglang 中的多进程 Tokenizer 优化实践

¶概述

本文记录了在 sglang 项目中针对多 GPU 环境下 Tokenizer 性能瓶颈的分析与优化过程。通过实现多进程 Tokenizer 架构，成功解决了大规模推理场景下的性能瓶颈问题。

¶问题发现与定位

在 9 台服务器、72 张 H100 GPU 的集群上运行 DeepSeek 模型进行解码性能测试时，发现了一个显著的性能差异：

服务端日志显示：单卡吞吐量达到 2000 tokens/秒 (TPS)
客户端测试结果：无论是 TTFT（Time To First Token）、TPOT（Time Per Output Token），还是整体吞吐量，都远低于预期值

¶初步分析

经过初步排查，问题可能出现在以下几个方面：

HTTP 服务器瓶颈：使用 FastAPI 作为 HTTP 服务器，在处理大量输入数据时可能成为性能瓶颈，即使切换到 Sanic 等其他框架也无法完全解决
测试脚本限制：Python 测试脚本需要同时处理请求发送、流式接收、计时统计等多个任务，可能引入额外开销

¶深入调查

通过代码分析发现核心问题：单进程的http server, tokenizer, detokenizer 成为系统瓶颈

计算分析：

总吞吐量： $2000 \text{ TPS} \times 72 \text{ GPU} = 144,000 \text{ tokens/秒}$
Detokenizer 处理时间：50~100 us/Token
理论需求：要在 1 秒内处理 144,000 个 Token，Detokenizer 需要在 7us内完成每个 Token 的处理

  graph TD
subgraph 客户端
Client[Client]
end

    subgraph Web服务器
        HttpServer[HTTP Server]
        Tokenizer[Tokenizer]
        HttpServer -- 函数调用 --> Tokenizer
    end

    subgraph GPU集群
        subgraph GPU1
            Scheduler1[Scheduler]
            Worker1[Worker]
            Scheduler1 --> Worker1
        end
        subgraph GPU2
            Scheduler2[Scheduler]
            Worker2[Worker]
            Scheduler2 --> Worker2
        end
        subgraph GPU3
            Scheduler3[Scheduler]
            Worker3[Worker]
            Scheduler3 --> Worker3
        end
        subgraph GPU4
            Scheduler4[Scheduler]
            Worker4[Worker]
            Scheduler4 --> Worker4
        end
    end

    subgraph 结果处理
        Detokenizer[Detokenizer]
    end

    Client -->|HTTP请求| HttpServer
    Tokenizer -->|ZMQ请求| Scheduler1
    Tokenizer -->|ZMQ请求| Scheduler2
    Tokenizer -->|ZMQ请求| Scheduler3
    Tokenizer -->|ZMQ请求| Scheduler4

    Worker1 -->|ZMQ结果| Detokenizer
    Worker2 -->|ZMQ结果| Detokenizer
    Worker3 -->|ZMQ结果| Detokenizer
    Worker4 -->|ZMQ结果| Detokenizer

    Detokenizer -->|ZMQ返回| Tokenizer
    HttpServer -->|HTTP响应| Client

    style Detokenizer stroke:#f66,stroke-width:2px

¶架构分析与解决方案

从系统架构图可以清晰地看到问题所在：Detokenizer 成为了单点瓶颈。多个 GPU Worker 同时向单个 Detokenizer 发送处理结果，形成了"多对一"的通信模式。

¶解决方案

基于架构分析，制定了以下优化策略：

Detokenizer 多进程化：将单进程 Detokenizer 改造为多进程架构，实现并行处理
测试脚本多进程优化：改造测试脚本，支持多进程并发处理

¶sglang PR 实现方案

¶核心设计原则

全面多进程化：系统中任何可能出现"多对一"通信模式的地方都需要进行多进程改造，避免单点瓶颈。

¶技术实现细节

单机多进程通信：使用共享内存（SHM）进行高效进程间通信
请求路由管理：通过 MultiTokenizerRegisterReq 机制维护请求标识符（RID）的路由信息，确保每个请求从哪个 Tokenizer 进入就从对应的路径返回
负载均衡：实现智能的请求分发机制，确保各个 Detokenizer 进程负载均衡