Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 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コードは次のようになる。

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で書くとこうなる。

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ラインの主要コンポーネントは次の通り。

- **Kubeflow Pipelines (KFP)**: DAGパイプラインSDK + UI

- **Katib**: 分散ハイパーパラメータチューニング

- **KServe**: モデルサービング (InferenceService CRD)

- **Training Operator**: PyTorch / TensorFlow / MPI分散学習オペレータ

- **Spark Operator, Notebook Controller, Central Dashboard**

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:

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:

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月時点で次のように分かれる。

- **SageMaker Studio**: 統合IDE

- **SageMaker Training / Processing Jobs**: バッチ学習

- **SageMaker Pipelines**: パイプラインオーケストレーション

- **SageMaker Endpoints (real-time, async, serverless)**: サービング

- **SageMaker Feature Store**: 特徴量ストア

- **SageMaker Model Monitor, Clarify**: ドリフト + バイアス

- **SageMaker JumpStart**: 事前学習モデルカタログ

- **SageMaker HyperPod**: 基盤モデル学習専用クラスタ

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

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が追加された。

- **Model Serving**: GPU + CPU統合エンドポイント、Provisioned Throughput

- **AI Gateway**: LLM呼び出しルーティング + コスト上限

- **Mosaic AI Agent Framework**: エージェント構築 + 評価

- **Genie Spaces**: NLQ → SQL自動化

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

Hugging Face Hub + Inference Endpoints + AutoTrain

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

- **Hub**: 130万件以上のモデル、データセット、Space

- **Inference Endpoints**: マネージドGPU/CPUサービング (AWS / Azure / GCPリージョン選択)

- **Inference Providers**: Together / Fireworks / Replicateなど外部プロバイダ統合ルーティング

- **AutoTrain**: コードなしのファインチューニングUI

- **Spaces**: Gradio / Streamlitアプリホスティング

- **TGI (Text Generation Inference)**: LLMサービングバックエンド

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関数だ。

from ray.train.torch import TorchTrainer

from ray.train import ScalingConfig

def train_fn(config):

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ファイルで済む。

from bentoml import api

from sklearn.ensemble import RandomForestClassifier

@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**: Pythonデコレータ優先のサーバーレス。コールドスタート1秒程度。

- **RunPod**: GPUポッド + サーバーレスエンドポイント、A100/H100/H200の単価がハイパースケーラー比で50%程度

- **Replicate**: API1行でOSSモデルを呼べる、cog形式でパッケージング

- **Fireworks AI**: OSS LLM最適化サービング、Llama/Mixtral/Qwenで1秒未満のTTFT

- **Together AI**: OSS LLMホスティング + カスタムモデルサービング + ファインチューニング

- **Lamini、Predibase**: エンタープライズ向けファインチューニング + サービング (LoRA serving)

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

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つのエンジンが市場を分け合う。

- **vLLM**: PagedAttentionの発明者。最も速い出発点。0.6.xでマルチLoRA同時サービングが安定化。

- **SGLang**: vLLMの次世代。RadixAttentionでprefix cacheを最適化。

- **TGI (Hugging Face)**: HFモデル親和。Inference Endpointsのバックエンド。

- **TensorRT-LLM**: NVIDIA製。H100 / H200で最低遅延。

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のハルシネーションまでを一緒に見る。

- **Arize AI**: ML + LLM監視を統合。Phoenix(OSS) + マネージドSaaS。

- **WhyLabs**: WhyLogs(OSS)ベース。セルフホスト親和。

- **Fiddler**: ML監視 + 説明可能性 + RAG eval。

- **TruEra**: TruLens(LLM eval OSS)のメンテナ。2024年Snowflake買収。

- **Galileo**: LLM専用の評価 + ガードレール。

- **Evidently AI**: OSS親和、レポート形式で出力。

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

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

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

- **DeepEval**: pytest親和のLLM評価OSS。faithfulness、answer relevancy、bias、toxicity。

- **RAGAS**: RAGパイプライン評価のデファクト。context recall、faithfulness、context relevancy。

- **Promptfoo**: prompt A/Bテスト、CLI親和。

- **langwatch**: prompt observability + 評価 + コスト追跡。

- **Argilla**: human-in-the-loopラベリング + 評価。2024年HF買収。

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

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

- **DVC**: Iterative.ai作のGit親和データバージョニング。S3/GCS/Azureバックエンド。

- **lakeFS**: Git風APIでオブジェクトストレージのbranch / merge。

- **Pachyderm**: パイプライン + データlineage。2023年HPE買収。

- **DagsHub**: DVC + MLflow + Git LFS統合SaaS。

データバージョニングは学習再現性 + 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)**は新しいデータが入ったら自動的に再学習 → 評価 → 昇格するパイプラインだ。

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

- **シャドウデプロイ**: 新モデルを実トラフィックに公開せずログだけ収集

- **カナリアデプロイ**: 5%、25%、50%、100%とトラフィック比を段階的に増やす

- **MLのblue-green**: 2つのモデルバージョンを同時に温め、ルーターで切り替え

- **A/Bテスト**: ユーザーセグメント別にモデルを分岐

- **自動ロールバック**: 監視SLO違反時に自動的に戻す

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

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

- **TensorFlow Lite**: Android / マイコン

- **Core ML**: Apple Silicon、iOS / macOS / visionOS

- **ONNX Runtime**: クロスプラットフォームランタイム (CPU、CUDA、DirectML、CoreML、OpenVINO EP)

- **OpenVINO**: Intel親和。CPU / iGPU / NPU加速。

- **Apache TVM**: コンパイラ優先。MLC LLMと組み合わせてモバイルLLM推論。

- **MediaPipe**: モバイルマルチメディアMLパイプライン。

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

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

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

| プラットフォーム | A100 80GB | H100 80GB | 約定 / 備考 |

| --- | --- | --- | --- |

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

韓国 — Naver HyperCLOVA、Coupang ML、Kakao Brain

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

- **Naver Cloud / HyperCLOVA X**: 大規模学習は自社GPUクラスタ + Megatron-LM / Slurmベース。サービングは社内モデルサービングプラットフォーム + Triton + vLLMの組み合わせ。

- **Coupang MLプラットフォーム**: 社内 Bumblebee プラットフォームとして知られ、KFP / MLflowベースのパイプライン + 自社特徴量ストアを運用。

- **Kakao Brain**: 自社SoftCoクラスタでKarloなどを学習、社内Brain Cloudでサービング。PyTorch + DeepSpeed + Slurmライン。

- **LG AI Research (EXAONEシリーズ)**: 自社クラスタ + NVIDIA DGX + 自社学習フレームワーク。

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

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

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

- **Preferred Networks**: 自社スパコンMN-3 / MN-Core、ChainerMNの後継としてPyTorch + 自社分散ライブラリPFCC。

- **Mercari**: 社内MLプラットフォーム「Mercari ML Platform」。KFP + Vertex AI + 自社特徴量ストア。

- **CyberAgent AI Lab**: CIU (CyberAgentのMLプラットフォーム) + 自社LLM (CyberAgentLM) の学習インフラ。

- **ABEJA Platform**: エンタープライズMLOps SaaS。annotation + 学習 + サービング統合。

- **DeNA、Yahoo Japan、Rakuten**: それぞれKFP + 自社特徴量ストア + 自社モデルレジストリ。

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

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

- **小規模スタートアップ (3〜10名)**: Modal + W&B + Hugging Face Hub + Evidently。K8sなしでGPUだけ借りる。

- **中規模MLチーム (10〜50名)**: SageMakerかVertex AI + MLflow + DVC + Arize。マネージドのフルスタック。

- **GPUクラスタを持つチーム (50名以上)**: Kubeflow 1.10 + MLflow + Ray + KServe + Argilla + Galileo。セルフホストのフルスタック。

- **LLM優先チーム**: vLLM + BentoML + Argilla + DeepEval + RAGAS + langwatch + Modal。評価とコスト追跡が核心。

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

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

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

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

References

- [MLflow](https://mlflow.org/) — Apache 2.0のMLライフサイクルプラットフォーム

- [Kubeflow](https://www.kubeflow.org/) — K8s上のフルスタックMLプラットフォーム

- [Weights & Biases](https://wandb.ai/) — 実験トラッキング + LLM ops

- [Neptune.ai](https://neptune.ai/) — 基盤モデルのメタデータストア

- [Comet ML](https://www.comet.com/) — 実験トラッキング + 監視の統合SaaS

- [Google Vertex AI](https://cloud.google.com/vertex-ai) — GCPのMLプラットフォーム

- [AWS SageMaker](https://aws.amazon.com/sagemaker/) — AWSのMLプラットフォーム

- [Azure Machine Learning](https://learn.microsoft.com/azure/machine-learning/) — MicrosoftのMLプラットフォーム

- [Databricks Machine Learning](https://www.databricks.com/product/machine-learning) — レイクハウス上のML + Mosaic AI

- [Hugging Face](https://huggingface.co/docs) — Hub + Inference Endpoints + AutoTrain

- [BentoML](https://www.bentoml.com/) — Pythonモデルサービング

- [Modal](https://modal.com/) — サーバーレスGPU

- [Anyscale](https://www.anyscale.com/) — マネージドRay

- [Ray](https://www.ray.io/) — 分散コンピューティング + ML

- [ZenML](https://github.com/zenml-io/zenml) — MLOps抽象化レイヤー

- [Flyte](https://flyte.org/) — K8sネイティブワークフロー

- [DVC](https://dvc.org/) — Git親和データバージョニング

- [lakeFS](https://lakefs.io/) — オブジェクトストレージのbranch / merge

- [Arize AI](https://arize.com/) — ML + LLM監視

- [WhyLabs](https://whylabs.ai/) — OSS WhyLogsベースの監視

- [Galileo](https://www.galileo.ai/) — LLM評価 + ガードレール

- [RAGAS](https://docs.ragas.io/) — RAG評価の標準

- [vLLM](https://docs.vllm.ai/) — LLMサービングエンジン