2026-08-31 00:00:00
Qwen 3.8 Flash Next 在单台懒猫AI算力舱上反复优化，这个应该达到极限了：Decode 100 ~ 102 TPS，Prefill 2070 ~ 2609 TPS，TTFT 5K 1.9s。
接下来把上下文增大。官方是 265K 的上下文，但是显存没用满呀，所以我通过 YaRN 技术把 Qwen 3.8 Flash Next 的 KV Cache 调大到 16GB，这样上下文就从 265K 搞到 320K 了。
除了 Fresh Decode 稍微下降一点点，其他的指标兜没变，甚至 Edit Decode 速度还提升了，哈哈哈哈。
优化了72小时后，Qwen 3.8 Flash Next 终于被我调教的差不多了，明天整要给图形化的部署程序给懒猫AI算力舱的用户用。
而社区DGX GB10要两台才能做到 100+ TPS，为啥算力舱可以一台搞定呢？因为 FP4 的算力，算力舱是GB10的2倍，因为算力够，显存够，一台算力舱直接访问显存的速度要比两台GB10的光口快太多了，反而效率更高。
2026-08-31 00:00:00
世界纪录，Qwen 3.8 Flash Next 单台 102 TPS！
经过三天的优化，我已经把 Qwen 3.8 Flash Next 在单台算力舱的 Decode 速度实现了从 23 TPS -> 65 TPS -> 102 TPS 的跨越，应该还可以再提升一点。
在 102 TPS decode 速度下，18K Prefill 的速度实现了 2588 TPS，30K TTFT 实现 11.43s。
这个数据估计很多两台 DGX 都很难达到，因为在 FP4 的精度下，我们算力舱的 T5000 芯片的算力是 2070T，DGX G10 是 1000T。相当于算力舱一台的价格，就可以实现两台 DGX G10 组合才能达到的性能。
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 又开始干活了。
