最新

我创建了UHOP（通用硬件优化平台），因为我厌倦了GPU开发者所处的无形牢笼——我们所编写的所有代码似乎都围绕着NVIDIA旋转。CUDA非常出色，但它也是一道护城河。将相同的代码移植到ROCm或OpenCL通常意味着需要重新开始。 UHOP是一个开源项目，旨在通过引入跨供应商的优化层来打破这种锁定。它可以检测你的硬件（CUDA、ROCm、OpenCL等），生成或基准测试内核，并缓存最佳性能的内核。你可以用装饰器包装你的操作，让UHOP选择或生成内核，然后它就可以在任何地方运行。 目前的功能包括： - 硬件检测 + 后端选择 - AI辅助的内核生成（CUDA / OpenCL / Triton） - 融合操作演示（conv2d+ReLU、矩阵乘法等） - 内核基准测试和缓存 - 命令行界面 + 早期浏览器仪表板 还有很长的路要走——分布式调优、编译器中间表示（IR）处理、更好的PyTorch/JAX钩子——但它是开放的、可修改的，并且由社区驱动。 代码库：github.com/sevenloops/uhop 演示网站：uhop.dev 希望能收到编译器工程师、GPU开发者或任何曾经感到被供应商API束缚的人的反馈。

我一直在开发 UHOP（通用硬件优化平台）——一个开源框架，帮助开发者在不同架构（如 CUDA、ROCm、OpenCL 等）之间优化 GPU 和加速器的工作负载，而不受供应商锁定的限制。 这个项目起初源于我个人的挫折：我编写的代码在 CUDA 上运行得很好，但随后不得不为 ROCm 或 OpenCL 重新编写或调整。UHOP 旨在使这一过程变得可移植——它能够检测你的硬件，生成或基准测试候选内核，并缓存表现最佳的内核。它还支持使用 OpenAI API 的 AI 辅助内核生成，并配备了一个简单的命令行界面，方便演示和基准测试。 目前，UHOP 可以： - 自动检测硬件后端并选择最佳内核 - 运行并基准测试融合操作，如 conv+ReLU - 缓存并重用调优后的内核 - 通过代码生成动态生成内核（CUDA/OpenCL/Python/Triton） 目前还有很多工作在进行中——更好的后端集成、分布式优化，以及用于可视化结果的网页仪表板。我提前分享这个项目，希望能从曾在编译器、GPU 运行时和机器学习基础设施方面工作过的人那里获得反馈。 代码库：github.com/sevenloops/uhop 演示：uhop.dev 非常希望能听到关于架构、测试方法或前 NVIDIA/ROCm 工程师可能贡献的想法。

这是Vexlio的一个新功能，我认为HN社区可能会觉得有趣或实用。 简而言之：可以轻松创建互动图表，即具有鼠标点击/悬停功能的图表，您可以利用这些功能展示弹出内容。最终结果可以通过无需登录的网页链接进行分享。 我认为这对于系统文档、入职培训或用户指南、演示等非常有用。适用于需要保持高层次视图整洁，同时又需要在某处提供重要元数据或细节的任何场合。 您可以无需注册直接试用，只需在这里启动应用程序（[https://app.vexlio.com](https://app.vexlio.com)），创建一个形状，使用主指针工具选择它，然后在上下文工具栏中点击“添加弹出窗口”。 我非常感谢任何反馈！

在开源Proton两年后，我们发布了v3.0版本，带来了企业级流媒体功能的开源版本：在一个单一的二进制文件中实现全连接、处理和路由，且无任何依赖。 主要特点： - 现代C++中首个向量化流SQL引擎，支持即时编译（JIT） - 高吞吐量、低延迟、高基数处理 - 端到端流处理：ETL、连接、聚合、警报和任务 - 原生连接器：Kafka、Redpanda、Pulsar、ClickHouse、Splunk、Elastic、MongoDB、S3、Iceberg - 原生Python用户定义函数（UDF）/用户定义聚合函数（UDAF）支持，以满足您的AI/ML工作负载 我们在大型企业部署中证明的同样性能，现在也可以在社区版中使用。 欢迎任何从事流数据工作或寻找Flink/ksqlDB替代方案的人提供反馈。

我开发了一款AI工具，可以将播客转换为文本，具备自动章节检测、多层次摘要和高亮提取功能。与基本的转录服务不同，它只需一键即可生成适合发布的节目说明。 技术亮点： • 使用优化的分块技术，Whisper的准确率超过99% • 无需训练数据即可实现说话人分离 • 基于主题边界分析的AI章节检测 • 支持导出为Markdown/TXT/JSON格式，并附带结构化元数据 免费版：5分钟预览 技术栈：Next.js、Whisper、R2存储 试用链接：<a href="https://harku.io/tools/podcast-transcription" rel="nofollow">https://harku.io/tools/podcast-transcription</a> 我是在为每集手动创建节目说明花费30-60分钟后开发了这个工具。希望能收到其他播客制作人和开发者的反馈。

你好，HN社区， 许多人可能已经使用过拖放构建器来创建内部工具或仪表板。这些工具非常适合快速原型制作，但随着项目的增长，总会出现相同的问题： 1) 性能问题。拖放构建器增加了大量的运行时开销。一旦你添加了更多的屏幕、逻辑或连接的数据源，系统开始变得迟缓，而你对优化几乎没有控制权。 2) 灵活性有限。你只能使用供应商提供的组件和配置选项。任何自定义的内容通常都会变成一种变通方法。 3) 设计开销。在连接数据之前，你仍然需要花费大量时间手动选择组件、安排布局和调整间距，而最终的结果往往看起来……不尽如人意。 4) 维护困难。打开一个旧项目（或移交给新队友的项目）通常意味着需要四处查找各个部分的位置。没有简单的方法来理解结构或重用。 在UI Bakery，我们不断思考如何解决这些问题，同时不失去低代码构建器的速度。 首先，我们构建了一个基于我们文档训练的AI助手。然后，大约1.5年前，我们推出了AI应用生成器，可以根据文本提示生成UI Bakery应用。这确实有所帮助，但在底层，它仍然是拖放构建器，存在所有固有的限制。 这时，我们决定彻底重新思考基础。 “什么是最灵活、最可定制的项目模型？” 答案是：代码。 因此，我们重建了我们的方式，现在推出了UI Bakery AI应用代理——一种通过聊天构建安全内部软件的新方法。 主要特点： - 数据连接器：连接SQL、NoSQL、REST API和第三方服务。 - 速度：从纯文本提示开始——AI在几分钟内生成一个功能完整的应用。 - 代码所有权：直接访问和编辑生成的React代码。 - 安全性：RBAC、SSO、SOC 2合规性、审计日志，以及在我们的云或完全本地部署。 - 可定制性：使用你在网上找到的任何React组件或自己构建的组件——一切都只是代码。 适合谁？ - 自动化内部流程的创始人/CTO。 - 厌倦了从头重建CRUD/admin UI的开发者。 - 需要具有高级安全性的内部工具的企业团队（本地部署、SSO、RBAC）。 我们将UI Bakery视为超越拖放构建器的下一次进化——从“快速但有限”到“快速、可定制且安全”。 我们很想听听HN社区的看法： 如果你使用过拖放构建器，扩展或维护它们时遇到的最大痛点是什么？ 你会信任AI生成可以像正常代码库一样扩展的内部工具吗？ 在这里试用： [https://uibakery.io](https://uibakery.io)