自行运行
在自有服务器上运行开放权重 LLM
Llama、Qwen、DeepSeek 或 Mistral 等模型，在您掌控的 GPU 上提供服务，位于您的数据中心或您自己的云账号中。提示词和数据留在您的网络之内，成本取决于您的硬件而非按 Token 计费，模型只在您决定时才会更换。
- 针对您的模型、上下文长度与延迟目标调优的推理服务引擎
- GPU 共享，让多个模型和团队共用您已有的 GPU 卡
- 您的微调模型以 LoRA 适配器的形式部署在共享基础模型之上
GPU 共享 · 模型服务 · 推理路由
基于 Kubernetes 的 AI 基础设施。
我们设计并运维介于您的模型与加速器之间的平台：GPU 调度与共享、模型服务、推理路由，以及围绕它们的可观测性与成本控制。
打开简短表单，工程师 1–2 个工作日内回复，与您一起商量从哪里开始。
- 开放权重与前沿模型
- 云、本地部署或离线隔离环境
- 评估、构建或运维
服务概述
您的模型赖以运行的那一层，
专为 GPU 而建。
大多数平台在设计之初，既没有考虑 GPU 和模型，也没有考虑如今同时追问这两者的审计方。我们设计介于您的模型与加速器之间的 Kubernetes 层，随后为您运维，或交接给贵司团队，并由一个工程伙伴对各部分的协同运作负责，任何建议背后都没有供应商的利益驱动。
应用场景
运行模型，由您做主。
团队来找我们，通常带着两个目标之一。底层则是同一个平台：GPU 高效共享，模型快速提供服务，每个请求都遵循您的策略。
混合与路由
前沿模型与本地模型，统一在一个网关之后
敏感或高流量的请求留在您自己的模型上，需要 GPT、Claude 或 Gemini 等前沿模型的请求则发往相应的提供商。您的应用只调用一个 OpenAI 兼容端点，两边适用同样的认证、限额与用量记录。
- 路由规则，依据数据敏感度、成本或请求所需的能力
- 在您自己的模型与托管 API 之间进行故障转移
- 按团队统计用量与支出，覆盖您的 GPU 与 API 账单
我们设计并运维什么
六个领域，
一个平台。
每一项都是 AI 卡在演示与生产之间的常见原因。其中一项的变化会体现在其他各项上，因此我们把它们放在一起处理。
GPU 调度与共享
强制限额的 GPU 切分、需要硬隔离时的 MIG，以及作为原生 API 的 DRA，让一张卡同时承载多个工作负载。
- 实测先行：按团队、按工作负载对比分配量与实际利用率
- 真正生效的共享：显存与算力限额按工作负载强制执行，而不只是停留在请求中
- 作业放置：通过排队与装箱调度，让作业适配您已有的 GPU 卡
模型服务
针对您的模型与流量调优的推理服务引擎、权重超出单节点时的多节点副本，以及按队列深度而非 CPU 进行的自动扩缩。
- 针对您的模型、上下文长度与延迟目标进行引擎选型与调优
- 将新模型版本逐步引入线上流量的发布与回滚
- 按队列深度与延迟、而非 CPU 进行的自动扩缩
推理路由与 KV 缓存
把每个请求发往已持有其提示词 KV 缓存的副本，或队列最短的副本，让共享上下文不被重复计算，首 Token 时间保持在低位。
- 缓存感知路由：对话与共享提示词会被送到其 KV 缓存已在的位置
- 引擎内的前缀缓存，让重复的系统提示词与文档无需重新计算
- KV 缓存卸载到 CPU 内存或存储，应对长上下文与大量并发用户
多模型服务
多个模型与微调适配器运行在共享 GPU 上，统一在一个 OpenAI 兼容端点之后；每个团队的流量按模型名称路由，并受各自的限额约束。
- 单一端点，覆盖您的团队使用的每个模型与版本
- 在共享基础模型上承载的 LoRA 适配器，无需为每个微调保留一份完整副本
- 针对请求数与 Token 数的团队级限额，避免一个工作负载耗尽其他负载的资源
监控与 GPU 成本
首 Token 时间、每个输出 Token 的时间与 GPU 遥测并列呈现，并基于同一份数据按团队和模型核算成本，让容量规划跟随实测需求。
- 用户感受到的延迟：按模型统计首 Token 时间与每个输出 Token 的时间
- GPU 遥测：从设备层开始采集的利用率、显存与错误
- 按团队与模型核算成本，并提供财务团队可以审核的成本分摊
自主可控与离线隔离
本地镜像仓库、离线模型存储、签名制品与准入策略，为必须留在您边界之内的 AI 而建。
- 位于您网络内部的本地镜像仓库与离线模型存储
- 签名制品，在任何内容运行之前完成验证
- 让工作负载始终处于您所设规则之内的准入策略
开源
我们赖以构建的云原生 AI 技术栈。
开源项目与 GPU 功能，组装成一个平台，并作为一个整体运维。这些是典型选择，而非固定的技术栈：我们会围绕您的需求和您已在使用的工具进行选型。
您的应用
对话 · 智能体 · API
网关与路由
为每个模型（无论自托管还是外部托管）提供一个 OpenAI 兼容端点，并依据缓存与队列状态路由每个请求。
- Gateway API Inference Extension
- llm-d router
- Agent Router原名 Envoy AI Gateway
分布式推理与 KV 缓存
推理分布在多块 GPU 与多个节点上，KV 缓存跨请求复用，而不是重新计算。
- llm-d
- LMCache
模型服务
运行您模型的引擎，以及负责部署、扩缩与发布它们的 Kubernetes 资源。
- vLLM
- SGLang
- KServe
GPU 共享与调度
GPU 切分与分区、Kubernetes 设备 claim，以及按团队设定配额的作业队列。
- HAMi
- DRA
- MIG
- Kueue
GPU 节点
每个节点上的驱动、device plugin 与 GPU 健康监控。
- NVIDIA GPU Operator
- AMD GPU Operator
您的加速器
NVIDIA · AMD · 云 · 本地部署
贯穿每一层
监控与成本
延迟、GPU 遥测，以及按团队和模型的成本。
- Prometheus
- OpenTelemetry
- DCGM Exporter
- OpenCost
供应链与策略
镜像同步的容器镜像与模型、签名制品，以及准入规则。
- Harbor
- Kyverno
- Sigstore
我们从这些场景切入
AI 团队找上我们时的四种处境。
每一种都对应一个已经定义好的服务方案，而且每一个都从与工程师的一次沟通开始。
“我们的 GPU 全都分配出去了，却大多闲着。”
整卡申请把加速器整块锁住，而它们只发挥了一小部分能力。评审会测量真实利用率，找出共享、排队与装箱调度能在哪里收回容量；落地实施则是单独的实施项目，让您在追加采购之前先收回容量。
平台就绪度评审“模型在演示里跑得很好。上了生产就是另一回事。”
延迟目标、自动扩缩、发布策略，以及理解 KV 缓存的路由：我们构建承载您模型的推理服务平台，连同文档一起交接，之后由贵司运维。
实施项目“我们的 AI 必须留在自己的边界之内。”
受监管的数据、内部模型，或是一个没有对外出口的网络。我们以本地镜像仓库、离线模型存储、签名制品与准入策略构建平台，让它运行在您的规则要求它运行的地方。
实施项目“运维是一份全职工作，超出了我们团队的人力。”
GPU 驱动、Operator、推理服务引擎与模型都在快速迭代，一次升级就可能破坏另一层。在为期 12 个月的合作中，由我们的工程师运维、升级并改进平台，让贵司团队专注于模型。
托管平台FAQ
开始之前，AI 团队最常问的问题。
Todea 提供 GPU 或模型吗？
不提供。模型与加速器始终归您所有，留在您的云账号或数据中心里。我们设计并运维两者之间的平台：工作负载如何调度并共享 GPU，模型如何提供服务与路由，以及这一切如何被观测、核算成本并得到保护。
我们还能继续使用 GPT 或 Claude 这样的前沿模型吗？
可以。许多团队把敏感或高流量的工作放在自己 GPU 上的开放权重模型上运行，同时为需要它的请求保留一个托管的前沿模型。我们把两者统一在一个网关之后，您的应用只需调用一个端点，每个请求都适用同样的认证、限额与用量记录。
支持哪些加速器与环境？
支持 NVIDIA 与 AMD GPU，运行于 AWS、Google Cloud、Azure、Naver Cloud 或本地部署环境，也包括依靠本地镜像仓库与离线模型存储运行的离线隔离网络。
我们必须替换现有工具吗？
不需要。我们综合考量您的需求、现有投资、团队技能与成本，讲清其中的权衡，并在现有工具合适时继续沿用。任何建议背后都没有来自云服务商、发行版厂商或软件供应商的利益驱动。
Todea 会构建或训练我们的模型吗？
不会。模型以及使用模型的应用归贵司团队所有。我们的工作是其下的平台：模型如何在 GPU 上提供服务、路由与调度，以及整个技术栈如何被观测并得到保护。
从哪里开始？
从与工程师的一次沟通开始。如果您已经在 Kubernetes 上运行 AI 工作负载，平台就绪度评审会在 2 到 4 周内，以固定费用为您提供一份按优先级排序的平台评估。如果您是从零开始，实施项目会构建平台，托管平台合约也可以包含构建。
来自我们的工程师
与这项服务相关的文章与演讲。
由亲自做这项工作的工程师撰写和演讲。在联系我们之前，您可以先判断我们的技术深度。
模型、GPU，以及两者之间的平台。
与亲自构建它的工程师直接沟通。
探讨您的 AI 平台
打开简短表单，工程师 1–2 个工作日内回复，与您一起商量从哪里开始。