新媒网 · 跨境数据社区

各位做跨境的朋友们，今天咱们要聊的这个话题，对于追求技术前沿、希望在本地AI应用上跑出极致性能的开发者来说，绝对是个重磅好消息。新媒网跨境了解到，微软公司今天正式向全球开发者开放了Windows ML，这可是咱们在PC端实现高效AI模型部署和运行的利器！

简单来说，Windows ML能让C#、C++和Python的开发者们，轻松地将AI模型高效地运行在PC的各种硬件上，无论是CPU、NPU还是GPU，都能得到最佳优化。特别是在英伟达的RTX系列GPU上，它更是直接集成了NVIDIA TensorRT for RTX执行提供程序（EP），充分利用GPU的Tensor Cores以及FP8和FP4等先进架构，让AI推理速度在基于Windows的RTX AI PC上达到最快。

用一句官方的话来说，美国微软公司平台的资深工程师Logan Iyer（洛根·艾尔）先生就明确指出：“Windows ML全面解锁了GeForce RTX和RTX Pro系列GPU的TensorRT加速能力，为Windows 11带来了卓越的AI性能。” 他还表示，他们很高兴这项技术能普遍提供给开发者，帮助大家大规模构建和部署强大的AI体验。

咱们深入一点，看看Windows ML到底是怎么工作的。它的核心是基于ONNX Runtime的推理API。它扩展了ONNX Runtime API的功能，可以处理PC上CPU、NPU和GPU等不同硬件之间执行提供程序的动态初始化和依赖管理。更棒的是，Windows ML还能按需自动下载所需的执行提供程序，大大减轻了应用开发者为多个不同硬件厂商管理依赖和软件包的负担，让大家能够更专注于核心业务逻辑的开发。

图1. Windows ML堆栈图

那这个英伟达的TensorRT for RTX执行提供程序（EP），究竟能给我们带来什么实实在在的好处呢？

首先，它能让ONNX模型实现低延迟推理，相比之前在英伟达RTX GPU上使用DirectML的实现，吞吐量能提升50%以上，这可不是小数字，是实打实的效率飞跃啊。从图2的性能对比柱状图就能看出来，搭载英伟达RTX 5090 GPU的设备，在Windows ML上，多个模型在推理吞吐量上都有显著提升。

图2. Windows ML与Direct ML在多种模型上的生成吞吐量加速。数据在NVIDIA RTX 5090 GPU上测量。

其次，它通过灵活的EP架构与ONNX Runtime（ORT）的集成，直接与Windows ML无缝对接。另外，它支持即时编译（Just-in-time compilation），这对于最终用户设备的部署来说，简直是福音，能大大简化流程。这个编译过程在ONNX Runtime中是以EP上下文模型的形式来支持的。

再者，它充分利用了Tensor Cores上的FP8和FP4等先进架构，这可是英伟达硬件的独家优势，能让AI运算效率更高。而且，它的安装包非常轻量，体积不到200 MB，这对于本地部署来说非常友好。最重要的是，它支持多种模型架构，无论是大型语言模型（LLMs，通过ONNX Runtime GenAI SDK扩展）、扩散模型、卷积神经网络（CNN）等等，都能得到很好的支持。

新媒网跨境认为，这些深度优化功能，对于希望在本地AI应用上实现突破的开发者来说，无疑提供了强大的助推力。

如何选择执行提供程序，让AI模型跑得更快

接下来，咱们聊聊如何选择合适的执行提供程序（Execution Provider）。这是确保AI模型跑在最佳硬件上的关键一步。ONNX Runtime 1.23.0版本，也就是Windows ML中包含的这个版本，提供了与供应商和执行提供程序无关的API，用于设备选择。这极大地减少了利用每个硬件供应商平台最佳执行提供程序所需的应用程序逻辑。

大家可以参考下面这段代码示例，无论是C++还是Python，操作起来都非常直观，能有效地在英伟达GPU上获得最大性能。

C++示例：

// 注册各种供应商所需的执行提供程序库
auto env = Ort::Env(ORT_LOGGING_LEVEL_WARNING);
env.RegisterExecutionProviderLibrary("nv_tensorrt_rtx", L"onnxruntime_providers_nv_tensorrt_rtx.dll");

// 选项1：依赖ONNX Runtime执行策略
Ort::SessionOptions sessions_options;
sessions_options.SetEpSelectionPolicy(OrtExecutionProviderDevicePolicy_PREFER_GPU);

// 选项2：遍历EpDevices以执行手动设备选择
std::vector<Ort::ConstEpDevice> ep_devices = env.GetEpDevices();
std::vector<Ort::ConstEpDevice> selected_devices = select_ep_devices(ep_devices);

Ort::SessionOptions session_options;
Ort::KeyValuePairs ep_options;
session_options.AppendExecutionProvider_V2(env, selected_devices, ep_options);

Python示例：

# 注册各种供应商所需的执行提供程序库
ort.register_execution_provider_library("NvTensorRTRTXExecutionProvider", "onnxruntime_providers_nv_tensorrt_rtx.dll")

# 选项1：依赖ONNX Runtime执行策略
session_options = ort.SessionOptions()
session_options.set_provider_selection_policy(ort.OrtExecutionProviderDevicePolicy.PREFER_GPU)

# 选项2：遍历EpDevices以执行手动设备选择
ep_devices = ort.get_ep_devices()
ep_device = select_ep_devices(ep_devices)

provider_options = {}
sess_options.add_provider_for_devices([ep_device], provider_options)

预编译运行时，让模型加载快如闪电

模型加载速度慢，是很多开发者头疼的问题，尤其是在用户体验上，一秒钟的等待都可能影响转化。但现在，有了预编译运行时，这个问题就迎刃而解了。通过ONNX Runtime中的EP上下文ONNX文件，模型运行时可以进行预编译。每个执行提供程序都可以利用这个功能来优化ONNX模型的整个子图，并提供特定于EP的实现。这个过程可以序列化到磁盘，从而在Windows ML中实现快速加载，这通常比之前DirectML中传统的基于操作符的方法要快得多。

下面的图表（图3）显示，TensorRT for RTX EP虽然需要一些编译时间，但由于优化已经序列化，它在模型加载和推理时速度会更快。此外，TensorRT for RTX EP中的运行时缓存功能确保了在编译阶段生成的内核被序列化并存储到一个目录中，这样就不必为后续的推理再次编译。

图3. DeepSeek-R1-Distill-Qwen-7B模型运行时的不同加载时间，包括ONNX模型、EP上下文文件以及EP上下文和运行时缓存。时间越短越好。

ONNX Runtime设备API与Windows ML：最小化数据传输开销

数据传输的开销，往往是隐藏的性能杀手。但在Windows ML和ONNX Runtime设备API的加持下，这个问题也得到了极大改善。这个新的ONNX Runtime设备API，同样在Windows ML中可用，可以枚举每个执行提供程序可用的设备。借助这个新概念，开发者现在可以直接分配设备专属的张量，而无需额外的EP依赖类型规范。通过利用CopyTensors和IOBinding，这个API能够让开发者以最小的运行时数据传输开销，执行与EP无关的GPU加速推理，从而显著提升性能并简化代码设计。

图4展示了Stable Diffusion 3.5 Medium模型在有无设备IO绑定时的性能对比。在AMD Ryzen 7 7800X3D CPU搭配RTX 5090 GPU的配置下，有了IO绑定，单次迭代的时间显著降低。时间越短，效率越高，这才是我们追求的！

图4. Stable Diffusion 3.5 Medium模型在AMD Ryzen 7 7800X3D CPU + RTX 5090 GPU（通过PCI 5连接）上，有无设备绑定时的运行情况。时间越短越好。

为了让大家看得更清楚，咱们用Nsight系统工具做了可视化分析。如果不用IO绑定，每次推理前，输入数据都要从主机（CPU）拷贝到设备（GPU），推理完输出又要从设备拷贝回主机，这个反复拷贝的过程，就是性能的瓶颈。在我们的分析中，输入张量的拷贝操作被标记为绿色，而设备到主机的输出拷贝也花费了大约相同的时间。此外，ONNX Runtime默认使用可分页内存，这使得设备到主机的拷贝隐式地成为了一个同步操作，尽管ONNX Runtime使用了cudaMemCpyAsync API。

图5. Nsight Systems时间线，显示了额外同步PCI流量造成的开销。

另一方面，当输入和输出张量进行IO绑定后，主机到设备的输入拷贝仅在多模型推理管道之前发生一次。同样地，设备到主机的输出拷贝也只发生一次，之后我们再将CPU与GPU同步。上面这张异步的Nsight追踪图描绘了循环中的多次推理运行，期间没有任何拷贝操作或同步操作，甚至还释放了CPU资源。这样一来，设备拷贝时间仅为4.2毫秒，一次性主机拷贝时间为1.3毫秒，总拷贝时间为5.5毫秒，无论推理循环的迭代次数是多少。举例来说，对于一个30次迭代的循环，这种方法能将拷贝时间减少大约75倍！这对于需要高并发、低延迟的跨境AI应用来说，意味着巨大的性能提升。

TensorRT for RTX的独家优化：再榨性能！

除了上面这些通用优势，TensorRT for RTX还提供了一些独家优化，能让性能更上一层楼。这些可是咱们压榨硬件潜力，打造极致体验的“秘密武器”！

1. CUDA Graphs： 通过设置enable_cuda_graph来启用，它能够将TensorRT启动的所有CUDA内核捕获到一个图中，从而减少CPU上的启动开销。当TensorRT图启动许多小内核时，这一点尤为重要，因为这可以让GPU比CPU提交它们执行得更快。这种方法能为大型语言模型（LLMs）带来约30%的性能提升，并且对许多模型类型，包括传统AI模型和CNN架构都非常有用。
   
   图6. ONNX Runtime API中启用与禁用CUDA Graphs时的吞吐量加速对比。数据在NVIDIA RTX 5090 GPU上使用多个LLMs测量。

2. 运行时缓存（Runtime cache）： nv_runtime_cache_path指向一个目录，编译后的内核可以在其中缓存，结合使用EP上下文节点，实现快速加载。

3. 动态形状（Dynamic shapes）： 通过设置profile_{min|max|opt}_shapes这三个选项，或者使用AddFreeDimensionOverrideByName指定静态形状来覆盖已知的动态形状范围，从而固定模型的输入形状。目前，这项功能还在实验模式中，但潜力巨大。

总结与实战展望

总的来说，美国微软公司与英伟达公司的这次强强联手，为咱们Windows平台的AI应用开发者，带来了前所未有的性能提升机遇。Topaz Labs和万兴喵影（Wondershare Filmora）等知名Windows应用开发商，目前都在积极地将Windows ML和TensorRT for RTX EP集成到他们的应用程序中。这意味着，未来我们将会看到更多高性能、低延迟的AI应用出现在大家的电脑上，这对于做跨境生意，需要处理大量图片、视频内容，或者进行智能客服、数据分析的朋友们来说，无疑是巨大的福音。

如果你也想搭上这波AI性能优化的快车，不妨立刻行动起来，通过以下官方资源开始你的探索之旅：

• Windows ML 文档
• Windows ML 示例
• ONNX Runtime API 示例
• 构建针对ONNX Runtime GenAI和NVIDIA TensorRT for RTX优化的LLM模型
• ONNX Runtime API 文档
• TensorRT for RTX EP 文档

别忘了持续关注未来的改进和新API，官方示例会第一时间向大家展示。如果你在使用过程中有任何功能需求，也欢迎在GitHub上提出issue，大家共同进步！

风险前瞻与时效提醒

最后，作为一名实战导师，我必须提醒大家，技术迭代的速度飞快。今天我们讲的这些优化方案，虽然效果显著，但未来可能会有新的API、新的硬件架构出现。所以，持续学习、关注官方文档（比如上面列出的那些资源），并积极参与社区交流，是确保咱们技术栈不过时、规避潜在风险的关键。特别是对于跨境电商行业，效率就是生命，一旦错过最佳的技术窗口，可能就会被竞争对手甩开。同时，大家在使用过程中务必关注官方发布的最新兼容性、稳定性更新，确保应用的合规性与安全性。

新媒网（公号: 新媒网跨境发布），是一个专业的跨境电商、游戏、支付、贸易和广告社区平台，为百万跨境人传递最新的海外淘金精准资讯情报。

本文来源：新媒网 https://nmedialink.com/posts/winml-trt-ai-accelerate-50pct-throughput-75pct-load.html