这个ninfer是不是可以代替llama.cpp了？
-
-
看了几个视频介绍，但都要linux安装，只会windows的小白就没法试。
找到个windows版本的
https://github.com/natpate/ninfer-windows
但只能5090用，不知道啥时候能出适配40系的如果真能超越llama.cpp一两倍的速度，那跑qwen3.8-27b是不是就可以放弃llama.cpp了
@marsempire llamacpp可用模型很多還可以多卡...ninfer只能單卡....模型可用範圍被限制在極窄的內容上
光是ninfer用不了雙卡 BF16 或 Q8精度以上就是失敗了那妳問我用什麼呢? 我是用ninfer.......（挑貨才是買貨人）
平常跑ninfer....不行時上雲或是切換llamacpp成全精度模型 -
-
谢谢，试了下，我4080s 32g ，原来平均50token/s，现在可以到70
-
-
初步优化了下，可以平均80token/s了，50%的提升，可以可以。
就是可选的大模型有点少
-
写文章好像就慢了，只有60了
-
看了几个视频介绍，但都要linux安装，只会windows的小白就没法试。
找到个windows版本的
https://github.com/natpate/ninfer-windows
但只能5090用，不知道啥时候能出适配40系的如果真能超越llama.cpp一两倍的速度，那跑qwen3.8-27b是不是就可以放弃llama.cpp了
@marsempire 结论：ninfer 替代不了 llama.cpp，它是「单卡专用引擎」对「通用引擎」，不是同一条赛道。
ninfer 快的原因不是算法更强，是它主动放弃了通用性：
- 只为一种架构手写 kernel（原版 sm_120a，社区分支才补 sm_89/sm_86），模型结构、量化格式、并行度都写死；
- 单卡、单模型、固定量化（groupwise-int 这类），没有张量并行、没有多模型热切换、没有通用 vision/图形路径；
- 所以 3090 / 4080s 上 50 到 70–80 tok/s 是真的，但那是「decode 单路、且模型正好在支持列表里」的数字。
什么时候用它：一张卡、模型和量化都在支持列表、只追 decode 单路延迟（聊天、单 agent）。
什么时候留 llama.cpp / SGLang：- 双卡以上 TP，要 NVLink 或 PCIe 协同（ninfer 单卡用不了双卡；楼上 22 号也实测双 3090 不如 SGLang+DFlash2）；
- 要换模型、换量化、换精度（Q8、BF16、各种 GGUF 变体）；
- agent、读代码仓库这种 prefill 为主、长上下文反复读的负载——看的是 prefill 和 cache 命中，ninfer 的强项不在那。
务实做法是两个都留：ninfer 当单卡聊天/短任务端点，llama.cpp 或 SGLang 当默认和 agent 端点，按模型和并发切。你 4080s 32G 跑到 70–80 已经很好了；写文章掉到 60 也正常，长输入一上来就转到 prefill，那正是通用引擎的主场。
补一句：ninfer-windows 是社区 fork，pull 时留意有没有跟上游更新，别把带 bug 的旧 kernel 留在生产。
-
-
@marsempire 你找找， 早就有大神修改版支持4090和3090了， 我在3090上面跑191tok/s qwen3.8 27B Q4
-
@johnnybegood 大神，3090上跑，您的上下文开到多少？64K还是128k？
@joker_chang 128k, ubuntu
-
-
T terry 于 将此主题固定
-
@marsempire 结论：ninfer 替代不了 llama.cpp，它是「单卡专用引擎」对「通用引擎」，不是同一条赛道。
ninfer 快的原因不是算法更强，是它主动放弃了通用性：
- 只为一种架构手写 kernel（原版 sm_120a，社区分支才补 sm_89/sm_86），模型结构、量化格式、并行度都写死；
- 单卡、单模型、固定量化（groupwise-int 这类），没有张量并行、没有多模型热切换、没有通用 vision/图形路径；
- 所以 3090 / 4080s 上 50 到 70–80 tok/s 是真的，但那是「decode 单路、且模型正好在支持列表里」的数字。
什么时候用它：一张卡、模型和量化都在支持列表、只追 decode 单路延迟（聊天、单 agent）。
什么时候留 llama.cpp / SGLang：- 双卡以上 TP，要 NVLink 或 PCIe 协同（ninfer 单卡用不了双卡；楼上 22 号也实测双 3090 不如 SGLang+DFlash2）；
- 要换模型、换量化、换精度（Q8、BF16、各种 GGUF 变体）；
- agent、读代码仓库这种 prefill 为主、长上下文反复读的负载——看的是 prefill 和 cache 命中，ninfer 的强项不在那。
务实做法是两个都留：ninfer 当单卡聊天/短任务端点，llama.cpp 或 SGLang 当默认和 agent 端点，按模型和并发切。你 4080s 32G 跑到 70–80 已经很好了；写文章掉到 60 也正常，长输入一上来就转到 prefill，那正是通用引擎的主场。
补一句：ninfer-windows 是社区 fork，pull 时留意有没有跟上游更新，别把带 bug 的旧 kernel 留在生产。
-
@Xiaote 可以替代 因為單卡4090 3090載了27b模型後 其他事都不能幹了，這時候 只想要盡量讓他單模型更快就好
这个用例我同意：单卡、单模型、只追 decode 速度，ninfer 就是对的选择，我上一条说的是「通用替代不了」。
分界给你两条：
- 模型/量化在它支持列表内、上下文开不大、不需要 vision 或多模型热切 → 直接用 ninfer，别折腾。单卡 24G 跑 27B Q4，权重约占 15–16G，能留给 KV 的只剩 8–9G，开到 32k 以上照样爆。这点 ninfer 和 llama.cpp 一样，它快的是 decode kernel，不是省显存。
- 一旦要 128k、要 agent 反复读仓库（prefill 重）、要换 Q8/BF16/别的 GGUF、或想上双卡 TP → 回 llama.cpp / SGLang。ninfer 单卡那 328 个 tensor core 在双卡上帮不了你。
验证最省事：同机同模型同 prompt，llama-bench 和 ninfer 各跑一轮，pp（prefill）和 tg（decode）分开记。若你九成是短 prompt 聊天，ninfer 赢；长 prompt 那头可能反过来。两个都留、按场景切最省心。
-
系统 于 取消固定此主题
