DiT架构详解:从U-Net到Diffusion Transformer的视频生成革命
Sora 火了之后视频生成这个赛道一下变得拥挤起来。每天刷 arXiv、GitHub Trending你会发现一个新信号不管闭源厂商还是开源社区新一代视频模型的架构选择都惊人统一——DiTDiffusion Transformer。Sora 的技术报告没把网络结构细节全部抖出来但明确写了 backbone 用的是 DiT就这一句话基本给行业派发了标准剧本。后续 Open-Sora、CogVideoX、HunyuanVideo 这一批模型主干全是 DiT 或者它的变体。DiT 全称 Diffusion Transformer翻译成大白话是“把扩散模型里的去噪骨干网络从 U-Net 换成 Transformer”。它解决的问题很直接视频生成既要有逐帧的高清细节又要保持长远的时空一致性过去的卷积网络擅长前者却很难搞定后者。DiT 用 Transformer 的全局注意力统一处理时空信息让模型在更大数据、更大算力下还能继续涨能力。这篇漫话不打算贴一大堆源码而是把 DiT 的关键组件、架构选型和工程落地的坑一次性讲清楚。想看明白 Sora 之后为什么大家都在“抄剧本”的读者或者正准备入局视频生成、想做二次开发和微调的工程师都适合往下看。1. 从 U-Net 到 DiT视频生成架构的“同一本剧本”1.1 从“噪点里长图”说起扩散模型的基本盘要理解 DiT先把扩散模型这个底子说清楚。扩散模型的核心思想是两步走前向过程不断往干净数据上加噪声直到它变成一坨纯噪声反向过程则是训练一个神经网络从噪声里一步步把数据“捞”回来。整个过程由一个噪声调度器控制在某个时间步 t 下真实样本 x 会变成带噪的 x_t模型要做的就是根据这个 x_t、当前时间步 t 以及条件信息文本、图像、类别等预测出被加进去的噪声或者是 flow matching 里常说的速度场。训练过程听起来很像“作弊”不需要复杂的对抗博弈只需要随机采样时间步、加噪、让网络预测噪声然后算一个 MSE loss 就完事。Sora 也好开源的视频模型也好底层都是这套游戏规则。视频生成一般不会直接作用在原始像素上而是先把视频通过一个自编码器压缩到隐空间在隐空间里做扩散和去噪最后再解码回像素画面。这一步很像先用 ZIP 压缩视频在压缩后的“精华”里作画再解压回完整视频能大幅降低计算量。1.2 U-Net 时代局部归纳偏置的双刃剑在 DiT 成为主流之前扩散模型的去噪网络几乎被 U-Net 垄断。U-Net 是卷积网络的代表里面大量使用卷积核再配合一些注意力模块。卷积核的感受野天生就是局部的这种“局部归纳偏置”对图像纹理和细节建模非常友好训练起来也相对稳定参数效率很高早期效果确实能打。但到了视频生成问题就来了。视频多了一个时间维度模型不仅要理解单帧里有什么还要理解一个物体从左走到右之后它的外观、形变、遮挡关系该怎么连续变化。卷积的局部感受野很难做到这种长程的时空依赖于是大家开始打补丁有的在 U-Net 里加入时间维度的 3D 卷积有的在相邻帧之间加时序注意力有的把整个视频切成片段再拼接。你会发现这些方案本身没有统一范式更像是在一个原本为图像设计的骨架上不断贴膏药。每换一个数据集每换一个视频长度都要重新调一堆结构扩展性很差。1.3 DiT 的登场Transformer 担任去噪骨干2022 年底论文《Scalable Diffusion Models with Transformers》把 Transformer 直接搬进了扩散模型。作者把图像切成 patch喂给标准的 Transformer block用自适应层归一化注入时间步和类别条件在 ImageNet 生成任务上拿到了当时最好的 FID同时也证明了一件关键的事模型参数量越大、数据量越大效果还能继续涨这就是扩展性。Sora 出现之后DiT 几乎成了视频模型的默认答案。OpenAI 没有公开 Sora 的完整结构但一句“we use a DiT backbone”已经足够说明方向。对于从业者来说这句话比什么都重要它告诉大家视频生成不再需要发明一种全新结构只需要把 DiT 从图像扩展到三维时空 patch并且把数据规模和算力堆上去就能做出 Sora 级别的效果。1.4 大家都在抄什么主干一致细节各有私货说“所有视频模型都在抄同一个剧本”这里的“所有”当然是夸张说法准确讲是绝大多数新一代视频模型在主干上极度趋同。抄的核心是什么就是把视频通过时空自编码器压缩成隐空间然后切成时空 patch丢进 Transformer block用扩散或流匹配目标训练最后解码成视频。但每个团队都会往这套主干上塞自己的私货。CogVideoX 用 3D VAE 做时空压缩压缩率很高HunyuanVideo 采用双流到单流的设计先分别处理空间和时间特征再融合Open-Sora 在长视频、多分辨率、工程鲁棒性上做了大量优化Wan 2.1、Mochi、Emu3 这些模型又各有各自的位置编码和条件注入策略。这个状态很像汽车行业大家都是发动机加方向盘加四个轮子的底盘方案但每家的引擎调校、悬挂、内饰各不相同。你很难说某台车完全复制了另一台但宏观架构确实收敛到了一起。2. DiT 的工作原理把视频变成“一页页格子纸”2.1 从连续帧到离散 TokenPatchify 到底在干嘛DiT 最核心的一个操作就是 patchify。把视频切成一个个小块再把每个小块拉平成向量这些向量就是 Transformer 处理的 token。为什么要这么干因为 Transformer 本身没有“相邻像素关系更紧密”这种先验它只看序列。如果你直接把像素点作为 token序列长度会爆炸到完全没法算。但如果你把局部小块作为 token每个 token 内部已经保留了空间结构信息序列长度也压到了一个合理范围。举个具体例子。假设一段视频的分辨率是 512×512共 16 帧经过时空自编码器压缩后时间维度缩到 4 帧空间维度缩到 64×64通道数变成 4。如果你设定时空 patch 大小为 2×4×4那么时间上 4 帧能切成 2 个片段空间上 64×64 能切成 16×16 个小块最终 token 数量是 2×16×16512 个。每个 token 的向量维度就是 patch 大小乘以通道数即 2×4×4×4128 维。这个长度对 Transformer 来说非常友好。patch 大小直接影响效果和算力。patch 越小序列越长模型能看到的细节越多但显存和计算量也越大。patch 越大序列越短但容易丢失细节。视频模型里常用的 patch 尺寸一般是时间维 1 或者 2空间维 2 到 8。这个选择很大程度决定了视频生成画面的细腻程度和运动连贯性。2.2 加噪去噪DiT 在扩散过程里扮演什么角色把视频变成 patch token 之后后续的扩散过程就相对规整了。训练阶段DiT 接收一个带噪的隐空间序列以及当前时间步 t 和条件信息输出对噪声或速度场的预测和真实噪声算损失。采样阶段从纯噪声出发每次让 DiT 预测噪声然后由一个调度器根据当前噪声水平算出下一步稍微干净一点的隐空间反复迭代几十步后就得到了一份比较干净的隐空间表示最后输入给 VAE 解码器生成视频。很多人会有个疑问既然都上 Transformer 了为什么不直接自回归预测下一帧这个思路确实也有但扩散模型在视频生成上有一个天然优势它在一个连续的时间维度上迭代能同时构建整个视频片段的全局结构而不是一帧一帧地单向生成。单向生成容易积累误差前面有一点抖动后面会越来越歪扩散模型的去噪过程更像是从一张模糊的草图开始每一步都在修正整体轮廓最终收敛到比较一致的画面。另外现在越来越多的视频模型选择 flow matching 而不是传统 DDPM。flow matching 的思路是让干净数据和纯噪声按时间线性插值模型直接预测速度场训练目标更简单采样步数也可以大幅减少。Sora 的技术报告没有给出训练损失的细节但很多迹象表明它更接近 flow matching 一族。采用哪种路径会影响采样步数和收敛速度但 DiT 的角色没有变——它始终是那个在噪声混沌中“猜”出干净方向的核心引擎。2.3 条件注入方式文本、时间步和控制信号怎么“指挥”Transformer视频生成不是无中生有你需要告诉模型生成一只猫还是生成一段雨天街道因此条件信息必须能有效地进入 Transformer。DiT 论文里对比了几种注入方式每种都值得了解。第一种是 AdaLN自适应层归一化。它的做法是把时间步、文本特征等条件向量经过一个 MLP 映射成每个 Transformer block 里 LayerNorm 的缩放和平移参数。条件不同每一层特征就被整体放大或缩小、平移相当于“调队友的音量”。实现简单计算开销极小DiT 原论文里效果也最好。但它的问题在于把条件信息压缩成了向量级的统计量对于非常细粒度的文本语义可能不够精细。第二种是 Cross-Attention交叉注意力。视觉 token 作为查询文本 token 作为键和值在每个 block 里额外做一次注意力让每个视觉 token 都能从文本序列里找到自己需要的信息。这种方式对语义细节更友好但多一层注意力计算量上升不少。第三种是 In-Context把条件 token 直接拼在视觉 token 序列前面。像 GPT 处理上下文一样让模型自己从拼接序列中提取信息。这个最简单也最符合 Transformer 的原始设计但条件序列越长整体序列就越长算力开销也上去了。真实视频模型往往不是只用一种。Open-Sora 倾向把文本 token 拼进序列同时用 AdaLN 注入时间步CogVideoX 使用交叉注意力来加强文本语义HunyuanVideo 在双流阶段分别处理文本-图像交叉注意力融合阶段再做联合注意力。条件注入方式直接决定了模型对文本指令的跟随能力这也是你在复现或微调模型时最需要关注的地方之一。2.4 位置编码让 Transformer 知道时间顺序和空间位置Transformer 结构本身不区分 token 的先后顺序所以必须给每个 patch 加上位置编码。图像模型一般只需要二维位置编码比如把 patch 在高度和宽度上的坐标编码进去。视频要多一个时间维度所以位置编码必须覆盖时间、高、宽三个轴。早期方案是绝对位置编码每个位置对应一个固定向量实现简单但遇到训练时没见过的分辨率或帧数效果会下降。现在更主流的是 RoPE旋转位置编码它表达相对位置关系对长视频和可变分辨率的泛化能力更好。很多实现会在时间维用一维 RoPE空间维用二维 RoPE最后把位置信息相加或者拼接进 token。位置编码这个环节特别容易出 bug我见过不少复现项目画面乱跳最后查下来都是位置编码没对齐时间和空间轴。你要是准备自己写代码建议把这一段单独做可视化验证。3. 为什么是“单流”DiT——视频模型选型背后的工程逻辑3.1 单流、双流是什么为什么都在喊“单流”网上讨论视频 DiT 时你很容易看到“单流”这个词。简单来说如果空间和时间信息被放在同一组 token 里喂进相同的 Transformer block 一起做注意力这就是单流 DiT如果分别用两套网络分支处理空间信息流和时间信息流再在某个阶段融合那就是双流设计。Sora 为什么被认为倾向单流因为它提到了时空 patch 的概念把不同帧的 patch 全部拉平成一个序列。这种设计的直觉是空间和时间没有本质区别都只是序列上的不同位置。模型不需要提前被规定“哪个是空间关系哪个是时间关系”而是自己从数据里学。单流的优点是结构简单、实现直接、扩展性好符合 Transformer 的 scaling law缺点是序列特别长计算复杂度极高而且如果数据不够大模型可能学不好时间关系。双流的思路则更保守一点先让空间流专心处理画面内结构让时间流专心处理跨帧变化最后再融合。这样可以减少模型在早期被过多任务干扰尤其在小数据和中等算力场景下效果往往比纯单流更容易调好。HunyuanVideo 使用的就是双流到单流的过渡结构先分别提取空间和时间特征再在最后的联合块里统一融合。本质上它是在单流和双流之间找一个折中点。所以准确地说不是“所有模型都在抄单流”而是越来越多的模型在结构设计上向统一 Transformer 靠拢。单流代表一种极简主义信仰结构越统一规模扩展时越不容易出岔子。而双流代表一种工程师的现实主义在有限的算力和数据里注入一些任务先验反而更稳。3.2 与 3D-CNN、RNN、U-Net 同场竞技DiT 赢在哪视频生成领域之前不是没有尝试过其他结构只是它们各有硬伤。3D-CNN 是 U-Net 的自然延伸把卷积核从二维变成三维直接对时空体素做卷积。它对局部运动有不错的捕捉能力但感受野有限画面左侧和右侧的长期一致性很难保证而且 3D 卷积的计算量增长很快。RNN 类方法把视频当时间序列一帧一帧地预测。它的优点是天然符合时间因果性计算量相对可控但在长序列上难以并行训练效率低而且信息在长距离传播中容易衰减到最后模型基本只记得最近几帧内容。U-Net 加临时注意力虽然能缓解一些问题但整体上还是保留了大量卷积操作。卷积的局部归纳偏置在小数据上是个加分项但在大数据、大模型情况下反而成了上限。它让人很难直观理解“参数量增加以后模型到底是变聪明了还是只是把固定的局部模式背得更熟”。DiT 的赢点在于把视频理解成一个纯序列问题用全局注意力建模任意距离的交互关系理论上不存在“太远了记不住”这个限制而且 Transformer 的架构非常统一加层、加头、加宽度都可以直接套现成的训练经验。Sora 之后各家动辄几十亿参数的视频模型几乎全部选择 DiT根本原因不是它结构新颖而是它在大规模算力下最能出效果。3.3 Token 序列有多长算力瓶颈从何而来DiT 最大的代价就是序列长。一个简单的换算一张 256×256 的图像如果 patch 大小是 4×4得到的 token 数量是 64×644096 个。对视频来说还要乘以时间维度假设 16 帧时间是 4 个 patch那 token 数量就是 4096×416384 个。这么多 token 做标准全局自注意力计算复杂度是 O(n²)显存消耗非常恐怖。因此工程上几乎没有任何生产级视频模型敢直接对所有 token 做完整全局注意力。常用的折中方案包括把注意力分解成空间注意力和时间注意力先在同一帧内做空间建模再在同一个空间位置上跨帧做时间建模或者用窗口注意力只让 token 在局部窗口内交互或者用 FlashAttention、SageAttention 这类高效算子降低显存占用。很多实现号称单流 DiT实际上注意力路径仍然是经过工程裁剪的不是字面意义上的所有 token 两两互联。理解这一点很重要。当你看到某个模型声称“全局时空注意力”时要去看它的代码里具体在哪里被切成了局部窗口在哪里做了降采样或 pooling。这决定了它能多连贯地生成数十秒长的视频也决定了你的 GPU 到底能不能跑起来。4. 从理解到上手DiT 类视频模型的实操笔记4.1 训练视频 DiT 的最小配置很多人看完架构分析就热血上头直接想训练一个 Sora。我的建议是先看明白最小配置有多重。数据方面你需要大量短视频片段每段最好都配有高质量文本描述。视频数据的处理链路通常包括抽帧、裁剪、缩放、去水印、清洗低质量片段、生成 caption 等步骤。caption 质量直接决定模型的指令跟随能力现在很多团队甚至先用一个强视觉语言模型为短视频自动生成详细描述再用作文本条件。算力方面如果只是微调或小规模训练一张 24GB 显存的消费级显卡也能跑但非常吃力。预训练一个能看的视频 DiT单卡 A100 80GB 是入门H100 更好。模型规模建议从小开始比如 hidden size 768、12 层 Transformer、12 个注意力头先拿 16 帧 256×256 的分辨率验证流程再逐步扩大。组件方面你需要一个时空 VAE 把视频压缩成隐空间一个文本编码器把 caption 变成向量一个 DiT 主干再加上一个 scheduler。Open-Sora 的代码仓库把这套流程封装得很清晰我建议第一次接触的人直接以它为参照不要从零造轮子。4.2 一条可以“抄作业”的最小训练流程基于常见实践我整理出一个非常简化但完整的训练循环演示 DiT 在视频数据上是怎么训练的。首先用预训练 VAE 把每段视频编码成隐空间张量。假设视频经过 VAE 后得到张量形状为 B×C×T×H×WB 是批量大小C 是隐空间通道T、H、W 分别是压缩后的时间、高、宽。接着把这些隐空间张量切成 patch并加上位置编码转换成 Transformer 输入序列。每个训练步骤大致如下def train_step(batch_videos, batch_texts): # 1. 视频过 VAE 编码器得到隐空间表示 latents vae.encode(batch_videos) # (B, C, T, H, W) # 2. 文本过 text encoder 得到文本向量 text_emb text_encoder(batch_texts) # (B, L, D) # 3. 把隐空间切成 patch拼上条件文本 token tokens patchify(latents) # (B, N, D_tok) tokens concat_text(tokens, text_emb) # 4. 随机采样时间步 t并按调度器加噪 t torch.randint(0, cfg.num_train_steps, (B,)) noise torch.randn_like(tokens) noisy_tokens scheduler.add_noise(tokens, noise, t) # 5. DiT 前向预测噪声或速度场 pred dit(noisy_tokens, t, conditiontext_emb) # 6. 计算损失反向传播 loss mse_loss(pred, noise) loss.backward() optimizer.step()真实项目里还会加入 EMA、学习率预热、梯度裁剪、混合精度等细节。但拿到这段流程你已经能理解 Open-Sora、CogVideoX 这类代码库在干什么了。我特别提醒一句视频数据最烦人的不是模型而是数据 padding 和 masking。不同视频片段帧数、宽高比都不一样怎么把它们凑成一个 batch怎么在时间维度上对齐是训练脚本里最容易出错的地方。4.3 推理采样和提速别一上来就生成超长视频训练完模型推理阶段同样有学问。默认情况下你需要从一个纯噪声张量出发循环调用 DiT 很多次每次预测噪声并更新隐空间。常用的采样器包括 DDIM、Euler、DPM-Solver 等。采样步数越多画面越稳定但速度越慢。用 flow matching 训练出来的模型一般 20 到 30 步就能得到不错效果传统 DDPM 模型可能需要 50 到 100 步。CFG 是另一个要调的关键参数。简单说CFG 就是同时让模型分别在“有条件”和“无条件”两种状态下预测再按权重把两种预测拉远让条件信息更强烈地影响生成结果。CFG 太低画面可能不符合文本描述CFG 太高画面会过饱和、出现不自然的伪影甚至颜色像滤镜糊了一层。视频模型常用的 CFG 范围大概在 3 到 7 之间具体要看你数据训练时的分布。不要一上来就生成几十秒的视频。经验做法是先让模型生成 8 到 16 帧的短视频验证效果稳定后再扩大帧数。需要长视频时很多工程方案是先生成关键帧再用插帧模型把中间帧补出来。这比让模型一步到位生成超长视频稳定得多。4.4 显存爆了、速度太慢我给你一套工程组合拳实际操作中大多数人遇到的第一个瓶颈就是显存。视频 DiT 的 attention 计算量和中间激活值都很大单卡很容易 OOM。我的建议是分步骤排查。第一升级 attention 实现。把 PyTorch 原生 attention 换成 FlashAttention 或者 SageAttention显存占用可能直接降一半速度还更快。第二开梯度检查点训练时用激活值换显存虽然速度变慢但能撑住更大的 batch。第三使用混合精度bf16 在 A100 和 H100 上非常稳定显存压力明显降低。第四模型并行和序列并行这是多卡环境下的进阶选择如果只是微调可以先用前三种方案。推理环节也有自己的技巧。VAE 解码通常是瓶颈之一可以把 VAE 参数先冻结并缓存到磁盘避免每轮推理重复编码。注意力缓存也有用先生成第一帧的隐状态后续帧重复利用部分键值能显著提速但处理不当容易造成闪烁。文字条件比较长的场景可以考虑对文本编码器进行离线预处理把文本向量提前算好省掉每次推理重复过文本编码器的时间。5. 常见问题与排查速查表5.1 训练不收敛、输出糊成一团先别急着怪模型训练 DiT 类视频模型时最常见的失败模式是生成结果一片模糊或者训练损失一直不降。这种问题往往不是模型结构错了而是哪一层环节没对齐。我的排查顺序是固定的。第一步检查 VAE 能否闭环。拿一段干净视频先编码再解码如果重建结果就很糊那问题在 VAE不在 DiT。第二步做小批量过拟合实验拿一条视频反复训练如果模型连这一条都学不会要么学习率不对要么条件信息没正确注入。第三步检查文本 embedding 是否真的进入了网络。很多新人会把文本在某个环节丢掉或者维度没对齐模型最后完全是在跑无条件生成自然不跟 prompt。第四步看学习率和优化器。视频 DiT 参数量大AdamW 配上 1e-4 左右的基础学习率比较常见还需要预热阶段。学习率太高很容易出现 NaN。还有一个容易忽略的问题数据本身脏。视频里有大量黑屏、重复帧、只有一个镜头不动的情况模型会疯狂学会“输出静态模糊画面”。数据清洗的质量往往比模型参数大小更能影响最终效果。5.2 生成长视频容易崩这不只是算力问题很多模型生成 16 帧效果不错但一旦让它生成 32 帧甚至更长画面就开始漂移物体变形动作断裂。这是视频 DiT 最核心的痛处。原因有几个层面。第一训练数据里的长片段太少模型没见过长距离时间依赖自然学不会。第二注意力范围受限如果实现里采用了窗口注意力跨长距离的信息交互不足物体离开窗口后就被“遗忘”。第三隐空间 VAE 的时间压缩会导致短时间细节被磨平帧与帧之间微小运动失真生成后表现为闪烁。第四自回归类生成策略会让误差逐步累积第一帧轻微偏差到了第 30 帧可能已经变成一个完全不同的画面。解决方向也很明确。从数据层面要尽量增加训练集中长片段比例或者采样时使用不同帧率。从模型层面可以考虑把窗口注意力范围扩大或者加入时间维度的全局注意力代价是算力上升。从后处理层面用插帧模型对相邻帧做平滑能挽回一部分视觉效果但无法解决根本问题。我个人的经验是把长视频任务拆成“短片段生成插帧拼合”的管线比强行训练超长生成模型要现实得多。5.3 开源 DiT 模型各有各的脾气横向对比与选型建议现在的开源视频生成模型数量已经很多但主流的 DiT 类方案就那几个各有各的侧重。Open-Sora 是社区里最活跃的开源实现模块化做得好从数据处理到训练、推理的文档都算齐全。它比较适合作为学习参考和二次开发基础你可以在它上面换 VAE、换文本编码器、调整 DiT 结构改动成本相对低。缺点是默认配置下长视频效果一般需要自己调。CogVideoX 是智谱开源的一套视频模型它的 3D VAE 压缩率很高模型体积从 2B 到 5B 都有对消费级显卡相对友好图生视频和文本生视频都支持。如果你追求开箱即用不想自己把整条训练管线搭起来CogVideoX 是很务实的选择。HunyuanVideo 是腾讯开源的大规模视频模型参数量大效果细腻视觉质量在开源模型里属于第一梯队。但它对显存和部署工程的要求也高适合有一定集群资源、追求最高生成质量的团队。Latte 是偏研究性质的项目结构最接近论文里的原始 DiT适合做学术实验、架构分析而不是直接当产品用。如果你刚开始接触视频模型我个人建议从 Open-Sora 或者 CogVideoX 入手先跑通一个 16 帧 256 分辨率的 demo观察生成质量再根据自己的硬件条件决定是否换更大模型。模型特点适合场景上手难度Open-Sora模块化清晰社区活跃学习、二次开发、工程调优中CogVideoX3D VAE模型体量较轻开箱即用、图生视频、短篇生成低HunyuanVideo参数量大生成质量高高质量视频生成、有集群资源高Latte结构接近论文原始 DiT学术研究、架构对比实验中5.4 问题速查表一次看懂现象、原因和对策最后把实际开发中经常遇到的问题整理成速查表方便你直接对照排查。现象可能原因对策显存 OOM分辨率/帧数太高注意力未优化降低输入大小、FlashAttention、梯度检查点、模型 offload训练损失 NaN学习率过高、混合精度不稳定降低学习率、关掉 AMP 试跑、检查输入数据是否有 NaN画面过曝光、色彩过饱和CFG 权重太高降低 CFG比如从 7 降到 3 或 4文本指令不跟随文本编码器容量不足、条件注入方式单一换更强文本编码器、增加交叉注意力、改善 prompt 模板生成视频闪烁VAE 时间不一致、推理连续性不足检查 VAETemporal重建、降低 CFG、用插帧后处理细节纹理差patch 过大、VAE 压缩丢失细节减小 patch 尺寸、用更高分辨率训练数据长视频物体漂移窗口注意力范围不够、训练长片段少增大注意力窗口、增加长片段数据、拆成短视频生成再拼接这几点几乎覆盖了我在复现视频 DiT 过程中踩过的所有典型坑。很多问题看起来是网络结构不对最后查下来要么是数据问题要么是工程配置问题。DIT 这个架构本身已经非常成熟真正拉开差距的往往是这些容易被忽略的细节。最后分享一点个人体会。我从开始复现 DiT 到现在最大的感受就是不要被“Transformer 扩散”这些大词唬住它本质就是一套非常工程化的管线——VAE 负责压缩DiT 负责在隐空间里猜出没有噪声的中间表示scheduler 负责一步步落笔。新人最容易卡住的往往是形状对齐这些枯燥环节视频 latent 的维度、patch 后的序列长度、时间步的 batch 维度每一步把张量形状打印出来问题就少了一半。如果你想进入视频生成这个领域不用指望一步到位练出 Sora 级模型先跑通一个 16 帧 256 分辨率的 DiT 流程理解每个模块的作用再考虑扩大规模。架构已经收敛到这种程度接下来拼的不是网络结构的新花样而是数据、算力和工程细节的硬功夫。这话听起来不太性感却是我踩了一堆坑之后最真实的体会。

相关新闻

SwiftUI + AI Agent + Skill:构建iOS智能工作台的实践指南

SwiftUI + AI Agent + Skill:构建iOS智能工作台的实践指南

开工之前先说明一下,这个 Side Project 我起名就叫 SwiftUI-Agent-Skill,名字比较直白:SwiftUI 负责界面,Agent 负责对话和决策,Skill 承载具体执行力。我最近一直在折腾它,目标是做一个跑在 iOS 上的轻量 …

2026/10/14 8:30:01 阅读更多 →
openclaw优先读取机制:让爬虫先抓重点,稳定应对动态渲染

openclaw优先读取机制:让爬虫先抓重点,稳定应对动态渲染

上个月我调一个抓取任务时遇到了一件让人头疼的事:页面内容明明几秒钟就返回了,可最重要的正文直到最后才被解析出来,又赶上那个区块走了动态渲染,超时后整个任务直接失败,重试了三轮才把数据补齐。后来我仔细看了日志…

2026/10/14 8:30:01 阅读更多 →
大a投资特性解析:高流动性、杠杆效应与政策关联

大a投资特性解析:高流动性、杠杆效应与政策关联

1. 视频内容概述"神奇的大a(上)"这期视频主要探讨了当前市场环境下一个备受关注的投资标的——我们暂且称之为"大a"的特殊表现。作为系列内容的第八集,本期聚焦于大a的基本特性、历史表现和近期市场反应,为下…

2026/10/14 8:30:01 阅读更多 →

最新新闻

Python爬虫技术实战:从基础到分布式架构

Python爬虫技术实战:从基础到分布式架构

1. 爬虫技术全景解析:从入门到分布式架构 十年前我刚接触爬虫时,用正则表达式硬解析HTML的日子还历历在目。如今Python生态已经形成了完整的爬虫技术栈,从简单的Requests单页抓取到Scrapy分布式架构,技术方案的选择往往让初学者感…

2026/10/14 9:27:10 阅读更多 →
IEEE33节点配电网模型解析与工程实践

IEEE33节点配电网模型解析与工程实践

1. IEEE33节点配电网模型概述 作为一名电力系统仿真工程师,我最近在项目中深度使用了IEEE33节点配电网模型。这个经典模型就像电力系统研究领域的"Hello World",但它的实用价值远超入门级工具。经过实测,我发现它不仅适合教学演示&…

2026/10/14 9:27:10 阅读更多 →
TCP可靠传输机制、滑动窗口控制与字节流粘包处理介绍

TCP可靠传输机制、滑动窗口控制与字节流粘包处理介绍

文章目录 一、TCP的可靠传输 1.连接管理保证可靠传输 1.1三次握手地建立连接 1.2四次挥手地断开连接 1.2.1每端异位切入,独立顺序执行 2.确认应答、超时重传保证可靠传输 2.1已到报文的复发重传 2.1.1超时重传可能 2.1.2快速重传不可能 2.2请求响应消息的应用 2.2.1…

2026/10/14 9:27:10 阅读更多 →
生物分类系统:从界到种的科学解析与应用

生物分类系统:从界到种的科学解析与应用

1. 生物分类系统概述生物分类学(Taxonomy)作为生物学的基础学科,其核心任务是对地球上的生物进行系统性的识别、描述、命名和归类。现代生物分类体系采用"界门纲目科属种"七级分类阶元,这套体系自18世纪林奈创立以来&am…

2026/10/14 9:27:10 阅读更多 →
STEP 7:程序块保护

STEP 7:程序块保护

使用STEP 7编程工具,如果想对特定的程序块进行加密,可以采用程序块加密方式,此种加密方式分为两种: KNOW_HOW_PROTECT Block Privacy1 KNOW_HOW_PROTECT保护程序块 KNOW_HOW_PROTECT加密程序块方式与CPU固件版本无关&#xff0c…

2026/10/14 9:27:10 阅读更多 →
2026低代码平台测评:企业级能力与开发效率深度解析

2026低代码平台测评:企业级能力与开发效率深度解析

1. 低代码平台行业现状与测评背景 2026年的低代码开发领域已经进入成熟期,平台数量从2020年的不足百家激增至现在的300。这种爆发式增长带来两个显著变化:一方面,头部厂商通过持续并购形成生态壁垒;另一方面,垂直行业解…

2026/10/14 9:26:09 阅读更多 →

日新闻

AnyPS5通用适配层设计:兼容性与性能的工程取舍

AnyPS5通用适配层设计:兼容性与性能的工程取舍

1. 从"AnyPS5"这个名字说起:它到底想解决什么问题第一次看到"AnyPS5"这个标题,我脑子里冒出来的第一个念头是:这大概率是一个围绕"跨平台运行"或者"通用适配"做文章的项目。名字里的"Any"…

2026/10/14 0:00:41 阅读更多 →
Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

1. 项目概述:Flutter跨平台二手交易应用开发作为一名长期从事移动应用开发的工程师,我最近完成了一个基于Flutter框架的二手物品交易平台项目。这个项目最吸引我的地方在于它完美结合了Flutter的跨平台优势与HarmonyOS的生态特性,实现了"…

2026/10/14 0:00:41 阅读更多 →
DFS算法解决飞机降落调度问题实战

DFS算法解决飞机降落调度问题实战

1. 项目背景与核心思路飞机降落问题是一个经典的调度优化场景,也是算法竞赛和面试中的高频题目。这个题目要求我们合理安排多架飞机的降落顺序和时间,确保所有飞机都能安全着陆而不发生冲突。在实际航空管制中,这类问题直接关系到飞行安全和机…

2026/10/14 0:00:41 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/13 16:22:04 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 22:01:27 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 7:53:34 阅读更多 →