苹果做AI，不在前台炫技，先钻进你的相册帮你省空间

出品 | 网易智能

作者 | 小爪

编辑 | 王凤枝

你的手机相册，可能永远不够用。

照片越拍越多，iCloud一遍遍提醒升级空间；聊天软件发一张原图要等半天；实况照片、高像素照片和大量截图，把本地存储和云端同步一起推高。

苹果机器学习团队最近公开的PICO，盯上的正是这个不够性感、但每个人都会遇到的问题：一张照片能不能看起来差不多清楚，却占用更少空间。

它不是聊天机器人，也不是图像生成模型，更不是一个已经上线的iPhone新功能。PICO出自一篇CVPR 2026论文《What Matters in Practical Learned Image Compression》，主题是practical learned image compression，也就是"实用的学习型图像压缩"。

过去一年，外界讨论AI产品，更多看见的是聊天框、Agent、图像生成和视频生成。PICO把视线拉到另一条产品链路上：AI进入消费产品，不一定总是站在前台，也可能先钻进压缩、同步、缓存和编码这些底层管道。

用户未必知道背后用了什么模型，但会感觉手机更省空间、同步更快、使用起来更安静。

图片压缩不是冷门问题

图像压缩已经是几十年的老问题。从JPEG到HEIC，再到AV1、VVC、JPEG-AI，不同路线反复解决的都是同一件事：怎样用更少的数据保存更可接受的画面。

这些名字离用户很远，但结果很近。你在手机里看到的一张照片，发到聊天软件里的原图，网页里加载的一张商品图，云盘里同步的一组旅行照，背后都在依赖压缩。

压缩做得好，用户不一定察觉；压缩做得差，用户马上会发现。 天空出现色块，文字边缘发糊，人脸细节丢失，夜景涂成一片，截图里的小字看不清，都是压缩从后台走到前台的时刻。

学习型图像压缩被反复研究，也正是因为这类取舍很难靠固定规则穷尽。神经网络理论上可以更贴近人眼感知来判断：哪些纹理可以少保留一点，哪些边缘不能坏，哪些细节对人眼更敏感，哪些信息虽然数学误差大但视觉上没那么重要。

论文效果和产品可用之间有距离。很多学习型压缩方案在实验里指标很好，但模型太重，编码太慢，解码太慢，或者需要服务器级算力。图像压缩不是离线艺术创作，它发生在拍照、预览、传图、上传、下载和打开图片的瞬间。用户可以等AI生成一张图十几秒，却很难接受每张照片都要等很久才能保存或打开。

PICO把问题推向了产品侧：学习型压缩如果真要进入日常设备，到底什么最重要？

PICO试图把论文指标拉回设备端

按照苹果项目页和论文的说法，在相近感知质量下，PICO所需的数据量大约是AV1、AV2、VVC、ECM、JPEG-AI等传统或标准路线的三分之一到不到一半。

码率可以理解为保存同一类视觉信息所需要的数据量。一张图片在某种压缩方式下需要较大文件才能保持可接受画质，PICO这类方法的目标是在肉眼观感接近时，用更少数据达到类似效果。这个比例不应直接写成所有照片都会缩小到三分之一，但它说明苹果团队看到的空间并不小。

和学术领域近几年发表的其他神经网络压缩方案相比，PICO也宣称能进一步节省约20%到40%码率。这一点同样重要。它不是只和老式编码器比，也在和同类AI压缩方法比。

PICO没有简单把神经网络做大，而是把模型结构和手机端速度绑在一起调。它借鉴了学习型图像压缩中常见的hyperprior框架：主编码器先把图像转换成潜在表示，辅助分支再为熵编码提供概率参数。它的一个关键改动，是把hyper-decoder拆成scale decoder和context decoder，其中scale decoder负责输出熵编码所需的scale参数，并被设计成跨设备输出确定、可量化到UINT8的小模块。论文还用了面向运行时的神经架构搜索，在iPhone上实测大量decoder候选，而不是只看理论算力。因为同样的模型结构在不同芯片、不同推理框架上的实际速度可以差出好几倍。

这些细节对应的是很具体的产品问题。图片压缩算法不能只在论文服务器上跑得漂亮，用户打开照片时，解码必须足够快、足够稳定。尤其是scale decoder这类参与熵解码的环节，如果不同设备上输出不一致，图片就可能无法可靠还原。 苹果团队把确定性和速度问题放进架构设计里，PICO才能从"AI压缩效果更好"往设备端方案靠近。

训练目标也在向产品风险靠拢。PICO不只追求像素级误差更小，还把均方误差（MSE）、学习型感知相似度（LPIPS）、多尺度结构相似度（MS-SSIM），以及专门针对文字失真和分块伪影的TextFidelityLoss、TilingArtifactLoss纳入训练目标。后两个名字对应的正是用户会遇到的问题：截图里的小字不能被压糊，分块处理后不能在边界留下明显色块或接缝。 PICO的感知优化不是泛泛地追求"人眼更舒服"，而是在修补学习型压缩最容易伤到体验的地方。

速度数据把这种产品化取向说得更清楚。论文写到，在iPhone 17 Pro Max上，PICO处理1200万像素图片时，编码最快约230毫秒，解码约150毫秒。 230毫秒大约是一眨眼的时间；如果照片保存和打开都要明显慢一拍，用户很快就会感觉到。

手机上的图像压缩不是跑分展示，而是嵌在一整套交互里。拍完一张照片，系统要保存；打开相册，系统要解码；发给朋友，系统要压缩；上传云端，系统要控制文件大小；从云端拉回，系统要快速显示。如果这些环节变慢，用户感受到的就不是"AI更聪明"，而是"手机变卡了"。

PICO的方向不是单纯追求最小文件，而是把压缩率、感知质量和设备端速度放在同一张表里比较。它标题里的"实用"，指向的就是这种工程约束。

产品信号不在"AI压缩"四个字

苹果如果未来把类似技术放进系统，用户很可能不会看到一个叫PICO的按钮。

更可能的情况是，拍照仍然是原来的拍照，相册仍然是原来的相册，发图仍然是原来的发图。变化发生在后台：照片占用更少本地空间，iCloud同步需要更少带宽，信息应用或邮件传图更快，应用缓存和网页图片加载成本下降。

这类变化不炫，但很值钱。照片和图片是移动互联网最大的基础负担之一。 社交应用、新闻应用、电商平台、云盘、相册、聊天工具，都在为图片存储、传输和预览付成本。用户端看到的是"空间又满了"，平台端看到的是存储、带宽和计算账单。

AI图像压缩如果能够稳定进入产品，影响的不只是相机和相册，也可能影响整条内容链路。电商平台的大量商品图，社交平台的用户图片，云盘里的相册备份，聊天软件里的原图发送，新闻网站里的头图和缩略图，都可能受益于更高效的压缩方式。

苹果在这个方向上有完整的产品条件：硬件、芯片、系统、相册、iCloud、信息应用和设备端机器学习框架。A系列芯片里的Neural Engine，过去几年已经用于相机降噪、人像模式、文字识别等设备端AI任务。PICO如果未来进入产品，类似的设备端加速能力很可能是它运行起来的前提。

苹果关心的不只是模型能不能在论文里赢，还包括它能不能在设备端以可接受的速度、功耗和稳定性运行。

这和很多AI产品的逻辑不同。 聊天机器人可以先云端运行，慢一点也能通过加载动画遮住；图像生成可以让用户等；视频生成可以排队。但图像压缩是基础设施。基础设施里的AI，如果没有足够低的延迟、足够稳定的质量和足够可控的失败方式，就很难成为日常功能。

PICO的价值就在这里：它把学习型图像压缩从"研究上能不能更好"往"产品里能不能用"推进了一步。

AI也会藏进后台

过去两年，AI产品的叙事有一个明显倾向：越可见，越容易被讨论。能聊天、能画图、能写代码、能生成视频，才像AI产品。

但很多改变体验的AI，可能不会这么显眼。 它们会进入键盘纠错、照片降噪、视频防抖、推荐排序、语音降噪、图像压缩、缓存管理、OCR、搜索理解和隐私检测。用户不一定主动调用它们，但每次打开产品都会受影响。

PICO属于这一类。它不负责帮用户生成一张照片，而是帮系统更有效地保存一张照片。 前者更容易被看见，后者更可能长期存在。

PICO面对的是另一个现实：用户已经有了太多图片。它减少的不是创作门槛，而是保存、传输和同步的成本。它离产品还差的，也不是单一指标，而是不同图片类型、不同设备、不同系统管线里的稳定性验证。

还不能写成iPhone新功能

PICO仍然只是一个研究项目。

苹果没有宣布PICO会进入iOS，也没有说它会取代HEIC、JPEG、AV1、JPEG-AI或现有相册压缩流程。论文中的数据量节省来自特定评测和感知质量对比，不能直接理解成每张照片都能压到原来的三分之一。

不同图片类型也可能带来不同挑战。自然照片、截图、文字密集图片、UI界面、商品图、纹理复杂的图片，对压缩伪影的敏感点并不一样。用户能接受风景照里少一点纹理，未必能接受截图里的小字边缘发糊。 论文里的平均结果，不能覆盖真实场景里的逐项测试。

还有一个产品问题：压缩不是越狠越好。对用户来说，文件小当然重要，但记忆、证据、工作资料和创作素材里的细节也重要。苹果如果未来真要在系统层面采用类似技术，必然要在空间节省、画质保真、速度、功耗和可恢复性之间做权衡。

AI开始进入消费产品的底层工程。它可以生成内容，也可以压缩内容；可以回答问题，也可以降低存储和传输成本；可以站在前台让用户惊讶，也可以藏在后台让产品少一点负担。

过去几年，AI最容易被看见的能力，是制造更多内容。PICO代表的是另一种方向：当内容越来越多，AI能不能帮我们把它们更便宜、更安静地保存下来。