本文基于对安徽融合智算科技有限公司（tensor-fusion.ai）联合创始人杨文斌的采访编辑而成，在此表示感谢。

融合智算是一家专注于 GPU 虚拟化与池化技术的 AI Infra 初创公司，成立于 2025 年 1 月，核心产品为开源项目 Tensor Fusion。公司致⼒于让 AI 算⼒像⽔电⼀样灵活切分、按需使⽤、安全共享，⽀撑 AI 业务在企业⾼效落地。本文记录了他们从 Day 1 选择 GreptimeDB，构建私有云 GPU 可观测性体系的完整历程——以及一个初创团队在早期做技术选型时，真正在意的是什么。

---

背景：让 GPU 算力"像水电一样"按需调度

在 AI 大模型落地的浪潮下，GPU 是企业最稀缺、也最难管理的生产资料之一。物理 GPU 不可分割，资源利用率往往不高：要么业务排队等待，要么 GPU 大量空转。Tensor Fusion 正是为了解决这个问题——通过 GPU 虚拟化和池化技术，把物理 GPU 切分为多个 vGPU，让 AI 算力像水电一样灵活切分、按需使用、安全共享。

要让这套调度系统真正可靠，可观测性是前提也是底座。运维人员需要实时掌握：

• 每块物理 GPU 的显存使用量与算力水位
• 每个 vGPU Worker 的实际资源分配，以及调度到的 GPU ID
• 算力池整体容量与超售情况
• 扩缩容触发事件的完整上下文

这些数据既是稳定性保障的基础，也是精细化计费的数据源。对一个 AI Infra 产品来说，可观测性设计是否到位，直接影响产品能否规模化交付与商业化落地。

Day 1 选型：初创公司真正在意什么

Tensor Fusion 团队在云平台和 SRE 领域有多年积累，对技术选型也更"务实"：

"团队被 Prometheus 的高基数问题半夜 On-call 留下过心理阴影，也见识过一些分布式方案带来的运维复杂度。"

GPU 可观测性场景天然是高基数的：每块 GPU、每个 vGPU Worker、每个 Namespace 和 Pod 都会带来独立的标签维度，这对时序数据库的索引与写入组织方式都是直接考验。

对于一个刚起步的 AI Infra 初创公司，可观测性数据库需要同时满足三个不同阶段的要求，缺一不可：

阶段	需求
开发测试	一个 YAML 一键部署 Standalone 实例，本地即可验证
生产上线	支持客户私有化部署，不绑定云厂商
规模扩展	大客户场景可引入原厂支持，留有弹性

三个条件看起来并不苛刻，但同时满足其实并不容易——很多方案能做到其中两点，却在第三点上留下隐患：要么本地太重，要么私有化交付复杂，要么缺乏企业级支持的路径。

通过 Vector 社区和 GitHub，团队发现了 GreptimeDB。仔细评估后，架构简洁、原生支持高基数场景、All-in-one TSDB 这三点同时满足了上述三个阶段的需求——其他开源存储方案也考虑过，但同时满足这三点的，当时看只有 GreptimeDB。

这也正是 Tensor Fusion 最终选择它的核心原因：不是因为它"最强"，而是因为它在整个生命周期里都够用，而且一个产品就搞定，不需要拼多套系统。

可观测性架构：从 Hypervisor 到 Dashboard 的完整管道

Tensor Fusion 的可观测性管道分三层：

GPU Hypervisor 组件（指标采集源）
        │
        ├─── Vector sidecar（日志规范化 + 指标转发）
        │         │ InfluxDB Line Protocol
        │         ▼
        └─── Golang SDK 直写（关键调度事件）
                  │ InfluxDB Line Protocol
                  ▼
              GreptimeDB（私有化部署）
                  │
                  ▼
          管理端 Dashboard（Grafana 可视化）

数据从两条路径写入 GreptimeDB：Vector sidecar 负责采集容器日志和系统指标，经过规范化处理后通过 InfluxDB Line Protocol 写入；Golang SDK 则在关键调度事件发生时直接上报，同样使用 InfluxDB Line Protocol 协议。

查询主要使用 SQL，在计费等聚合统计场景下尤其适合——无需引入 PromQL 或 Flux，团队熟悉的 SQL 语法即可直接完成按时间窗口的算力用量统计。

指标层：三维度覆盖 GPU 全栈资源

指标采集频率为每分钟一次，覆盖三个核心层次：

• tf_gpu_usage：物理 GPU 的实际使用情况，包含显存占用、算力利用率
• tf_worker_usage：vGPU Worker 的资源使用，关联到具体工作负载和 Namespace
• tf_worker_resources：调度事件记录，包含 Worker 的扩缩容时间、实际分配的 GPU ID、资源分配变更

这三张核心表共同支撑算力池的容量监控、超售洞察和自动扩缩容策略的数据输入。

日志层：GPU Pod 创建的完整事件链路

日志来自容器标准输出，经 Vector 规范化处理后写入 GreptimeDB。Tensor Fusion 最有价值的日志查询场景是：追踪一个 GPU Pod 从创建到就绪的完整链路——跨越 AdmissionWebhook、Operator、Scheduler、CUDALimiter、RemoteGPU Worker 五个组件，在同一个查询界面里还原全貌。这种跨组件的端到端追踪，是排查调度异常、资源分配失败等问题的关键手段。

部署形态

Tensor Fusion 主要面向私有云场景，GreptimeDB 以 self-hosted 方式部署。开发测试环境通过 Helm Chart 一键拉起 Standalone 实例（参见 greptime-standalone.yaml）；生产环境随客户规模灵活扩展，团队将数据保留策略配置为 30 天。

踩过的坑，以及如何解决

坑 1：InfluxDB Line Protocol SDK 的 tag key 排序问题

现象：使用 github.com/influxdata/line-protocol/v2/lineprotocol 这个 Go SDK 编码写入数据时，偶发写入失败。

原因：该 SDK 默认在严格模式下运行，要求 tag key 必须按字母顺序排列（lexical order），违反规则会导致编码报错。这与 GreptimeDB 本身无关，属于 SDK 侧的默认行为约束。

修复：在初始化 Encoder 时调用 SetLax(true) 关闭严格校验：

enc := lineprotocol.Encoder{}
enc.SetPrecision(lineprotocol.Millisecond)
enc.SetLax(true)

坑 2：多写入源导致字段语义类型冲突

现象：提前手动建表并指定表结构后，来自不同写入源（Vector 和 Golang SDK）的数据写入失败，Vector 侧日志中出现如下报错：

WARN vector::sinks::util::retries: Retrying after error.
error=status: InvalidArgument,
message: "Invalid request to region 4793183502336(1116, 0),
reason: column uuid has semantic type Field, given: TAG(0)"

原因：Vector 和 Golang SDK 对同一个字段的语义类型判断不一致——同一列 uuid，Vector 将其识别为 Field，SDK 将其识别为 Tag。提前建表固化了 schema，两边的类型期望产生冲突，GreptimeDB 拒绝接受与已有 schema 不符的写入。

修复：放弃手动建表，改为依赖 GreptimeDB 在首次写入时自动推断并生成表结构。自动建表后，schema 由实际写入数据决定，不再受多源不一致影响，冲突彻底消失。

这个问题背后的经验是：在多个写入端（Vector sidecar + SDK 直写）并存的架构里，手动维护 schema 的成本很高，且极易在快速迭代中出错。GreptimeDB 的 schemaless 自动建表机制，在这种场景下是更务实的选择。

坑 3：Cloudflare Worker 环境无法使用 pg driver 直连

现象：尝试在 Cloudflare Worker 中通过 PostgreSQL 驱动连接 GreptimeDB 时，连接始终失败。

原因：Cloudflare Worker 基于 V8 引擎构建的 Serverless 沙箱环境，没有原生 TCP 连接能力，常规 pg driver 依赖 TCP socket，因此无法直接建立数据库连接。

修复：改用 Cloudflare 提供的 Hyperdrive。Hyperdrive 在 Cloudflare 的网络侧维护连接池，Worker 侧通过兼容 pg 协议的 HTTP 接口访问，从而绕过 TCP 限制，实现在 Serverless 环境中访问 GreptimeDB（PostgreSQL 协议端口）。

实际收益：不只是"存数据"

计费能力开发成本明显降低

GPU 算力计费是 Tensor Fusion 商业模式的核心。借助 GreptimeDB 对时序事件的聚合能力，再加上 SQL 查询的灵活性，团队只需要上报调度事件和资源使用数据，就能做精细化算力计量，不必在早期额外引入 Kafka、Flink 等流处理组件。这个决策直接减少了早期团队的工程投入。

一库覆盖多种数据类型

GreptimeDB 统一存储指标、日志和调度事件，让 Tensor Fusion 避免维护多套异构系统的复杂度。对于私有云 AI Infra 场景，架构越简单，客户侧的部署和运维负担就越低——这也是产品竞争力的一部分。

开发测试提速明显

Standalone 模式下，一个 YAML 就能启动，本地开发不需要先搭分布式集群。对快速迭代的初创团队来说，这能缩短从功能设计到数据验证的周期。

下一步：把 Grafana 也"简化掉"

目前 Tensor Fusion 依赖 Grafana 做可视化，但团队也有明确预期：希望未来能有与 GreptimeDB 深度集成的轻量告警和可视化方案，进一步降低可观测性栈的部署与运维成本。这也代表了一类私有云 AI Infra 用户的共同诉求：能少一层组件，就少一层组件。

---

总结

Tensor Fusion 的案例，提供了一个初创公司做可观测性选型的清晰视角：不是找功能最全的，而是找在整个生命周期里都不会成为瓶颈的。

从本地一个 YAML 跑起来，到私有化交付给客户，再到大规模企业场景引入专业支持——GreptimeDB 的 All-in-one 设计和架构简洁性，让团队在每个阶段都没有遇到"需要换掉它"的理由。这对一个资源有限、需要快速迭代的初创团队来说，是比功能列表更重要的选型依据。

---

关于 Tensor Fusion：tensor-fusion.ai | GitHub

欢迎 Star，一起让 GPU 算力像水电一样普惠。