语音合成性能优化实战：如何通过Benchmark测试提升TTS系统吞吐量

1次阅读

共计 2897 个字符，预计需要花费 8 分钟才能阅读完成。

在电商客服机器人项目中，我们遇到了语音合成服务的性能瓶颈。当并发请求量超过 50QPS 时，系统出现明显的延迟波动，P99 延迟从 200ms 飙升至 2s 以上。更严重的是，内存占用会在高峰期暴涨到 8GB，导致 Kubernetes 集群频繁触发 OOM Kill。通过火焰图分析，发现主要耗时集中在梅尔频谱生成和波形合成两个阶段，其中自回归推理的串行处理成为关键瓶颈。

我们对主流 TTS 模型在相同硬件环境下进行了基准测试（AWS c5.2xlarge + T4 GPU）：

模型类型	平均延迟 (ms)	QPS(CPU)	QPS(GPU)	显存占用 (MB)
Tacotron2	320	12	45	1800
FastSpeech2	150	25	78	2100
VITS	90	18	65	2500

测试使用 1000 次 ” 欢迎使用智能客服系统 ” 的合成请求，文本长度统一为 15 个汉字。结果显示 FastSpeech2 在延迟和吞吐量上表现最优，最终选择其作为基础模型。

将 PyTorch 模型转换为 TensorRT 引擎时，采用 FP16 量化并启用动态形状支持：

# torch 转 onnx
torch.onnx.export(
    model, 
    dummy_input, 
    "fastspeech2.onnx",
    input_names=["input_ids"],
    dynamic_axes={"input_ids": {0: "batch"}}
)

# onnx 转 TensorRT
builder = trt.Builder(TRT_LOGGER)
network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
parser = trt.OnnxParser(network, TRT_LOGGER)

# 关键配置
config = builder.create_builder_config()
config.set_flag(trt.BuilderFlag.FP16)
config.set_flag(trt.BuilderFlag.STRICT_TYPES)
config.max_workspace_size = 1 << 30  # 1GB
profile = builder.create_optimization_profile()
profile.set_shape("input_ids", (1,16), (8,64), (16,128))  # 动态批次
config.add_optimization_profile(profile)

使用环形缓冲区和条件变量实现线程安全的生产者 - 消费者模式：

class BatchQueue {
public:
    void push(const Request& req) {std::unique_lock<std::mutex> lock(mutex_);
        cond_.wait(lock, [this]{return queue_.size() < capacity_; });
        queue_.push_back(req);
        lock.unlock();
        cond_.notify_all();}

    std::vector<Request> pop() {std::unique_lock<std::mutex> lock(mutex_);
        cond_.wait(lock, [this]{return !queue_.empty() || 
                   (GetTickCount() - last_pop_) > timeout_ms_;
        });

        // 动态调整批次大小
        size_t batch_size = std::min(max_batch_, queue_.size());
        std::vector<Request> batch;
        for(size_t i=0; i<batch_size; ++i) {batch.push_back(queue_.front());
            queue_.pop_front();}
        last_pop_ = GetTickCount();
        return batch;
    }

private:
    std::deque<Request> queue_;
    std::mutex mutex_;
    std::condition_variable cond_;
    uint32_t last_pop_ = 0;
    const uint32_t timeout_ms_ = 50; // 最大等待时间
};

针对频繁申请的显存对象设计复用机制：

class MemoryPool:
    def __init__(self, max_items=10):
        self.pool = {}
        self.lock = threading.Lock()

    def get_buffer(self, shape, dtype):
        key = (tuple(shape), dtype)
        with self.lock:
            if key not in self.pool or not self.pool[key]:
                return torch.empty(shape, dtype=dtype, device='cuda')
            return self.pool[key].pop()

    def release_buffer(self, tensor):
        key = (tuple(tensor.shape), tensor.dtype)
        with self.lock:
            if key not in self.pool:
                self.pool[key] = []
            self.pool[key].append(tensor)

使用 Locust 模拟真实场景的请求分布，其中 80% 请求文本长度在 10-20 字，20% 为 30-50 字的长文本：

class TTSUser(HttpUser):
    @task
    def synthesize(self):
        text = generate_random_text() 
        self.client.post("/synthesize", 
            json={"text": text},
            headers={"Content-Type": "application/json"})