串流的文字为什么会发虚，以及我们为什么认为超分辨率能帮上忙。
传统视频编码器是为运动画面调校的，而不是为文字和界面元素那种细密、高对比度的边缘。带宽一紧张，这些边缘最先被牺牲——这是视频压缩本身的特性，任何远程桌面都一样，不只是 Remio。
远程桌面的画面在抵达你眼睛之前，要经历两次压缩。第一次，当源分辨率超过客户端能显示的范围时，主机会先缩小画面——一台 14 英寸 M4 MacBook Pro 以 3024×1964 的分辨率作为主机，串流到分辨率为 2266×1488 的 iPad mini，编码器还没看到这一帧，就已经损失了大约三分之一的像素。第二次，编码器本身会进行有损压缩，以适应网络能承载的码率。这两步都会丢掉高频细节——而它恰恰决定了一个字形是清晰锐利，还是糊成一团。
我们正在探索的，是一道在客户端解码之后运行的画质恢复环节：观察解压后的画面，预测原始画面在被缩小、被编码器压缩之前所拥有的高频内容。传统的双线性或双三次放大只能根据已有像素做插值；而训练过的神经网络能学会边缘、字形和界面形状在全分辨率下的样子，并重建出简单插值无法恢复的细节。
如果它能像我们期望的那样工作，效果会最先出现在你最需要的地方：11 磅的正文、等宽字体的代码、Figma 文件里的细线、侧边栏里的按钮轮廓。在这些场景里，几个发虚的像素，就是“看得清”和“得凑近看”的差别。任何针对运动画面调校的编码器，单靠自身都存在这样的缺口——这正是值得投入研究时间去弄清设备端模型能否填补它的原因。
我们还没有做到。今天，对于“网络不好时怎么让画面保持清晰”，诚实的答案是 Remio 的自适应码率引擎——它已经能读取你的网络状况，选出在连接条件允许下最清晰的画质档位，又不会让延迟飙升。神经网络超分辨率只会是叠加在它之上的又一层，而不是替代品。
真正的原生客户端，而不是套壳网页。
Remio 的每个客户端在各自平台上都是 100% 原生应用——中间没有 Electron，也没有浏览器沙盒。所以它本来就能直接调用神经网络超分辨率模型需要的那些硬件框架：Apple 芯片上的 Core ML 和 Neural Engine，配有专用 NPU 的 Android 设备上的 NNAPI。如果我们要做这件事，它会接入已经就绪的采集、编码和解码架构——不绕云端，也不用额外附加一套运行时。
这就是为什么设备端是我们唯一会考虑的实现方式。绕一圈云端会增加 Remio 的零缓冲理念无法接受的延迟——所以我们发布的任何模型都必须在本地运行，否则就不发布。
在 Apple 芯片上——每一台 M 系列 Mac、iPad Pro、iPad Air 和近几代 iPhone Pro——Core ML 可以把编译好的模型交给 Neural Engine 运行。它是和 CPU、GPU 位于同一块芯片上的专用协处理器，专为神经网络绝大部分时间都在做的那种小规模、重复性的矩阵乘法而生，功耗只有 GPU 的一小部分。对这个想法所需的模型来说，这是一个能力够强又很节能的运行平台——只是目前还没有接上。
在 Android 上，NNAPI 同样能把支持的设备——搭载 Google Tensor 的 Pixel，以及近几年的 Galaxy 和一加手机——的运算交给硬件 NPU。在这两个平台上，NPU 不够快的旧设备会直接回退到 1:1 解码，和 Remio 今天在所有设备上的表现一样：它绝不会为了等一块并不存在的硬件而卡住串流。
以上都不是对发布日期的承诺。它只是我们认为这项研究值得做的理由——最难的架构前提已经具备，对这类功能来说，这是一个相当少见的起点。
上线之前，我们得先证明什么。
我们不会因为“AI”好卖，就硬塞一个 AI 功能。以下是我们必须先给出可靠答案的几个问题。
它是否明显胜过我们现有的方案？Remio 的自适应码率引擎已经会读取你的网络，选出在当前网络条件下最清晰的画质档位。神经网络模型只有在这个基线之上，还能多还原出人们真正能察觉的细节时，才有资格留下——而不是某个跑分上赢了、一到正常观看距离就看不出差别的成绩。
它会不会在手机或平板上显著耗电？整场会话里对每一帧解码画面都运行一次模型，是有实实在在的功耗代价的。我们希望这个代价小到没人需要在意——或者提供一个清晰、坦诚的“自动”行为，只在确实有细节值得恢复时才耗电，并且为不想付出这份电量的人留一个真正的关闭开关。
它对自己在做什么是否足够诚实？一个从压缩后的像素里重建出看起来合理的细节的模型，和一个凭空编造原本不存在的内容的模型，是两回事。对远程桌面而言，你看到的必须和主机上实际有的一致，这种区别不是锦上添花——而是整个信任模型的根基。我们发布的任何东西，都只能重建，绝不能臆造。
在我们能用真实数据而不是预测，回答完这三个问题之前，它在这个页面上就只是一个研究想法——而不是应用里的一个开关。
现在就让画面保持清晰的，不靠 AI。
想要一次清晰的 Remio 会话，今天并不需要什么研究项目。四项已经上线的朴实工程，就已经把活干了。
端到端硬件 H.265，意味着主机上的编码器和你客户端上的解码器都跑在专用视频芯片上，而不是 CPU——这和 4K 视频在手机上能流畅播放，而软件解码却会卡死，是同一个道理。正是这份余量，让 Remio 能在软件编解码器撑不住的码率下保留细节。
自适应码率引擎承担的，正是我们探索神经网络超分辨率想要帮忙解决的那件事：会话开始时它会测量你的连接，选出该连接能撑住、又不会引起延迟飙升的最高码率档位，而不是悄悄地让串流“挨饿”。了解自适应画质如何工作 →
虚拟显示器和零缓冲渲染器则补上了最后两块。因为 Remio 串流的显示画面刚好按你的窗口大小生成，而不是主机的整个显示器，你看到的就不会是某个更大画面缩小后的副本。又因为渲染器始终绘制最新解码出的一帧——丢掉过时的帧而不是追赶它们——你看到的任何内容，到达屏幕时都不会是旧的。这四项合在一起，大多数会话根本不需要额外的画质恢复环节。
如果有一天发布，我们会坚持的原则。
生成式 AI 的营销让人以为“AI 增强”就是凭空编造细节。在把这样的模型放进 Remio 之前，它必须先通过一份简短而坦诚的清单。
它不会臆造缺失的界面。如果编码器丢掉了某个区域，导致一个按钮在串流边缘被截断，那么一个自行补全按钮其余部分的模型，不属于远程桌面。你需要相信，在 iPad 上看到的和主机上实际有的是一致的——一个把原本不存在的内容填进去的生成式模型，会破坏这份信任，所以我们只会发布依据真正编码过的像素进行重建的模型，绝不发布凭空创造的模型。
它不会声称能提高帧率。Remio 的帧率由主机的采集速率和网络按时送达画面的能力决定——这是已经上线的零缓冲渲染器的工作，而不是超分辨率的工作。我们做出的任何模型，都只会为每一帧解码画面生成一帧更锐利的画面，仅此而已。
它不会被宣传成能修复主机上的视频播放。如果你在远程 Mac 上看电影，串流出来的就是主机自己的视频解码器渲染出的画面——分辨率也是主机的。对串流做画质恢复，并不能改善主机已经输出的源画面；想要更清晰的电影播放，诚实的建议和现在一样：在你的客户端设备上播放，而不是在主机上。
它也绝不会被当作良好网络的替代品。无论叠加多少超分辨率，直连的局域网连接始终比被限速的广域网连接更清晰——Remio 现在自带的自适应码率引擎，已经能让你在实际连接条件允许下得到最好的画面。我们在这里做的任何东西，都只是给糟糕网络多加一层保险，而不是好网络的替身。
常见问题
关于设备端神经网络超分辨率的常见问题——下面是坦诚的回答。
Remio 现在有设备端神经网络超分辨率吗？
如果你们做出来了，有什么东西会离开我的设备吗？
为什么只是探索，而不是直接发布？
现在 Remio 靠什么让文字和代码保持清晰？
发布时你们会告诉我吗？
今天就快速而清晰。我们还在探索让它更清晰的办法。
安装 Remio，即可体验端到端硬件 H.265 串流、读取你网络状况的自适应码率引擎，以及刚好按你窗口大小生成的虚拟显示器——这些现在都已上线。设备端神经网络超分辨率在这个页面上仍然只是研究中的想法；不承诺日期，一旦情况有变，这个页面会如实告知。