推理变慢，未必是算力不足。模型精度、请求长度、并发量和显存占用都会影响AI服务器的响应时间与吞吐量。优化时应先确定目标：交互应用通常关注首字延迟和单请求响应，离线生成则更看重单位时间处理量。以下六项方法可以分开验证，再组合使用。
先建立可比较的基线
选取一组贴近实际的请求，固定模型版本、输入长度、输出上限和并发数，记录首字延迟、每秒生成词元数、总吞吐及显存使用。至少测试短输入与长输入、低并发与目标并发。更换优化项后沿用同一组条件，才能判断AI服务器是否真正变快，而非只是测试负载变轻。
六项优化：从模型到并行方式
1. 量化：以精度换显存和计算效率
量化把权重从较高精度表示转换为较低精度，例如FP16转INT8或4位格式。它可能减少显存占用，并在硬件和推理软件支持时提升速度；代价是输出质量可能下降，且低比特格式不一定在所有设备上更快。先用一小批代表性提示词比较原模型与量化模型的答案、任务指标和吞吐，再决定是否扩大部署。对代码、数学等敏感任务，应单独检查错误率。
2. 连续批处理：让请求动态共享计算
连续批处理（continuous batching）会在已有请求完成或新请求到达时动态调整批次。它适合请求持续到达、输出长度不一的服务；相较固定批次，通常能减少等待空档、提升整体吞吐，但调度策略也会影响单个请求延迟。可在vLLM等支持此类调度的运行时中，逐步提高并发上限，并同时观察排队时间和首字延迟，避免吞吐上升却让用户等待过久。
3. KV缓存：减少生成阶段的重复计算
自回归模型逐词元生成时，会缓存此前注意力计算所需的键和值，这就是KV缓存。缓存可避免每一步重新处理全部历史内容，但会随并发请求和上下文长度增长而占用显存。长对话场景可限制最大上下文、设置合理的并发上限，并启用运行时支持的分页或缓存管理机制。若长请求增多后显存先耗尽，优先排查缓存容量，而不只是增加计算卡。
4. 张量并行：把单层计算拆到多张卡
张量并行（tensor parallel）将模型层中的矩阵计算分到多张加速卡，适合单卡放不下模型或单卡计算成为瓶颈的情况。它可能缩短单请求计算时间，但卡间通信会带来开销；模型较小、设备互联较慢或请求批次很小时，收益可能有限。部署前确认推理框架支持目标模型和设备组合，并比较单卡与多卡的延迟及吞吐，而非仅看总算力。
5. 流水线并行：按层分段放置模型
流水线并行（pipeline parallel）把不同模型层放在不同设备上，适用于模型层数较多、单设备显存不足的部署。它能分摊权重占用，但单个请求要依次经过各段，分段不均或批次太小会让部分设备空等。与张量并行相比，它减少了层内拆分需求，却不保证降低单请求延迟。应先按层数和显存大致均分，再用实际请求检查各段利用率与等待时间。
6. 数据并行：复制模型以承接更多请求
数据并行是在多张卡或多组设备上部署模型副本，由服务端把请求分派给不同副本。它主要提升并发承载与总吞吐，通常不能直接缩短单个请求的生成时间；每个副本还需要各自存放模型权重。若模型能放入单卡、瓶颈是同时到来的请求，可先增加副本并观察排队变化；若模型本身放不下，则应考虑张量或流水线并行。
如何组合与验证
- 先确认瓶颈：显存紧张先评估量化与KV缓存；排队过长则测试连续批处理或数据并行。
- 模型无法放入单卡时，比较张量并行和流水线并行，并核对设备互联、框架支持及切分开销。
- 每次只改一个主要设置，使用同一模型、请求集和并发条件复测；分别记录延迟、吞吐、显存和输出质量。
- 在接近预期业务负载的条件下复测。若某项优化提高吞吐却突破延迟或质量要求，就降低并发、调整精度或撤回该项。
不存在适用于所有负载的唯一配置。对AI服务器而言，量化解决的主要是精度与资源取舍，并行方式解决的是模型拆分或请求扩展；最终选择应由真实请求的延迟、吞吐、显存和质量共同决定。
常见问题
量化后一定会更快吗？
不一定。速度取决于设备对相应精度的支持、推理软件和负载，需用目标模型实测。
张量并行和数据并行能互相替代吗？
不能完全替代。前者拆分单个模型的计算，后者复制模型以处理更多请求，适用瓶颈不同。
KV缓存能否减少模型权重占用？
不能。它缓存生成过程中的中间状态；权重与缓存是不同的显存用途。
应该优先优化延迟还是吞吐？
交互服务通常先设定可接受的响应时间，再提升该约束下的吞吐；批量任务则可优先考察总处理量。
