提升 AI 推理：高级技术和最佳实践

当谈到实时 AI 驱动的应用，如自动驾驶汽车或医疗监测时，即使多一秒的处理时间也可能带来严重的后果。实时 AI 应用需要可靠的 GPU 和处理能力，这在过去对于许多应用来说非常昂贵和耗费资源——直到现在。

通过采用优化的推理过程，企业不仅可以最大化 AI 效率，还可以降低能耗和运营成本（最高可达 90%）；增强隐私和安全性；甚至可以提高客户满意度。

常见推理问题

企业在管理 AI 效率时面临的一些最常见的问题包括 GPU 集群利用率低、默认使用通用模型以及缺乏对相关成本的洞察。

团队经常为峰值负载预配 GPU 集群，但由于工作流不均匀，70% 至 80% 的时间里，GPU 集群都处于未充分利用的状态。

此外，团队默认使用大型通用模型（GPT-4、Claude），即使对于可以在较小、较便宜的开源模型上运行的任务也是如此。原因是缺乏构建自定义模型的知识和陡峭的学习曲线。

最后，工程师通常缺乏对每个请求的实时成本的洞察，这导致了巨大的账单。像 PromptLayer 和 Helicone 这样的工具可以提供这种洞察。

由于缺乏对模型选择、批处理和利用率的控制，推理成本可能会指数级增加（最高可达 10 倍），浪费资源，限制准确性，并降低用户体验。

能耗和运营成本

运行像 GPT-4、Llama 3 70B 或 Mixtral-8x7B 这样的较大 LLM 需要显著更多的电力每个令牌。平均而言，数据中心使用的 40% 至 50% 的能量用于为计算设备供电，另外 30% 至 40% 用于冷却设备。

因此，对于一家公司来说，考虑使用本地提供商而不是云提供商来避免高昂的成本和 能耗是更有益的。

隐私和安全

根据思科的2025 年数据隐私基准研究，64% 的受访者担心无意中公开分享敏感信息或与竞争对手分享，而近半数受访者承认将个人员工或非公开数据输入到 GenAI 工具中。这增加了如果数据未被正确记录或缓存而导致的不合规风险。

另一个风险是跨不同客户组织在共享基础设施上运行模型，这可能导致数据泄露和性能问题，并且存在一个用户的行为影响其他用户的风险。因此，企业通常更喜欢在其云中部署服务。

客户满意度

当响应需要超过几秒钟时，用户通常会放弃，支持工程师为零延迟进行优化。另外，应用程序存在“障碍，如幻觉和不准确性，这可能会限制广泛的影响和采用”，根据Gartner新闻稿所述。

管理这些问题的商业利益

优化批处理、选择合适的模型（例如，从 Llama 70B 或封闭源模型如 GPT 切换到 Gemma 2B）和改善 GPU 利用率可以将推理账单减少 60% 至 80%。使用像 vLLM 这样的工具可以帮助实现这一目标，如同切换到无服务器的按需付费模型一样，对于间歇性工作流来说是有益的。

以 Cleanlab 为例。Cleanlab 推出了可信赖语言模型（TLM）以为每个 LLM 响应添加可信赖度评分。它旨在提供高质量的输出和增强的可靠性，这对于企业应用至关重要，以防止未经检查的幻觉。在 Inferless 之前，Cleanlabs 遇到了增加的 GPU 成本，因为 GPU 即使在未积极使用时也会运行。他们的问题对于传统云 GPU 提供商来说是典型的：高延迟、成本管理效率低下以及管理复杂的环境。通过使用无服务器推理，他们将成本降低了 90%，同时保持了性能水平。更重要的是，他们在两周内上线，没有任何额外的工程开支。

优化模型架构

基础模型，如 GPT 和 Claude，通常是为通用性而训练的，而不是为效率或特定任务而训练的。通过不自定义开源模型以适应特定用例，企业会浪费内存和计算时间用于不需要这种规模的任务。

像 H100 这样的新 GPU 芯片速度快、效率高。这些对于运行大规模操作（如视频生成或 AI 相关任务）尤为重要。更多的 CUDA 核心可以提高处理速度，超越较小的 GPU；NVIDIA 的张量核心旨在加速这些任务。

GPU 内存在优化模型架构方面也很重要，因为大型 AI 模型需要大量空间。这种额外的内存使 GPU 能够在不损害速度的情况下运行更大的模型。相反，较小的 GPU 内存较少，性能会因将数据移至较慢的系统 RAM 而受损。

优化模型架构的几大好处包括节省时间和金钱。首先，切换到 LoRA 优化或 FlashAttention 基础的变体可以将每个查询的响应时间缩短 200-400 毫秒，这在聊天机器人和游戏等应用中至关重要。另外，量化模型（如 4 位或 8 位）需要的 VRAM 较少，在较便宜的 GPU 上运行速度更快。

长期来看，优化模型架构可以节省推理成本，因为优化后的模型可以在较小的芯片上运行。

优化模型架构包括以下步骤：

• 量化—减少精度（FP32 → INT4/INT8），节省内存并加快计算时间
• 剪枝—移除不太有用的权重或层（结构化或非结构化）
• 蒸馏—训练一个较小的“学生”模型来模仿较大模型的输出

压缩模型大小

较小的模型意味着推理速度更快、基础设施费用更低。较大的模型（13B+、70B+）需要昂贵的 GPU（A100、H100）、高 VRAM 和更多电力。压缩这些模型使其能够在较便宜的硬件上运行，如 A10 或 T4，延迟也更低。

压缩模型对于在设备（手机、浏览器、IoT）上运行推理也至关重要，因为较小的模型可以在不扩大基础设施的情况下服务更多的并发请求。在一个有超过 1,000 名并发用户的聊天机器人中，从 13B 到 7B 压缩模型使团队能够在不出现延迟峰值的情况下每个 GPU 服务两倍以上的用户。

利用专用硬件

通用 CPU 不适合张量操作。像 NVIDIA A100、H100、Google TPUs 或 AWS Inferentia 这样的专用硬件可以为大型 LLM 提供更快的推理（快 10-100 倍）和更好的能效。即使将每个请求的延迟缩短 100 毫秒也会带来显著的差异，当每天处理数百万个请求时尤其如此。

考虑这个假设例子：

一个团队正在标准 A10 GPU 上运行 LLaMA-13B 用于其内部 RAG 系统。延迟约为 1.9 秒，由于 VRAM 限制，他们无法批量处理太多内容。因此，他们切换到 H100，启用 TensorRT-LLM、FP8 和优化的注意力内核，并将批大小从 8 增加到 64。结果是将延迟降低到 400 毫秒，并将吞吐量提高了五倍。
因此，他们能够在相同的预算下服务五倍的请求，并让工程师摆脱基础设施瓶颈的困扰。

评估部署选项

不同的过程需要不同的基础设施；一个聊天机器人有 10 个用户，而一个每天服务数百万个查询的搜索引擎有不同的需求。全部投入云（例如 AWS Sagemaker）或 DIY GPU 服务器而不评估成本表现比率会导致浪费的支出和糟糕的用户体验。注意，如果您过早地提交给一个封闭的云提供商，稍后迁移解决方案将会很痛苦。然而，早期评估采用按需付费结构可以在未来提供选择。

评估包括以下步骤：

• 跨平台基准模型延迟和成本：在 AWS、Azure、本地 GPU 集群或无服务器工具上运行 A/B 测试以复制。
• 衡量冷启动性能：这对于无服务器或事件驱动的工作负载尤为重要，因为模型加载速度更快。
• 评估可观察性和扩展限制：评估可用的指标并确定每秒查询的最大值，然后性能会恶化。
• 检查合规支持：确定是否可以强制执行地理边界数据规则或审计日志。
• 估计所有权总成本。这应该包括 GPU 小时、存储、带宽和团队的开销。

结论

推理使企业能够优化其 AI 性能，降低能耗和成本，保持隐私和安全，并让客户满意。可以强制执行地理边界数据规则或审计日志。估计所有权总成本。这应该包括 GPU 小时、存储、带宽和团队的开销。