Nvidia DLSS 5 浏览器演示摆脱 RTX 限制，但每次渲染需数秒

据报道，Nvidia 的 DLSS 5 浏览器演示已将一个 147MB 的神经模型移植至 WebGPU，尽管该功能官方上依赖 RTX 硬件和原生游戏集成。开发者 MAAN 表示，这项实验同样可在 macOS 和非 Nvidia GPU 上运行。但代价十分明显：在一次独立测试中，每张处理后的图像需要一到两秒才能完成渲染。

这一差距比其兼容性主张更能定义该项目。MAAN 并未将 DLSS 5 变成实用的浏览器游戏功能。该开发者似乎只是将 Nvidia 的神经渲染模型从该公司常规的驱动、SDK 与硬件路径中剥离出来。

因此，这项实验挑战的是 Nvidia 的受控部署模式，而不是其游戏性能优势。Nvidia 已在 RTX 50 系列系统和 GeForce NOW 的 NBA 2K27 中推出 DLSS 5。据报道，MAAN 的实现通过普通浏览器图形 API 暴露了同一视觉处理流程的一部分。

这是一项颇具吸引力的可移植性测试，但仍有重大问题未获解答。据称，其权重来自泄露的库；初步报道发布时，源代码尚未公开；其输出速度也依然不适用于游戏。现在的关键在于，独立审查能否验证该实现，并找到可接受每张图像耗时数秒的应用场景。

Nvidia DLSS 5 浏览器演示将神经渲染带离 Nvidia 官方路径

重要的变化并非 DLSS 5 突然能在浏览器中运行游戏，而是据称一个由 Nvidia 训练的渲染模型无需采用 Nvidia 已文档化的 DLSS 集成路径即可执行。

MAAN 于 2026 年 9 月 16 日发布了这一演示。根据最初的浏览器演示报道，该页面通过 Cloudflare Workers 运行，并以名为“Cowboy Gramps”的场景启动。它包含可调节控件、对比视图，并支持用户提供的 3D 模型。

开发者将该项目描述为使用 WebGPU 计算着色器对 DLSS 5 神经网络进行重新实现。WebGPU 是一种浏览器 API，可将现代图形和通用计算任务发送至设备 GPU。计算着色器是一种专为并行计算而设计的 GPU 程序，而非直接绘制三角形或像素。

这一区别至关重要。该页面似乎并非通过隐藏的浏览器桥接调用 Nvidia 常规的 DLSS 运行时。相反，据称它将神经模型的运算表达为兼容浏览器的 GPU 工作负载。

MAAN 表示，神经权重约占 147MB。压缩后的 JavaScript 运行时约增加 1MB。权重包含神经网络使用的已学习参数，而运行时则负责组织应用这些参数所需的计算。

这些数字使该项目对网页而言规模较大，但对于托管式交互实验仍足够小。完成初始下载后，浏览器便可通过 WebGPU 将任务发送至本地 GPU。Cloudflare 托管该应用，但现有报道显示，设备本身负责神经处理。

据报道，该演示可通过文件选择或拖放接收常见 3D 模型格式。这一功能使页面不只是固定视频或一组预先准备的截图。用户可以测试模型如何处理自己的资产，不过该项目的安全性和隐私行为仍需源代码级别的审查。

该界面还将普通模型移动与神经处理分开。在一台 RTX 40 系列台式机的一次测试中，旋转 3D 查看器仍保持流畅。对图像应用 DLSS 5 效果则需要一到两秒，尤其是在实时模式下。

这一耗时是准确描述该项目的核心。两秒渲染相当于每秒处理半帧。实时游戏通常每秒目标为数十帧，而每帧只能获得数毫秒的处理时间。

因此，该演示并非完整 NBA 2K27 体验的浏览器移植版。更恰当的理解是，它是神经组件的可移植执行测试。周边的游戏引擎、运动数据、延迟控制和帧生成管线则是独立问题。

MAAN 还表示，该页面可在 macOS 上运行。这一说法在 API 层面是可信的，因为 WebGPU 实现可将浏览器工作负载转换至 Apple 的 Metal 图形系统。但这并不证明它能在所有 Mac 和浏览器上实现同等速度、视觉质量或数值表现。

同样需要谨慎看待非 Nvidia GPU 的说法。WebGPU 的设计目标是跨越硬件厂商，但不同设备具备不同的限制和性能特征。能够运行工作负载，并不等同于能够高效运行。

不过，这一基本事件确实带来了现实张力。Nvidia 将 DLSS 5 定位为高度集成的 RTX 游戏功能。而 MAAN 报道中的实现则将其神经网络视作可在标准 Web 图形层上重建的可移植计算图。

为什么 WebGPU 改变了硬件边界

WebGPU 以通用浏览器层替代 Nvidia 的专有执行路径，以专门优化换取可移植性。

Nvidia 通常为游戏开发者提供两条成熟的 DLSS 接入路径：使用该公司的 NGX 集成，或采用位于游戏与其渲染 API 之间的 Streamline 框架。

Nvidia 将 Streamline 集成描述为面向多家硬件厂商图形技术的插件式层。开发者可为运动矢量和深度缓冲区等资源添加标签，再将所需功能置入渲染管线中。

这一路径让 Nvidia 对兼容性拥有相当大的控制权。驱动可识别受支持的硬件，插件可验证所需输入，公司也可更新模型行为。游戏开发者还会获得一份围绕成熟原生图形 API 建立的集成契约。

浏览器改变了这种安排的每一个部分。JavaScript 无法自由加载专有图形 DLL，也无法发出任意原生驱动调用。浏览器应用在沙箱中运行，访问须经由标准化接口进行。

WebGPU 提供了缺失的计算层。其着色语言 WGSL 允许应用定义由浏览器编译至底层系统的程序。当前的 WGSL 规范包含计算管线，可在并行 GPU 工作组之间处理缓冲区和图像。

从实际角度看，开发者可将神经网络运算转换为计算着色器。矩阵计算、卷积、采样过程和图像变换，随后便可在浏览器所暴露的任何兼容 GPU 上运行。

这种转换并不会保留 Nvidia 的整个软件栈。它以选定计算的新实现替代了原有栈。任何依赖 Tensor Cores、专有指令、驱动调度或 Nvidia 运行时的优化，都必须以不同方式复现，或被放弃。

这有助于解释速度差距。Nvidia 的官方版本运行在 RTX 50 系列硬件上，且驱动和应用均围绕该功能设计。MAAN 的版本据称则通过优先考虑兼容性的可移植浏览器抽象层执行。

Nvidia 表示，DLSS 5 使用 3D 引导神经渲染改善光照和材质表现。该功能并非仅放大低分辨率帧，而是利用场景信息改变表面、皮肤、头发、阴影和光线的呈现方式。

其首个官方展示重点突出篮球运动员。Nvidia 表示，该模型改善了穿过耳朵的次表面光线、面部毛发照明、皮肤材质和接触阴影。该公司的 DLSS 5 发布公告将这些效果置于 NBA 2K27 的原生渲染器中。

浏览器演示采用了更窄的使用场景。用户加载或选择模型，更改呈现控件，并等待神经处理结果。该工作负载不必以交互式帧率维持完整游戏模拟。

这种差异为非游戏用途创造了空间。产品设计师在预览单个资产时或许可以容忍短暂延迟。建筑师可能会在展示前处理一张静态视图。艺术家也可能无需安装受支持游戏，即可比较不同材质处理方案。

这些可能性仍属假设，而非经过验证的产品。现有测试并未证明其在专业资产上的准确性、可预测的渲染时间，或对大型场景的稳定支持。它仅说明了为何延迟要求决定这项实验是否具有价值。

WebGPU 也在扩大访问范围的同时，并未让每台机器都变得等同。GPU for the Web 项目在其兼容性指南中列出了不同的最低操作系统和硬件组合。浏览器可能提出更严格的要求，或禁用驱动不可靠的设备。

因此，“可在 macOS 上运行”不应被理解为“可在每一台 Mac 上运行”。浏览器版本、操作系统、GPU 世代、内存和功能限制都会影响执行结果。

同样的问题也存在于 Windows 和 Linux 上。兼容浏览器或许会在 AMD、Intel 或 Nvidia 硬件上暴露 WebGPU，但同一着色器可能会通过每家厂商编译器和驱动中的不同路径执行。

这就是提升抽象层级的代价。Nvidia 的官方路径提供一个狭窄但高度优化的目标；WebGPU 则提供一个更广泛的目标，对底层硬件作出更少假设。

可移植性挑战的是 Nvidia 的门槛，而非其性能

这场较量的核心是受控部署与可移植执行，而 Nvidia 仍拥有决定性的性能优势。

Nvidia 对 DLSS 5 的官方发布始于有限的硬件与软件组合。NBA 2K27 在 GeForce RTX 50 系列 PC 和笔记本电脑上支持该功能。GeForce NOW Ultimate 会员也可通过 Nvidia 运营的 RTX 5080 级云系统使用它。

该公司要求使用受支持的游戏、适当的驱动和兼容硬件。这种模式与早期 DLSS 部署相似，彼时 Nvidia 将训练模型与专有运行时组件及 RTX 专用加速结合起来。

据报道，MAAN 的方法移除了其中数个门槛。它不要求 NBA 2K27、原生 Windows 应用或 Nvidia GPU。它转而询问：浏览器及其所暴露的 GPU 能否执行对该神经工作负载的重建。

这并未抹去 Nvidia 的贡献。该模型仍源自 Nvidia，其有用行为来自 Nvidia 的训练成果。将其计算移植至 WebGPU 所展示的是推理的可移植性，而不是对模型开发的独立替代。

这也不会让官方硬件限制失去意义。Nvidia 销售的是具备特定延迟、质量目标与支持体系的体验。浏览器页面目前提供的则是一项没有可比服务保障的实验。

性能对比极其悬殊。Nvidia 表示，RTX 5090 在启用完整 DLSS 套件和光线追踪的 NBA 2K27 中，可在 4K 分辨率下达到最高 370 帧每秒。这一数字反映的是特定系统、预设和一组 DLSS 技术，因此不应与单次孤立的浏览器处理直接比较。

即使有这一限定，每次输出耗时数秒也无法服务于交互式游戏。以每秒 60 帧计算，完整的帧预算约为 16.7 毫秒。一次耗时一秒的神经网络推理，在其他游戏工作开始前就会消耗大约 60 个这样的预算。

这项演示揭示的其实是另一种压力。它提出了一个问题：一旦权重和运算过程可用，对神经图形模型的访问是否还必须绑定在厂商预设的交付机制上。

浏览器端人工智能早已面临类似问题。开发者经常通过 WebGPU 在本地运行语言、视觉和图像模型。其吸引力在于避免服务器往返、让部分数据保留在设备端，以及通过一个应用覆盖多个操作系统。

图形模型对时序提出了更严格的要求。文本模型即使逐步生成 token，依然有实用价值。图像工具即使需要数秒完成创作，也依然可用。而当渲染以一个数量级错过帧预算时，游戏体验就会变得难以忍受。

这使得 DLSS 5 成为对浏览器计算能力异常严苛的测试。如果该移植版本最终接近交互式速度，将表明 WebGPU 可以跨厂商承载复杂的渲染模型。即使它始终较慢，仍可用于离线预览和技术分析。

Nvidia 并未因这项演示面临迫在眉睫的竞争威胁。游戏工作室无法用一个基于泄露权重的非官方页面，替代受支持的 DLSS 集成方案。它们需要可预测的性能、明确的许可、质量保证，以及对引擎数据的访问。

不过，该项目削弱了一种更简单的假设：神经模型的执行天然需要 RTX GPU。官方产品或许需要 RTX 硬件，但在放宽速度与支持要求后，一个重构的网络显然可以在其他平台运行。

这一差别对于评估未来神经渲染系统的开发者十分重要。模型在理论上可以具备可移植性，但在生产环境中仍可能针对特定硬件。延迟至关重要时，专用加速器占优；覆盖范围至关重要时，通用 API 占优。

因此，Nvidia 的优势从独占性转向优化能力。其硬件、驱动、开发工具以及对模型的直接访问，应能让官方路径维持更高速度。这个浏览器实验测试的是：这种优势有多少来自执行工程，而非绝对的兼容性壁垒。

泄露的权重与缺失的代码，让最重要的问题仍悬而未决

这项演示在技术上颇具启发性，但其来源和验证缺口使其无法成为独立 DLSS 兼容性的明确证据。

据报道，MAAN 表示该项目使用了从泄露的 DLSS 5 库中提取的权重。开发者还表示，尚不清楚该库是否与正式发布版本存在差异。

这一披露改变了这项成果的性质。该项目似乎并非通过训练独立替代方案来复现 Nvidia 的模型，而是重新封装 Nvidia 的已学习参数，并通过 WebGPU 实现推理过程。

模型权重并非无关紧要的组成部分。它们编码了训练过程中学习到的模式，并在很大程度上决定网络输出。即使执行代码是新的，复用这些权重仍保留了 Nvidia 系统中最难复现的部分。

这带来了潜在的许可与知识产权问题。泄露文件可公开获取，并不代表获得了重新分发或部署其内容的许可。现有报道并未说明 Nvidia 对这一具体实现的立场。

计划中的源码发布将是第一个重要检验。MAAN 表示，代码将在首次演示后的那个周末发布到 GitHub。在此之前，外部开发者无法全面检查这些着色器如何对应其声称的模型。

源代码有助于回答若干技术问题。审查者可以识别所使用的算子，确认处理是否始终在本地进行，检查精度选择，并测试输出是否与 Nvidia 的官方实现一致。

它还将澄清“浏览器中的 DLSS 5”究竟意味着什么。这一表述可能指完整公开的神经模型、部分重构，或是受泄露网络启发的处理管线。这些类别存在实质性区别。

独立的图像对比将比开发者挑选的截图更重要。测试者需要使用相同的场景、相机位置、输入和输出设置。在能够构建等效场景的情况下，他们应将浏览器结果与官方 DLSS 5 进行比较。

该演示中两秒的耗时也需要更广泛的测量。一项 RTX 40 系列桌面端测试无法代表 Apple、AMD、Intel 和 Nvidia 硬件。性能可能随模型复杂度、输出分辨率、浏览器、操作系统和着色器编译而变化。

初始加载值得单独分析。对于受限网络连接而言，下载 147MB 意义重大，但这不同于每次渲染所需的时间。浏览器缓存可能降低后续启动成本，但内存压力仍可能限制中低端设备。

精度是另一个未知因素。神经模型常使用低精度格式以提升速度和内存效率。WebGPU 对特定数据类型和运算的支持取决于浏览器与硬件能力，这可能迫使其采用较慢的回退方案。

不同系统之间的图像一致性也可能存在差异。原生 Nvidia 执行依赖已知的硬件与驱动组合。WebGPU 实现则要经过多家厂商的着色器编译器，可能产生微小的数值差异，或更严重的兼容性故障。

由于该页面接受用户提供的 3D 文件，安全性需要审查。浏览器沙箱降低了应用对系统的访问权限，但上传或本地选择的模型仍会经过解析和渲染代码。源码审查可以揭示资源是否始终留在本地，还是会离开设备。

在这一行为明确之前，用户不应将该演示视为可信的生产工具。机密产品设计、未发布角色和建筑方案，都不适合作为未经审计页面的测试文件。

泄露权重问题还可能影响项目的长期存续。托管服务商或代码平台可能会响应有效的法律请求。即使实现仍然在线，未来的 Nvidia 模型更新也可能让泄露版本过时。

这些顾虑都不会抹杀其中的工程经验。在 WebGPU 中重新实现大型神经图形工作负载，依然具有参考价值。不过，它们确实限制了关于可用性、合法性和等价性的更强主张。

更恰当的结论应当更为克制。据报道，该演示表明 Nvidia 的模型运算可以通过可移植的浏览器计算来表达。它尚未证明这一结果已获许可、完整、可独立复现，或适合实时使用。

三个信号将决定这项演示是否重要

该项目的重要性现在取决于代码审查、跨厂商基准测试，以及一种可移植性收益大于速度损失的可信应用场景。

第一个信号是承诺中的源码发布。公开仓库将让图形开发者审查 WebGPU 计算着色器并追踪处理管线。它还会揭示 147MB 权重包是被包含在内、单独下载，还是在使用前进行转换。

完整且可复现的发布将强化可移植性的主张。独立开发者应能够构建该项目、运行相同场景，并获得可比的输出。若发布版本缺少关键模型组件，核心主张就仍将依赖于 MAAN 托管的页面。

仓库的法律状态将与其技术内容同样重要。下架、受限发布或移除权重，都会削弱该项目作为可复用实现的价值。这不会抹去这项演示，但会限制后续验证。

第二个信号是跨硬件厂商的结构化基准测试。审查者应测量 Apple Silicon、AMD Radeon、Intel Arc、集成显卡以及多代 RTX 产品。每项测试都应分别统计下载时间、着色器编译、首次渲染、后续渲染、内存占用和输出分辨率。

这些测量将表明，两秒的结果究竟是暂时的实现问题，还是更深层的限制。若经过着色器调优后出现大幅提速，浏览器端神经渲染的可行性将得到增强。若优化版本的性能依然停滞，项目就更适合转向离线预览。

质量测量应伴随速度测试。一个丢失材质细节或改变几何形状的快速移植版本，并不等同于预期系统。并排图像需要保持一致的输入，并仔细检查时间稳定性、纹理错误和光照伪影。

第三个信号是在新奇演示之外的应用。建筑预览、数字产品目录、角色审查和基于浏览器的 3D 协作，对延迟的容忍度都高于竞技游戏。它们也受益于向用户发送链接，而不是要求安装原生应用。

真实应用需要的不只是一个令人印象深刻的滤镜。它还需要可重复的输出、对模型权利的明确说明、可预测的浏览器支持，以及对客户资源的安全处理。当前的 Nvidia DLSS 5 浏览器演示尚未证明具备这些属性。

Nvidia 的回应将提供补充背景。该公司可能忽略这一实验、质疑其对泄露资源的使用，或扩大对更多硬件的官方支持。根据最初报道，Nvidia 已表示 RTX 40 系列支持即将到来，这削弱了使用非官方变通方案的一个理由。

该公司自身的路线图也可能进一步强化专业化。如果未来的 DLSS 版本更依赖硬件特定运算，浏览器移植版本或许仍然可行，但会越来越慢。如果模型架构变得更容易通过通用着色器表达，可移植实验应会有所改进。

对开发者而言，眼下的教训并不是用 WebGPU 替代原生 DLSS，而是关注专有 AI 模型与标准化本地推理之间的边界。模型所有者控制训练和官方分发，而可移植计算 API 可以放松对已公开工作负载执行地点的控制。

对用户而言，这项演示提供了观察这一边界的罕见机会。据报道，一个与特定 GPU 家族关联的神经渲染器，可以通过浏览器在多种硬件上运行。但这种体验牺牲了让 DLSS 在游戏中实用的速度。

这种取舍使该项目值得关注，但不应过度解读。如果代码实现变得可复现、基准测试得到改善，并且有合法的非游戏工作流采用它，这项实验将指向厂商中立的神经图形技术。如果这些信号未能出现，它仍将是一项围绕泄露模型数据构建的巧妙演示。

请仅使用非敏感资源尝试 Nvidia DLSS 5 浏览器演示，记录你的浏览器和硬件详情，并比较输出结果，而不要仅凭兼容性作出判断。决定性问题不再是单张处理后的图像能否出现在 Mac 上，而是一个开放、合法且可重复的 WebGPU 实现，能否在等待时间抵消其更广泛覆盖能力之前，提供有用的质量。