> ## Documentation Index
> Fetch the complete documentation index at: https://dingguoliang.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# LLM 性能技巧：延迟与吞吐优化

> 降低 LLM 应用延迟、提升吞吐：异步调用、缓存、提示压缩与推理优化。

LLM 应用的性能画像和普通后端不一样——瓶颈几乎总是推理延迟，不是数据库或磁盘。常规优化（索引、CDN）往往不痛不痒。更有效的心智模型是：少调模型、调得更快、用流式把等待藏起来。

<Note>
  投入顺序通常是：**异步 → 缓存 → 模型路由 → 提示压缩 → 推理调参**。前两项高收益、低风险。
</Note>

## 先测量

关注 TTFT（首 Token）、总生成时间、检索延迟、端到端墙钟。用 LangSmith / OpenTelemetry，或开发期简单 timing。

## 全面异步

LLM 调用本质是等 I/O。用 `ainvoke` / `astream`；彼此独立的检索、历史、画像用 `asyncio.gather` 并行，常能把串行几百毫秒压成「最慢那一个」。

## 语义缓存

按字面缓存命中率低——用户说法多变。按查询向量近邻缓存（阈值约 0.95）更有效，FAQ/客服类命中 30–50% 并不罕见。

## 提示压缩

长提示又贵又慢。检索上下文往往是大头。可用 LLMLingua 一类压缩；或重排只留 3–5 块、只抽相关句、文档级摘要代替全文切块。

## 按复杂度路由模型

分类、事实查询别一律上最强模型。小模型先判 simple/complex，再选模型，成本差可以到一个数量级。

## 流式改善体感

3 秒干等和 300ms 开始出字，体感完全不同。优化首 Token；骨架屏；多步骤时把「正在检索…」也推给用户。

## 自托管 vLLM 调参

关键旋钮：`--max-num-seqs`、`--gpu-memory-utilization`、AWQ 量化、大模型再考虑 tensor parallel。小模型有时多实例负载均衡比硬拆并行更划算。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.