设计环节用线上GPT的全局规划能力。如图：我让Codex在全局列一下需求，回答尽量简洁，这样内容少了才好全局思考，把需求收拢成几条清晰的要点。
GPT给出设计方案后，我直接把方案丢给离线的27B执行。如图：Qwen 3.8 27B在AIPod上以vLLM方式运行，在Pi里无审查地执行“生成LPK并安装LPK”任务，23分45秒跑了22条命令，中途遇到本机缺unzip、sudo要密码这类问题也自己补了个node版unzip shim解决掉了。
看到了吗？利用线上GPT的全局规划能力，我和GPT在协作设计的时候，27B在后台慢慢用电来干活，而不是用订阅来干活。
这样我兼具了线上GPT模型的能力和线下模型的省钱，因为只要设计好，线下模型现在非常能打了。关键给我节省了90%的订阅费。
]]>Chrome 可以打开开发者模式，直接加载解压后的插件。Firefox 正式版和 Firefox ESR 安装 XPI 时会强制检查 Mozilla 签名，未签名的 XPI 即使代码完全正常，也会提示插件损坏或者签名无法验证。
about:debugging 虽然可以临时加载未签名插件，但 Firefox 重启以后插件就没了，只适合开发调试，不能用来给用户发布插件。
下面记录一下 Mozilla Firefox 插件的注册、上传检测和获取 API 信息的方法。
先打开 Mozilla 插件开发者中心：
https://addons.mozilla.org/developers/
点击登录，用 Mozilla Account 登录。没有账号就先注册一个，然后同意 Firefox Add-ons 的开发者协议。
Mozilla 不需要提前单独注册一个插件 ID，第一次上传插件以后，开发者中心会自动创建插件项目。但是 manifest 里面一定要写固定的 Gecko ID，例如：
{
"browser_specific_settings": {
"gecko": {
"id": "my-extension@example.com",
"strict_min_version": "140.0"
}
}
}
这个 ID 相当于 Firefox 插件的身份证。后续更新版本必须继续使用同一个 ID，不能每个版本都随机换。
登录开发者中心以后，点击“提交新附加组件”，Mozilla 会让你选择发布方式：
如果只是想在自己的网站上提供 Firefox 插件下载，就选择“自行分发”，也就是 unlisted 渠道。
然后上传打包好的 XPI。XPI 本质上就是 ZIP 文件，但是要注意 manifest.json 必须直接位于压缩包根目录，不能在外面多套一层文件夹。
上传以后 Mozilla 会自动检测插件。检测失败就按照页面上的错误逐个修改，常见问题有：
manifest.json 格式错误，或者使用了 Firefox 不支持的 Chrome 字段。version。Firefox 新版对插件数据收集声明检查得比较严格。比如插件需要读取网页活动和登录信息时，可以在 Gecko 配置中声明：
{
"browser_specific_settings": {
"gecko": {
"id": "my-extension@example.com",
"strict_min_version": "140.0",
"data_collection_permissions": {
"required": ["websiteActivity", "authenticationInfo"],
"has_previous_consent": false
}
}
}
}
具体声明要和插件真正读取的数据保持一致，不要直接照抄上面的权限。检测页面报错时，也要以 Mozilla 当时给出的字段说明为准。
检测通过以后继续提交。自行分发的插件不需要上架商店，Mozilla 处理完成后会生成一个已经签名的 XPI，下载这个文件才可以在正式版 Firefox 和 Firefox ESR 中长期安装。
安装签名 XPI 的方法是打开 about:addons，点击右上角齿轮，选择“从文件安装附加组件”。
每次都在开发者中心手工上传和下载太麻烦，Mozilla 提供了 API，可以用 web-ext 自动上传、检测和下载签名后的 XPI。
登录开发者中心后，打开 API 凭据页面：
https://addons.mozilla.org/developers/addon/api/key/
点击生成新的凭据，页面会显示两项信息：
user:123456:xxx。API Key 不是插件的 Gecko ID，也不是 Mozilla 账号。API Secret 相当于账号密码，不要写进源码，不要提交到 Git，也不要放到公开日志里。如果密钥泄漏了，马上回到这个页面重新生成凭据，让旧密钥失效。
我一般把它们分别保存成两个文件：
firefox_addons_api_key.txt
firefox_addons_api_secret.txt
然后限制文件权限，并加入 .gitignore：
chmod 600 firefox_addons_api_key.txt firefox_addons_api_secret.txt
先确保待签名目录中包含 manifest.json 和插件需要的所有文件，然后执行：
export WEB_EXT_API_KEY="$(<firefox_addons_api_key.txt)"
export WEB_EXT_API_SECRET="$(<firefox_addons_api_secret.txt)"
npx --yes web-ext@latest sign \
--channel unlisted \
--source-dir ./firefox-extension \
--artifacts-dir ./artifacts
unlisted 表示自行分发。web-ext 会把插件上传给 Mozilla，等待检测和签名，再把签名后的 XPI 下载到 artifacts 目录。
不要把 API Key 和 Secret 直接写在命令行参数中，否则可能进入 Shell 历史或者被进程列表看到。用环境变量传递会稳妥一些，自动构建程序也应该避免打印这两个变量。
每次生成新版 Firefox 插件前，要先增加 manifest 中的 version。同一个 Gecko ID 和同一个版本号不能重复签名，否则 Mozilla API 会直接拒绝。
可以解压 XPI，检查里面是否存在 Mozilla 的签名文件：
unzip -l my-extension.xpi | grep META-INF
正常会看到类似下面的文件：
META-INF/mozilla.rsa
META-INF/mozilla.sf
META-INF/cose.sig
不过最终还是要在正式版 Firefox 或 Firefox ESR 中实际安装一次。能通过 about:addons 正常安装，并且重启 Firefox 后插件仍然存在，才算整个签名和发布流程真正跑通。
简单总结一下：开发阶段用 about:debugging 临时加载，交付用户时走 unlisted 自动签名，想公开推广时再发布到 Firefox 插件商店。三种方式不要混在一起，就不会一直被 Firefox 的签名错误折腾。
之前一直以为手臂入水是直的，拍了视频才发现是弯的，如同敬礼的状态。
教练最后说，你这种自学的人，直接来个矫枉过正，以毒攻毒吧，你手臂入水的时候用八字方式入水。
果然，这一下手臂入水直了，身体摆动和游速都快多了。
]]>包括今天和英伟达的芯片架构师聊过，他的一个观点：
“30B 的稠密模型就能解决个人编码的需求，以后不需要高显存带宽的更贵机器，因为 AI 模型本身会进化”
这句话就像我今晚做的试验一样，Qwen 3.8 27B 的足够能力，让我觉得，其实 GPT 再强大，它后台的服务器集群再牛逼，也许分到每个用户身上，就是 30B 的算力资源。
]]>深度 AI 用户，7x24 小时地用，跑长线任务，肯定硬件划算，一年就赚钱。但是你平常用线上 API 都不超过 2000 块，确实离线 AI 设备帮不了你。
Mac 的显存带宽和 Decode 能力非常优秀，但是 Mac 的 Prefill 非常差，并发也很差，CUDA 不支持。Mac 从来不说这些，所以买东西要理性，多看多对比，理性选择自己想要的东西。
你只用线上 API，你在 AI 上的认知就和所有用线上 API 的人的认知是一样的，而 AI 未来的发展一定会让每家每户都有离线 GPT。你早一天用离线设备，就早一天获得竞争性优势，因为你比别人更懂离线 AI，就跟 20 年前你比别人更早玩电脑编程一个道理，那时候大家都还在犹豫要不要买一台笔记本？
所以，买 AI 设备，不能光看成本，要看你能用自己的设备做出哪些不一样的产品来？离线 AI 设备的目的不是否定在线 AI，而是在在线 AI 也用的情况下，你能通过折腾离线 AI 设备获得哪些未来在社会上的竞争力？
简单来说，买设备从来都是投资，而不是省钱，只比省钱是没法赚钱的。
]]>经过三天的优化，我已经把 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 组合才能达到的性能。
]]>
接下来把上下文增大。官方是 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的光口快太多了，反而效率更高。
]]>今天有一个用户反映懒猫读书会导致平板卡死，我一看，好家伙，超大文件 PDF 彩印文件。
原因很清楚了：PDF 过于大，首屏渲染高清图片加上后面几页预加载，瞬间内存过大触发了果子家的 OOM，直接把前端 WebView 进程干死了。
做更精细的视口渲染，保持清晰度和操作不变的情况下，让后端只发屏幕区域和缩放比例的图，把内存占用控制在常量，减少 90% 的内存占用，这样果子就不会杀进程了。
远程定位问题，三下五除二找到根因，这就是二十年老程序员的手感。
]]>通过两台协同计算的方式，一台计算一半最终对结果，实现稳定 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 模型？评论区留下你的建议 😎
]]>利用 YaRN 技术实现 Qwen 3.8 27B 模型从 786K 提升到 900K 的挑战，整个模型占了 120GB 的显存。
900K 的上下文无限接近于 1M 上下文，意味着世界上 99% 的代码项目，利用 Qwen 3.8 27B 本地 AI 都很难遇到因为上下文不足而降智的问题。
做个对比：
懒猫 AI 算力舱跑 Qwen 3.8 27B 不但速度超快，还可以不降智地支持 99% 的大型代码项目稳定运行。
]]>