Magnitude：让开源模型快2倍的推理引擎
Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
Magnitude 是一款专为智能体设计的开源推理引擎，它能在你的设备上自动编译并调优内核，让开源模型运行速度比 llama.cpp 快高达2倍。无论是 Apple Silicon、NVIDIA、AMD 还是纯 CPU 环境，它都能完美适配。只需一键即可连接 Pi、OpenCode、Hermes 等常用智能体，且完全免费、隐私安全，所有数据都在本地处理，无需联网。
它在你的设备上编译并调优内核，因此开源模型的运行速度比 llama.cpp 快高达2倍。
HN 评论区
57- kmike84
UI 中的速度估算准确吗？我之所以问这个，是因为对于 Qwen 3.8 (Q8)，UI 中引用的速度数字看起来相当糟糕：
您机器上的预估速度
上下文 token 数 Tokens / 秒
25 000 17
50 000 16
75 000 16
262 144 12
262K 这个数字还行，但对于较小的上下文大小（<128K），它比我在使用 qwen3.8 q8 (mac m5 max) 进行真实 mtplx 会话时得到的数字慢约 2 倍。
是缺乏优化，还是数字错误，或者是基准测试的产物（例如，某些对 spec decoding 来说比通常的 agentic 会话更难的情况）？
- lxe
在我的本地推理服务器上，我在 llama.cpp 的检出目录中一直运行着一个永久的 codex 线程。我会定期让它查看当前挂起的 llama.cpp PR，研究最新的 MTP、Dflash 以及其他预测或注意力优化方案，研究最新的模型量化和微调版本，浏览 localLlama Reddit 板块，基本上就是对前沿技术进行一次全面扫描。
然后它会重新构建最新的 llama.cpp，抓取它认为值得测试的 PR，接着进行基准测试，完成升级，并验证我们应该运行哪个模型、哪个变体，甚至是哪个独立的微调版本。
偶尔，它还会执行自己的优化并提交代码，随后这些提交会被拉取请求和合并的代码所取代，而这些代码本质上验证了模型自身的优化方向。
- kmike84
这似乎是个好主意。不过，要在速度上超越 llama.cpp 门槛很低 :)
我发现它是个不错的基准，但至少在我用的 Mac 上，总是有比它快得多和/或内存需求更低的方案——就像你说的，ds4、omlx、mtplx 等等。看来如果你真的要在本地使用 LLM，几乎没有理由不使用那些更优化的引擎。
我观察到这些引擎主要有三种失效模式：
* 未使用可用的最佳 spec decoding
* KV cache 占用了过多的 VRAM（例如，在 ds4 中 KV cache 几乎不占空间，但在 unsloth/llama.cpp 运行 deepseek 模型时却占用大量 VRAM）
* 大上下文尺寸下性能下降——4K 或 32K 的基准测试结果很棒，但在现实的 100-200K 场景下，速度甚至比一些愚蠢的基准方案还慢
- mncharity
顺便说一句，就我个人而言，痛点列表的顶端（我想鉴于第一项，这是个双关语）包括：
基于外部/策略的温度控制节流。如果不节流，我的笔记本底部会热到烫皮。但固定的计算上限在特定情况下会导致性能非线性地急剧下降。计划是添加一个运行时旋钮，以取代手动限制的临时方案。
我会使用那些勉强能塞进 VRAM+RAM 的模型，速度也就每秒 1 个 token 左右。因此工具调用步骤的开销可能很痛苦——在一个 `ls` 命令都要花几十秒的世界里。计划是将 harness 插件与推理循环融合，实现“不，别停——我已经把调用结果给你了——继续跑”（同时也玩一些 logit 游戏）。
- herf
我这里有两张 NVIDIA GPU (16GB+16GB)，但它把每张都检测了两次（说我总共有 4 张 GPU）。但随后，它又说大多数模型太大了（任何 >8GB 的？），似乎只在一张 GPU（5070ti）上运行。
不幸的是，即使使用我的 5070ti，llama.cpp 在解码时似乎仍然快 20-30%，运行方式如下：
set CUDA_VISIBLE_DEVICES=0
build\bin\Release\llama-server -hf google/gemma-4-12B-it-qat-q4_0-gguf -ngl 99 --no-mmproj-offload -mg 0 -c 262144 -fa on --host 0.0.0.0