airllm:消费级显卡本地推理大模型的分层加载与量化实践
1. 大模型本地推理的显存困局与airllm的破局思路显存不够这件事几乎是每个想在自己机器上跑大模型的人都会撞上的第一堵墙。一张消费级显卡动辄8GB、12GB、24GB显存而一个70B参数量的模型光是权重加载进去就要吃掉140GB左右的显存空间这还没算上推理过程中的KV Cache和中间激活值。结果就是大多数人要么放弃本地部署要么被迫去租云端的多卡实例成本一下子就上去了。airllm这个项目做的事情说白了就是让大模型能在显存极其有限的机器上跑起来。它的核心思路并不复杂既然一次性装不下整个模型那就把模型按层切开用的时候加载一层、算完就释放像流水线一样逐层推进。这样一来显存占用就从整个模型的大小变成了单层模型的大小量级上的差异非常明显。我第一次接触这个思路的时候直觉反应是这不就是把磁盘当显存用吗速度肯定慢得没法看。但实际跑下来发现它的设计比我想的要精细得多。它并不是简单地把所有层都往磁盘上扔而是做了分层管理、预加载策略和量化压缩的组合拳。具体来说airllm支持对模型进行4bit或8bit量化后再分层存储这样每一层的数据量本身就缩小了磁盘IO的压力也随之降低。同时它在推理时会提前把下一层加载到内存中形成一种类似CPU流水线的预取机制尽量减少GPU等待数据的时间。这个项目适合什么人呢我觉得有三类人特别值得关注。第一类是手头只有一张消费级显卡、但想跑大参数模型的开发者比如你有一张RTX 3060 12GB想跑一个70B的模型做实验airllm能帮你实现。第二类是做模型推理优化研究的人airllm的分层加载策略本身就是一个很好的研究对象你可以基于它做各种改进实验。第三类是对成本敏感的独立开发者或小团队不想花大价钱租多卡实例用airllm配合自己的机器就能跑起来。当然它也不是没有代价的。分层加载意味着大量的磁盘读写如果你的硬盘是机械盘那速度会让你怀疑人生。即使是NVMe固态推理速度也会比全量加载慢不少。所以airllm的定位很明确它解决的是能不能跑的问题而不是跑得快不快的问题。你得先能跑起来才谈得上优化速度。2. airllm的核心机制拆解与关键技术点2.1 分层加载与推理流水线的工作原理airllm最核心的机制就是分层加载。一个Transformer架构的大模型本质上是由几十到上百个结构相似的层堆叠而成的。每一层包含自注意力机制和前馈网络层与层之间是串行关系——第N层的输出是第N1层的输入。这个特性决定了你可以把每一层独立看待不需要同时把所有层都放在显存里。具体的工作流程是这样的模型被预先切分成单独的层文件存储在磁盘上。推理开始后airllm先把第一层加载到GPU显存中执行前向计算得到中间结果。然后释放第一层的显存加载第二层继续计算。如此反复直到所有层计算完毕输出最终结果。这个过程听起来简单但实际实现时要处理很多细节问题。第一个细节是层的粒度划分。如果按单个Transformer层来切分一个70B模型大约有80层每层大约1.75GBFP16精度。这意味着显存至少要有2GB以上的空闲空间来容纳单层。如果显存更小还可以进一步把单层拆分成注意力部分和前馈部分分别加载。airllm在这方面做了自适应的处理会根据可用显存自动调整加载粒度。第二个细节是预取策略。如果严格按加载-计算-释放-加载的串行方式来做GPU在加载数据的时候是空闲的这就造成了计算资源的浪费。airllm的做法是在计算第N层的同时异步地把第N1层从磁盘读到内存缓冲区。等第N层算完第N1层的数据已经在内存里准备好了只需要从内存拷贝到显存即可。这个预取机制能显著减少GPU的等待时间。第三个细节是KV Cache的管理。在生成式推理中每次生成一个新token都需要用到之前所有token的Key和Value矩阵。如果每层算完就释放那KV Cache也会丢失下次生成新token时又得重新计算所有层。airllm的处理方式是把KV Cache单独存储在内存或显存中不随层释放而丢弃。但KV Cache本身也会占用不少空间尤其是长序列生成时。所以airllm也提供了KV Cache的量化选项用精度换空间。2.2 量化压缩在airllm中的实际应用量化是airllm另一个关键武器。分层加载解决的是空间不够的问题量化解决的则是数据太大的问题。两者结合才能让大模型在消费级硬件上真正跑起来。airllm支持的主要是4bit和8bit量化。8bit量化相对温和模型精度损失很小基本上肉眼看不出来输出质量的下降。4bit量化更激进模型体积能压缩到原来的四分之一左右但精度损失会稍微明显一些尤其是在需要精细推理的任务上。我实测下来对于一般的对话和文本生成任务4bit量化的效果完全可以接受但在代码生成或数学推理这类对精度敏感的场景8bit会更稳妥。量化的具体做法通常有两种一种是训练后量化直接把训练好的FP16权重映射到低比特表示另一种是量化感知训练在训练阶段就模拟量化误差让模型适应低精度。airllm用的是训练后量化因为它的定位是推理加速不涉及重新训练。训练后量化里又分对称量化和非对称量化airllm默认用的是对称量化因为实现简单且对硬件友好。这里有个容易踩的坑不是所有层都适合用同样的量化精度。有些层对精度特别敏感比如注意力机制中的QKV投影层量化太狠会导致注意力分布偏移输出质量急剧下降。airllm的做法是对这些敏感层保持较高精度对其他层用更低精度。这种混合精度的策略能在压缩率和质量之间找到更好的平衡点。2.3 磁盘IO与内存缓冲的协同设计分层加载的瓶颈往往不在GPU而在磁盘IO。每次加载一层都要从磁盘读取几百MB到几GB的数据如果磁盘速度跟不上GPU再快也没用。airllm在IO层面做了几件事来缓解这个问题。首先是文件格式的优化。airllm把每一层保存为独立的二进制文件而不是一个大文件。这样做的好处是可以按需读取不需要一次性打开整个模型文件。同时它用了内存映射的方式读取文件操作系统会自动把常用的层缓存在页缓存里重复加载同一层时速度会快很多。其次是内存缓冲区的设计。airllm在系统内存中维护了一个层缓存池最近使用过的层会留在缓存里。如果推理过程中需要反复调用某些层比如自回归生成时每步都要过所有层缓存命中率会很高实际磁盘读取次数远小于理论值。缓存池的大小可以根据可用内存灵活配置内存越大缓存命中率越高速度越快。第三是IO调度策略。airllm会优先加载即将使用的层而不是按顺序盲目预取。在自回归生成中每一轮生成都需要从第一层走到最后一层所以预取策略是当前层算完后立即预取下一层。但在某些特殊场景下比如beam search可能需要同时维护多条候选路径这时候预取策略就要相应调整优先保证主路径的层加载。3. 从零开始搭建airllm推理环境的完整实操3.1 环境准备与依赖安装在开始之前你需要确认自己的硬件条件。最低要求是一张支持CUDA的NVIDIA显卡显存至少4GB。系统内存建议16GB以上因为层缓存和KV Cache都会占用内存。硬盘必须是NVMe固态机械盘虽然也能跑但速度会让你失去耐心。我实测过用机械盘跑一个13B模型生成一个token要等十几秒完全没法用。软件环境方面Python版本建议3.9到3.11之间太新的版本可能有些依赖还没适配。CUDA版本建议11.8或12.1这两个版本兼容性最好。PyTorch要装对应CUDA版本的别装成CPU版本了否则airllm会直接报错说找不到GPU。安装airllm本身很简单一条pip命令就行pip install airllm但这里有个坑airllm的依赖里包含了一些编译型的包比如bitsandbytes在某些系统上可能需要提前装好编译工具链。如果你在安装过程中遇到编译错误先装一下build-essential和cmake再重试。安装完成后验证一下是否正常from airllm import AutoModel print(airllm imported successfully)如果这行代码能跑通不报错说明基础环境没问题了。3.2 模型下载与分层转换airllm支持直接从HuggingFace加载模型但第一次加载时会自动做分层转换这个过程比较耗时。以70B模型为例下载加转换可能需要几个小时取决于你的网速和磁盘速度。建议提前把模型下载到本地然后用本地路径加载避免重复下载。分层转换的逻辑是这样的airllm读取原始模型文件按Transformer层切分每一层单独保存为一个文件。同时它会记录每一层的元信息比如层类型、参数形状、量化配置等存成一个索引文件。推理时根据索引文件按需加载对应的层文件。转换过程中有几个参数可以调。layer_shards_saving_path指定分层文件的保存路径建议放在NVMe固态上。compression指定量化方式可选4bit、8bit或None。profiling_mode开启后会输出每一层的加载时间和计算时间方便你定位瓶颈。from airllm import AutoModel model AutoModel.from_pretrained( model_name_or_path, layer_shards_saving_path/path/to/nvme/airllm_shards, compression4bit, profiling_modeTrue )第一次运行会触发分层转换你会看到进度条一层一层地推进。转换完成后后续加载就直接读分层文件了速度快很多。3.3 推理参数配置与性能调优模型加载好之后推理参数的配置直接影响生成速度和输出质量。airllm的推理接口和HuggingFace的transformers很像但多了几个特有的参数。max_new_tokens控制生成的最大长度这个参数越大生成时间越长因为每一轮都要过所有层。do_sample和temperature控制采样的随机性做确定性任务时把do_sample设为False。use_cache控制是否启用KV Cache启用后生成速度会快很多但会占用额外内存。input_text 请解释一下什么是分层加载 input_ids tokenizer(input_text, return_tensorspt).input_ids output model.generate( input_ids, max_new_tokens128, do_sampleFalse, use_cacheTrue, temperature0.7 )性能调优方面最有效的手段是调整层缓存大小。airllm提供了一个layer_cache_size参数控制内存中缓存多少层。缓存越大磁盘读取越少速度越快。但缓存太大会导致内存不足系统开始用交换分区反而更慢。我的经验是缓存大小设为总层数的三分之一到一半比较合适既能保证较高的命中率又不会把内存吃满。另一个调优手段是调整预取深度。prefetch_depth参数控制提前加载多少层。设为1表示只预取下一层设为2表示预取下两层。预取深度越大GPU等待时间越短但内存占用也越大。在内存充足的情况下适当增加预取深度能明显提升吞吐量。4. 实际部署中绕不开的坑与排查手册4.1 显存溢出与内存泄漏的排查路径即使airllm已经把显存占用降到了单层级别仍然有可能遇到显存溢出。最常见的原因是KV Cache没有正确释放。在长序列生成时KV Cache会随着序列长度线性增长如果序列特别长KV Cache本身就可能超过单层的大小。排查这个问题的第一步是打开profiling模式观察每一轮生成后的显存占用变化。如果显存占用持续增长而不释放基本可以确定是KV Cache的问题。解决办法是限制最大序列长度或者启用KV Cache量化。airllm支持把KV Cache也做8bit量化能省一半空间。另一个显存溢出的原因是层加载粒度太粗。有些模型的单层特别大比如某些MoE架构的模型单层可能包含多个专家网络参数量远超普通层。这时候需要把加载粒度进一步细化把单层拆成多个子模块分别加载。airllm的auto_split参数可以自动处理这种情况但需要手动开启。内存泄漏则更多出现在长时间运行的场景。Python的垃圾回收机制有时候不能及时释放GPU内存尤其是当你在循环中反复调用generate时。解决办法是定期手动调用torch.cuda.empty_cache()强制释放未使用的显存。但要注意这个操作会清空所有缓存包括有用的层缓存所以不能太频繁建议每生成几百个token后调用一次。4.2 生成速度过慢的优化策略速度慢是airllm用户反馈最多的问题。原因可能有很多需要逐一排查。首先看磁盘IO是否是瓶颈。在profiling输出中如果每层的加载时间远大于计算时间那瓶颈就在磁盘。解决办法是换更快的NVMe固态或者增大层缓存减少磁盘读取。我实测过同样的模型放在SATA固态上比NVMe固态慢将近一倍放在机械盘上慢十倍以上。其次看GPU利用率。如果GPU利用率长期低于50%说明GPU在等数据瓶颈在数据供给端。这时候可以增加预取深度让数据提前准备好。另外检查一下PCIe带宽如果显卡插在PCIe 3.0 x4的插槽上带宽会成为瓶颈换成x16插槽能明显改善。还有一个容易被忽略的点是CPU解码。如果模型做了量化加载到显存后需要CPU先解码再传给GPU。如果CPU性能太弱解码速度跟不上也会拖慢整体速度。这种情况下可以尝试用GPU解码airllm提供了gpu_dequant选项但需要显卡支持相应的指令集。4.3 常见问题速查表问题现象可能原因排查方法解决方案显存溢出KV Cache过大profiling观察显存变化限制序列长度或启用量化生成速度极慢磁盘IO瓶颈对比加载时间和计算时间换NVMe固态或增大缓存输出质量差量化精度过低对比不同量化配置的输出改用8bit或混合精度加载报错依赖版本冲突检查bitsandbytes和torch版本重装匹配版本内存泄漏GPU缓存未释放监控显存占用趋势定期调用empty_cache层加载失败分层文件损坏检查文件完整性删除后重新转换这张表是我在实际使用中总结出来的基本上覆盖了90%以上的常见问题。遇到新问题时建议先按这个表排查一遍能省不少时间。5. 进阶玩法airllm的扩展与二次开发5.1 自定义分层策略适配特殊模型架构airllm默认的分层策略是按Transformer层切分这对大多数模型都适用。但有些模型架构比较特殊比如包含跨层连接或共享权重的模型简单的按层切分可能会破坏模型结构。这时候就需要自定义分层策略。airllm提供了custom_layer_split_fn参数允许你传入一个自定义函数来决定如何切分模型。这个函数接收模型对象返回一个层列表每个元素是一个可独立加载和计算的模块。你可以根据模型的具体结构把共享权重的部分单独提取出来或者把跨层连接的两层合并成一个加载单元。举个例子某些模型在注意力层和前馈层之间有权重共享如果分开加载每次都要重复加载共享权重浪费IO。自定义分层时可以把它们合并成一个单元一次加载完成。这样虽然单次加载的数据量大了但总IO次数减少了整体速度反而更快。5.2 多卡并行的可行性探索airllm本身是为单卡场景设计的但它的分层加载机制天然适合扩展到多卡。思路很简单把不同的层分配到不同的显卡上每张卡只负责自己那几层的计算。层与层之间的中间结果通过PCIe或NVLink传输。这种并行方式属于流水线并行和传统的数据并行、张量并行都不一样。它的优势是对显存要求低每张卡只需要容纳自己负责的层。劣势是卡间通信开销大如果PCIe带宽不够通信时间可能超过计算时间。airllm目前没有内置多卡支持但你可以基于它的分层加载接口自己实现。核心工作是管理一个层到卡的映射表以及在层切换时做设备间的数据传输。我试过一个简单的双卡实现把前半层放卡0后半层放卡1速度比单卡快了将近一倍。但卡间传输确实是个瓶颈如果换成NVLink连接提升会更明显。5.3 与推理框架的集成思路airllm可以和其他推理优化框架结合使用取长补短。比如vLLM的PagedAttention对KV Cache管理做了很好的优化但它的前提是模型能全部加载到显存。你可以用airllm做分层加载把每一层加载后交给vLLM的注意力计算模块处理这样既解决了显存问题又享受了PagedAttention的高效KV Cache管理。另一个思路是和ONNX Runtime集成。airllm负责分层加载每一层导出为ONNX格式用ONNX Runtime做推理。ONNX Runtime对算子融合和硬件加速做了很多优化单层推理速度可能比PyTorch快不少。但导出ONNX需要额外的转换步骤而且不是所有模型都支持动态导出需要根据具体情况评估。这些集成方案都需要一定的开发工作量适合对性能有极致追求且愿意折腾的人。如果你只是想快速跑起来直接用airllm的原生接口就够了。6. 一些实操后的个人体会用airllm跑了几个模型之后我最大的感受是它确实解决了从0到1的问题。以前想跑大模型第一道门槛就是硬件现在这个门槛被大大降低了。虽然速度上还有妥协但至少能让更多人有机会在本地跑起来大模型这个价值是实实在在的。几个我觉得比较实用的经验第一硬盘速度比显卡性能更重要如果你打算长期用airllm投资一块好的NVMe固态比升级显卡更划算。第二量化配置要根据任务来选对话类任务用4bit完全够用代码和数学类任务建议8bit。第三层缓存大小不要设得太激进留一些内存给系统和KV Cache否则容易触发交换分区反而更慢。还有一个容易被忽略的点是模型的选择。不是所有模型都适合用airllm跑。有些模型层数少但单层特别大分层加载的收益就不明显。有些模型层数多但每层很小分层加载的效果就很好。一般来说层数在40层以上的模型比较适合airllm层数太少的话分层带来的IO开销可能超过收益。最后分享一个小技巧如果你只是想做推理实验不需要每次都加载完整模型可以用airllm的partial_load功能只加载模型的前几层和后几层中间层用随机权重代替。这样能快速验证推理流程是否跑通等流程没问题了再加载完整模型。这个技巧在调试阶段特别省时间。

相关新闻

# 开发者自认快了20%,实测却慢了19%?把官方指南里“人的职责”当效率争议的参照系

# 开发者自认快了20%,实测却慢了19%?把官方指南里“人的职责”当效率争议的参照系

一个反直觉的数字 AI 编程到底让开发者变快还是变慢了?这可能是当前软件行业最有争议的问题之一。 一方面,Stack Overflow 的 2025 年开发者调查显示,65% 的开发者至少每周使用 AI 编程工具;GitHub、Google 和 Microsoft 的早期…

2026/10/19 12:13:26 阅读更多 →
华为MetaERP 在 Fusion Applications Control(本质是 OEM Fusion Middleware Control 套壳)里做性能瓶颈定位,日志分析工具不是孤立用的,而

华为MetaERP 在 Fusion Applications Control(本质是 OEM Fusion Middleware Control 套壳)里做性能瓶颈定位,日志分析工具不是孤立用的,而

在 Fusion Applications Control(本质是 OEM Fusion Middleware Control 套壳)里做性能瓶颈定位,日志分析工具不是孤立用的,而是和 Metrics / Problem Analysis / ECID 串联 / ADF Request 分析 / SOA Flow Trace / JVM Diagnosti…

2026/10/19 12:12:24 阅读更多 →
软考系统架构设计师论文涉及知识点之Prometheus(2)

软考系统架构设计师论文涉及知识点之Prometheus(2)

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

2026/10/19 12:12:24 阅读更多 →

最新新闻

C标准库源码深度剖析:从printf到malloc的底层实现与移植指南

C标准库源码深度剖析:从printf到malloc的底层实现与移植指南

简介:这份资源是C标准库的完整源代码集合,面向希望深入理解C语言底层实现、提升系统级编程能力的开发者与学习者。它涵盖输入输出、字符串处理、内存管理、数学运算、时间日期、文件系统接口等核心模块,适合在阅读源码、优化性能或进行底层开…

2026/10/19 13:00:15 阅读更多 →
AI图像生成提示词工程:从一句话到稳定可复刻配方

AI图像生成提示词工程:从一句话到稳定可复刻配方

你有没有过这种体验:好不容易憋出一句描述,丢给生成工具,出来的图和脑子里想的完全不是一回事,换两次种子还是不对,于是觉得是模型不行,或者干脆怪自己运气差。 我也经历过这个阶段。后来把提示词从“一句…

2026/10/19 13:00:15 阅读更多 →
2026年AI Agent构建全栈应用:多Agent协作与工程化实践指南

2026年AI Agent构建全栈应用:多Agent协作与工程化实践指南

1. 为什么“AI Agent 构建全栈应用”在2026年成了绕不开的命题2026年再聊“用 AI Agent 构建全栈应用”,如果还停留在“让模型帮我补全一段函数”的层面,那基本等于白聊。我从2024年开始陆续用 Agent 跑过十几个大小项目,从内部工具到面向用户…

2026/10/19 13:00:15 阅读更多 →
AIoT端侧猫狗识别实战:从模型选型到多模态融合的工程化落地

AIoT端侧猫狗识别实战:从模型选型到多模态融合的工程化落地

1. 从一个喂食器的误触发说起:AIoT端侧识别的真实门槛去年帮一个做宠物硬件的团队看他们的智能喂食器样机,场景很简单:猫靠近就出粮,狗靠近不出粮,防止狗偷吃猫粮。听起来是个二分类问题,ImageNet上随便一个…

2026/10/19 13:00:15 阅读更多 →
AI生产力全链路:输入-认知-输出三层解耦与协议化协同

AI生产力全链路:输入-认知-输出三层解耦与协议化协同

1. “三位一体AI生态”不是营销话术,而是生产力链路的物理切分“三位一体AI生态”这个词最近在不少技术社区和产品发布会里高频出现,但很多人听完只记得个概念,回去一想——这到底跟我每天要写的周报、要调的模型、要改的PRD有什么关系&#…

2026/10/19 13:00:15 阅读更多 →
工业时序预测实战:基于CNN-BiLSTM-Attention的三模态融合模型

工业时序预测实战:基于CNN-BiLSTM-Attention的三模态融合模型

1. 三模态融合的架构设计与选型理由1.1 为什么偏偏是CNN、BiLSTM、Attention三件套工业时序预测(比如设备剩余寿命预测、关键部件温度趋势预估、整线能耗滚动预报)有一个共性痛点:数据维度高、噪声大、时间依赖长,单靠一种模型总是…

2026/10/19 12:59:13 阅读更多 →

日新闻

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

简介:本资源为电源技术方向的学术研究文档,聚焦介质阻挡放电型臭氧发生器电源的频率跟踪型PWM控制策略,面向电力电子、高压电源及臭氧应用领域的科研人员与工程技术人员。针对负载呈容性、等效电容随外加电压升高而增大、谐振频率随之漂移的难…

2026/10/19 0:00:47 阅读更多 →
Vibe Coding 遇上 TaoToken:把开发者思维圣殿的灵感流接入统一 Key 通道

Vibe Coding 遇上 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/19 0:00:47 阅读更多 →
HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

【免费下载链接】HundredCV-Chat 项目地址: https://ai.gitcode.com/hf_mirrors/Jax-dan/HundredCV-Chat 点击查看 免费下载 HundredCV-Chat 是一个由 100 位青年简历数据开发而来的中文多轮对话数据集,共包含 24,750 组日常闲聊对话和 4,871 个话题标签…

2026/10/19 0:00:47 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/19 10:02:04 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/18 0:00:55 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/19 1:30:52 阅读更多 →

月新闻

我发现了一个新思路:用 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/19 2:54:50 阅读更多 →
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/19 9:10:22 阅读更多 →
黑夜航拍船只数据集训练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/18 12:16:16 阅读更多 →