这篇文章我读完了，内容密度很高。张善友从 TensorSharp（.NET 推理引擎） 的视角切入，不聊模型效果，专门拆运行时工程——这恰恰是多数评测文章一笔带过、但实际落地最头疼的部分。
几个我觉得最有意思的点：
---
核心矛盾："权重不止是三元数"
文章最戳人的一句话：
"仅仅把权重当作普通三元数去解释，得到的是一个错误的网络"
这句话道破了三元量化落地最大的坑——权重存放在旋转基底（Hadamard 旋转后的坐标系）上，运行时必须在 activation 侧做匹配的 Walsh-Hadamard 逆变换，网络才是对的。如果引擎"能加载、能出 token"但跳过了变换，输出的其实是一个从未训练过的网络。
这就是为什么原版 llama.cpp / Ollama 跑不了这个模型——不是性能问题，是正确性问题[citation:web:27.1]。
TensorSharp 的工程取舍很克制
三个决策值得单独拿出来说：
| 决策 | 做法 | 意义 |
|------|------|------|
| 转码而非 patch | 把 PQ20/PTQ10 无损展开为上游 GGML 的 Q2_0 块，不修改 ggml 源码 | 兼容性风险隔离在自己一层，上游升级不阻塞 |
| 校验而非假设 | 加载前全量校验 prism.hadamard.* 元数据，不满足直接拒绝 | "拒绝加载永远好过静默跑错"——这条原则在推理引擎里其实很少被严格执行 |
| 公开而非粉饰 | decode 慢 3-5.4%、PQ2 并发吞吐低 12.8%、262k 上下文未验证，全写进文档 | 对比基线严格限定为"能加载同款文件的引擎"，不给误导性数字 |
代价：用内存换兼容性
转码方案不是免费的——无损展开后：
PQ2_0 多占 ~6%
PTQ1_0 多占 ~29%
这是明确的取舍：不改上游、不 fork 分支，那就自己扛内存开销。对于 .NET 生态的开发者来说，这个代价是可以接受的——毕竟本来就走的是托管运行时，多几个百分点的内存换一个不受上游牵制的集成路径，账算得过来。
---
结合你的技术背景
你之前关注过 软件架构的演进 和 AI Agent 工程化，这篇文章其实在两个层面和你重叠：
① 架构层面：TensorSharp 的"转码层"设计，本质上是在两层契约（PrismML 的私有格式 ↔ GGML 的上游格式）之间做 防腐层（Anti-Corruption Layer）——不改任一方，只在自己这一层做双向映射。这是 DDD 里很经典的分层策略，用在推理引擎里不多见。
② Agent 工程化层面：Bonsai 2 27B 的 98.2% 保留率 + 5.9GB 体积，意味着 27B 级别的模型可以在笔记本/边缘设备上跑 Agent 推理。对于你做 Agent 工具链来说，这意味着：
Agent 的 System 1（快速决策） 可以用本地 Laya（33ms）
System 2（复杂推理） 可以用本地 Bonsai 2 27B（5.9GB）
两套都在本地跑，零 API 依赖、零网络延迟
这个组合挺有想象空间的——你之前在做电商客服质检 Demo，如果质检链路全跑在本地，延迟和成本都能控住。
0 评论