码农早餐 · eBPF 安全 agent 的开销，一个 inode 缓存砍掉 90% | Magic Tools

一个 eBPF 安全 agent 里最吃 CPU 的不是策略执行，是每次 open 文件都要沿父 dentry 重建路径做策略匹配；作者按 mount namespace ID、mount ID、inode number 三元组缓存命中的策略，内核 CPU 开销降了约 90%。这数字看着漂亮，但缓存键选三个字段而不是单靠 inode，说明真正值钱的是他先想清楚了会撞在哪。

🍳 今日头菜当天唯一一条深度解读

eBPF 安全 agent 的开销，一个 inode 缓存砍掉 90%

一个 eBPF 安全 agent 最贵的地方，不是判断放行还是拒绝，而是判断「这条规则到底该不该管这个文件」。作者和弟弟一起做这个 agent，最近 profile 之后发现：真正吃 CPU 的是策略匹配，不是策略执行。他们的策略是按路径写的，eBPF 挂在 LSM 的 file open 钩子上，每次打开文件都要重建路径、沿着父 dentry 一层层往上走，检查文件或任意一层祖先目录有没有命中策略。

解法很朴素：按 inode 缓存「这个文件该用哪条策略」，命中就直接放行或拒绝，不命中再走那条慢路径并把结果写回缓存。作者原话是「这把我们内核 CPU 开销降了大约 90%」。

eBPF 安全 agent 的开销，一个 inode 缓存砍掉 90%

缓存键是三个字段：mount namespace ID、mount ID、inode number。为什么不只用 inode？因为 inode number 只在同一棵 mount tree 里唯一，策略覆盖多棵 mount tree 时 inode 会撞车；mount ID 标记这个文件是从哪棵树看到的，mount namespace ID 防止跨命名空间复用条目。缓存值两部分：access_index 和 cache state，策略本身用 bitmask 存以省空间，access_index 就是对应的 bit 位置。实现上是一个 BPF_MAP_TYPE_LRU_HASH，max_entries 设成 10000。

性能数字来自一个很直接的 benchmark：同一个文件打开 20 万次。没有缓存时内核消耗 280 亿 cycles，加上缓存后是 30.3 亿。火焰图里 tail_call_security_check 出现在栈上 89.2%、is_restricted_filepath 81.9%、path_check_callback 63.7%；加缓存后后两个各自缩到约 0.02%，基本从图上消失。测量用的是 perf 的 cycles:k 事件，只算 file open 期间内核侧的 CPU 成本。

最值得看的是他们怎么处理边界情况。一个 inode 可以对应多条路径，硬链接就是最简单的例子——两个不同路径共享同一个 inode，缓存键撞上就会给出错误结论。作者的态度很明确：结果的准确性比缓存命中率重要。他们的做法是读 inode 的 i_nlink，如果大于 1 就跳过这条缓存、退回慢路径：

if (BPF_CORE_READ_INTO(&nlink, inode, i_nlink)) {
    return false;
}
if (nlink != 1) {
    inode_cache_stats_inc(INODE_CACHE_STATS_SKIPS_NLINK);
    return false;
}

作者自己承认这「更像是个 workaround 而不是真正的解法」，代价是放弃了一部分缓存覆盖率，但他觉得问题不大。这个取舍挺诚实：缓存的价值上限由它的正确性决定，一个偶尔给错答案的快缓存不如没有。

换个角度看这 90% 的分量：280 亿到 30.3 亿，省下来的量级大致相当于把原来那套路径遍历的活儿整个删掉。而整个改动是纯内部的——用户的策略一行都不用改，agent 自己就快了。作者说这是让他挺开心的一点。

顺带一提，这个 repo 最近开源了，文章里的所有东西都能在 GitHub 上找到。原文没说这套缓存上线后有没有遇到别的问题，也没交代 i_nlink > 1 的跳过率实际有多高——想看这个数字的话，得自己去看仓库里的 stats 计数。

💡 主厨说：注意他们缓存的是「策略判定结果」而不是文件内容，所以真正的风险面是策略热更新——规则一变，这批 inode 缓存就得整体失效，文章里没展开这块。

来源：

Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

🍲 今日硬菜 · 2 条深读

Cloudflare 把源站握手猜错率从 52% 压到 3.7%

TLS 1.3 有个挺别扭的设计：客户端在第一个包里就得押注用哪套密钥协商算法，押对了握手一个往返搞定，押错了对方回一个 HelloRetryRequest（HRR），重来一遍，多花一个往返。Cloudflare 每天要开 450 亿条连接，多年来押的注一直是 X25519——支持率超过 95%，看着很稳。但一测才发现，对大约 30% 的源站连接来说这个选择并不划算，HRR 比例一度在 52% 上下。

现在的做法是把「猜」换成「测」：先探测每个源站支持并偏好哪套算法，第一次就按它来，源站能说后量子就用后量子混合方案 X25519MLKEM768。效果是 HRR 从约 52% 掉到 3.7%，p90 握手延迟少了 150 ms 以上。代价也不是没有——X25519MLKEM768 的 keyshare 是 1216 字节，X25519 只有 32 字节，ClientHello 直接撑过一个网络包，而有些老旧的中间盒和源站遇到分包就握手失败，早先扫描里约 0.34% 的源站栽在这上面。所以 HRR 一直被当成安全阀用：先只声明支持后量子，实际发经典 keyshare，让有能力的源站主动要求重试。现在这套探测逻辑接管了这件事。

对写代码的你来说，直接要改的东西不多，但有两件事值得留意。一是后量子连接现在是自动的，几十万个域名在没人配置的情况下已经跑上了，你大概率不知道自己域名的握手在用什么算法——如果链路上有自建的中间设备或老网关，值得去确认一下它扛不扛得住超过一个包的 ClientHello。二是「harvest-now, decrypt-later」不是理论威胁：现在被录下来的流量，等算力够了再解。Cloudflare 给自己定的期限是 2029 年前把互联网做成量子安全，理由也很实在——不可能指望几百万站长人人变成密码学专家，只能自动化。加密这件事，正在从「记得开开关」变成「默认就该是对的」。

来源：

hackernews · iamsyr

Qwen3 语音双模型开源：63ms 首字延迟，价格是 ElevenLabs 的五分之一

Nari Labs 在 Coval 的语音 AI 榜上把自己的 Qwen3-TTS / Qwen3-ASR 端点送上了前排。TTS 这边，Qwen3-TTS Fast 的 time-to-first-audio 中位数 63 ms，WER 3.8%，两项都是第一梯队——延迟排第 2，准确率排第 1，价格 $10 / 1M 字符，并列全场最便宜，ElevenLabs Eleven v3 Conversational 要贵 5 倍，Cartesia Sonic 3.6 贵 6.5 倍。ASR 那边，Qwen3-ASR Fast 的 time-to-final-segment 中位数 44 ms 排第 1，WER 3.6% 排第 2，只差榜首 AssemblyAI Universal 3.5 Pro 的 3.5% 一个身位，价格 $0.12 / 小时并列第 2 低，对方贵 3.75 倍。还有个 Standard 档，TTS $5 / 1M 字符、ASR $0.06 / 小时，才是真正的最低价。

最值得看的是同一模型的横向对照：阿里官方的 Qwen3 TTS Flash Realtime 端点 WER 8.8%、TTFA 中位数 692 ms；Baseten 的专用 Qwen3-TTS 端点 WER 6.0%、TTFA 101 ms。模型是同一个，差距全在推理工程上。Nari 的说法是 vLLM / SGLang 这类通用引擎不适配多模态推理，所以他们专门为 Qwen3-TTS 写了一个推理引擎并开源（github.com/nari-labs/nari-qwen3-tts），10 RPS 下延迟压到 50 ms 以内。这话有几分道理：语音模型要一边出 token 一边切音频块，通用引擎的调度和 KV cache 策略确实不是为这种流水线设计的。

但别把排名当成定论。Coval 的榜单每 30 分钟就可能变一次，这篇引的是 2026 年 9 月 14 日 15:00 UTC 的一天快照，而且排名明确排除了专用推理端点——换句话说，这是「公开可调用端点」这个小圈子里的第一。WER 还是跨数据集汇总的，换个语种、换个口音、多点背景噪声，名次大概率要重排。你要真拿它上生产，先在自己的音频上跑一遍再决定。

对做语音 Agent 的人来说，这件事的意义不在谁第一，而在价格锚点被拉下来了：TTS 一毛钱能换一万字符，STT 一小时一毛二。以前「实时语音」是成本项，现在可以当功能项来设计。代价是这类小厂的端点稳定性和并发上限都得自己压测，别等上线才发现 p99 和 p50 是两个世界。

来源：

Nari Labs Leads Coval's Voice AI Benchmarks

🥢 配菜 · 另外 2 条

微软补丁修完漏洞，音频、远程访问和粘贴跟着坏了

Windows 和 Excel 的月度安全更新刚推出去，就有用户发现音频没了、远程访问连不上、粘贴也不灵了。修漏洞的补丁顺手把日常功能一起带走，这种事在 Windows 上不算新鲜，但对被强制推送更新的你来说，代价是实实在在的：远程连不上的时候，你可能正在家里连公司机器干活。装完先别急着干活，留一手回滚的时间。

来源：