首页 / 文章 / 超越文本的推理：VLM、嵌入模型、语音、图像与视频的优化

inferencemultimodaldiffusionembeddingsgpu-optimization

超越文本的推理：VLM、嵌入模型、语音、图像与视频的优化

每种模态都有其自身的瓶颈。了解如何通过恰当的批处理、内核、缓存及量化技术来优化VLM、嵌入模型、ASR、TTS以及图像和视频生成器。

2595 词

提升纯文本语言模型的速度早已是解决得相当完善的问题，以至于人们将其技巧视为通用方法。但实际上并非如此。一旦推出实际产品，文本生成只是多个环节中的一个，而每个环节都有不同的瓶颈。那种能让大语言模型服务速度提升一倍的优化手段，对嵌入模型可能毫无用处；而图像或视频生成又会带来自身的计算与注意力机制问题。在这里，你将了解视觉语言模型、嵌入器、语音识别、文本转语音、语音转语音技术、图像生成器和视频生成器，从两种基本的执行模式入手，进而探讨每种技术的性能指标、硬件选择、缓存策略、量化处理、批量处理以及质量与效率之间的权衡。贯穿始终的核心思想是：推理工程的实现方式取决于具体的工作负载。

为何单一方案行不通

实际应用会将各种模型串联起来。语音助手可能会接收音频，进行语音识别，对文本进行分析，然后再合成语音。文档系统则可能在检索和调用大型语言模型之前，先通过OCR处理PDF文件，再使用视觉模型和嵌入技术。视频工具则可能从文本开始，通过反复去噪生成片段，最后进行媒体解码。

每一步都有其特定的成本结构，因此需要优化的目标也会随之变化。让自回归语言模型快速运行的机制无法直接应用到图像或视频处理流程中。

两种模式涵盖了大多数情况

几乎所有的生成式系统都遵循这两种结构中的一种。

第一种是自回归生成。模型逐步骤产生输出，每个词元都基于前序内容来决定：

Input
  ↓
Token 1
  ↓
Token 2
  ↓
Token 3
  ↓
...

这就是我们熟悉的LLM循环。基于语言模型架构构建的视觉语言模型、嵌入系统、ASR解码器以及许多TTS模型，都可以从中借鉴大量的Transformer服务理念。

第二种是迭代去噪方法，即扩散模型，通过逐步优化带有噪声的初始状态来实现目标：

Random / noisy latent
        ↓
      Step 1
        ↓
      Step 2
        ↓
      Step 3
        ↓
       ...
        ↓
Final image/video

图像和视频生成技术主要集中于此。

这一点很重要，因为无法用统一的延迟、吞吐量或效率标准来衡量所有这些技术。对于聊天机器人而言，生成第一个标记的时间往往是关键指标；而对于语音合成，则是产生首个有意义音频的时间更为重要。在长文本转录任务中，实时性往往起决定性作用。对于图像生成，减少去噪步骤可能比降低内核延迟更有效；至于视频处理，注意力机制和庞大的张量可能会占据全部计算资源。

视觉语言模型将图片转换为标记

视觉语言模型是将视觉编码器与语言模型相结合。编码器负责将像素转换为语言模型能够与文本一同处理的表示形式：

Image / Video
      │
      ▼
Vision Encoder
      │
      ▼
Visual Tokens
      │
      ▼
Language Model
      │
      ▼
Text Response

有趣的是，图像会延长输入序列的长度。一张高分辨率图像就能产生大约一千个视觉标记。视觉细节越多，产生的标记就越多，进而带来更多的上下文信息以及更大的KV缓存空间。

因此，调整VLM的方法与调整长上下文LLM非常相似。可以考虑使用量化后的KV缓存、推测性解码、前缀缓存、张量并行处理、将缓存任务卸载到其他设备，或是将预填充操作与解码操作分开处理。对于重复出现的图像和多轮对话而言，前缀复用尤其有效；而随着输入长度的增加，内存管理的重要性也会日益凸显。

视频理解的成本会迅速上升

图片本身就需要一定的成本，而视频则会让这一成本成倍增加。以每秒24帧的速度计算，哪怕是短暂的片段也会产生大量的视觉标记。一个四秒的高清视频，在进行实际降采样之前，其输入标记数量理论上可能接近10万。

这就意味着在处理速度与质量之间，降采样成了关键的权衡因素。你可以降低分辨率、帧率、帧数或视觉标记数量，但每做一次削减都会丢失部分信息。因此，不必纠结于如何加快视频推理的速度，而应思考：在仍能满足应用质量要求的前提下，最小的视觉表示形式是什么？这才是真正的推理工程思维：调整工作负载，而不仅仅是内核参数。

多模态模型并非总是最佳解决方案

行业正朝着能够同时接收和输出多种模态数据的模型发展：

Text ─────┐
Image ────┤
Audio ────┼──► Omni Model ──► Text / Audio / Image
Video ────┘

那听起来很理想，但通用性总有代价。专用的OCR模型能超越大型VLM内置的OCR功能，而专为语音设计的模型则比通用的多模态模型运行效率更高。因此，生产系统往往由各领域的专业工具组成流程链：

┌──► OCR
PDF/Image ───┤
             ├──► Vision Model
             └──► Embedding Model
                       │
                       ▼
                     LLM

接下来的工程原则是让每个组件都能独立优化和扩展。

嵌入模型追求处理效率

嵌入模型与生成型大语言模型有本质区别。它们会将内容转换为固定大小的向量：

Document / Image
       ↓
Embedding Model
       ↓
[0.12, -0.43, 0.87, ...]

这些向量驱动着RAG、语义搜索、推荐系统、智能体记忆以及文档检索功能。最重要的是工作负载的形态，而两种形态看起来差异很大。

批量嵌入就是其中一种形式，例如将一千万份文档导入向量数据库：

10 million documents
       ↓
Embedding pipeline
       ↓
Vector database

在那种情况下，吞吐量和成本更为重要。另一种则是在线检索，即用户的查询会被立即嵌入并开始搜索：

User query
    ↓
Embedding
    ↓
Vector search

在这里，毫秒级的时间差至关重要。当两者规模都足够大时，分开部署往往更具优势，因为每种部署都可以针对自身目标进行优化。

维度与兼容性

嵌入技术又增加了一个质量与速度之间的权衡因素：向量大小。向量可以存储数百甚至数千个数值。更大的向量能保留更多信息，但也会增加存储、检索以及相似度计算的成本。一些现代嵌入方法支持可变的有效维度，正是出于这种权衡而设计的。

还有一个常见的误解：长度相同的两个向量并不具备自动可比性，因为每个嵌入模型都会构建属于自己的语义空间。更换模型并不等同于用另一个API替换当前API，通常需要围绕新模型重新设计检索系统。

批量处理是嵌入技术的核心手段

与自回归解码不同，嵌入模型主要以并行方式处理标记，这改变了相应的策略。前缀缓存以及预填充/解码分离在此并不重要。重点应放在大批量处理、快速标记化、队列管理、水平扩展、优化过的内核以及量化技术上。嵌入模型能够处理比生成模型大得多的批量数据，有时甚至可以同时处理数十个或数百个输入。

合理的生产环境架构会在多个副本之前设置队列和批量管理器：

Requests
   ↓
Queue
   ↓
Batch Manager
   ↓
GPU Replica 1
GPU Replica 2
GPU Replica 3
GPU Replica 4

对于大规模嵌入任务，每个水平扩展的副本配备一台 GPU，通常比复杂的多 GPU 模型并行架构更有效。

语音识别：解码器起主导作用

ASR 负责将音频转换为文本。典型的处理流程包括预处理、编码器以及解码器：

Audio
  ↓
Audio preprocessing
  ↓
Encoder
  ↓
Autoregressive Decoder
  ↓
Transcript

ASR并非大型语言模型，但其解码器的作用类似大型语言模型，且占据了大部分推理时间。正因如此，采用大型语言模型式的优化方法尤为有效。对于实时转录而言，单纯的吞吐量并非核心目标，系统需要具备即时响应的特性，合理的指标是每段实时音频的往返延迟在200毫秒左右。

流式处理提升了体验

ASR性能提升中最显著的效果之一无需对模型进行任何修改，只需调整服务架构即可实现。无需采用上传、等待然后接收数据的模式：

Upload audio
      ↓
Wait
      ↓
Receive transcript

切换为连续流模式：

Continuous Audio
       ↓
     VAD
       ↓
Audio Chunks
       ↓
    ASR GPU
       ↓
Streaming Transcript

WebSocket 保持数据流持续开放，同时语音活动检测模型会筛选出包含有效音频的片段。这说明推理性能并不总是运行时的问题，有时流程协调才能带来最大优势。

长时长录音需要并行处理

长文件与交互式听写截然不同，不能按顺序逐一处理：

Chunk 1 → Chunk 2 → Chunk 3 → Chunk 4

你可以构建一个并行流水线：

┌──► GPU 1 ──► Chunk 1
Audio → VAD ─────┼──► GPU 2 ──► Chunk 2
                 ├──► GPU 3 ──► Chunk 3
                 └──► GPU 4 ──► Chunk 4
                              ↓
                         Stitch by time

虽然会失去一些顺序上下文的复用能力，但能大幅提升处理效率。对于长文本转录而言，实时性是一个重要的衡量指标，而并行分块处理则适合高吞吐量的任务。为保证质量，可添加后期处理机制，识别出异常重复的内容并仅重新处理有问题的部分。

TTS：目标并非每秒处理更多令牌

文本转语音的处理方向与自动语音识别相反：

Text
 ↓
TTS Model
 ↓
Audio Tokens
 ↓
Audio Decoder
 ↓
Waveform

现代文本转语音模型通常采用类似大型语言模型的架构，因此从大型语言模型服务中借鉴了优化后的内核、批量处理以及低精度推理技术。不过，评估指标存在细微差别：如果音频解码器仅需近似实时的输出，那么每秒生成500个音频符号并不比生成100个更好。一旦生成速度能达到实时水平，问题就转变为单个GPU能够支持多少并发用户。这其实是根据产品需求进行优化，而非追求基准测试数值。

图像生成：摒弃大型语言模型的思维模式

图像生成工具主要是迭代式去噪工具，而非逐个符号生成的工具：

Noise
 ↓
Denoising Step 1
 ↓
Denoising Step 2
 ↓
...
 ↓
Image

与LLM解码不同，这类任务通常受计算能力限制，因此内存带宽不再是主要瓶颈。相应的优化策略转向内核选择、内核融合、高效注意力机制、GEMM运算调优、Torch编译优化、降低精度以及减少去噪处理。

内核至关重要

在图像生成中，注意力机制相关的内核尤为重要。根据GPU架构和实现方式，可以选择诸如FlashAttention、DeepGEMM、CuTe和CUTLASS等优化过的方案。像RMSNorm这样的归一化操作也是很好的融合候选对象。

更重要的启示是，最佳的推理引擎取决于工作负载和硬件条件。PyTorch具备灵活性，专门的实现会提供经过优化的内核，而编译过程还能将各种操作整合为针对GPU的特定路径。唯有在真实的硬件上对实际模型进行基准测试，才能找到最佳方案。

扩散模型的有效技巧

扩散模型需要执行大量步骤：前期的步骤负责构建整体结构，后期的步骤则用于细化细节。这便出现了一个机会——可以减少后期成本较高的引导操作。有一种方法是在不改变步骤总数的前提下，跳过流程后期的无分类器引导环节。在50步的示例中，模型的失败率可从100降至80，同时质量基本保持不变。

具体的技巧不如原则重要。并非每次迭代对最终结果的影响都相同，推理优化可以利用这种不平衡性。

视频生成是另一个维度

视频生成是在图像生成的基础上增加了时间维度。其中，图像的潜在表示为：

Height × Width

视频潜在内容变为：

Height × Width × Time

这使得计算问题变得更为复杂。视频处理受计算能力限制，系统往往需要占用整个多GPU节点，即便批量大小很小，甚至仅为1个样本，因为所有GPU都需要协同处理同一个视频片段。

这与文本生成有明显区别。在文本处理中，更大的批量可以提高处理效率；而在视频处理中，批量优化作用有限，因为单次生成就已经消耗了大部分计算资源。因此，降低视频处理成本的最快方法通常是使用更高效的模型。

注意力机制在视频处理中起主导作用

在视频生成过程中，注意力机制会占用大量计算资源，在某些任务中这一比例甚至高达70%到80%。这就改变了优化重点——工程师们不再主要关注权重量化，而是致力于注意力核的优化、注意力机制的量化、缓存技术、上下文并行处理以及GPU级别的并行执行。

视频的缓存机制有所不同

视频生成并不采用自回归KV缓存方法。相反，系统通过两种主要方式重用早期计算的结果。时间步缓存会重用选定的去噪步骤产生的输出；Transformer缓存则会重用隐藏状态，并跳过Transformer中某些部分的计算。这两种方法都能显著提升速度，但根据所使用的算法不同，也可能会严重降低质量。因此应将每一项优化都视为一个循环过程来处理：

Optimization
     ↓
Speed ↑
     ↓
Quality ?
     ↓
Evaluate
     ↓
Production

切勿仅因为视频看起来仍然正常就认为缓存优化是安全的。

量化需针对瓶颈

对于大语言模型而言，量化通常针对大型线性层和权重，因为其推理过程往往受内存带宽限制。而视频生成则受计算能力制约，尤其是注意力机制，因此注意力本身就成了一个值得量化的目标。不过注意力机制对数值误差也极为敏感。

有两种选择：可以使用 MXFP8 等微缩格式按块进行量化，或者有选择地量化，并逐步骤调整精度：

Early steps   → FP16
Middle steps  → Lower precision
Late steps    → Lower precision

或按层次划分：

Input layer   → FP16
Hidden layers → Lower precision
Output layer  → FP16

在模型表现脆弱的地方保持精确度，在表现良好的地方则进行优化。

不存在通用的优化方法

在不同类型的任务中，有效的策略截然不同：

| Modality         | Dominant Concern            | High-Value Techniques                                 |
| ---------------- | --------------------------- | ----------------------------------------------------- |
| VLM              | Long visual context         | KV optimization, caching, parallelism                 |
| Embeddings       | High request volume         | Batching, queueing, horizontal scaling                |
| ASR              | Decoder latency             | Optimized decoder, streaming, parallel chunks         |
| TTS              | Real-time concurrency       | Streaming, batching, efficient decoding               |
| Image generation | Compute                     | Kernel fusion, compilation, fewer expensive passes    |
| Video generation | Massive compute + attention | Attention kernels, caching, quantization, parallelism |

正因如此，推理工程更接近系统开发工作，而非仅仅加快大型语言模型的运行速度。

要点总结

  1. 多模态推理取决于具体工作负载。最优架构需遵循执行模式与产品需求。
  2. 自回归模型与扩散模型的瓶颈存在本质差异。
  3. 视觉语言模型会将视觉输入转换为额外上下文，因此KV缓存与长上下文优化更为重要。
  4. 嵌入系统主要面临批量处理和吞吐量问题，而非解码延迟问题。
  5. 语音识别技术的提升主要来自任务调度与流式处理，而不仅仅是更快的内核。
  6. 对于文本转语音技术，一旦生成速度超过实时处理能力，优化重点就转变为并发用户数量。
  7. 图像生成受计算资源限制，因此内核设计、数据融合、编译优化以及降噪步骤的减少至关重要。
  • 视频生成将这一切进一步推向极致，需要处理庞大的注意力计算任务，并依赖多GPU来执行。
  • 缓存机制因数据类型而异：KV缓存用于驱动自回归生成，而扩散模型则通过其他方式重用计算资源。
  • 在瓶颈所在处进行量化处理。对于受内存限制的大型语言模型，权重优化更为重要；而对于计算资源受限的视频生成，注意力机制则可能更具关键性。

    • 未来的发展方向

    人工智能产品正逐渐默认具备多模态能力。文本、图像、音频、视频以及嵌入向量越来越多地被整合到同一应用中，因此工作重点也从调整单个模型转变为优化整个处理流程。现在需要思考的问题不再是该使用哪种优化技术，而是特定任务中的瓶颈所在，以及可以采取何种权衡措施来消除该瓶颈。

    从使用单个 GPU 运行嵌入模型的场景，到多 GPU 集群生成实时视频的场景，这种思维方式都适用。需先了解工作负载，找出瓶颈，测试自己愿意承受的权衡，进而调整整个系统而非仅优化模型本身。

    全部文章发送简报