朋友把一台小米14 Pro递过来时，我正在等A100集群的排队结果。RTX 4090也没空，被同事拿去跑SFT训练。桌上的Mac mini M4倒是闲着，但Linux容器装不顺。
最后只剩一个有点离谱的方案：用一台搭载骁龙8 Gen3、12GB内存的旧旗舰，跑一支15秒的开源视频模型。
结果是跑通了。Wan2.1-1.3B-Instruct的INT4量化版，生成一段15秒、720p短片，总耗时38分12秒。电量从满格掉到61%，机身上半部烫到不适合长时间手持。成片不算精致，但猫跳上桌子的动作是连贯的，窗外自行车在第9秒闪了一下，整体还能看。
这不是“Sora平替”。更像是一次端侧推理的压力测试：没有A100、没有RTX 4090，只靠旧手机，开源视频模型到底能走到哪一步。
为什么选Wan2.1 1.3B
候选模型先筛了一遍。
Open-Sora 2.0的1.1B版本对消费级GPU还算友好，但官方推荐显存16GB起步，手机这边基本不用想。LTX-Video 0.9.7在Hugging Face上热度不低，可移动端NPU适配仍偏实验。我试了一次，直接OOM。
最后选的是阿里开源的Wan2.1-1.3B-Instruct。它的优势不在画质，而在“有机会跑完”。模型权重做INT4量化后约780MB，配合T-MAX的DiffusionCache策略，可以在Adreno 750上跑4步去噪。
这个方向也不是孤例。雷峰网报道过，面壁智能和OpenBMB在5月25日至29日做过一次“端侧大模型开源周”，其中BitCPM-CANN主打1.58-bit低比特训练，目标是让更大参数规模的模型进入手机一类设备。低比特、缓存、端侧调度，正是视频模型想上手机必须跨过的几道坎。
38分12秒里发生了什么
测试机是小米14 Pro：骁龙8 Gen3，12GB LPDDR5x，Adreno 750 GPU。初始机身温度28℃，测试前关闭后台应用。
模型使用Wan2.1-1.3B-Instruct的INT4 GGUF版本。输出规格设为720×480、24fps、15秒，大约360帧。提示词很简单：清晨咖啡馆里一只橘猫跳上木桌，窗外有自行车经过。
加载阶段先给了一个下马威。模型权重解压和显存映射耗时4分20秒，峰值内存占用8.7GB，里面包含系统开销。12GB内存听起来不少，真正跑起来只剩2.1GB左右可用空间，微信、企业微信都被系统杀掉了。
生成阶段采用分块推理，每块8帧，块间用光流缓存复用潜变量。第一块最慢，7分48秒；后面每块平均3分15秒。过程中CPU温度稳定在61℃附近，GPU温度最高到68℃，没有触发明显降频，但机身背面已经很烫。
最终耗时：38分12秒。
同样规格的视频，用RTX 4090跑大约2分钟。手机和桌面显卡的差距摆在这里。不过半年前这类尝试还常见于“单帧能跑”“视频直接爆内存”，现在至少能把15秒链路走完。
画面质量也要说清楚：猫毛有塑料感，人物脸部细节糊，背景物体偶尔漂移。它更适合做概念验证，离可交付成片还有距离。
三个设置，比换提示词更有用
真正影响体验的，不是把prompt改得多漂亮，而是几个工程细节。
第一个是关闭实时预览。Wan2.1默认每生成一块就回传缩略图，这部分会占用H.264硬解和屏幕合成资源。加上--preview-mode off后，总耗时压到31分钟左右。少看几张过程图，换来的是更稳的推理。
第二个是把模型文件手动迁移到UFS 4.0专用分区。小米14 Pro默认会把大文件调度到低速闪存区，加载时间原本是4分20秒。通过adb shell迁移后，加载阶段降到2分50秒。这一步不需要root，但需要愿意碰命令行。
第三个是外接散热背夹。加上半导体散热片后，CPU/GPU温度下降约7℃，最后5块的生成速度提升约18%。端侧视频生成的瓶颈不只是算力，散热和内存带宽同样关键。
我又在24℃空调房里重跑了一次，降频点推迟，总耗时缩短到34分钟。夏天户外基本不用试，冬天或空调房才像是这套方案的最低环境要求。
复现这套管线，需要哪些东西
如果只是想跑通一遍，配置可以压得很简。
硬件最低建议：骁龙8 Gen2以上，或天玑9300以上；内存至少12GB，最好16GB；存储要留出约6GB空闲空间，用来放模型和临时帧缓存。UFS 4.0机型会明显舒服一些。
模型选择：Wan2.1-1.3B-Instruct INT4 GGUF版本，约780MB，可以从Hugging Face下载。备选是Open-Sora 2.0-mini-int8社区量化版，约1.8GB，但内存占用更高，12GB机型会比较吃紧。
推理框架：llama.cpp的video分支，对Adreno和Immortalis做过专门优化。也可以看腾讯TVM-Lite移动端构建，或者阿里MNN 3.0+，后者支持NPU混合调度。
辅助工具包括Termux、proot-distro、Android版FFmpeg，以及用于管理模型版本的Ollama。基本流程是：下载模型和框架，push到手机本地目录；用adb shell迁移模型文件；写一个Python或C++推理脚本；输入图片和文本prompt，关掉预览；最后用FFmpeg把多段5秒片段拼成15秒视频。
全程不需要root，也不需要云服务。
它适合什么场景
38分钟生成15秒，当然不适合批量出片。它更像一个本地兜底方案。
麻省理工科技评论在对刘知远、姚远的专访中提到，真正接近人的AI助手需要持续听和看，但这会带来算力、延迟和隐私问题。云端算力充足，却无法绕开实时上传音视频带来的风险；端侧运算的价值，正在于响应速度和数据留在本地。
放到创作者场景里，手机跑视频模型最现实的用途是预览。比如先在本地生成低分辨率版本，确认构图、动作方向和镜头节奏，再交给云端或桌面显卡做高清成片。这样不必每次改一个镜头都排队、付费、下载、再重来。
它还有一个更朴素的价值：旧硬件能继续干活。一台不用的旗舰手机，接上散热、插着电，夜里跑几组低清预览，第二天挑能用的方案继续精修。效率不高，但成本很低。
离真正可用还差几步
这条路线还远没到舒服的程度。速度慢、发热高、画质不稳，任何一个问题都足以劝退普通用户。
但几个变化值得看。
低比特训练正在往前走。面壁智能提到的1.58-bit训练方法，不只是把模型推理时压小，而是在训练阶段就加入极低比特约束。如果类似方法能迁移到视频模型，模型体积和端侧推理压力都有继续下降的空间。
NPU调度也在改善。视频扩散模型反复读写中间结果，内存搬运经常比算力更要命。MNN 3.0+这类移动端框架继续做混合调度和缓存复用，对视频生成会更直接。
腾讯混元在广东人工智能与机器人产业创新产品与服务新闻发布会上提到，混元已上线并开源“图生视频模型”，用户上传一张图片、输入创意描述，可以生成带音效、2K分辨率的5秒高清短片。开源视频模型正在从云端能力向更轻量的使用方式扩散，端侧迟早会被卷进来。
现在的结论可以写得窄一点：旧手机跑开源视频模型，已经能跑通；想拿它替代云端服务，还不现实。它目前最适合做本地预览、隐私敏感素材测试，或者作为没有显卡时的备份方案。
38分12秒很慢。但对端侧视频生成来说，这个数字至少说明一件事：问题已经从“能不能跑”，变成了“怎么跑得更快”。
