案例研究：真实工作负载，一个控制平面

我们目前还没有客户标识墙。取而代之的是我们自己的基础设施，它每天在 Odysseus 下运行着生产环境和准生产环境的工作负载——我们对其进行了实际测量，而非凭记忆描述。

主机，测量于2026年8月21日

123 个容器不是为了好看而搭建的合成基准测试或演示集群——它是在我们撰写此页面时，来自运行此网站自身控制平面主机上 docker ps 的计数。它包括了下面列出的工作负载以及此主机运行的其他所有内容：控制平面本身、营销站点、监控以及不相关的客户项目。

工作负载A：一个受监管的文档处理平台

此租户的身份受到保密协议保护，因此下文描述的是工作负载的形态，而非其运行方。它是一个真实的、用于处理和验证受监管文档的多服务平台——这种技术栈在大多数企业中会是一个完整的 Kubernetes 应用程序，而在这里，它作为 23 个容器 运行在一个 Odysseus 租户下。

• 一个API服务、一个UI以及专用的接收和模型服务
• 一个Postgres数据库和一个 SeaweedFS 对象存储，用于文档存储
• 一个 Rekor和Trillian透明日志 — 五个容器（rekor-server、rekor-redis、trillian-db、trillian-log-server、trillian-log-signer），提供密码学可验证的、仅追加的文档来源记录，这与Sigstore背后的透明日志技术相同
• 十二个专用工作者，每个都是其自身的容器：cad、classify、codedraft、codeingest、evaluate、explain、export、ifc、notifier、pdf、release、structured

这是一个具有真实依赖图的微服务架构——一个数据库、一个对象存储、一个拥有五个容器拓扑的透明日志、以及十几个可独立扩展的工作器——它们作为一个 Odysseus 租户，运行在一个控制平面上，其下没有叠加任何独立的编排器。

工作负载B：一个针对多租户的 SaaS 后端

同一主机上的第二个不相关租户运行着 36 个容器：后端和前端服务、一个文档摄取与提取管道、嵌入模型、一个 MCP 网关和构建器、一个超级管理员和租户管理员控制台对（每个都有自己的后端和前端）、MongoDB、Redis、RabbitMQ，以及一个自己的小型内部数据库中继集群。这是一个完全独立的应用程序，具有完全独立的形态，通过 合规性页面上描述的相同租户边界与工作负载 A 隔离——它并非同一技术栈的一个变体。

此规模下的控制平面开销

所有这些都不需要运行更重的控制平面来管理。Odysseus 自身的常驻内存占用经过实际测量——而非建模——在生产环境中为 47-51 MB，在开发环境中为 49-64 MB，该数据在 2026 年 8 月 20 日对每个环境进行了 14 分钟窗口内的 18-19 次采样，并发布在 主页的方法学脚注中。2026 年 8 月 21 日在同一次主机上的现场检查读取为 57 MB 常驻——处于该测量范围内，并非新的主张。

这展示了什么，以及没有展示什么

这是一台主机，而非大规模集群基准测试，我们将其呈现为：证据表明 Odysseus 能够在一个真实的、多服务、安全敏感型工作负载（该工作负载与一个不相关的多租户 SaaS 后端并行运行）下保持稳定——而并非是对上限的主张。关于该平台控制平面运行在真正独立基础设施上的情况，请参阅 多云验证 页面。