LabHub

ブログ

MLOpsプラットフォーム 2026 完全版 - MLflow · Kubeflow · W&B · Vertex AI · SageMaker · Databricks · BentoML · Ray · Modal · Hugging Face 徹底ガイド

2026-05-16 · 21 分で読めます · #mlops#mlflow#kubeflow#weights-and-biases#vertex-ai#sagemaker#databricks#bentoml#ray#modal#huggingface#model-serving#experiment-tracking#llm-ops

한국어English日本語

はじめに — 2026年5月、MLOpsとLLMOpsは同じ表面を共有する

2024年までは「MLOps」と「LLMOps」という言葉は別物として扱われていた。2026年5月現在、両者はほぼ同じ表面を共有している。実験トラッキングはプロンプトrunを記録し、モデルレジストリはLoRAアダプタをバージョン管理し、サービングプラットフォームはvLLMとTGIを公式バックエンドとして搭載する。監視ツールはデータドリフトだけでなく、ハルシネーション率、毒性、faithfulnessを同じダッシュボードに並べる。

本記事は流行のplatform-of-the-monthマトリクスではない。2026年に本番のMLチームが実際にどんな組み合わせを動かしているのかを30個のツールでまとめる。OSS優先のスタック、クラウドマネージドのスタック、「GPUだけ借りる」サーバーレススタック、韓国・日本の大手の社内プラットフォームまで同じ物差しで見る。

2026 MLOpsスタックを8レイヤーに分解する

まず全体像から。2026年の標準MLOpsスタックは次の8レイヤーに分解できる。

  1. 実験トラッキング (experiment tracking): run、パラメータ、メトリクス、アーティファクト
  2. モデルレジストリ (model registry): バージョン、ステージ、モデルカード
  3. パイプラインオーケストレーション (orchestration): DAG、キャッシュ、再試行
  4. 学習インフラ (training infra): GPUスケジューリング、分散学習、HPO
  5. モデルサービング (serving): オンライン / バッチ / エッジ
  6. データバージョニング (data versioning): データセット、特徴量、インデックス
  7. 監視 (monitoring): データドリフト、概念ドリフト、予測ドリフト
  8. LLM評価 (LLM eval): faithfulness、毒性、jailbreak検出

1〜2個のツールで1レイヤーを片付けられた時代は終わった。同じレイヤーの中でもクラシックMLトラックとLLMトラックに分岐する。

実験トラッキング — MLflow 3、Weights & Biases、Comet、Neptune.ai

実験トラッキングの90%は2つのツールで占められている。MLflow 3.0とWeights & Biasesだ。MLflowはDatabricksが作りLinux Foundationに寄贈したBSDライセンスのOSSで、3.0からはGenAIトレーシング、評価、プロンプトレジストリが一級市民になった。W&BはSaaS優先だがSDKはオープンで、Models / Weave / Launch / Sweepsを1パッケージで売る。

代替群も無視できない。Comet MLはML + LLM実験 + 本番監視を統合したSaaS、Neptune.aiは基盤モデル学習向けのメタデータストアにポジショニングを強化した。OSSセルフホスト陣営ではAimとClearMLが固い。

代表的なMLflow 3コードは次のようになる。

import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

mlflow.set_tracking_uri("http://mlflow.internal:5000")
mlflow.set_experiment("iris-rf-2026")

X, y = load_iris(return_X_y=True)
with mlflow.start_run() as run:
    mlflow.log_param("n_estimators", 200)
    model = RandomForestClassifier(n_estimators=200).fit(X, y)
    mlflow.log_metric("train_acc", model.score(X, y))
    mlflow.sklearn.log_model(
        model,
        artifact_path="model",
        registered_model_name="iris-rf",
    )
    print(run.info.run_id)

同じ流れをW&Bで書くとこうなる。

import wandb
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

run = wandb.init(project="iris-rf-2026", config={"n_estimators": 200})
X, y = load_iris(return_X_y=True)
model = RandomForestClassifier(n_estimators=200).fit(X, y)
wandb.log({"train_acc": model.score(X, y)})
artifact = wandb.Artifact("iris-rf", type="model")
artifact.add_file("model.pkl")
run.log_artifact(artifact)
wandb.finish()

ストレージとガバナンスで分かれる。MLflowはセルフホストが標準でライセンスも友好的だがUIは平凡。W&Bは協業UXが滑らかでLLM評価も同梱だがコストが累積しやすい。

ClearML、DagsHub、MLEM — OSS陣営の統合ツール

ClearMLは実験トラッキング + オーケストレーション + データ管理 + サービングを1パッケージにまとめたOSSだ。agent-workerパターンでキューにジョブを投げるとGPUノードが拾って実行する。1ツールで完結させたい中小チームがよく選ぶ。

DagsHubはDVC + MLflow + Git LFSを1つのSaaS UIに束ねる。データバージョニングと実験トラッキングを同じ画面で見られる点が売り。MLEMはIterative.aiが作るモデルパッケージツールで、scikit-learn / PyTorchモデルをFastAPIサービスとして一行で書き出せる。

Kubeflow 1.10 — K8s上のフルスタックMLプラットフォーム

Kubeflowは単一ツールではなくK8s上のフルスタックだ。2026年5月の1.10ラインの主要コンポーネントは次の通り。

KFPパイプラインはPythonで書きYAMLにコンパイルする。

from kfp import dsl, compiler

@dsl.component(base_image="python:3.11")
def preprocess(input_path: str, output_path: dsl.OutputPath(str)) -> None:
    import pandas as pd
    df = pd.read_csv(input_path)
    df.to_parquet(output_path)

@dsl.component(base_image="ghcr.io/myorg/trainer:1.4")
def train(data_path: dsl.InputPath(str), model_path: dsl.OutputPath(str)) -> None:
    import joblib, pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    df = pd.read_parquet(data_path)
    model = RandomForestClassifier().fit(df.drop("y", axis=1), df["y"])
    joblib.dump(model, model_path)

@dsl.pipeline(name="iris-pipeline")
def iris_pipeline(input_path: str) -> None:
    p = preprocess(input_path=input_path)
    train(data_path=p.output)

compiler.Compiler().compile(iris_pipeline, "iris.yaml")

隠れたコストはK8s自体だ。EKS / GKE / AKSのマネージドKubeflowを使わないなら、専任プラットフォームチームが事実上必須になる。

Metaflow、Flyte、ZenML、Prefect ML、Airflow ML

K8sネイティブが重すぎるなら、Python優先ツールを選ぶ。MetaflowはNetflixが作りOuterboundsが商用化した。AWS Batch + Step Functionsと深く統合され、デコレータ1行でGPUステップを宣言できる。FlyteはLyft発でUnion.aiが商用化。K8sネイティブ + 型安全が強み。

ZenMLは「フレームワーク非依存の抽象化レイヤー」として位置づけられる。MLflow / W&B / Kubeflow / Airflow / SageMakerをバックエンドとして差し込み、同じコードを移し替える。Prefect 3 + Prefect MLはデータパイプラインとMLパイプラインを1つのUIで見る。Airflow 3はML向けデコレータ(@task.virtualenv、@task.kubernetes)を追加したが依然としてML優先のツールではない。

Vertex AI — Google CloudのフルマネージドML

GCPのVertex AIは学習 + チューニング + サービング + パイプライン + 特徴量ストア + 監視を1つのコンソールに束ねる。Custom Training、AutoML、Workbench(ノートブック)、Pipelines(KFPベース)、Endpoints、Model Garden、Vertex AI Agent Builder、Vertex AI Searchなどに分岐する。

Vertex AI Custom Jobはこう投入する。

from google.cloud import aiplatform

aiplatform.init(project="my-project", location="us-central1")

job = aiplatform.CustomContainerTrainingJob(
    display_name="iris-rf-2026",
    container_uri="us-central1-docker.pkg.dev/my-project/ml/iris-trainer:1.4",
    model_serving_container_image_uri="us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-3:latest",
)
model = job.run(
    args=["--n_estimators=200"],
    replica_count=1,
    machine_type="n1-standard-8",
    accelerator_type="NVIDIA_TESLA_T4",
    accelerator_count=1,
)

Vertex AIの強みはBigQuery + Dataplex + Lookerとの自然な統合、Gemini学習インフラのノウハウ、そしてModel Gardenによる70以上の基盤モデル提供だ。弱みはGCPロックインと、セルフホストよりも顕著に高いインスタンス単価である。

SageMaker — AWSのML山脈

AWS SageMakerは単一サービスではなく山脈だ。2026年5月時点で次のように分かれる。

エンドポイントを展開すれば次のコードブロックだけだ。

import boto3
from sagemaker import Session
from sagemaker.sklearn import SKLearnModel

session = Session()
role = "arn:aws:iam::123456789012:role/SageMakerRole"

model = SKLearnModel(
    model_data="s3://my-bucket/iris-rf/model.tar.gz",
    role=role,
    entry_point="inference.py",
    framework_version="1.4-1",
    sagemaker_session=session,
)
predictor = model.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.large",
    endpoint_name="iris-rf-endpoint",
)
print(predictor.predict([[5.1, 3.5, 1.4, 0.2]]))

SageMakerの強みはAWS統合(S3、IAM、VPC、CloudWatch、EventBridge)と深い自動化だ。弱みはインスタンス単価がEC2比で30〜50%高いことと、JumpStartモデルのライセンス追跡を別途行う必要がある点だ。

Azure ML Studio + Microsoft Fabric

Azure Machine Learning StudioはSageMaker / Vertex AIと同じポジションだ。Workspaces、Compute Clusters、Pipelines、Endpoints (Online + Batch)、Model Catalog、Prompt Flow、Responsible AI Dashboardを束ねる。2026年に入ってMicrosoft Fabric + Azure MLの統合が強化され、OneLakeのデータをそのまま学習入力にできる。Azure OpenAI Serviceは別サービスだがPrompt Flowから呼び出せる。

エンタープライズMicrosoftスタック(Entra ID、Purview、Defender for Cloud)との深い統合が強み。弱みはUIの一貫性に難があり、自己署名証明書やprivate linkの設定の学習曲線が急なことだ。

Databricks ML + Mosaic AI — レイクハウス上のML

DatabricksはUnity Catalog + MLflow + Delta Lakeを1パッケージにまとめ「レイクハウスML」を標榜する。2024年のMosaic AI買収後、Mosaic AI Pretraining、Mosaic AI Vector Search、Mosaic AI Model Servingが追加された。

データを既にDatabricksに置いているチームには、ロックインコストに対する費用対効果が最も良い部類に入る。

Hugging Face Hub + Inference Endpoints + AutoTrain

Hugging Faceは単なるモデルハブを超え、フルスタックMLOpsツールに進化した。2026年5月時点の中核ラインは次の通り。

Inference Endpointは次のようにデプロイする。

from huggingface_hub import create_inference_endpoint

endpoint = create_inference_endpoint(
    name="llama-3-8b-prod",
    repository="meta-llama/Meta-Llama-3-8B-Instruct",
    framework="pytorch",
    accelerator="gpu",
    instance_size="x1",
    instance_type="nvidia-a10g",
    region="us-east-1",
    vendor="aws",
    type="protected",
)
endpoint.wait()
print(endpoint.url)

OSSモデルとマネージドサービングを同じUIで一度に扱える点が強み。弱みはエンタープライズSLAがハイパースケーラーより短く、専用インスタンスのコストがRunPod / Modal比で約30%高いことだ。

Determined AI、Anyscale + Ray Train — GPU分散学習

GPUクラスタを自前で回す必要があるチームは分散学習専用ツールを使う。Determined AI(2021年HPE買収)は分散学習 + HPO + 実験トラッキングを統合したOSSだ。ノードにエージェントを入れるとGPUプールが自動でスケジューリングされる。

AnyscaleはRayメンテナが作るマネージドSaaSだ。Ray Train、Ray Tune、Ray Serve、Ray Dataを同じクラスタで動かす。Ray TrainでPyTorch DDPを立ち上げると次の1関数だ。

import ray
from ray.train.torch import TorchTrainer
from ray.train import ScalingConfig

def train_fn(config):
    import torch
    import torch.nn as nn
    from torch.utils.data import DataLoader, TensorDataset
    model = nn.Linear(10, 1)
    opt = torch.optim.SGD(model.parameters(), lr=config["lr"])
    ds = TensorDataset(torch.randn(1024, 10), torch.randn(1024, 1))
    dl = DataLoader(ds, batch_size=32)
    for epoch in range(config["epochs"]):
        for x, y in dl:
            loss = ((model(x) - y) ** 2).mean()
            opt.zero_grad(); loss.backward(); opt.step()

trainer = TorchTrainer(
    train_fn,
    train_loop_config={"lr": 1e-3, "epochs": 10},
    scaling_config=ScalingConfig(num_workers=4, use_gpu=True),
)
result = trainer.fit()

RayはLLM学習だけでなくエージェントオーケストレーション(複数LLM呼び出しの並列化)にも使われ、LLMOpsスタックの中核インフラとして定着した。

BentoML — Python優先のモデルサービング

BentoMLはPythonモデルをコンテナにパッケージングしてマネージドBentoCloudへ展開するOSSフレームワークだ。1.4ではLLMサービングモード(bentoml serve --reload --use-vllm)とマルチモデルルーティングが正式サポートされた。

サービス定義は1ファイルで済む。

import bentoml
from bentoml import api
from sklearn.ensemble import RandomForestClassifier
import joblib

@bentoml.service(resources={"cpu": "2", "memory": "1Gi"}, traffic={"timeout": 30})
class IrisRF:
    def __init__(self) -> None:
        self.model: RandomForestClassifier = joblib.load("model.pkl")

    @api
    def predict(self, x: list[list[float]]) -> list[int]:
        return self.model.predict(x).tolist()

BentoMLはK8sに直接デプロイするか、マネージドBentoCloudへ展開する。KServe / Seldon Core 2 / Triton と比較すると、Python親和性が最も高い。

Modal、RunPod、Replicate、Fireworks AI、Together AI — サーバーレスGPU

GPUだけ借りてインフラは消えてほしいチームはサーバーレスGPUプラットフォームを使う。

ModalでGPU関数を起動するコードは次の通り。

import modal

app = modal.App("llama-inference")
image = (
    modal.Image.debian_slim()
    .pip_install("torch==2.4.0", "transformers==4.44.0", "vllm==0.6.0")
)

@app.function(image=image, gpu="A100-40GB", timeout=300)
def generate(prompt: str) -> str:
    from vllm import LLM, SamplingParams
    llm = LLM(model="meta-llama/Meta-Llama-3-8B-Instruct")
    out = llm.generate([prompt], SamplingParams(max_tokens=200, temperature=0.7))
    return out[0].outputs[0].text

@app.local_entrypoint()
def main():
    print(generate.remote("MLOps in 2026 means"))

LLMサービングバックエンド — vLLM、SGLang、TGI、TensorRT-LLM

LLMサービングは独立したカテゴリだ。2026年5月時点で4つのエンジンが市場を分け合う。

BentoML 1.4とKServe 0.13は上記4つをすべてバックエンドとして差し込める。vLLMのOpenAI互換サーバーは1コマンドで起動する。

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3-8B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192 \
  --enable-prefix-caching \
  --enable-lora \
  --max-lora-rank 32 \
  --port 8000

モデル監視 — Arize、WhyLabs、Fiddler、TruEra、Galileo、Evidently

学習-サービングスキュー、データドリフト、概念ドリフト、予測ドリフト、そしてLLMのハルシネーションまでを一緒に見る。

同じレイヤーでも強みが異なる。クラシックMLはArize / WhyLabs / Fiddler、LLM専用はGalileo / Arize Phoenix / TruLens、OSSセルフホストはEvidently / WhyLogs / Phoenixを選ぶ。

LLM評価革命 — DeepEval、RAGAS、Promptfoo、langwatch

LLM評価は独立したスタックとして分岐した。

LLMモデルカードとデータセットカード(datasheet)については、Hugging Face Hubが事実上のフォーマットになった。

データバージョニング — DVC、lakeFS、Pachyderm

データバージョニングは学習再現性 + GDPR削除要求の追跡 + データセットlineageを同時に扱う。

ハイパーパラメータ最適化 — Optuna、Ray Tune、W&B Sweeps、Katib

OptunaはOSS HPOの事実上の標準だ。TPE、CMA-ES、NSGA-IIといったアルゴリズムを引数1つで切り替える。Ray TuneはRayクラスタ上で分散HPOを回す。W&B SweepsはW&B内でgrid / random / bayesを起動する。KatibはK8s上で同じことを行う。

study:
  storage: postgresql+psycopg2://user:pw@db/optuna
  direction: maximize
  sampler:
    type: tpe
    n_startup_trials: 20
  pruner:
    type: hyperband
parameters:
  - name: learning_rate
    type: float
    low: 1e-5
    high: 1e-2
    log: true
  - name: hidden_size
    type: categorical
    choices: [128, 256, 512]

ML向けCI/CD — Continuous Training (CT)

伝統的なCI/CDに一段階追加される。CT (Continuous Training)は新しいデータが入ったら自動的に再学習 → 評価 → 昇格するパイプラインだ。

主要パターンは次の通り。

KServeとBentoCloudの両方で、canary / shadowをInferenceServiceの一級概念として支援する。

エッジ/組込推論 — TF Lite、Core ML、ONNX Runtime、OpenVINO、TVM

エッジに近づくほど量子化 (INT8 / INT4 / GPTQ / AWQ)、剪定、蒸留が必須になる。

GPUコスト比較 — 2026年5月時点の時間単価

最もよく聞かれる質問はGPU単価だ。同じH100 80GBがプラットフォームごとに2〜3倍違う。

プラットフォームA100 80GBH100 80GB約定 / 備考
AWS p5.48xlarge (8x H100)n/a$5.13/hr 程度 ($98/hr / 8)1年予約でさらに50%節約
GCP A3 (8x H100)n/a$5.5/hr 前後CUD約定で大幅割引
Azure NDv5 (H100)n/a$5.4/hr 前後1年reservedで30〜50%割引
CoreWeave$1.65/hr$4.25/hr あたりspot割引は別途
Lambda Labs$1.29/hr$2.49/hr あたりon-demand、4090 / A6000も安価
RunPod (Community)$1.19/hr$1.99/hr あたり可用性の変動が大きい
Modaln/a$4.0/hr あたり秒単位課金、コールドスタート1秒程度
Replicaten/aモデルごとのコールあたり課金API per-call費用

実際の価格はリージョン、約定、spotの有無で大きく変動するので、常に公式の価格ページを確認するのが必須だ。それでも傾向は明確だ。OSS GPUブローカー(CoreWeave / Lambda / RunPod)がハイパースケーラーより40〜60%安い。

韓国 — Naver HyperCLOVA、Coupang ML、Kakao Brain

韓国大手3社の社内MLOpsを公開資料ベースで見るとこうなる。

大学や研究機関もNIPA / NCDSのK-Cloud / KSC-Vのような公的GPU資源を使い始めている。

日本 — Preferred Networks PFCC、Mercari、CyberAgent、ABEJA

日本側は次の4社が社内MLOpsの標準を作った。

共通点はVertex AIへの依存度が非常に高いことだ。MercariとCyberAgentは公開ブログでGCP親和スタックの詳細を共有している。

スタック推奨 — 4つのシナリオ

正解はない。ただしレイヤーを意識的に分けておくと、レイヤー内のツールを差し替えるときの移行コストが小さい点だけは確かだ。

締めくくり — MLOpsは結局「再現性と回収可能性」

2026年5月のMLOps風景を一行で要約すると「再現性 (reproducibility) と回収可能性 (recoverability) が一級市民になった」だ。どのデータでどのコードで学習したモデルか、そのモデルがどのトラフィックに露出しているか、問題が起きたとき何分以内に戻せるか、が本当の評価軸だ。

ツールは差し替えられる。しかしレイヤー境界と責任分離は、一度引き間違えると6〜12か月を失う。本記事がその境界を引き直す助けになれば幸いだ。

References

コメント

まだコメントはありません。

ログインするとコメントできます