【Rust日报】 ffmpReg 简介：一个完全用纯 Rust 重写的 ffmpeg-洪萨配资

嗨，各位 Rustaceans，我今年 21 岁，我一直在开发ffmpReg，它是用纯 Rust 语言完全重写的 ffmpeg。
过去五天我一直专注于扩展容器和编解码器支持。目前，ffmpreg 可以转换 WAV 格式（pcm_s16le → pcm_s24le → pcm_f32le），并能部分读取 MKV 流，显示容器、编解码器和时基信息。完整的容器支持即将推出。
如果你觉得这个项目有趣，给它点个赞真的能帮助它保持势头🥺。
r/rust - ffmpReg 简介，一个完全用 Rust 重写的 ffmpeg 库。

【实验性】通过二进制协议使用 SolidJS 驱动 Zed 的 GPUI——一种“无 DOM” GUI 架构

嗨，各位Rustaceans🦀，

我一直在尝试一个想法：如果我们能将 SolidJS 的 DX 与 Zed 的 GPUI 引擎的原始性能结合起来，会怎么样？

我没有使用 WebView（如 Tauri/Electron），而是构建了一个名为Alloy 的原型。

建筑设计：

逻辑层：SolidJS（已编译）运行在嵌入式 QuickJS 运行时环境中。
协议：自定义二进制命令缓冲区（不使用 JSON 序列化）。JS 线程将字节码（CreateNode、SetStyle、UpdateText 等）写入 Uint8Array。
渲染层：Rust 每帧消耗一次缓冲区，更新“Shadow DOM”结构，并直接使用GPUI进行渲染。

“Vibe Coding”免责声明：这是一个“第0阶段”的概念验证。为了快速验证架构，我使用了LLM（Claude/Gemini）生成了大量样板代码，特别是JS到Rust的粘合代码。

我发帖的目的是：我认为这种架构（通过二进制流实现逻辑/渲染分离）是实现高性能 GUI 的可行方案。我正在寻求关于该架构的反馈，并希望熟悉 GPUUI 内部机制的人士能够帮助我改进样式系统。

仓库：Alex6357/alloy：一个“无 DOM” GUI 运行时：SolidJS 逻辑驱动 Rust GPUI 渲染。

今天我发布了 Haagenti，这是一个纯 Rust 压缩库，它能让你在现有硬件上实现前沿的 AI 推理。请原谅我的啰嗦，因为并非每个人都了解下面的数学原理。

声称：一个 700 亿参数模型可以在单个RTX 4500 Ada（24GB 显存）上运行。

不合理的计算：FP16 精度下 700 亿参数约需 140GB 内存。即使是 INT4 量化也需要约 35GB 内存。RTX 4500 Ada 显卡只有 24GB 内存。

方法：Haagenti 实现了HoloTensor编码——一种用于神经网络权重的全息压缩和渐进式重构技术。权重以压缩形式存储在显存 (VRAM) 中，并在推理过程中按需解压缩。

真实的数字：

当前测得吞吐量：1.3 个令牌/秒

目标吞吐量：25 个令牌/秒

是的，1.3 tk/s 的速度确实很慢。但问题是——它不是哈根蒂处理器。

我们发现瓶颈在于张量库的开销。每次加载 448MB 的张量需要 306 毫秒，而理论上的最短时间仅为 18 毫秒。这是库层而非压缩层造成的 17 倍性能损耗。完整分析：docs/CANDLE-CEILING-ANALYSIS.md

Haagenti 的任务是将 140GB 的数据装进 24GB 的存储空间。它做到了。吞吐量问题出在上游。

接下来是Nihil——一个基于Sigil的张量库，专为全息内存访问模式而设计。我们预计它的速度将达到25+ tk/s。

为什么发布速度定在 1.3 tk/s？因为 Haagenti 算法有效。压缩算法有效。显存适配算法有效。而且，也许有人会在我之前解决张量库的问题。

从更宏观的角度来看：前沿人工智能不应该需要云基础设施或企业级硬件。如果这种模式可行，你就可以在本地私有地运行自己的 700 亿模型，而且可以使用你实际可以购买的 GPU。

28 个 crate。纯 Rust 编写。支持 SIMD 加速。可选 CUDA。MIT 许可。

链接：GitHub：https://github.com/Daemoniorum-LLC/haagenti crates.io：https://crates.io/crates/haagenti（发布中）由 Lilith Crook 和 Claude (Opus 4.5) 构建

From 日报小组时光

社区学习交流平台订阅：

Rustcc论坛: 支持rss 微信公众号：Rust语言中文社区