Balto 是 Deep Origin 的生命科学 AI 工作空间产品。这类产品要解决的是一个很实际但常被低估的问题：生物信息与计算化学的软件环境极其难配，数据散落各处，实验记录与计算结果对不上。研究者常常花在配环境和找数据上的时间超过做研究本身。
科研工作空间要解决的问题
| 痛点 | 典型表现 |
|---|---|
| 环境配置地狱 | CUDA 版本、conda 依赖冲突、编译失败 |
| 算力获取慢 | 申请 GPU 排队数天，或本地没有 |
| 数据散落 | 本地硬盘、共享盘、云盘、邮件附件各一份 |
| 结果不可复现 | 半年后重跑得到不同结果，不知道当时用了什么版本 |
| 协作困难 | 「在我机器上能跑」，同事跑不通 |
| 知识不沉淀 | 人离职后流程无人能重现 |
这些问题的共同点是「不是科学问题，但严重消耗科研产能」。一个团队如果每个新人要花两周配环境，这个成本累积起来相当可观。
这类产品的通用能力
- 预配置环境：常用的生信与计算化学工具已装好，开箱即用；
- 弹性算力：按需申请 CPU/GPU 资源，用完释放；
- 统一数据层：数据集中存储，带版本与权限管理；
- Notebook / IDE 集成：熟悉的交互界面；
- 工作流固化：把跑通的流程保存为可复用的模板；
- 协作与共享：环境、数据、结果可在团队内共享。
自建的开源路径
# 这套组合能覆盖大部分核心能力
# 1) 环境标准化 —— 容器化是根本解法
FROM mambaorg/micromamba:1.5
COPY env.yml /tmp/env.yml
RUN micromamba install -y -n base -f /tmp/env.yml && micromamba clean -a
# 锁死版本，保证半年后重跑结果一致
# 2) 交互环境
# JupyterHub（多用户）或 code-server（VS Code in browser）
# 3) 算力调度
# 小规模：Docker Compose
# 集群：Slurm / Kubernetes
# 云端：AWS Batch + 竞价实例（成本可降 60%~80%）
# 4) 数据管理
# 对象存储（MinIO / S3）+ DVC 做版本控制
# 或 LakeFS 做数据湖版本管理
# 5) 工作流
# Nextflow / Snakemake，流程定义进 git
# 6) 实验追踪
# MLflow：记录参数、指标、产物
买还是建：怎么决策
- 团队规模：5 人以下的团队，自建的运维成本摊薄不下来，SaaS 更划算；20 人以上，自建的边际成本优势明显。
- 是否有平台工程能力：没有专职维护的人，自建的平台会迅速腐化。这是最现实的约束——不是能不能搭起来，而是能不能长期维护。
- 数据敏感度：涉及未公开靶点、专有化合物、患者数据时，数据出境是硬约束，往往直接决定必须自建或用私有云。
- 需求的特殊性：需要大量定制工具、非标准流程时，通用平台的适配成本可能超过自建。
- 成本对比：SaaS 订阅费 vs（云资源费 + 至少 0.5～1 个 FTE 的运维人力）。人力成本常常被低估。
无论买还是建，这几条都要做
- 锁死依赖版本：容器镜像或 lock 文件，否则半年后重跑结果不同；
- 记录每次运行的完整上下文：代码版本、数据版本、参数、环境；
- 留出逃生口：必须能导出数据和用自己的脚本处理；
- 从最痛的一两个场景切入：不要一开始就做大而全的平台。
提示
商业平台功能与定价变动较快，本文为方向性介绍，采购前请核对官方最新信息并确认数据保密条款。买还是建的关键往往不是功能对比，而是团队有没有长期维护的能力。