你的Mac，可能正在浪费一个价值几十万的视频生成能力。
Redis之父antirez用一套代码证明：运行33B参数的视频生成大模型，不需要云端服务器，不需要A100显卡，你手边那台Mac就够了。
前不久，MiniMax正式发布新一代多模态生成模型MiniMax H3。这是一个330亿参数的全模态生成系统，能根据文字、图像、视频、音频等多种输入，生成最高2K分辨率、最长15秒、带有原生立体声音频的视频。8月3日模型正式开源。
几乎同一时间，Redis创始人antirez在GitHub上发布了一个名叫h3.c的项目。一个C语言文件，几万行代码，让MiniMax H3这个庞然大物在Apple Silicon Mac上跑了起来。
这不是一个“能跑就行”的玩具。这是一个经过深度优化的原生推理引擎，深度集成了苹果的Metal图形API，利用了M3 Max和M5 Max芯片的每一分算力。
最大的反常识在于：antirez没有用Python，没有用PyTorch，没有用任何“主流”的AI框架。他用的是C语言。
在人人都在用高级框架搭积木的时代，这位Redis之父选择了最底层的工具，亲手把330亿参数的模型“塞”进了个人电脑。
这不是炫技。这是一种工程哲学：真正的性能，藏在别人懒得触碰的底层里。
330亿参数是什么概念——你的MacBook里塞进了一整个电影制片厂
先做一个简单的算术题。MiniMax H3-Base有330亿参数。每个参数如果用BF16精度存储，占用2个字节。330亿乘以2，等于660亿字节，也就是 roughly 66 GB。
这还没算上模型运行时的中间激活值、注意力缓存、视频编解码器。项目文档里写得清清楚楚：在128GB内存的M5 Max上，一个完整的图像加音频生成任务，峰值物理内存占用约40.1GB。
40个G。这还只是“能跑”的门槛。
antirez在项目里做了一件疯狂的事：他把模型权重文件直接用内存映射的方式加载，而不是复制到匿名共享缓冲区里。这意味着37GB的模型文件是“文件 backed”的、可回收的，操作系统可以在内存紧张时把不用的部分换出。
翻译成人话：别人加载大模型需要把几十个G的数据全部拷进内存，antirez让操作系统“看着办”——需要哪块读哪块。
零拷贝。这是系统编程的老手艺，但在AI圈几乎没人这么干。
h3.c的代码里还有更多这种“老派”的优化手段。比如流式提示编码：用八个I/O工作线程预取未来层的数据，让文本编码和GPU计算并行。比如融合内核：把多个连续的操作合并成一个，减少GPU内核启动次数。比如激活缓冲区复用：QKV投影的显存先给注意力头用，用完再给MLP输入用——同一块显存反复利用。
这些技术名词听起来很专业，本质就一句话：能省则省，能复用就复用，能不拷贝就不拷贝。
项目文档里有一组数据：在512x512分辨率、22帧、20步去噪的配置下，M5 Max上完整跑一次大约需要16.69秒。如果开启token reduction——一种通过配对相邻视频token来减少计算量的技术——时间缩短到12.60秒。再配合内部渲染尺寸降到320x320然后高质量放大，DiT部分的计算时间从15.82秒降到了8.02秒。
几乎翻倍的提速。没有换硬件，没有加显存，全靠代码优化。
这就是antirez在做的事。他证明了在AI时代，底层优化依然有巨大的空间。那些被高级框架掩盖的性能浪费，在C语言面前无所遁形。
4步生成视频——当“差不多”成了新标准
h3.c项目里最让人意外的参数叫--steps。它控制的是去噪步数——你可以理解为模型“画”一张图要来回修改多少次。
标准的参考质量配置是50步。默认配置是20步。但antirez在文档里专门提到了一个“低预算”配置：4步。
4步。一个视频，22帧，每帧只让模型修改4次。
4步能出什么效果？项目文档里有一组客观数据：在512x512的狐狸测试中，4步生成的结果与29步参考版本的SSIM（结构相似性指数）是0.556。另一个冲浪者测试是0.547。
0.55的SSIM不算高。但antirez的结论是：4到7步就能生成“可识别”的视频。
4步去噪在M5 Max上只用了大约3.5秒。而50步的参考版本需要26.4秒。
3.5秒对26.4秒。速度提升超过7倍，换来的是“能用”的质量。
antirez甚至在文档里给出了一个“激进预览”的配置组合：内部渲染320x320、只跑40层Transformer、开启reuse 3。这个配置在验证中产生了“干净、可识别”的22帧狐狸视频。
注意用词：“干净、可识别”。不是“完美”，不是“参考级”，是“能用”。
这背后是一种被很多人忽视的工程智慧：在算力有限的情况下，找到“足够好”的边界。
antirez在项目文档里详细记录了他们的实验过程。他们测试了多种去噪调度策略：基于实际视频sigma的线性间隔、二次和三次扭曲、尾部子集、幂扭曲、零阶保持全网格速度、线性速度外推、RES。更偏向尾部的候选方案往往让主体更清晰，但破坏了运动连贯性，或者留下了重复的编织背景。
换句话说，他们试过各种方案，最终找到了一个在“快”和“能看”之间平衡的点。
这种“差不多就行”的思路，在追求极致的AI研究圈里并不常见。大部分论文都在比拼谁的效果更好、指标更高。但antirez在做一个实用工具：让普通人在普通硬件上能用上大模型。
4步出片。这就是答案。
首尾帧控制、参考图像、音频替换——你在Mac上拥有了一个迷你制片厂
h3.c不只是个“文本生成视频”的工具。它支持的工作流比你想象的要复杂得多。
项目文档里专门有一节讲“参考模式”。你可以用--first-frame指定视频的起始画面，用--last-frame指定结束画面。模型会在两头之间生成连贯的过渡。
你还可以用--ref-image传入参考图片，用--ref-video传入参考视频。甚至可以用--ref-audio单独指定音频。
更精细的是，--ref-video会保留视频自带的音轨，而--ref-silent-video会忽略音轨。如果你不喜欢原声，还可以用--ref-video-audio手动替换。
音频参考有明确的限制：每个片段2到15秒，最多接受三个音频输入，总时长上限15秒。
这些功能组合在一起，效果惊人。你可以给一段视频指定开头和结尾的画面，让模型脑补中间的过程。你可以用一张参考图生成一段围绕它展开的视频。你甚至可以给一段无声视频配上指定的背景音乐。
h3.c在交互式会话里支持!ref-image、!refs列表查看、!ref-remove删除等命令。你可以在一个会话里反复调整参考素材，模型一直驻留在内存里，不用每次重新加载。
这已经不是一个“演示项目”了。这是一个功能完整的视频生成工作台。
项目文档里有一组实测数据：在128GB M5 Max上，一个完整的“图像+音频”参考生成任务耗时74.58秒，峰值内存40.1GB。视频+音频参考生成耗时76.99秒。
一分多钟，在你的Mac上生成一段带声音、带参考画面的视频。
h3.c还支持--show参数，可以在支持的终端里实时预览生成过程中的中间帧。每完成一步去噪，终端就会刷新一帧代表画面。你看着画面一点点从噪点变成图像，从模糊变成清晰。
这是一种很奇妙的体验——你在自己的电脑上，亲眼看着一个330亿参数的模型“画”出视频。
选配还是选速——h3.c让你在质量和速度之间做选择题
h3.c最厉害的地方，不是它跑得快，而是它给了你选择的权利。
项目文档里有一张控制表。控制维度包括：去噪步数（--steps）、整层复用（--reuse）、活跃DiT层数（--layers）、核心残差复用（--core-reuse）、token reduction、内部画布尺寸。
每个维度都有“慢速参考”、“默认”、“激进”三档。
你可以全开最高：50步、50层、不复用任何东西——这是参考质量。你也可以全开最低：4步、40层、reuse 3、内部320x320、开启token reduction——这是最快速度。
antirez甚至在文档里警告：不要把某些激进配置组合在一起，比如同时用--layers 40和--reuse 3再加--token-reduction，这个组合会产生颜色环、轮廓和重影肢体。
他试过了。他踩过坑了。他把结果写在了文档里。
这种透明度在开源项目里并不常见。大多数项目只会告诉你“怎么用”，不会告诉你“什么组合千万别用”。antirez把实验数据、失败案例、性能对比全部公开。
项目文档里还有一组关于Metal性能优化的数据：M5 GPU自动使用原生的BF16 Metal 4/TensorOps处理DiT的QKV和注意力输出投影。在序列长度不超过2048时，这个路径比通用方案快约2%。
2%。一个优化可能只换来2%的提升，但antirez把几十个这样的优化叠加在一起。每个优化单独看都微不足道，合在一起就是几倍的差距。
项目还支持--use-int8-row-fc2这个实验性选项，用每行一个激活缩放因子的int8量化来加速FC2层。在测试中，这个选项把完整的去噪前向传播时间减少了约2.6%。生成的狐狸和冲浪者视频保持了相同的主题、场景和运动。
2.6%。又是一个小优化。
但这就是antirez的风格。他从不在意某个优化是不是“足够大”。他在意的是每一个可以榨取性能的地方都不放过。
从Redis到H3——同一种工程哲学的不同战场
antirez是谁？
Redis之父。2009年创造了这个全球最流行的内存数据库。2020年宣布不再担任Redis维护者。
Redis之所以成功，很大程度上因为antirez对性能的极致追求。他用C语言写出了当时最快的键值存储，用巧妙的数据结构设计让Redis在单机就能支撑数十万的QPS。
2026年，antirez把同样的工程哲学带到了AI领域。
h3.c项目从头到尾都是用C语言写的。它直接调用苹果的Metal API进行GPU加速。它用内存映射加载权重。它用多线程预取隐藏IO延迟。它融合内核减少GPU调用。它复用显存减少分配。
这些技术手段，和Redis当年用的那些优化思路——事件驱动、单线程、内存存储——本质上是一回事。
都在做一件事：在有限的硬件上榨出最大的性能。
有开发者评论说：“antirez出的东西闭眼用，C代码也读得舒服。”还有人说：“antirez就是那种代码手感最好的作者。”
在AI圈人人都在用Python搭积木的时候，antirez在用C语言造轮子。在大家默认“大模型必须上云端”的时候，他在证明个人电脑也能跑。
这种反差本身就是一种力量。
h3.c项目目前还在持续优化中。当前的工作重点是M3 Max和M5 Max上的Metal性能和内存优化。项目采用“垂直切片”的方式逐步推进：先确定host/model元数据，然后是Metal块的一致性、提示编码、提示到视频/音频、首尾帧条件控制。
每一步都是一个完整可用的功能切片。每一步都在向“在Mac上流畅运行330亿参数视频生成模型”这个目标靠近。
这不是一个论文项目。这是一个能用的工具。antirez在项目首页写得很清楚：这是一个“为Mac计算机设计的MiniMax H3推理引擎”。
Redis之父用C语言证明了一件事：在AI时代，底层优化依然有价值。那些被高级框架掩盖的性能浪费，在懂行的人手里，依然可以被榨出来。
你的Mac可能已经准备好了。问题只在于，你愿不愿意打开终端，敲下那行命令。
总结：Redis之父antirez用C语言写出了h3.c，让330亿参数的MiniMax H3视频生成模型在Apple Silicon Mac上流畅运行。通过零拷贝、流式编码、内核融合等底层优化，4步即可生成可用视频。底层工程的价值，在AI时代依然成立。