MLOps 完全ガイド — Model Serving・Feature Store・Drift・A/B Test・GPU Economics (Season 2 Ep 7, 2025)

はじめに — MLOps が「DevOps + ML」ではない理由

DevOps はコードをデプロイする。MLOps は コード + データ + モデル の 3 つを同時にデプロイ・監視・バージョン管理する。

MLOps が特に難しい 4 つの理由:

1. 再現性: 同じコード + 同じデータで異なるモデル (乱数・ハードウェア差)
2. Drift: データ分布が変われば、モデルはリアルタイムで腐る
3. レイテンシ: 学習はバッチ / 推論はリアルタイム → アーキテクチャ分離
4. コスト: GPU 1 台で月 $2,000〜$30,000。設計を誤るとスタートアップの予算が蒸発

2024〜2025 年、LLM 時代に入り MLOps は LLMOps へ拡張。本稿は両領域をカバーする。

第 1 部 — MLOps 成熟度 5 段階 (Google 2021 フレームワーク)

現実の多くの企業は Lv.1〜2。Lv.3+ は Netflix・Uber・Airbnb レベル。

第 2 部 — Model Serving: 推論システム

2.1 一般 ML Serving

2.2 LLM Serving (2024〜2025 標準)

2025 年 OSS LLM 本番のデフォルト: vLLM。

2.3 vLLM の革新: PagedAttention

伝統的 Attention KV Cache: 連続メモリ割当 → 断片化、GPU メモリの 60〜80% を浪費。

PagedAttention: OS の仮想メモリのように ブロック単位 管理 → 無駄 4% 未満、同時リクエストのスループット 2〜4 倍。

2.4 Serving パターン 4 種

1. Online (リアルタイム): ms 単位応答。API サーバ。
2. Batch: 大量推論 (夜間ジョブ)。効率重視。
3. Streaming: イベント駆動 (Kafka → モデル)。
4. Edge: デバイス側で直接 (モバイル・IoT)。

2.5 Serving 性能指標

• Latency (P50, P95, P99): 応答時間
• Throughput (QPS): 秒間リクエスト数
• TTFT (Time to First Token, LLM): 初トークン到達時間
• TPS (Tokens Per Second, LLM): 生成速度
• GPU Utilization: 目標 60〜80% (低すぎは浪費、高すぎはレイテンシ爆発)

第 3 部 — Feature Store: ML の特徴計算層

3.1 なぜ Feature Store か

学習時点と推論時点で Feature 計算がズレて失敗するのを防ぐため。

例: 「直近 7 日の購入金額」 — 学習データと実時間リクエストで時間境界や集計ロジックが 0.001% でもズレると、モデル性能は激減する。

3.2 Feature Store 3 つの役割

1. Offline Store (学習用): Parquet、BigQuery、Snowflake — 学習用の大量参照
2. Online Store (Serving 用): Redis、DynamoDB — 低レイテンシ参照
3. Feature Definition: 「この Feature は何でどう計算するか」の中央管理

3.3 2025 Feature Store 選択肢

3.4 Feast 例

from feast import Entity, FeatureView, Field
from feast.types import Float32, Int64

user = Entity(name="user_id", value_type=Int64)

user_activity = FeatureView(
    name="user_activity_7d",
    entities=[user],
    features=[
        Field(name="purchase_amount_7d", dtype=Float32),
        Field(name="click_count_7d", dtype=Int64),
    ],
    source=bigquery_source,
    online=True,
    ttl=timedelta(days=7),
)

# 学習時
features = store.get_historical_features(entity_df, feature_refs).to_df()

# Serving 時
features = store.get_online_features(
    features=feature_refs, entity_rows=[{"user_id": 1}]
).to_dict()

第 4 部 — Training Infra: 大規模学習

4.1 Single GPU → 分散学習の段階

1. Single GPU (〜7B パラメータ)
2. Data Parallel (DP): 複数 GPU が同モデル複製 + 異なるデータ
3. Distributed Data Parallel (DDP): DP 改良、All-Reduce で勾配同期
4. Model Parallel: モデルが巨大で分割
5. Tensor Parallel: 1 層の中でも分割 (Megatron-LM)
6. Pipeline Parallel: レイヤ単位で GPU 分配
7. 3D Parallel: DP + TP + PP の組み合わせ (GPT-4 級)

4.2 2025 分散学習ツール

4.3 ZeRO (Zero Redundancy Optimizer)

Optimizer State を GPU 間で分割 → メモリ使用量を大幅削減:

• ZeRO-1: Optimizer State 分割
• ZeRO-2: + Gradient 分割
• ZeRO-3: + Model Parameter 分割 (FSDP と類似)

4.4 Fine-tuning 軽量化技法

第 5 部 — Experiment Tracking: 実験記録

5.1 なぜ必要か

「3 ヶ月前のあのモデル、なぜ良かった?」 → 答えられない = 再現不能 = 無意味。

5.2 2025 ツール比較

5.3 MLflow 基本

import mlflow
import mlflow.pytorch

mlflow.set_experiment("image_classifier")

with mlflow.start_run():
    mlflow.log_params({"lr": 0.001, "batch_size": 64})

    for epoch in range(epochs):
        train_loss = train(model, loader)
        val_acc = validate(model, val_loader)
        mlflow.log_metrics({"train_loss": train_loss, "val_acc": val_acc}, step=epoch)

    mlflow.pytorch.log_model(model, "model")
    mlflow.log_artifact("confusion_matrix.png")

5.4 追跡すべき 10 項目

1. Hyperparameter: LR、batch size、optimizer
2. Data Version: DVC または Delta Lake ハッシュ
3. Code Version: git commit hash
4. Metric: train/val loss、acc、AUC など
5. Model Artifact: weights、architecture
6. Environment: Python バージョン、GPU 種類、requirements
7. Training Time: 総時間、エポックあたり時間
8. Resource: GPU メモリ、CPU 使用
9. Random Seed: 再現性
10. Dataset Stats: クラス分布、サンプル数

第 6 部 — Drift 検知: モデルが腐る仕組み

6.1 Drift の 3 種類

1. Data Drift (Covariate Shift): 入力分布の変化
   • 例: コロナ前後のショッピングパターン
2. Concept Drift: 入力→出力関係の変化
   • 例: スパムの定義自体が変わる
3. Label Drift: ラベル分布の変化
   • 例: 不正率が 1% から 5% に急増

6.2 検知方法

統計的:

• KS Test (単一特徴)
• PSI (Population Stability Index)
• Wasserstein Distance
• Chi-Square (カテゴリ)

ML ベース:

• Domain Classifier (学習/本番データ分類器)
• Autoencoder Reconstruction Error

性能ベース:

• 遅延ラベル到着後の実性能追跡
• Proxy Metric (CTR、CVR)

6.3 2025 Drift ツール

• Evidently AI: OSS、ダッシュボード
• Arize AI: 商用、LLM・ML 統合
• WhyLabs: データ品質 + Drift
• Fiddler: エンタープライズ

6.4 LLM 特有の問題

• Prompt Drift: プロンプト分布変化 (ユーザ動向)
• Response Drift: 応答品質低下 (モデル更新の影響)
• Cost Drift: 平均トークン数の増加 → コスト爆発

第 7 部 — Model A/B Test とデプロイ戦略

7.1 デプロイ戦略 5 種

7.2 A/B Test 設計

1. Hypothesis: 「新モデルは CTR を 5% 以上向上」
2. Sample Size 計算: Statistical Power 80%、有意水準 5%
3. Randomization: User ID ハッシュ
4. Duration: 週次パターン含む (最低 1 週間)
5. Guardrail Metric: 主指標 + 安全網指標 (latency、error rate)
6. 分析: 有意な効果か + サブグループ影響

7.3 Shadow Deployment

User Request
  |
[Router]
  |-- Prod Model --> User Response (返却)
  +-- Shadow Model --> Log (ユーザには非表示)

長所: リスク 0、実トラフィックで検証。 短所: 2 倍コスト、ロジック変更時の副作用検知が難しい。

7.4 2024〜2025 実験プラットフォーム

• Eppo: 統計厳格
• GrowthBook: OSS
• Statsig: Facebook 出身起業
• 自前構築: 大企業志向

第 8 部 — GPU Economics 2025

8.1 GPU オプション比較

8.2 2024〜2025 トレンド

• H100 → B200 (Blackwell): 2.5 倍性能、価格同等
• AMD MI300X: H100 代替、メモリ 192GB
• Groq LPU: 推論特化、トークン/秒最高
• AWS Trainium/Inferentia: 自社チップ、コスパ高
• Google TPU v5: 学習・推論特化

8.3 コスト最適化 10 戦術

1. Spot + Checkpoint: 学習は再開可能。70% 割引
2. Mixed Precision (FP16/BF16): 速度・メモリ 2 倍
3. Gradient Accumulation: 小 GPU で大 batch 効果
4. Gradient Checkpointing: メモリ半減、速度 20% 損失
5. Quantization (INT8/INT4): 推論メモリ 2〜4 倍削減
6. LoRA/QLoRA: fine-tuning コスト 99% 削減
7. Model Distillation: 小モデルで性能複製
8. Batching + Dynamic Batching: Serving スループット向上
9. Request Caching: 同プロンプト結果の再利用
10. Right-sizing: 過剰 GPU を避ける (A10 で済むのに A100 を使わない)

8.4 Cloud vs 自前購入の損益分岐点

簡易ルール: 24/7 使用の GPU が 3 台以上 + 1 年以上 予想 → 自前購入を検討。

現実: インフラチーム人件費、電力・冷却、更新サイクル (3〜4 年) まで計算が必要。

第 9 部 — データパイプライン

9.1 Batch vs Streaming

9.2 2025 オーケストレーション

• Airflow 2.x: 標準、成熟
• Prefect: Pythonic、UX 良好
• Dagster: 型安全、データ認識
• Temporal: ワークフロー特化、再起動可能

9.3 ML データ品質チェック

• 欠損値: 比率閾値
• 異常値: Z-score または Isolation Forest
• スキーマドリフト: カラム追加/削除/型変更
• 範囲チェック: age > 0、price > 0
• 分布: ベースラインとの比較
• 一意性: ID 重複なし
• 関係: FK 整合性

9.4 Great Expectations・Soda

import great_expectations as ge

df = ge.from_pandas(df)
df.expect_column_values_to_not_be_null("user_id")
df.expect_column_values_to_be_between("age", 0, 150)
df.expect_column_value_lengths_to_be_between("email", 5, 100)

第 10 部 — 可観測性とデバッグ

10.1 3 軸 + ML 固有

一般アプリ:

• Metric (Prometheus)
• Log (Loki、Elasticsearch)
• Trace (OpenTelemetry)

ML 追加:

• Prediction Log: 入力 + 出力 + モデルバージョン
• Feature Log: Feature Store 参照記録
• Drift Metric: 分布統計
• Explanation: SHAP、LIME

10.2 LLM 可観測性ツール

• LangSmith: LangChain チーム
• Langfuse: OSS
• Helicone: プロキシ型
• Phoenix (Arize): OSS で強力

第 11 部 — MLOps マスターロードマップ 6 ヶ月

Month 1: 基礎 + Serving

• FastAPI + PyTorch モデル Serving
• Docker + K8s 基本

Month 2: Training Infra

• PyTorch DDP
• Ray Train または DeepSpeed 体験
• MLflow で実験追跡

Month 3: Feature Store + Data

• Feast 導入・運用
• Airflow または Dagster パイプライン
• Great Expectations データ品質

Month 4: LLM 特化

• vLLM 運用
• プロンプト管理 (Langfuse)
• LLM-as-a-Judge eval

Month 5: Drift + A/B

• Evidently AI で Drift 検知
• GrowthBook で A/B Test
• Shadow Deployment 実戦

Month 6: 最適化・スケール

• GPU コスト監視
• LoRA fine-tuning
• Model Distillation 実験

第 12 部 — MLOps チェックリスト 12

1. MLOps 成熟度 5 段階で自チームの位置を知る
2. vLLM が既存 Serving より速い理由を知る (PagedAttention)
3. Feature Store 3 つの役割を言える
4. DDP vs FSDP vs ZeRO の差を知る
5. LoRA vs QLoRA のメモリ節約原理を知る
6. MLflow の 5 つのログ対象を知る
7. 3 種の Drift (Data/Concept/Label) の違いを説明できる
8. Shadow Deployment の長短を知る
9. Canary vs A/B Test の選択基準を知る
10. GPU Spot インスタンスで学習する際の注意点を知る
11. Batch vs Dynamic Batching の違いを知る
12. LLM 可観測性 3 要素 (prompt・completion・metadata) を知る

第 13 部 — MLOps アンチパターン 10

1. Notebook のみでデプロイ: 再現性 0。パイプライン化
2. Feature 計算を学習・Serving で分離: 必ず Feature Store または共有ライブラリ
3. Eval セットなしでデプロイ: 性能低下検知不能
4. Drift 監視なし: 6 ヶ月後に静かに破綻
5. 単一 A/B 指標: Guardrail 必須
6. GPU を「適当に」選ぶ: A10・A100・H100 に明確な基準
7. Spot インスタンスに Checkpoint なし: 終了で学習消滅
8. Shadow Deploy なしの Big Bang: リスク過小評価
9. 可観測性を後回し: 最初から組み込む
10. MLOps を ML チームだけの仕事に: DevOps・Data チーム協業必須

おわりに — MLOps は「見えない 70%」

論文の美は、モデル構造にある。本番の美は 30 個の見えないシステムが噛み合って動くこと にある。

2025 年 AI/ML エンジニアの区分点:

• 「モデルを動かせる」 = 入口レベル
• 「パイプライン・Serving アーキテクチャを描ける」 = シニア
• 「Drift・Cost・Eval まで設計できる」 = スタッフ+

論文は公開されるが、運用ノウハウは公開されない。だからこの領域が年収差を生む。

次回予告 — 「データエンジニアリング完全ガイド: Lakehouse・Streaming・dbt・Orchestration・Data Mesh」

Season 2 Ep 8 は、ML の下にある基盤、データエンジニアリング。次回は:

• Lakehouse アーキテクチャ (Iceberg・Delta・Hudi)
• Batch vs Streaming (Flink、Kafka Streams、Spark Structured Streaming)
• dbt + Elementary でデータモデリング
• Airflow vs Prefect vs Dagster vs Temporal
• Data Mesh の本当の意味
• Data Contract と Schema Registry

「データが働く方式」が変わった 2025 年。次回に続く。