通过 CUDA 缓存技术实现 AI 模型部署加速
分享AI模型部署提速的方法。
这两周都在研究AI模型的移植和优化，昨天晚上认真分析了一下部署模型的耗时，主要是三块：
1. 模型权重加载
2. KV Cache 初始化
3. 编译 CUDA 内核
权重加载和 KV Cache 初始化没有太多优化空间
加载权重和 KV Cache 初始化更多是模型从磁盘到显存的搬运和初始化过程，没有太多优化策略。
编译 CUDA 内核这一步完全没有必要
反而是 CUDA 内核编译却没有必要，所以我先在 T5000 芯片上编译 CUDA 内核，然后把编译好的 cache、triton、nv 等生成目录合成一个 CUDA 缓存包，用户只需要下载缓存包就可以加载 CUDA 内核，而不是每次加载模型都需要重新编译 CUDA 内核。
优化前后的耗时对比
通过这样的方式，我把整个重新部署的时间从 40 分钟，压缩到 16 分钟，大大节省了部署 AI 模型的时间。
via https://manateelazycat.github.io/feed.xml
Invalid media: image
分享AI模型部署提速的方法。
这两周都在研究AI模型的移植和优化，昨天晚上认真分析了一下部署模型的耗时，主要是三块：
1. 模型权重加载
2. KV Cache 初始化
3. 编译 CUDA 内核
权重加载和 KV Cache 初始化没有太多优化空间
加载权重和 KV Cache 初始化更多是模型从磁盘到显存的搬运和初始化过程，没有太多优化策略。
编译 CUDA 内核这一步完全没有必要
反而是 CUDA 内核编译却没有必要，所以我先在 T5000 芯片上编译 CUDA 内核，然后把编译好的 cache、triton、nv 等生成目录合成一个 CUDA 缓存包，用户只需要下载缓存包就可以加载 CUDA 内核，而不是每次加载模型都需要重新编译 CUDA 内核。
优化前后的耗时对比
通过这样的方式，我把整个重新部署的时间从 40 分钟，压缩到 16 分钟，大大节省了部署 AI 模型的时间。
via https://manateelazycat.github.io/feed.xml
Invalid media: image
给坦克500Hit4扩油箱
今天来把我的油箱换了，从 68 升换到 140 升 这样加上车上的电池，油电混合可以跑 1500 公里 这样可以轻松穿越中国任何一个无人区😎
坦克这种车，天然有两个加油口，官方就支持安装副油箱，但是安装副油箱的一个问题是，主油箱的油用完了以后，需要用压力泵把油从副油箱抽到主油箱，这种方式在野外极限越野的时候，容易油泵出现问题不泵油，导致你有油却开不动的问题
我这次改装的方式是，原车的油表/油管/电路都不动，直接用140升的新油箱替换原车68升的油箱，这样就不会存在油泵的问题了 看油表的时候，就看车机仪表盘，燃油剩余里程 x 2就是真实的油箱里程
via https://manateelazycat.github.io/feed.xml
Invalid media:
image
image
image
image
今天来把我的油箱换了，从 68 升换到 140 升 这样加上车上的电池，油电混合可以跑 1500 公里 这样可以轻松穿越中国任何一个无人区😎
坦克这种车，天然有两个加油口，官方就支持安装副油箱，但是安装副油箱的一个问题是，主油箱的油用完了以后，需要用压力泵把油从副油箱抽到主油箱，这种方式在野外极限越野的时候，容易油泵出现问题不泵油，导致你有油却开不动的问题
我这次改装的方式是，原车的油表/油管/电路都不动，直接用140升的新油箱替换原车68升的油箱，这样就不会存在油泵的问题了 看油表的时候，就看车机仪表盘，燃油剩余里程 x 2就是真实的油箱里程
via https://manateelazycat.github.io/feed.xml
Invalid media:
image
image
image
image
分享 Qwen AI 模型移植的经验给大家，避免像我这样踩坑
最近两周移植了 DeepSeek V4 Flash 和 Qwen 3.8 27B 的未审查版本，都没有问题 唯独 Qwen 3.8 Flash Next 的未审查版，5K 以上长输出会遇到“中英韩”的多国语言混合乱码问题
这个首先肯定是 Qwen 3.8 Flash Next 训练不严谨的问题，其他模型都不会乱码
同时需要配置好 AI Agent 的参数，我测试了很多遍，必须按照温度 0.3、top_p 0.95、top_k 20 的设定后，Pi Agent 中输出才不会乱码 另外模型 ID 也要统一，模型 ID、models id、Pi Agent id 都要设置为
今天忙了一天，把算力舱的 DeepSeek/GLM/Qwen/MiniMax 全部都更新了一遍，性能更强，显存/磁盘的管理也更加方便了 明天继续优化 Qwen 3.8 Flash Next 和 MiniMax H3，明天下午挑战两台算力舱跑最新的 DeepSeek V4.1！
via https://manateelazycat.github.io/feed.xml
最近两周移植了 DeepSeek V4 Flash 和 Qwen 3.8 27B 的未审查版本，都没有问题 唯独 Qwen 3.8 Flash Next 的未审查版，5K 以上长输出会遇到“中英韩”的多国语言混合乱码问题
这个首先肯定是 Qwen 3.8 Flash Next 训练不严谨的问题，其他模型都不会乱码
同时需要配置好 AI Agent 的参数，我测试了很多遍，必须按照温度 0.3、top_p 0.95、top_k 20 的设定后，Pi Agent 中输出才不会乱码 另外模型 ID 也要统一，模型 ID、models id、Pi Agent id 都要设置为
qwen3.8-flash-next-uncensored今天忙了一天，把算力舱的 DeepSeek/GLM/Qwen/MiniMax 全部都更新了一遍，性能更强，显存/磁盘的管理也更加方便了 明天继续优化 Qwen 3.8 Flash Next 和 MiniMax H3，明天下午挑战两台算力舱跑最新的 DeepSeek V4.1！
via https://manateelazycat.github.io/feed.xml
今天跟大家分享一下技术人创业需要补强的几个方面
1. 大方向要对，方向不对，就是勤奋自我感动。大方向来源于读书、交流、晒太阳、散步、深度思考
2. 大错不要犯，一般犯大错的原因就是自己在顺境中获取优势以后，自我膨胀。膨胀才会犯大错。避免犯大错的方法还是读书，多读历史书，看到古人作死的方式，就会时刻反省自己不要膨胀
3. 做事要果断，在 AI 时代，最重要的是你的判断力，执行力不是瓶颈了。判断力培养的方式就是要果断做决定，果断犯小错，也比优柔寡断不做决定好，因为 AI 时代的执行力很强，你犯的小错可以通过快速迭代来解决
via https://manateelazycat.github.io/feed.xml
1. 大方向要对，方向不对，就是勤奋自我感动。大方向来源于读书、交流、晒太阳、散步、深度思考
2. 大错不要犯，一般犯大错的原因就是自己在顺境中获取优势以后，自我膨胀。膨胀才会犯大错。避免犯大错的方法还是读书，多读历史书，看到古人作死的方式，就会时刻反省自己不要膨胀
3. 做事要果断，在 AI 时代，最重要的是你的判断力，执行力不是瓶颈了。判断力培养的方式就是要果断做决定，果断犯小错，也比优柔寡断不做决定好，因为 AI 时代的执行力很强，你犯的小错可以通过快速迭代来解决
via https://manateelazycat.github.io/feed.xml
超大 PDF 的流畅缩放优化
分享一下读书软件的深度优化技巧。
懒猫读书的后端是传输片段到前端去做实时渲染的。这样的好处就是不光传图片，前端可以直接用后端传输的原始数据进行文字标注和文字选中。
但是遇到很多超大的 PDF，传输 PDF 的原始数据就不现实了，因为会超级卡，甚至很多超大的 PDF 会把平板和手机的内存撑爆。
所以这种超大的 PDF 只能传缩略图，但是传缩略图又会导致放大的时候会有一定的模糊。
所以现在懒猫读书的方案是：
● 可编辑的文档传原始数据。
● 不可编辑的文档，像 PDF 扫描版传缩略图。
● 遇到缩放的时候再临时传输 tile 做高清晰渲染层。
这样就可以兼顾流畅性、前端内存的控制，同时针对极限缩放提供无极的清晰度。
今天终于把这个花雕完了，大家可以看一下我们实时放大的效果，还是很不错的。
via https://manateelazycat.github.io/feed.xml
Invalid media: video
分享一下读书软件的深度优化技巧。
懒猫读书的后端是传输片段到前端去做实时渲染的。这样的好处就是不光传图片，前端可以直接用后端传输的原始数据进行文字标注和文字选中。
但是遇到很多超大的 PDF，传输 PDF 的原始数据就不现实了，因为会超级卡，甚至很多超大的 PDF 会把平板和手机的内存撑爆。
所以这种超大的 PDF 只能传缩略图，但是传缩略图又会导致放大的时候会有一定的模糊。
所以现在懒猫读书的方案是：
● 可编辑的文档传原始数据。
● 不可编辑的文档，像 PDF 扫描版传缩略图。
● 遇到缩放的时候再临时传输 tile 做高清晰渲染层。
这样就可以兼顾流畅性、前端内存的控制，同时针对极限缩放提供无极的清晰度。
今天终于把这个花雕完了，大家可以看一下我们实时放大的效果，还是很不错的。
via https://manateelazycat.github.io/feed.xml
Invalid media: video
模型不同上下文的解码速度
这几天在做精细化的 AI 模型移植，发现一个特别有趣的现象。
Qwen 3.8 Flash Next 的甜品区是 265K 的上下文，它的解码速度最快。
Qwen 3.8 27B 的甜品区，不是 265K，也不是 900K，反而是 512K 的时候，它的解码速度最快。
这个测试结果是非常有意思的，分享给大家，赶快去把你的上下文调到最优的值吧😎
via https://manateelazycat.github.io/feed.xml
Invalid media: image
这几天在做精细化的 AI 模型移植，发现一个特别有趣的现象。
Qwen 3.8 Flash Next 的甜品区是 265K 的上下文，它的解码速度最快。
Qwen 3.8 27B 的甜品区，不是 265K，也不是 900K，反而是 512K 的时候，它的解码速度最快。
这个测试结果是非常有意思的，分享给大家，赶快去把你的上下文调到最优的值吧😎
via https://manateelazycat.github.io/feed.xml
Invalid media: image
GPT + Qwen 3.8 27B 协作工作流
我还是太爱 Qwen 3.8 27B 了，虽然没有 GPT 那么全能，但是只要是明确的任务，详细说好了，真的是指哪打哪。
很多朋友会问为什么不用解码速度更快的 Qwen 3.8 Flash Next？因为我这两三周都在做 AI 模型移植的工作，我发现 Qwen 3.8 Flash Next 这个模型训练的还是不够严谨，上下文非常长的时候，会出现乱码的情况，只能靠 Pi Agent 温度配置来缓解，而 Qwen 3.8 27B 各种稳定呀。
我现在都用 GPT 做规划，让 27B 去执行，效率杠杠的。
用 Pi Agent 配 Qwen 3.8 27B 修复博客视频问题的过程：
via https://manateelazycat.github.io/feed.xml
Invalid media: image
我还是太爱 Qwen 3.8 27B 了，虽然没有 GPT 那么全能，但是只要是明确的任务，详细说好了，真的是指哪打哪。
很多朋友会问为什么不用解码速度更快的 Qwen 3.8 Flash Next？因为我这两三周都在做 AI 模型移植的工作，我发现 Qwen 3.8 Flash Next 这个模型训练的还是不够严谨，上下文非常长的时候，会出现乱码的情况，只能靠 Pi Agent 温度配置来缓解，而 Qwen 3.8 27B 各种稳定呀。
我现在都用 GPT 做规划，让 27B 去执行，效率杠杠的。
用 Pi Agent 配 Qwen 3.8 27B 修复博客视频问题的过程：
via https://manateelazycat.github.io/feed.xml
Invalid media: image
AI 模型动态 KV Cache 技术分享。这两天我一直在研究上下文和 KV Cache 的动态调节技术，终于被我搞出来了。
现在用户部署的时候，KV Cache 会根据用户输入的上下文动态调节显存占用的值，而不是像原来那样通过
KV Cache 按照公式计算：
再按 256 MiB 对齐。
改动以后，Qwen 3.8 27B 512K 和 900K 上下文的显存差距可以拉到 30GB 左右，用户可以用多余的 30GB 显存并行跑其他模型。
via https://manateelazycat.github.io/feed.xml
现在用户部署的时候，KV Cache 会根据用户输入的上下文动态调节显存占用的值，而不是像原来那样通过
--gpu-memory-utilization 固定的显存分配申请。KV Cache 按照公式计算：
2 GiB + tokens × 87 KiB
再按 256 MiB 对齐。
改动以后，Qwen 3.8 27B 512K 和 900K 上下文的显存差距可以拉到 30GB 左右，用户可以用多余的 30GB 显存并行跑其他模型。
via https://manateelazycat.github.io/feed.xml
DeepSeek V4 Flash TP2 并发 Prefill 调优实战
DeepSeek 模型调优并发技术分享。最近都在调优 DeepSeek V4 Flash 的 TP2 模型，简单来说就是两台算力舱同时通过 TP2 的技术跑 DeepSeek。因为两台机器的显存总共超过 256 GB，所以即使是非常大的 DeepSeek 也可以提供 1MB 的超大上下文。
最近用户反馈多个并发的时候，第二个 Prefill 会等很久。今天上午研究了一会，发现跟 vLLM 的
问题定位：long-prefill-token-threshold 参数
最开始我移植 DeepSeek 的时候，觉得这个值设置为 2048 肯定够了。早上研究才发现，这个值不能设置得很大。因为太大了，vLLM 就会让第一个 Prefill 充分执行；当 Prefill 的值达不到 2048 的时候，后续的 Prefill 就会被排队。
需要调小这个值，给 vLLM 增加调度多个 Prefill 的机会。我测试了一上午，最后发现 1024 这个值最好。
测试结果对比
当设置为 1024 时，8 并发同时请求，后续的 Prefill 可以从最大的 90 秒的等待时间下降到 7 秒左右，而总吞吐只下降了 2.5%。
如果继续下降到 512，虽然后续请求的 TTFT 还会继续下降，但是总吞吐量就会下降到 15% 以上。
https://manateelazycat.github.io/pics/deepseek-tp2-prefill-tuning/prefill-threshold.png
从上面的测试数据可以看出：
● 1024 综合最好：短请求 TTFT 降低 35%~46%，A TTFT 增加约 2.5%，总吞吐下降约 2.5%。
● 512 延迟继续下降，但 A TTFT 增加约 18%，总吞吐下降约 15%，8 并发波动也更大。
● 当前线上已恢复为 2048，部署状态 succeeded/ready，健康检查通过。8 并发下的 waiting 4096-token 是调度预算，不是 KV 内存不足。
结语
今天的 AI 模型调优核心技术就分享到这里。欢迎大家购买懒猫 AI 算力舱 + 懒猫微服套餐，CEO 亲自给你调优 AI 模型性能，把设备的性能压到极限。
via https://manateelazycat.github.io/feed.xml
DeepSeek 模型调优并发技术分享。最近都在调优 DeepSeek V4 Flash 的 TP2 模型，简单来说就是两台算力舱同时通过 TP2 的技术跑 DeepSeek。因为两台机器的显存总共超过 256 GB，所以即使是非常大的 DeepSeek 也可以提供 1MB 的超大上下文。
最近用户反馈多个并发的时候，第二个 Prefill 会等很久。今天上午研究了一会，发现跟 vLLM 的
--long-prefill-token-threshold 参数有关。问题定位：long-prefill-token-threshold 参数
--long-prefill-token-threshold 是限制单个 Prefill 请求一次调度迭代中最多处理的 Tokens 数量，默认是 2048，最大可以设置成 4096。最开始我移植 DeepSeek 的时候，觉得这个值设置为 2048 肯定够了。早上研究才发现，这个值不能设置得很大。因为太大了，vLLM 就会让第一个 Prefill 充分执行；当 Prefill 的值达不到 2048 的时候，后续的 Prefill 就会被排队。
需要调小这个值，给 vLLM 增加调度多个 Prefill 的机会。我测试了一上午，最后发现 1024 这个值最好。
测试结果对比
当设置为 1024 时，8 并发同时请求，后续的 Prefill 可以从最大的 90 秒的等待时间下降到 7 秒左右，而总吞吐只下降了 2.5%。
如果继续下降到 512，虽然后续请求的 TTFT 还会继续下降，但是总吞吐量就会下降到 15% 以上。
https://manateelazycat.github.io/pics/deepseek-tp2-prefill-tuning/prefill-threshold.png
从上面的测试数据可以看出：
● 1024 综合最好：短请求 TTFT 降低 35%~46%，A TTFT 增加约 2.5%，总吞吐下降约 2.5%。
● 512 延迟继续下降，但 A TTFT 增加约 18%，总吞吐下降约 15%，8 并发波动也更大。
● 当前线上已恢复为 2048，部署状态 succeeded/ready，健康检查通过。8 并发下的 waiting 4096-token 是调度预算，不是 KV 内存不足。
结语
今天的 AI 模型调优核心技术就分享到这里。欢迎大家购买懒猫 AI 算力舱 + 懒猫微服套餐，CEO 亲自给你调优 AI 模型性能，把设备的性能压到极限。
via https://manateelazycat.github.io/feed.xml
2026 年江苏万驰国际赛车场一日游
这是走出上海赛道的第一步，来到了江苏万驰赛车场，开启人生中天马以外的第一个房车赛道。
万驰赛车场名义上是一个「AAA 级旅游景区」，入口的大门看上去像是一个高级小区的门口，在进门前左右手边都是居民楼，阳台可以直接看到整个赛道，不知道这个赛景房的居民居住体验是如何的。
价格方面，多亏了江浙沪富哥哥们的努力，万驰赛道在江浙沪地区一再被冷漠，已经开始官方直接出售 399 元一整天的体验票，于是趁着周二去南京████的机会，周三体验了一次一整天只要 399 元的活动（实际上是 434 ： 399 + 5 （手环费？）+ 30 （保险费））。（日常价格依然和天马对齐，是 500 元一节）
从万驰的赛道图可以看到，不像天马只要会踩刹车就行，万驰有大量依赖节奏的连续弯，例如 T4~T7 组合弯，每个弯的入弯和出弯状态会直接影响下一个弯的进弯节奏，需要根据每个车不同的动力，布局和已有的一些特性逐渐掌握一个适合自己车的最佳路线，且许多弯心速度不低，循迹控制不好很容易把车尾甩出去，整体来说比天马有趣/难/危险的多。
此外，不像天马基本只有 T7 高速弯略微有些危险，万驰中著名的「海螺弯」（T8） 需要在 T7 全油出后一路全油到达 T9 走 double apex 或者超晚弯心路线，且 T9 刹车点前全程全油，侧向 G 值几乎一直稳定 > 1G ，非常刺激。
这一次由于到达时间较晚，错过了早上第一节，只跑了 5 节，其中还包括带人上场跑，Racechorno 的记录如下（从早到晚是，从右往左）：
上场第一节开着空调开着 ESP 带人跑出的最快成绩是 1:23:1 ，到了下午稍微熟悉了一些之后，关闭了空调关闭了 ESP 最快单人成绩是 1:21:02 ，不过下午由于 Knock Control 在持续增高（从 0.49 -> 0.70），动力应该有所衰减。
这一次万驰练习下来感觉暴露出我个人对于真车驾驶的一个很大的问题：循迹刹车不够稳定，由于之前模拟器练习基本都是驾驶 GT3 为主，且 ACC 对于循迹刹车只要求做一个刹车的假动作车头就已经可以入弯了，加之之前练习的赛道都是天马，天马似乎只有 T1 和 T4 对于循迹略有要求，导致我在万驰的 T2，T12 非常推头（要么刹车直接松完快速丢方向开始推头，要么刹车晚了一点带着较大的刹车丢方向导致推头），导致即使有 -2 度的前轮外倾角，胎肩磨损依然很大：
右前轮上午跑完两节后的状态：
右后轮上午跑完两节后的状态：
导出了 Racechorno 的数据喂给 ChatGPT 后也有类似的结论：
最快圈记录如下：
当天下午还看到了在 T1 末尾小米保留环节：
车载视频
YouTube
iframe (www.youtube.com)
Bilibili
iframe (External Player - 哔哩哔哩嵌入式外链播放器)
整体来说第一次来跑能跑到 1:21 还是比较满意的，详细赛道练习记录放在了 https://fk7.nova.moe/track/logs/2026-09-wantrack/ ，期待下次再来。
via Posts on Nova Kwok's Awesome Blog
Invalid media:
image
image
image
image
image
image
image
image
image
image
image
这是走出上海赛道的第一步，来到了江苏万驰赛车场，开启人生中天马以外的第一个房车赛道。
万驰赛车场名义上是一个「AAA 级旅游景区」，入口的大门看上去像是一个高级小区的门口，在进门前左右手边都是居民楼，阳台可以直接看到整个赛道，不知道这个赛景房的居民居住体验是如何的。
价格方面，多亏了江浙沪富哥哥们的努力，万驰赛道在江浙沪地区一再被冷漠，已经开始官方直接出售 399 元一整天的体验票，于是趁着周二去南京████的机会，周三体验了一次一整天只要 399 元的活动（实际上是 434 ： 399 + 5 （手环费？）+ 30 （保险费））。（日常价格依然和天马对齐，是 500 元一节）
从万驰的赛道图可以看到，不像天马只要会踩刹车就行，万驰有大量依赖节奏的连续弯，例如 T4~T7 组合弯，每个弯的入弯和出弯状态会直接影响下一个弯的进弯节奏，需要根据每个车不同的动力，布局和已有的一些特性逐渐掌握一个适合自己车的最佳路线，且许多弯心速度不低，循迹控制不好很容易把车尾甩出去，整体来说比天马有趣/难/危险的多。
此外，不像天马基本只有 T7 高速弯略微有些危险，万驰中著名的「海螺弯」（T8） 需要在 T7 全油出后一路全油到达 T9 走 double apex 或者超晚弯心路线，且 T9 刹车点前全程全油，侧向 G 值几乎一直稳定 > 1G ，非常刺激。
这一次由于到达时间较晚，错过了早上第一节，只跑了 5 节，其中还包括带人上场跑，Racechorno 的记录如下（从早到晚是，从右往左）：
上场第一节开着空调开着 ESP 带人跑出的最快成绩是 1:23:1 ，到了下午稍微熟悉了一些之后，关闭了空调关闭了 ESP 最快单人成绩是 1:21:02 ，不过下午由于 Knock Control 在持续增高（从 0.49 -> 0.70），动力应该有所衰减。
这一次万驰练习下来感觉暴露出我个人对于真车驾驶的一个很大的问题：循迹刹车不够稳定，由于之前模拟器练习基本都是驾驶 GT3 为主，且 ACC 对于循迹刹车只要求做一个刹车的假动作车头就已经可以入弯了，加之之前练习的赛道都是天马，天马似乎只有 T1 和 T4 对于循迹略有要求，导致我在万驰的 T2，T12 非常推头（要么刹车直接松完快速丢方向开始推头，要么刹车晚了一点带着较大的刹车丢方向导致推头），导致即使有 -2 度的前轮外倾角，胎肩磨损依然很大：
右前轮上午跑完两节后的状态：
右后轮上午跑完两节后的状态：
导出了 Racechorno 的数据喂给 ChatGPT 后也有类似的结论：
你现在已经不是“先把车开顺”的阶段了，当前主要瓶颈是中低速连续弯里的减速量与放刹时机，以及几个弯之间的速度连接；重刹能力、快速弯胆量和单圈基本节奏已经相当稳定。
最值得注意的是 T3–T5。在你其他快圈里，T4 曾经以大约 87.7 km/h 通过，相比 80.84 圈高接近 8 km/h；T5 也有大约 77 km/h 的记录，比最快圈高 4 km/h 左右，而且对应小段确实更快。这不像单纯“别人走了不一样的线造成 GPS 误差”，而更像是 80.84 那一圈在这组弯里多减了一点速度。
所以这里下一次不要先想着“把刹车点再延后五米”。更有效的是：同一个刹车点附近保持首次制动强度，然后更早、更连续地释放刹车，让车在入弯阶段保留 3–5 km/h；尤其不要出现已经释放后又二次补刹、重新把前轮压死的情况。 你最快局部数据已经证明车能承受更高速度。
最快圈记录如下：
当天下午还看到了在 T1 末尾小米保留环节：
车载视频
YouTube
iframe (www.youtube.com)
Bilibili
iframe (External Player - 哔哩哔哩嵌入式外链播放器)
整体来说第一次来跑能跑到 1:21 还是比较满意的，详细赛道练习记录放在了 https://fk7.nova.moe/track/logs/2026-09-wantrack/ ，期待下次再来。
via Posts on Nova Kwok's Awesome Blog
Invalid media:
image
image
image
image
image
image
image
image
image
image
image
vLLM PK Ninfer, 到底谁的速度更快?
最近发现很多人说 Ninfer 这个专门为 Qwen 系列优化的推理框架性能很猛。
我这两天用 Qwen 3.8 27B 测试了一下，在开启 CUDA Graph 的情况下，反而 vLLM 性能更强，Decode 和 Prefill 性能全面超越 Ninfer。
vLLM 的极限性能
Qwen 3.8 27B 的 Fresh Code 解码速度最高达到 63.34 TPS，Prefill 最高达到 3230 TPS，TTFT 更是低到 0.15 秒。
基准测试数据对比
下面是 Ninfer 和 vLLM 两组配置的基准测试数据，vLLM 是优化后的配置：
可以看到，在绝大多数场景下 vLLM 配置都更快，差距最悬殊的是 250K Prefill 和 250K TTFT，Ninfer 相对 vLLM 落后了 54.5%。
优化后的提升
vLLM 优化后，三类单流 Decode 提升约 8.6%～14.5%，5K Prefill 提升 60.7%，并发吞吐提升约 15.6%，250K Prefill 提升 13.6%。
等我再压榨压榨，把 Qwen 3.8 27B 的速度整到极限。
via https://manateelazycat.github.io/feed.xml
Invalid media: image
最近发现很多人说 Ninfer 这个专门为 Qwen 系列优化的推理框架性能很猛。
我这两天用 Qwen 3.8 27B 测试了一下，在开启 CUDA Graph 的情况下，反而 vLLM 性能更强，Decode 和 Prefill 性能全面超越 Ninfer。
vLLM 的极限性能
Qwen 3.8 27B 的 Fresh Code 解码速度最高达到 63.34 TPS，Prefill 最高达到 3230 TPS，TTFT 更是低到 0.15 秒。
基准测试数据对比
下面是 Ninfer 和 vLLM 两组配置的基准测试数据，vLLM 是优化后的配置：
可以看到，在绝大多数场景下 vLLM 配置都更快，差距最悬殊的是 250K Prefill 和 250K TTFT，Ninfer 相对 vLLM 落后了 54.5%。
优化后的提升
vLLM 优化后，三类单流 Decode 提升约 8.6%～14.5%，5K Prefill 提升 60.7%，并发吞吐提升约 15.6%，250K Prefill 提升 13.6%。
等我再压榨压榨，把 Qwen 3.8 27B 的速度整到极限。
via https://manateelazycat.github.io/feed.xml
Invalid media: image
极限优化 Qwen 3.8 27B 的性能
上一篇文章《vLLM PK Ninfer, 到底谁的速度更快?》里说”等我再压榨压榨，把 Qwen 3.8 27B 的速度整到极限”。现在迷上了 AI 模型调优，今天就把 Qwen 3.8 27B 压榨到了极限：
● Fresh Code 解码速度提升到 65.88 TPS
● 重度代码编辑解码提升到 123 TPS
● Prefill 提升到 3176 TPS
● TTFT 降低到 0.1 秒
两组配置对比数据
下面是两组配置（124 和 104）的真实端到端吞吐对比，均包含 TTFT，五项中位数也全部由 124 领先：
TTFT 同样明显改善：
结语
太爽了，错过算力舱就错过了世界上性能最快的 Qwen 3.8 27B。
原推
via https://manateelazycat.github.io/feed.xml
Invalid media: image
上一篇文章《vLLM PK Ninfer, 到底谁的速度更快?》里说”等我再压榨压榨，把 Qwen 3.8 27B 的速度整到极限”。现在迷上了 AI 模型调优，今天就把 Qwen 3.8 27B 压榨到了极限：
● Fresh Code 解码速度提升到 65.88 TPS
● 重度代码编辑解码提升到 123 TPS
● Prefill 提升到 3176 TPS
● TTFT 降低到 0.1 秒
两组配置对比数据
下面是两组配置（124 和 104）的真实端到端吞吐对比，均包含 TTFT，五项中位数也全部由 124 领先：
TTFT 同样明显改善：
结语
太爽了，错过算力舱就错过了世界上性能最快的 Qwen 3.8 27B。
原推
via https://manateelazycat.github.io/feed.xml
Invalid media: image
不需要 ComfyUI 即可用 MiniMax H3 生成视频。
昨晚对 MiniMax H3 做了一个优化，通过把 BF16 Qwen3-VL 32B 这个编码器做了量化，把 64GB 显存占用压缩到 16GB，这样编码器就可以和 H3 的视频生成模型共存。
通过这样的优化，就可以把原来 H3 只能生成预先准备好的提示词，改成通过编码器实现一个”文本翻译器”，把用户的文字提示词转换成视频模型能理解的数据，最后交给 MiniMax H3 生成视频。
最后直接通过调用 MiniMax H3 的 API，文本即可生成视频，不需要安装 ComfyUI。
via https://manateelazycat.github.io/feed.xml
昨晚对 MiniMax H3 做了一个优化，通过把 BF16 Qwen3-VL 32B 这个编码器做了量化，把 64GB 显存占用压缩到 16GB，这样编码器就可以和 H3 的视频生成模型共存。
通过这样的优化，就可以把原来 H3 只能生成预先准备好的提示词，改成通过编码器实现一个”文本翻译器”，把用户的文字提示词转换成视频模型能理解的数据，最后交给 MiniMax H3 生成视频。
最后直接通过调用 MiniMax H3 的 API，文本即可生成视频，不需要安装 ComfyUI。
via https://manateelazycat.github.io/feed.xml
分享 Qwen 3.8 Flash Next 模型调优经验
上周用户反馈 Qwen 3.8 Flash Next 未审查版在长上下文的时候会遇到多国语言乱码的问题，所以上周我移植了一下 Qwen 3.8 Flash Next 原版，问题解决了，代价就是不能破甲。
昨天晚上我好奇，怎么修复破甲的问题，感谢懒猫的用户郭总指点，说可以用提示词”逐层比对精度偏差”来解决中英日韩俄漂移的问题。
最后成功 1MB 上下文测试中，成功解决，解决方案如下：
1. GDN 循环状态使用 BF16
每生成一个 token 都会读取并更新循环状态。BF16 的舍入误差会随生成长度和网络层数不断累积，最终导致隐藏状态偏移，出现语言混杂、标点异常和重复循环。
2. 量化 lm_head 放大误差
FP4/FP8 lm_head 会扰动相近 token 的概率排序，使已经偏移的隐藏状态更容易选中错误字符，并在自回归生成中持续放大。
修复方法
修复方法是将 GDN 循环状态恢复为 FP32，同时让 lm_head 使用原生 BF16；模型主体仍保持 NVFP4，因此不需要把整个模型恢复为高精度。
逐层对比显示，BF16 状态的相对误差会从第 0 层的约 0.017% 增长到第 43 层的约 12.69%。修复后，连续生成约 1.1 万 tokens 未再出现多语言漂移和符号循环。代价是显存占用增加，并发量和生成速度有所下降。
总结
所以大家要长时间使用 Qwen 3.8 Flash Next 建议还是用官方原版做量化，不要破甲，这样比较稳定。要破甲的话，建议只做研究使用，不建议做日常生产力。
via https://manateelazycat.github.io/feed.xml
上周用户反馈 Qwen 3.8 Flash Next 未审查版在长上下文的时候会遇到多国语言乱码的问题，所以上周我移植了一下 Qwen 3.8 Flash Next 原版，问题解决了，代价就是不能破甲。
昨天晚上我好奇，怎么修复破甲的问题，感谢懒猫的用户郭总指点，说可以用提示词”逐层比对精度偏差”来解决中英日韩俄漂移的问题。
最后成功 1MB 上下文测试中，成功解决，解决方案如下：
1. GDN 循环状态使用 BF16
每生成一个 token 都会读取并更新循环状态。BF16 的舍入误差会随生成长度和网络层数不断累积，最终导致隐藏状态偏移，出现语言混杂、标点异常和重复循环。
2. 量化 lm_head 放大误差
FP4/FP8 lm_head 会扰动相近 token 的概率排序，使已经偏移的隐藏状态更容易选中错误字符，并在自回归生成中持续放大。
修复方法
修复方法是将 GDN 循环状态恢复为 FP32，同时让 lm_head 使用原生 BF16；模型主体仍保持 NVFP4，因此不需要把整个模型恢复为高精度。
逐层对比显示，BF16 状态的相对误差会从第 0 层的约 0.017% 增长到第 43 层的约 12.69%。修复后，连续生成约 1.1 万 tokens 未再出现多语言漂移和符号循环。代价是显存占用增加，并发量和生成速度有所下降。
总结
所以大家要长时间使用 Qwen 3.8 Flash Next 建议还是用官方原版做量化，不要破甲，这样比较稳定。要破甲的话，建议只做研究使用，不建议做日常生产力。
via https://manateelazycat.github.io/feed.xml
Omarchy 第一坑 Flclash 默认启动不了
今天在一台新装的 Arch Linux 上配置 FlClash，自建的 Reality 节点一直显示 Timeout。排查后发现有两个问题：节点缺少 TLS 指纹配置，导致代理握手失败；系统还有残留的 IPv6 路由，导致 TUN 启动失败。两个问题叠在一起，看起来都是网络不通。
排查这种问题，先把连接过程拆开：电脑能不能连接服务器，代理协议能不能完成握手，系统流量有没有进入代理。每一步出错，都可能在界面上显示超时。先检查服务器，443 端口可以连接，普通 TLS 握手也能成功。这只能说明服务器能够到达，还不能证明 Reality 代理能用。继续看代理核心日志，发现：
意思是 Reality 需要 uTLS，请配置客户端指纹。不同浏览器发起 TLS 连接时，握手消息的格式和参数组合有所不同。uTLS 可以模拟这些特征，
问题就在这里。当前安装的内核已经移除了这个全局选项，需要把指纹写到具体的代理节点里面。找到配置中
Linux 上 FlClash 导入的配置通常保存在
接着检查 TUN。普通代理和 TUN 的工作方式不同，上面的
核心启动 TUN 时，报了另一个错误。这是创建网卡路由时失败，和刚才的 Reality 握手不是同一个环节：
查看 IPv6 策略路由，发现一条异常规则：
这里的
再次执行下面的命令，这次能看到
最后还要验证系统流量是否真的被接管。去掉显式代理，执行：
via https://manateelazycat.github.io/feed.xml
今天在一台新装的 Arch Linux 上配置 FlClash，自建的 Reality 节点一直显示 Timeout。排查后发现有两个问题：节点缺少 TLS 指纹配置，导致代理握手失败；系统还有残留的 IPv6 路由，导致 TUN 启动失败。两个问题叠在一起，看起来都是网络不通。
排查这种问题，先把连接过程拆开：电脑能不能连接服务器，代理协议能不能完成握手，系统流量有没有进入代理。每一步出错，都可能在界面上显示超时。先检查服务器，443 端口可以连接，普通 TLS 握手也能成功。这只能说明服务器能够到达，还不能证明 Reality 代理能用。继续看代理核心日志，发现：
REALITY is based on uTLS, please set a client-fingerprint
意思是 Reality 需要 uTLS，请配置客户端指纹。不同浏览器发起 TLS 连接时，握手消息的格式和参数组合有所不同。uTLS 可以模拟这些特征，
client-fingerprint: chrome 就是让客户端使用 Chrome 的握手特征，这套内核的 Reality 实现依赖它。检查配置，节点里面没有这个字段，只有一条全局设置：global-client-fingerprint: random
问题就在这里。当前安装的内核已经移除了这个全局选项，需要把指纹写到具体的代理节点里面。找到配置中
type: vless 的那个节点，添加下面这一行，缩进和节点的 type、server、port 对齐：client-fingerprint: chrome
Linux 上 FlClash 导入的配置通常保存在
~/.local/share/com.follow.clash/profiles/。修改后重新加载配置，用命令验证：curl --noproxy '' -x http://127.0.0.1:7890 \
--max-time 10 -sS -o /dev/null -w '%{http_code}\n' \
https://www.gstatic.com/generate_204
-x 明确指定使用 FlClash 的本地代理，--noproxy '' 避免环境里的绕过设置影响测试。这个检测地址正常返回 204，表示请求成功，不需要返回正文。补上指纹后，测试返回 204，整个请求不到一秒，节点已经能用了。这里还有一个细节：握手失败的日志级别是 warning，客户端原来却设置成了 error，所以关键提示被过滤掉了。排查时先把日志级别调到 warning 或 debug。接着检查 TUN。普通代理和 TUN 的工作方式不同，上面的
curl -x 主动把请求交给本地代理；TUN 则需要创建虚拟网卡、安装路由，把系统流量接进来。所以普通代理能用，还要继续验证 TUN。虽然界面上开启了 TUN，但执行下面的命令，系统里没有 FlClash 网卡：ip -br address
核心启动 TUN 时，报了另一个错误。这是创建网卡路由时失败，和刚才的 Reality 握手不是同一个环节：
configure tun interface: add route 1: no route to host
查看 IPv6 策略路由，发现一条异常规则：
ip -6 rule
9000: from all unreachable
这里的
9000 是优先级，数字越小越先执行。from all unreachable 表示匹配所有来源，并直接返回不可达。它排在正常查询主路由表的规则前面，所以即使 Wi-Fi 有 IPv6 地址和默认路由，流量也会先被它拒绝。TUN 网卡已经不存在，这条规则却还留着。再看 IPv4，也能发现规则引用了已经不存在的接口：ip rule
iif FlClash [detached]
detached 表示规则引用的接口已经不存在。网卡消失了，相关的路由规则没有清理完整。这次恢复时，我临时用仅启用 IPv4 的 TUN 配置启动核心，绕过出错的 IPv6 路由创建步骤，再正常停止，让核心执行自己的路由清理。确认残留规则消失后，恢复原来的 IPv6 配置，重新启动 FlClash。再次执行下面的命令，这次能看到
FlClash 网卡，同时具有 IPv4 和 IPv6 地址，TUN 成功启动：ip -br address
最后还要验证系统流量是否真的被接管。去掉显式代理，执行：
curl --noproxy '*' \
--max-time 10 -sS -o /dev/null -w '%{http_code}\n' \
https://www.gstatic.com/generate_204
--noproxy '*' 让 curl 忽略应用层代理设置，但不会绕过系统的 TUN 路由，这样才能验证透明代理是否工作。这次同样返回 204，继续测试 GitHub 和百度，都返回 200，普通代理和 TUN 两条路径都恢复正常了。via https://manateelazycat.github.io/feed.xml
Omarchy 安装手册
最近终于把懒猫AI算力舱的模型优化的差不多了，今天下午没有忍住，开始折腾 Omarchy。
先说一下优点：
1. 安装器非常极简，我非常喜欢，特别适合 Linux 高级玩家
2. 安装时间总共只消耗了 56 秒，太夸张了，也从侧面证明 Omarchy 非常的精简
3. 指纹通过通知来添加，非常符合直觉，很好用
4. 锁屏动画非常黑客风格，很喜欢
5. 很多设置都是通过终端弹出一个命令行来搞定，虽然没有那么多 UI，但是对于一些一次性的设置来说，弹出一个终端非常顺手
6. 内置 Agent，这个非常实用啊，有啥需要折腾的，直接让 AI 上就好了
下面是 Omarchy 开机会折腾的事情：
修改镜像源
需要修改默认的镜像源，加速系统更新和软件包安装速度。
ArchLinuxCN
添加 ArchLinuxCN 的源，ArchLinuxCN 有很多中国用户需要的软件包，在
ArchLinux Mirror
修改
导入镜像源的 GPG Key
更新系统
配置代理
装好系统后，首先配置代理，要不是啥都干不了。代理配置可以参考：代理配置 2026-06-26 Xray VPS 一键部署
配置输入法
目前 Linux 下最流畅的输入法方案就是雾凇输入法，词库精心配置，输入体验非常流畅。
具体的配置看：Fcitx 最佳配置实践 2026-03-17
默认使用 Fish
Fish 4.0 引入 Kitty Keyboard Protocols 协议，会导致 pyte 基础的终端产生额外的 5u 字符，需要在配置文件
默认使用 micro
nano 用了很多年还是不习惯，换 micro 吧。
安装 micro 并让 git 默认使用 micro：
via https://manateelazycat.github.io/feed.xml
最近终于把懒猫AI算力舱的模型优化的差不多了，今天下午没有忍住，开始折腾 Omarchy。
先说一下优点：
1. 安装器非常极简，我非常喜欢，特别适合 Linux 高级玩家
2. 安装时间总共只消耗了 56 秒，太夸张了，也从侧面证明 Omarchy 非常的精简
3. 指纹通过通知来添加，非常符合直觉，很好用
4. 锁屏动画非常黑客风格，很喜欢
5. 很多设置都是通过终端弹出一个命令行来搞定，虽然没有那么多 UI，但是对于一些一次性的设置来说，弹出一个终端非常顺手
6. 内置 Agent，这个非常实用啊，有啥需要折腾的，直接让 AI 上就好了
下面是 Omarchy 开机会折腾的事情：
修改镜像源
需要修改默认的镜像源，加速系统更新和软件包安装速度。
ArchLinuxCN
添加 ArchLinuxCN 的源，ArchLinuxCN 有很多中国用户需要的软件包，在
/etc/pacman.conf 配置文件末尾加上：[archlinuxcn]
Server = https://mirrors.ustc.edu.cn/archlinuxcn/$arch
ArchLinux Mirror
修改
/etc/pacman.d/mirrorlist：## China
Server = https://mirrors.ustc.edu.cn/archlinux/$repo/os/$arch
导入镜像源的 GPG Key
sudo pacman -S archlinuxcn-keyring
sudo pacman -S archlinux-keyring
更新系统
sudo pacman -Syyu
配置代理
装好系统后，首先配置代理，要不是啥都干不了。代理配置可以参考：代理配置 2026-06-26 Xray VPS 一键部署
配置输入法
目前 Linux 下最流畅的输入法方案就是雾凇输入法，词库精心配置，输入体验非常流畅。
具体的配置看：Fcitx 最佳配置实践 2026-03-17
默认使用 Fish
sudo pacman -S fish
chsh -s $(which fish)
Fish 4.0 引入 Kitty Keyboard Protocols 协议，会导致 pyte 基础的终端产生额外的 5u 字符，需要在配置文件
~/.config/fish/config.fish 中添加下面配置禁用 Kitty 协议：set -Ua fish_features no-keyboard-protocols
默认使用 micro
nano 用了很多年还是不习惯，换 micro 吧。
安装 micro 并让 git 默认使用 micro：
sudo pacman -S micro
git config --global core.editor "micro"
via https://manateelazycat.github.io/feed.xml
Omarchy Workspace Gallery 像 GNOME Shell 一样管理工作区
我的第五个 Omarchy 插件
大家是不是都怀念 10 多年前 GNOME 3 最开始发布时带来的惊艳？最惊艳的就是它的工作区预览模式，可以随意地在大小工作区之间拖拽窗口，快速整理工作区。
这种设计，不管是 Floating WM 还是 Tiled WM，其实都非常实用。今天我开发了我的第五个 Omarchy 插件 Omarchy Workspace Gallery。
可以三指上滑进入预览状态，三指左右滑动切换工作区，上下工作区中的窗口可以随意拖拽，完美复刻 GNOME Shell 的核心功能。
所有代码已经在评论区按照 GPL 3.0 协议开源，Enjoy！
via https://manateelazycat.github.io/feed.xml
Invalid media: video
我的第五个 Omarchy 插件
大家是不是都怀念 10 多年前 GNOME 3 最开始发布时带来的惊艳？最惊艳的就是它的工作区预览模式，可以随意地在大小工作区之间拖拽窗口，快速整理工作区。
这种设计，不管是 Floating WM 还是 Tiled WM，其实都非常实用。今天我开发了我的第五个 Omarchy 插件 Omarchy Workspace Gallery。
可以三指上滑进入预览状态，三指左右滑动切换工作区，上下工作区中的窗口可以随意拖拽，完美复刻 GNOME Shell 的核心功能。
所有代码已经在评论区按照 GPL 3.0 协议开源，Enjoy！
via https://manateelazycat.github.io/feed.xml
Invalid media: video
Omarchy Window Switcher 带预览的窗口切换器
我的第一个 Omarchy 插件
Omarchy 默认的 Tile 设计很像我当年用的 i3/awesome/Xmonad，这种完全依靠快捷键跳转窗口的方式非常高效。
但是根据我 20 多年设计 Linux 桌面系统的经验，不管是 Tile 还是 Floating 的窗口设计，都需要窗口预览。因为窗口很多，需要让用户先在小窗口里面查看一下再切换。没有预览直接切换，第一会晃眼睛，闪得厉害；第二没有边界感，不知道还剩多少窗口，反而浪费用户时间。
我基于 Orbit 和 Overview Window 插件改造了一下，直接安装 Omarchy Window Switcher，装好就可以用 Alt + Tab 切换工作区内的窗口，用 Super + Tab 切换工作区，不需要做任何设置，开箱即用。
源代码在评论区，按照 MIT 许可证发布，Enjoy!
via https://manateelazycat.github.io/feed.xml
Invalid media: video
我的第一个 Omarchy 插件
Omarchy 默认的 Tile 设计很像我当年用的 i3/awesome/Xmonad，这种完全依靠快捷键跳转窗口的方式非常高效。
但是根据我 20 多年设计 Linux 桌面系统的经验，不管是 Tile 还是 Floating 的窗口设计，都需要窗口预览。因为窗口很多，需要让用户先在小窗口里面查看一下再切换。没有预览直接切换，第一会晃眼睛，闪得厉害；第二没有边界感，不知道还剩多少窗口，反而浪费用户时间。
我基于 Orbit 和 Overview Window 插件改造了一下，直接安装 Omarchy Window Switcher，装好就可以用 Alt + Tab 切换工作区内的窗口，用 Super + Tab 切换工作区，不需要做任何设置，开箱即用。
源代码在评论区，按照 MIT 许可证发布，Enjoy!
via https://manateelazycat.github.io/feed.xml
Invalid media: video
Omarchy Tray Bar 更直观高效的系统托盘
我的第二个 Omarchy 插件
Omarchy 整个系统的默认设计非常简洁，特别适合工程师。只是默认的托盘设计是在右上角放一个箭头，每次查看托盘消息，都需要小心翼翼地点击箭头，等显示动画弹出来以后才能点击应用托盘图标。这个设计模仿自 GNOME Shell，好看是好看，但是非常不实用。
我重新设计了一个插件 Omarchy Tray Bar，安装以后自动展示所有托盘，随时随地都可以看到托盘状态，点击也非常直观高效。
源代码按照我最喜欢的 GPL 3.0 发布，放到评论区了，稍后发布到 Omarchy 插件商店。
via https://manateelazycat.github.io/feed.xml
Invalid media: image
我的第二个 Omarchy 插件
Omarchy 整个系统的默认设计非常简洁，特别适合工程师。只是默认的托盘设计是在右上角放一个箭头，每次查看托盘消息，都需要小心翼翼地点击箭头，等显示动画弹出来以后才能点击应用托盘图标。这个设计模仿自 GNOME Shell，好看是好看，但是非常不实用。
我重新设计了一个插件 Omarchy Tray Bar，安装以后自动展示所有托盘，随时随地都可以看到托盘状态，点击也非常直观高效。
源代码按照我最喜欢的 GPL 3.0 发布，放到评论区了，稍后发布到 Omarchy 插件商店。
via https://manateelazycat.github.io/feed.xml
Invalid media: image
Omarchy Smart Gaps 单窗口自动隐藏空隙和描边
我的第四个 Omarchy 插件
Omarchy 是一个 Tile WM，多个窗口平铺的时候，配合半透明的窗口，隐隐约约能看到下面的桌面壁纸，确实很赛博朋克，也很好看。
但是一些效率应用，比如浏览器或者文件管理器，单独放在一个工作区的时候，如果工作区只有一个窗口，依然显示窗口周边的空隙和描边，就不是那么好看，而且浪费屏幕空间，少了沉浸工作的感觉。
所以我写了 Omarchy Smart Gaps 这个插件。当工作区只有一个窗口的时候，自动隐藏窗口周边的空隙和描边，让工作更加专注。
代码按照 GPL 3.0 开源，评论区有链接，Enjoy！
via https://manateelazycat.github.io/feed.xml
Invalid media: video
我的第四个 Omarchy 插件
Omarchy 是一个 Tile WM，多个窗口平铺的时候，配合半透明的窗口，隐隐约约能看到下面的桌面壁纸，确实很赛博朋克，也很好看。
但是一些效率应用，比如浏览器或者文件管理器，单独放在一个工作区的时候，如果工作区只有一个窗口，依然显示窗口周边的空隙和描边，就不是那么好看，而且浪费屏幕空间，少了沉浸工作的感觉。
所以我写了 Omarchy Smart Gaps 这个插件。当工作区只有一个窗口的时候，自动隐藏窗口周边的空隙和描边，让工作更加专注。
代码按照 GPL 3.0 开源，评论区有链接，Enjoy！
via https://manateelazycat.github.io/feed.xml
Invalid media: video