Hugging Face在7月6日更新了Kernels项目,三件事最关键:kernel变成Hub上独立的仓库类型,加载kernel默认只信任白名单发布者,代码签名机制上线但还没在加载时强制生效。三件事合在一起,是HF第一次认真回应一个此前被忽略的问题——自定义GPU kernel运行的是和Python进程同权限的原生代码,本质上和npm、PyPI一样,是一条能被投毒的供应链。
更值得留意的是,这次更新看着完整,实际只走了一半。代码签名系统已经搭好,但kernels在真正加载kernel的那一刻,并不会去验证签名是否有效。官方博文自己写得明白:这项功能"还需要更多测试"。安全叙事和工程现实之间,还留着一个窗口期。
kernel有了自己的身份证
HF给kernel开了独立仓库类型,不再和普通模型仓库混在一起,能标注支持的加速卡、操作系统、后端版本,比如flash-attn3的页面就能一眼看出兼容性。配套的has_kernel()和get_kernel_variants()接口把"这台机器能不能用这个kernel"变成了程序可查的问题,不用再靠试错。CLI也做了切割:kernels只管加载,kernel-builder只管编译,分工更干净。这一层解决的是"能不能用"的问题,真正的看点在信任那一层。
白名单不是新发明
trusted publisher机制不是临时补丁,而是嫁接在Hub已有的OIDC可信发布者体系上——这套体系原本面向CI/CD发布场景,用短期令牌替代长期存放的HF_TOKEN,kernel只是拿来复用,再加一层默认拦截:普通用户拉取kernel时,系统只认白名单组织,想用其他来源必须手动传trust_remote_code=True。想进白名单,要向HF申请,官方逐个审核。
- 结论.谁能进白名单、审核标准是什么,目前只有HF自己说了算,这份名单很可能决定哪些团队的kernel被默认选中,哪些永远要用户手动开绿灯。
签名装好了,门口没人查证件
签名用的是Sigstore的短期密钥,有效期很短,私钥就算泄露也很难被利用;系统还会核验签名是否来自可信的GitHub workflow和仓库。这套设计防的不是"骗你用假kernel",而是更狠的场景——可信发布者自己的Hub账号被盗,攻击者拿别人的马甲上传毒代码。verify-signature命令已经能手动核验一个kernel有没有被动过手脚,但kernels在实际加载的那一刻,不会自动做这个校验。
锁配齐了,钥匙孔却还没装上。
- 风险.白名单准入标准未公开,签名校验又暂不强制,攻击者利用被盗账号发布恶意kernel的窗口期实际还在。
放到整条赛道里,Kernels还是新兵
对比跑了多年的方案:FlashAttention依旧是注意力场景的默认答案,Triton灵活但调优成本高,xFormers实用但边界情况多,PyTorch custom ops胜在集成方便。HF Kernels想做的是统一分发和安全标准的新基础设施,还没到让开发者默认信任、生产环境直接照搬的地步。
这次加入的Torch Stable ABI能让一个kernel兼容未来约两年内发布的Torch版本,不用每次重新编译;Apache TVM FFI是第一个跳出Torch生态、能对接JAX、CuPy的框架支持。这两步是在补"跨版本"和"跨框架"这两块最大的短板,但短板补上不等于生态已经成熟。
对kernel开发者来说,现在申请成为可信发布者、把kernel适配到Stable ABI,是能提前卡位的动作。对下游用户来说,更现实的做法是继续认准白名单里的组织,看到trust_remote_code=True这行代码时多想一步——这套签名系统目前还替你把不了关。