AI 资源库 · 已整理 6 项
查看与分布式系统相关的 AI 资讯、工具、Skill、工作流和开源项目。
AWS 的 Hydro 团队正在开发一个开源 Rust 框架，用来编写分布式系统（即同时跑在多台机器上的软件）。现在他们的大部分代码由 AI 编程智能体生成，人力主要负责把关，于是出现了长达约 5000 行、难以拆分的改动，人工审查跟不上。更麻烦的是，智能体常同时写代码和单元测试，测试未必可信。他们的做法是在智能体的“信任范围”之外加入由编译器执行的共享正确性检查，像 Rust 借用检查器那样在运行前就发现问题，让智能体立刻得到反馈。Hydro 目前是早期版本，适合对延迟和吞吐有要求的团队，但还不完善、需要学习；相关工具 Hydro 和 Infinity 已开源，由 AWS 与加州大学伯克利分校联合开发。
这是一场演讲，讲者是 Khawaja Shams，主题是如何高效地大规模运行大语言模型（LLM）服务。问题在于：模型推理很吃 GPU，而对话上下文对应的 KV Cache 会占用大量显存，容易撞上“内存悬崖”，还会拖慢响应、推高成本。演讲从分布式系统的角度给出几种做法：提高 GPU 利用率、管理 KV Cache 内存、利用分层存储、降低尾部延迟，以及把预填充和解码拆开部署。读者可以借此了解如何让整套推理集群跑得更快、更便宜、更稳。目前公开的只有标题和摘要，具体实现细节、数据和演示材料均未说明。
提供的材料未提及具体可用工具。
Manju Rajashekhar 做了一场演讲，讲怎么用 Actor 模型解决生产环境中 AI 智能体运行时的麻烦。Actor 模型可以简单理解成：每个“小工人”（Actor）只管理自己的状态，彼此只靠发消息协作，谁出问题就单独处理。演讲把智能体看成分布式系统，围绕状态由谁持有、消息传递、写穿状态（状态一变就立刻写入持久存储）和监督边界（谁来发现并处理故障）来设计，从而应对失败、任务续接和可动态变化的执行图。这样智能体工作流就能从容易崩溃的演示，变成更稳定、可恢复的架构。目前只是演讲分享，材料没有说明有可用的代码或产品。
提供的材料未提及具体可用工具。
文章讨论分布式系统从微服务走向智能体式 AI 架构的转变。过去微服务是把系统功能拆成小服务，各自负责一块；智能体式架构则是把“做决定”这件事拆开，交给多个能自主判断的 AI 智能体。作者指出，这种变化会让可观测性（看清系统内部发生了什么）、可靠性和整体设计都变得更复杂，因此需要更新原有的架构模式和实践。文章由 Mallika Rao 撰写，但目前只有摘要，具体方案和落地效果原文没有说明。
提供的材料未提及具体可用工具。
软件工程师 Hillel Wayne 做了一场演讲，主题是如何在系统还没真正建好之前，就提前发现那些会导致故障的架构问题。他借用形式化方法里的一些思路，比如属性强度、状态空间验证和环境假设，帮助大家更早地揪出关键 bug。他提出“对抗式非确定性”这样的实用思维模型，用来推理并发、边界情况和分布式系统故障，而且不需要复杂的数学工具。对普通开发者来说，这意味着可以更早发现隐患、少走弯路，降低后期返工的风险。
提供的材料未提及具体可用工具。
rwilliamspbg-ops/Ghostlink · Distributed LLM inference fabric for heterogeneous local clusters. Features zero-copy SPSC ring buffers, automated tuning, and an OpenAI-compatible API.
Ghostlink 是一个用 Rust 编写的分布式推理织构，面向由 CPU、GPU、NPU 混合组成的本地局域网集群。它通过 llama.cpp 的 ggml-rpc 后端拆分 GGUF 模型权重，自动发现局域网节点并按硬件能力放置负载，对外提供 OpenAI 兼容的 /v1/chat/completions API 服务；同时包含硬件探测、自动调优以及 SPSC 环形缓冲区、TCP/UDS 传输、AF_XDP 内核旁路等研究性组件（实验性质，其基准数值只反映传输分帧延迟而非 LLM 生成速度）。