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

极限优化 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

不需要 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

分享 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

Omarchy 第一坑 Flclash 默认启动不了

今天在一台新装的 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 有很多中国用户需要的软件包，在 /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 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 Tray Bar 更直观高效的系统托盘

我的第二个 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 Power Awake 插电时保持唤醒

我的第三个 Omarchy 插件

以前 Linux 的电源管理做得都特别复杂，特别是你干活的时候就给你屏保了。

其实 AI 时代的逻辑很简单，就是插电的时候不要屏保。我可以不动电脑，但是我时不时地瞟一眼 AI 干完活没有，这很重要。

所以我做了我的第三个 Omarchy 插件：笔记本插电的时候禁用一切屏保和省电模式，只有拔电的时候才启用电源管理。这样既满足了移动续航的需求，又保证我们平常工作中，不管是看 AI 发呆还是开会看 PPT，都不受 Linux 蹩脚的电源管理限制。如果真的要离开一会儿，为了保证安全，手动锁屏一下就好了。

代码用 GPL 3.0 开源，放到评论区，Enjoy Omarchy!

via https://manateelazycat.github.io/feed.xml

Invalid media: image

Omarchy 插件卸载后所有快捷键失效的排查

今天试用了一个 Omarchy Workspace Manager 插件，发现不符合自己的需求后就卸载了。结果卸载完以后，Alt + Tab、Super + Tab、Super + H/J/K/L 全部失效，就连我自己写的几个 Omarchy 插件也像坏了一样，所有快捷键按下去都没有反应。

一开始以为是 Omarchy Shell 热重载把插件搞坏了，重启了一次 Omarchy Shell：

omarchy restart shell

但是问题依旧。

排查过程

先检查 Hyprland 的快捷键绑定：

hyprctl binds

文章中配置的快捷键都还在，Alt + Tab 和 Super + Tab 也已经正常注册。

再检查插件注册的全局快捷键：

hyprctl globalshortcuts

Omarchy Window Switcher 和 Workspace Gallery 的快捷键服务也都在，说明插件本身没有坏。

最后检查 Hyprland 当前的 submap：

hyprctl submap

输出居然是：

omarchy-workspace-manager-capture

原因终于找到了。

问题原因

Hyprland 的 submap 类似 Emacs 的按键映射，可以临时切换到一套完全不同的快捷键。Workspace Manager 为了在图形界面中捕获用户输入的快捷键，会进入自己的捕获 submap。

但是插件卸载时没有退出这个 submap，Hyprland 就一直停留在快捷键捕获模式。原来的快捷键和插件服务其实都正常，只是键盘事件再也没有发送给默认按键映射，所以看起来像所有插件一起坏掉了。

重启 Omarchy Shell 也无法解决，因为 submap 状态属于 Hyprland，不属于 Quickshell。

修复方法

执行下面的命令，退出残留的快捷键捕获模式：

hyprctl dispatch 'hl.dsp.submap("reset")'

再次检查：

hyprctl submap

输出恢复为：

default

所有快捷键和 Omarchy 插件立即恢复正常。

这个问题本质上是插件的卸载清理不完整。使用自定义 submap 的插件，在关闭界面、禁用和卸载时都应该检查自己是否仍然拥有当前 submap，并主动恢复默认按键映射，否则一个看似不起眼的状态残留，就会让整个桌面的快捷键全部失效。

via https://manateelazycat.github.io/feed.xml

Omarchy Terminal Clipboard 终端按键重定向

我日常用的终端主要有两个： lazycat-terminal 本地快速做研究，LightOS 主要手机和电脑多端远程 AI 编程

但是这两个应用 Omarchy 不认识，都认为它是普通应用而不是 terminal 应用，所以你在 Omarchy 中按 super + c 的时候， Omarchy 会按照普通用户的设计， 直接转换成 ctrl + c, 但是在终端中这样转换就会直接把 codex 退出，非常奇怪

所以我写了我的第六个插件， omarchy-terminal-clipboard ， 让 Omarchy 识别这两个终端， 按 super + c 的时候转换成 ctrl + shift + c, 按 super + v 转换成 ctrl + shift + v, 这样就不用 bings.lua 配置文件了，直接安装这一个包就好了，欢迎大家提交 terminal 名单，把这个包做的兼容性更好一点

源代码放在评论区，按照 GPL 3.0 开源， Enjoy!

via https://manateelazycat.github.io/feed.xml

Invalid media: image

Omarchy Fcitx Status 输入法指示器

rime-ice-installer 解决了中文用户一键搞定输入法安装的问题，但是 Omarchy 的托盘区域没有中文的指示，导致工作中不知道当前的输入法状态，总是需要按一下 Shift 来测试一下当前的状态， 有时候甚至要按两下 Shift ，非常浪费时间

所以，我今天写了第7个插件 omarchy-fctix-status, 可以在右边的托盘区域清晰的看到输入法的状态，右键菜单可以用鼠标切换，还集成了 Fcitx 的 replace 重启功能，方便修改输入法配置的时候快速重启 Fcitx 服务

源代码按照 GPL 3.0 的方式开源， Enjoy！

via https://manateelazycat.github.io/feed.xml

Invalid media: image

Omarchy Color Picker 简单易用的屏幕取色器

我的第八个 Omarchy 插件

Omarchy 社区的屏幕取色器都太难用了，我自己从零设计了一个， 点击右上角的图标，光标直接变成屏幕放大镜，移动光标到目标区域，鼠标左键复制颜色到系统剪切板，还可以右键托盘区域选择复制颜色的格式，可以在 HEX、RGB、HSL三种格式中切换

源码按照 GPL 3.0 许可证发布， Enjoy！

via https://manateelazycat.github.io/feed.xml

Invalid media: video

英伟达光模块速率提升研究

这两天在折腾两台算力舱之间的四条 25G 光口。四条线都通，测速却只有 12～14Gbps；另一组同样的机器能跑到 17～18Gbps，差得有点多。

对比后发现，驱动版本和物理链路速度都一样，网卡实际跑的参数却不一样。最明显的是 MTU，四条光口里有三条实际只有 1466。

这次主要调了四个地方：

1. 四条光口的实际 MTU 统一到 8966。
2. IOMMU 从 DMA 改成 DMA-FQ。
3. 中断合并：接收从 512 微秒 / 64 帧调到 6 微秒 / 1 帧，发送从 256 微秒 / 16 帧调到 32 微秒 / 1 帧。
4. 队列规则：从根队列 mq 改成 fq_codel，quantum 设为 8966。

重启后确认参数还在，接着逐口做双向测试，单位是 Gbps：

搞定！

via https://manateelazycat.github.io/feed.xml

Omarchy Display Reset 显示器信号重置插件

我的第九个 Omarchy 插件

在多显示器的时候，Nvidia的显卡总是会在 Omarchy 锁屏后把信号丢失了，导致我4个显示器底部的两个显示器总是变成镜像，最近太慢了，还没有调查英伟达驱动的原因

但是并不妨碍我顺手写一个新的 Omarchy 插件 omarchy-display-reset, 这个插件的作用是，你遇到上面的问题，点一下任务栏的图标， 它就会在所有屏幕上显示这个对话框， 然后你就点击出问题的两个显示器，重新reload后就会恢复显示器的信号，解决这个bug

原理就是，选中显示器后，插件暂停 hyprmoncfgd，在配置中临时将对应输出设为 disabled = true 并执行 hyprctl reload，两秒后恢复配置、再次 reload 并启动服务

源代码在评论区，按照 GPL 3.0 的协议开源， Enjoy！

via https://manateelazycat.github.io/feed.xml

Invalid media: image

Omarchy Language Switcher 语言切换插件

我的第十个 Omarchy 插件

做产品，经常需要切换系统语言去检查英文版的细节，AI跟我说 Omarchy 没有图形化的语言切换程序，要用命令行帮我切换系统语言

我说你别， 我来写一个语言切换插件, omarchy-language-switcher 点击按钮后， 可以快速搜索所有语言，按回车重新注销系统即可

源代码：omarchy-language-switcher

via https://manateelazycat.github.io/feed.xml

Invalid media: image

Omarchy Startup Map 启动管理插件

我的第十一个 Omarchy 插件

家里的多显示器，每次启动都需要手动在习惯的屏幕启动制定的应用，做了一个启动管理程序，可以方便的控制应用在制定的显示器和制定的工作区启动，节省自己的开发时间

为什么要自己重新写一个，因为 Omarchy 商店的启动管理程序我都实验过了，太垃圾了，要用户手动填写应用的启动路径，我懒得去终端敲which命令，直接快速搜索了

还有就是社区的启动插件让我先管理显示器的名称，再管理启动程序列表，我要管理显示器的名称干嘛？我直接鼠标点击选择不就知道了？ 程序直接告诉我显示器的位置，我不用去记忆HDMI和DP的序号啊

源代码：omarchy-startup-map

via https://manateelazycat.github.io/feed.xml

Invalid media:
image
image

自动化移植AI模型的方法

问题

@manateelazycat 好奇一个细节：模型移植/优化这种长任务，AGENTS.md 里最关键的约定是哪条？我跑代码类 agent 最怕长任务中途自由发挥，一个约定没写清楚就开始改不该改的东西。你们这种跑几小时的场景怎么防跑偏？

回答

世界很多事情是反过来的，不是你还不会移植模型之前，你写一个AGENTS.md去约束AI，你怎么能够约束一件你自己都不会的事情？

正确的方法是，你就手工移植，当你移植了很多AI模型后，让AI把你手工移植过程中各种纠偏的手段，总结成 AGENTS.md，这个总结的秘籍才是自动化移植其他AI模型的正确方法

实战出真知

via https://manateelazycat.github.io/feed.xml