软件开发人员感谢帖
摘要
一位用户对开源开发者表达感谢,着重提到vllm最近的多项重大发布修复了OOM问题,使得在5090上使用Qwen 27B时,上下文窗口大小翻倍至240k。
我在去上班的公交车上,感觉大家对那些贡献时间和精力的男人、女人、孩子以及所有参与开源项目的人表达得不够感谢。就在昨晚,我发现我一直没注意到vllm开发者已经发布了三个新的主要版本,而且不仅如此,之前由于预分配和调优导致的OOM问题似乎也消失了!太棒了!!仅仅是修复那个bug,就让我在5090上用qwen27b时将上下文窗口大小从120k翻倍到了240k。所以这只是一个提醒:支持开源开发者、基础设施,以及更新你的软件。当我们诚实地在开放中工作时,软件会随着时间变得更好用,而不是更差。这从来都不容易,对参与者来说可能情感上非常困难(贡献者感到自己不受欢迎,尽管他们只是试图帮忙;而维护者则因每个人都觉得维护者欠他们什么而筋疲力尽)。所以总的来说,记得要保持尊重和感激,因为开源软件确实让世界运转。我希望随着我们这一代人开始积存/逐渐摆脱职场竞争,能看到更多这样的精神。
相似文章
开发们 - 你有64GB显存 - 你用什么模型写代码?
一位拥有64GB显存的开发者分享了他使用unsloth版Qwen 3.5 122b-a10b模型进行编码的偏好,并向社区征求推荐。
@leopardracer: 这位美国开发者花了数周调试Ollama中的超时错误。然后他查看了底层——LM Studio只是……
一位开发者通过直接使用llama.cpp修复了Ollama中持续存在的超时错误,绕过了LM Studio和Ollama等封装层,在M1 Max上以262K上下文达到了53 tok/s。
Qwen3.6 27B 在 vLLM 中的表现比在 llama.cpp 中更差
一名用户报告称,Qwen3.6-27B 模型在使用 llama.cpp 时比使用 vLLM 表现更好且更可靠,并指出尽管进行了大量配置,vLLM 仍出现工具调用错误和“被切除脑叶”的行为。
实测 OpenCode 与自托管 LLM 的协作:Qwen 3.5、3.6、Gemma 4、Nemotron 3、GLM-4.7 Flash - v2
一位开发者在 RTX 4080 上用 OpenCode 对多款自托管 LLM(Qwen 3.5/3.6、Gemma 4、Nemotron 3、GLM-4.7)进行两项编码任务基准测试,揭示了速度与质量的权衡。
Qwen3.6 27B 本地与 Opus 4.8 对比,以及使用纯C零框架构建的体素引擎
对比本地运行的Qwen3.6 27B和Opus 4.8,并重点介绍一个使用纯C语言且不依赖任何框架构建的体素引擎。