推出 HN：Magnitude (YC S25) – 用于代理的自优化推理引擎

【HN用户评论摘要】 这似乎是个好主意。然而，在速度上击败 llama.cpp 是一个低标准:)我发现它是一个很好的基线，但至少在 Mac 上总是有更快的东西，和/或更好的内存要求 - 就像你说的，ds4，omlx，mtplx 等。似乎如果你真正使用本地 LLM，没有什么理由不使用更优化的引擎之一。我在引擎中观察到的 3 个主要故障模式：* 不使用最佳可用规范解码* 使用太多用于 KV 缓存的 VRAM（例如 KV ca 从您的描述来看，这根本不适用于 AMD 或 Strix Halo？另外，我不确定但肯定起着重要作用的一件事是您下载的模型的变体 - 这如何帮助您为您的特定硬件/上下文大小选择最快的版本？ 在我的本地推理框中，我在 llama.cpp 结账中打开了一个永久的 Codex 线程，我定期要求查看当前待处理的 llama.cpp PR，对最新的 MTP、Dflash 和其他预测或注意力优化进行一些研究，对最新的模型量化和微调进行研究，查看 localLlama Reddit 线程，并基本上对前沿进行扫描。然后它会重建最新的 llama.cpp，获取与测试相关的 PR，然后执行 我这里有两个 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 除了图像之外，还有有关基准/方法的来源吗？ llama.cpp 的性能可能存在大量差异，具体取决于其配置方式。我还希望看到针对 MLX 的基准测试。 原始链接：https://github.com/magnitudedev/magnitude