最新

Hi HN， 我们构建了 LUML ( <a href="https://github.com/luml-ai/luml" rel="nofollow">https://github.com/luml-ai/luml</a> )，这是一个开源 (Apache 2.0 许可) 的 MLOps/LLMOps 平台，涵盖了实验管理、模型注册、LLM 追踪、部署等功能。 它将控制平面与您的数据和计算资源分离。所有产出物都是自包含的。每个模型产出物都包含所有元数据（包括实验快照、依赖项等），并存储在您的存储空间中（兼容 S3 或 Azure）。 文件传输直接在您的机器和存储之间进行，执行则发生在您托管并连接到 LUML 的计算节点上。 我们希望您试用该平台并分享您的反馈！

我们正在构建一个能够捕捉人与人或人与 AI 之间的对话信号，并根据这些信号采取行动的系统。设想一下：对话结束 → 事情真正得到解决。我们的主要产品面向中小企业，但我们也提供了一个试用平台，供您体验 - <a href="https:&#x2F;&#x2F;hoster.primeorbit.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hoster.primeorbit.ai&#x2F;</a> 或访问 <a href="https:&#x2F;&#x2F;primeorbit.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;primeorbit.ai&#x2F;</a>。 很好奇您会尝试什么。感谢您的阅读！

大家好， 我构建了一个运行时，使用 wasm 沙箱隔离不受信任的代码。 基本上，它可以保护您的宿主系统免受不受信任代码可能导致的问题。最近我们一直在 Python 中就沙箱技术进行深入讨论，其中详细阐述了这个问题 [1]。在 TypeScript 中，由于两个生态系统之间的紧密联系，wasm 集成甚至更加自然。 核心部分是用 Rust 构建的。除此之外，我通过 wasmtime 和组件模型使用 WASI 0.2，以及自定义 SDK，以尽可能保持代码的惯用性。 例如，在 Python 中，我们有一个简单的装饰器： ```python from capsule import task @task( name="analyze_data", compute="MEDIUM", ram="512mb", allowed_files=["./authorized-folder/"], timeout="30s", max_retries=1 ) def analyze_data(dataset: list) -> dict: """在隔离的、资源受控的环境中处理数据。""" # 您的代码在 Wasm 沙箱中安全运行 return {"processed": len(dataset), "status": "complete"} ``` 而在 TypeScript 中，我们有一个包装器： ```typescript import { task } from "@capsule-run/sdk" export const analyze = task({ name: "analyzeData", compute: "MEDIUM", ram: "512mb", allowedFiles: ["./authorized-folder/"], timeout: 30000, maxRetries: 1 }, (dataset: number[]) => { return {processed: dataset.length, status: "complete"} }); ``` 您可以设置 CPU（通过 compute）、内存、文件系统访问和重试次数，以便精确控制您的任务。 目前还处于早期阶段，但我很乐意收到反馈。我会在这里回答问题。 GitHub: [https://github.com/mavdol/capsule](https://github.com/mavdol/capsule) [1] [https://news.ycombinator.com/item?id=46500510](https://news.ycombinator.com/item?id=46500510)

我之前对 Go 验证器中的运行时反射感到很沮丧，所以转而构建了一个代码生成方案。 govalid 读取结构体标记，并生成纯 Go 验证代码。无需反射，运行时无内存分配，速度比 go-playground/validator 快 5-44 倍。同时也支持 CEL 表达式来实现复杂的规则。 欢迎提供反馈 :)

大家好

受到这个 Ask HN 的启发：https://news.ycombinator.com/item?id=46834977 但我将追溯更久远的历史，看看这里是否还有人使用计算尺？