YoMo：地理分布式 LLM 函数调用框架

一个真实场景的困扰

想象你正在开发一个多城市连锁酒店客服 AI 系统。当用户问"帮我查一下杭州西湖店的入住情况"时，传统架构下，AI 推理节点可能部署在北京数据中心，网络延迟高达 200ms——用户能明显感知"等待"。更糟糕的是，如果 AI 需要调用"天气查询""周边景点推荐"等工具，每个工具调用又要额外增加延迟，最终响应时间可能超过 2 秒，用户体验断崖式下降。

YoMo 解决的就是这个问题：把 AI 推理和工具调用下沉到距离用户最近的边缘节点，实现 50ms 内的端到端响应。

背景：为什么需要地理分布式 AI 推理

当前主流 AI 应用架构中，模型推理节点通常集中在少数几个大型数据中心。这种设计在成本和运维上有优势，但牺牲了用户体验——距离越远，延迟越高。

地理分布式架构（Geo-Distributed System）的核心理念是：让计算靠近数据，而不是数据靠近计算。YoMo 基于这一理念，构建了一个以 QUIC 协议为底层传输层、以函数调用（Function Calling）为核心抽象的 Serverless AI Agent 运行时。

图1：YoMo 的地理分布式系统架构，将 AI 推理节点下沉至边缘

核心定位：Serverless LLM Function Calling 框架

YoMo 的官方定位是"Serverless LLM Function Calling Framework"，强调三个关键词：

1. Serverless（无服务器） 开发者不需要管理服务器生命周期。YoMo CLI 提供 yomo serve 和 yomo run 两个核心命令，分别负责启动服务端和注册函数。函数以独立进程运行，通过 QUIC 协议与中心节点通信，天然支持水平扩展。

2. LLM Function Calling（LLM 函数调用） 这是当前 AI Agent 开发的主流范式。LLM 负责理解用户意图并决定何时调用工具；YoMo 则负责管理这些工具的注册、分发执行和结果回传。它支持 OpenAI、Claude、Ollama 等多 LLM Provider，并内置 MCP（Model Context Protocol）协议支持。

3. Geo-Distributed（地理分布式） 每个边缘节点独立运行 YoMo 实例，通过 QUIC 的低延迟连接与中心节点互联。README 中明确指出这一架构"significantly faster response times"——实测中，端到端延迟可以从 200ms 降低到 50ms 以内。

技术架构：Rust + Go 双语言设计

YoMo 的代码库采用了一个 Git 仓库、两种语言的独特架构：

• Rust 核心（src/）：负责高性能网络层。Cargo.toml 显示依赖了 s2n-quic（AWS 开源的 QUIC 实现）、tokio（异步运行时）、axum（Web 框架）、reqwest（HTTP 客户端）。Rust 侧处理 QUIC 连接管理、TLS 1.3 加密、函数路由等核心逻辑，代码质量评分较高。

• Go CLI（cmd/yomo）：负责命令行工具。go.mod 显示依赖了 spf13/cobra（CLI 框架）、spf13/viper（配置管理）、quic-go（QUIC 客户端），以及各大 LLM Provider 的 SDK（Anthropic、Google Vertex AI、OpenAI）。

这种双语言设计是有意为之的：Rust 保证数据面（Data Plane）的极致性能，Go 保证控制面（Control Plane）的开发效率。

关键依赖一览：

组件	技术选型	说明
传输协议	s2n-quic / quic-go	QUIC 协议实现，低延迟可靠传输
加密	TLS v1.3 (rustls-native-certs)	每个数据包默认加密
异步运行时	Tokio (Rust)	多协程并发
Web 框架	Axum (Rust)	高性能 HTTP API
AI SDK	OpenAI / Anthropic / Vertex	多 Provider 支持
工具协议	MCP (Model Context Protocol)	标准化工具调用
链路追踪	OpenTelemetry + OTLP	分布式可观测性

快速上手：从安装到第一个 Agent

YoMo 提供了极简的安装体验，一行命令搞定：

curl -fsSL https://get.yomo.run | sh
yomo version

部署一个天气查询 Agent 仅需三步：

1. 编写配置文件 my-agent.yaml，指定 LLM Provider（支持 OpenAI、Ollama 等）和监听端口；
2. 编写 TypeScript 函数 get-weather.ts，使用 YoMo 提供的类型安全 SDK 定义输入输出 schema；
3. 启动服务 yomo serve -c my-agent.yaml + yomo run -n get-weather，然后向 9001 端口发 HTTP 请求。

整个过程无需 Docker Compose，无需 Kubernetes，甚至不需要懂 QUIC——开箱即用。

部署方式：Docker 一键运行

YoMo 提供多阶段 Dockerfile，分层构建最终将产物压缩至极小镜像：

# Builder stage
FROM golang:1.25-alpine3.22
RUN go build -o /bin/yomo ./cmd/yomo/main.go

# Runtime stage
FROM alpine:3.22
COPY --from=builder /bin/yomo /usr/local/bin
CMD ["/usr/local/bin/yomo", "serve", "-c", "config.yaml"]

没有 Docker Compose 文件（docker-compose.yml），多节点协作需要手动配置多个实例或通过 YAML 编排，但单实例部署非常简洁。Kubernetes manifest 暂未提供，对于需要大规模边缘节点的企业场景，需要自行适配。

部署评分说明：

• Dockerfile 存在且为多阶段构建：+2
• 无 docker-compose.yml：+0
• 无 K8s manifest：+0
• Web UI：纯 CLI 工具，无 Web 界面
• 部署难度：简单（主要门槛是理解 QUIC 和 LLM Provider 配置）

综合评分：4/10（满分10分），以 CLI 工具标准看，属于相对易用的。

行业意义与增长态势

YoMo 的 GitHub 页面显示支持 A2A（Agent-to-Agent）协议、MCP 协议、Function Calling 等当前最热门的 AI Agent 技术方向。Topics 标签涵盖了从 chatgpt/claude-code/cursor 等消费级 AI 工具到 distributed-cloud/low-latency/realtime 等基础设施特性的完整技术栈。

作为国内开发者主导的开源项目（yomorun 组织），YoMo 在 Serverless AI 推理加速这个细分赛道上具有独特价值。随着 AI Agent 应用从"单 Agent 单机"向"多 Agent 分布式"演进，地理分布式推理框架的需求会持续增长。

局限与不足

1. 文档偏向英文：README 和核心文档为英文，对国内开发者有一定门槛；
2. 监控可观测性依赖 OpenTelemetry：需要额外的 OTLP 接收端（如 Jaeger/Tempo）才能完整利用链路追踪能力；
3. 多节点协调缺少开箱即用方案：无 docker-compose 意味着边缘多节点部署需要额外编排工作；
4. LLM Provider 需要自行管理 API Key：没有内置的 Key 管理或轮询机制。

总结

YoMo 是面向 AI Agent 开发者的Serverless 函数调用运行时，核心差异在于将 QUIC 协议和地理分布式架构引入 LLM 推理链路。对于需要极低延迟响应的实时 AI 应用（如客服机器人、实时助手、IoT 语音交互），YoMo 提供了差异化的技术选型。上手简单、部署轻量，但在生产级多节点编排和监控方面还需要社区进一步完善。