2026-08-29 00:00:00
算力舱AI模型适配实录：
通过两台协同计算的方式，一台计算一半最终对结果，实现稳定 70 TPS 的效果，顺带把上下文从 131K 拉到了 382K。主打日常 Agent 全能。
稠密计算模型小钢炮，通过 DFlash2 优化，最终实现单流 125 ~ 133 TPS、8 并发 231 TPS 的效果。虽然 27B 稠密模型计算非常耗费性能，但是显存消耗不多，可以做大量 KV Cache。最终通过 YaRN 技术把上下文从官方的 265K 拉到恐怖的 900K，代码智力爆表 + 超大上下文。主打离线代码 GPT。
相对于社区两台方案，昨晚实现单台就可以稳定跑。昨晚首先测试了 n-gram 的方案，虽然 decode 速度最高可以到 92 TPS，但发现这个方案纯粹是噱头——只有抄重复代码的时候快，Prefill 只有 100 多，而且上下文太小只有 64K。最后还是换传统的 MTP 方案，现在日常解码稳定在 60 TPS，Prefill 2232 TPS，上下文也增大了 265K，这样的数据更适合日常写代码。
看看我晚上能优化到什么水平？
等 Qwen 3.8 Flash Next 优化完，我准备继续挑战两台 GLM 5.3 Flash。大佬们你们想要我移植什么 AI 模型？评论区留下你的建议 😎
2026-08-29 00:00:00
20 年古法编程，非遗手法就是 “远程把脉”。
今天有一个用户反映懒猫读书会导致平板卡死，我一看，好家伙，超大文件 PDF 彩印文件。
原因很清楚了：PDF 过于大，首屏渲染高清图片加上后面几页预加载，瞬间内存过大触发了果子家的 OOM，直接把前端 WebView 进程干死了。
做更精细的视口渲染，保持清晰度和操作不变的情况下，让后端只发屏幕区域和缩放比例的图，把内存占用控制在常量，减少 90% 的内存占用，这样果子就不会杀进程了。
远程定位问题，三下五除二找到根因，这就是二十年老程序员的手感。
2026-08-28 00:00:00
NND，今天正在用 Pi Agent + Qwen 3.8 27B 整活呢，突然就报错了
我最开始还以为是 Pi Agent 配置和 Qwen 不兼容，最后发现不是。
然后我又以为是我部署的 Qwen 3.8 27B 模型有问题，看了一圈不对啊，Qwen 3.8 27B 本身就是多模态的模型呀。
最后发现，NND，原来是部署的时候 vLLM 默认加了下面这两个参数：
--limit-mm-per-prompt.image 2
--limit-mm-per-prompt.video 0
第一个的意思是，如果上下文超过 2 张图片，vLLM 就直接报错，第二个的意思是，禁止发送视频文件给大模型。
我把这两个参数删除以后，重启 Docker，世界安静了，Qwen 3.8 27B 又开始干活了。
2026-08-28 00:00:00
有人建议测一下开启 YaRN 扩展上下文后的表现，说 Qwen 3.8 27B 可以扩展到 1M 上下文。
我试了一下，Qwen 3.8 27B 通过 YaRN 技术最多可以把上下文从原版 265K 增加到 768K。
1M 上下文主要是 KV Cache 就需要 84GB 显存，差 3GB 显存😂
在这台 128GB 机器上的具体测试结果：
当前统一内存约使用 107.5/125.8 GB，可用约 17 GB，因此这台 128GB 机器目前实用上限是 768K，不是 1M。
我一会试一下这个 768K 上下文的时候，在日常的编程中能不能打，不能光看参数，我要去实战压测一下😎
2026-08-28 00:00:00
挑战成功，Qwen 3.8 27B 实现 900K 的代码上下文。
利用 YaRN 技术实现 Qwen 3.8 27B 模型从 786K 提升到 900K 的挑战，整个模型占了 120GB 的显存。
900K 的上下文无限接近于 1M 上下文，意味着世界上 99% 的代码项目，利用 Qwen 3.8 27B 本地 AI 都很难遇到因为上下文不足而降智的问题。
做个对比：
懒猫 AI 算力舱跑 Qwen 3.8 27B 不但速度超快，还可以不降智地支持 99% 的大型代码项目稳定运行。
