最新

由nvidia-smi、nvtop、Weights & Biases、Amazon CloudWatch、Google Cloud Monitoring和Azure Monitor报告的标准GPU利用率指标非常具有误导性。该指标报告的是任何内核在GPU上运行的时间比例，这意味着即使只有一小部分计算能力被实际使用，GPU也可以报告100%的利用率。在实际应用中，我们观察到某些工作负载的真实计算吞吐量仅为1%到10%，而仪表盘却显示为100%。 当团队依赖该指标进行容量规划或优化决策时，这就会成为一个问题，因为它可能使未充分利用的系统看起来像是饱和状态。 我们正在发布一个开源工具（Apache 2.0），名为Utilyze，以不同的方式测量GPU利用率。它采样硬件性能计数器，并报告相对于硬件理论极限的计算和内存吞吐量。它还估算了给定工作负载的可达利用率上限。 GitHub链接： [https://github.com/systalyze/utilyze](https://github.com/systalyze/utilyze) 我们期待听到您的想法！

礼品文章：<a href="https://www.bloomberg.com/news/articles/2026-04-27/microsoft-to-stop-sharing-revenue-with-main-ai-partner-openai?accessToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzb3VyY2UiOiJTdWJzY3JpYmVyR2lmdGVkQXJ0aWNsZSIsImlhdCI6MTc3NzI5NjE3MiwiZXhwIjoxNzc3OTAwOTcyLCJhcnRpY2xlSWQiOiJURTVMT0lLSzNOWUkwMCIsImJjb25uZWN0SWQiOiJDN0U3REM1Q0MxRTQ0NzM0QkY2MzYxQjY5QzgxN0UzMyJ9.mkOwEicK1kMLb-h6ZjkN4u-DsF55439rrFad0m1lqZM" rel="nofollow">https://www.bloomberg.com/news/articles/2026-04-27/microsoft...</a><p><a href="https://openai.com/index/next-phase-of-microsoft-partnership/" rel="nofollow">https://openai.com/index/next-phase-of-microsoft-partnership...</a>

我一直在尝试构建一个完全本地的 RAG（检索增强生成）管道：使用 Weaviate 进行向量和混合搜索，Node.js 脚本，以及在 Ollama 上运行的 Qwen 3.5。 我发现大多数挑战出现在检索和分块上，而不是在大语言模型（LLM）上。一个好的分块策略加上混合搜索中的正确平衡，比使用更大更昂贵的模型更有效。

多年来，我一直对那些要求你将工作适应其系统的项目管理工具感到沮丧。Chimerical 颠覆了这一点：你只需描述你正在做的工作，工作空间就会围绕你的回答自动组建。这个产品是我在16年的行业知识基础上，花了6周时间构建的，今天正式上线。