Hugging Face と商用 API: モデルエコシステムのマッピング

このトピックを修了すると

パート 12 で PyTorch を使用してニューラルネットワークを最初から構築したので、このセクションでは、現在利用可能な数十万もの事前学習済みモデルを活用する方法を学びます。Hugging Face の Model Hub と Transformers ライブラリから、OpenAI、Anthropic、Google などの商用 API、さらには Ollama や vLLM を使用したローカルでの運用まで。このセクションでは、今日の AI 開発者が取り組む必要のあるツールのランドスケープをマッピングします。

これは、Tools Phase 3 の 2 番目のパートです。パート 14 のエージェント (Claude Code、Cursor) のコーディングと、パート 15 のバイオ統合のための実践的な基礎として役立ちます。

モデルを使用する 3 つのパス

現在、LLM と Transformers を使用する主な 3 つの方法を以下に示します。

パス A: 商用 API。OpenAI (GPT)、Anthropic (Claude)、Google (Gemini) などの企業の API を呼び出します。

メリット: 優れたモデルへの即時アクセス、インフラストラクチャを心配する必要がない、自動アップデート。
デメリット: コスト、データプライバシーに関する懸念、API への依存。
実際には: ほとんどの SaaS およびアプリがこのパスを使用します。

パス B: オープンソースモデル + ローカルでの運用。LLaMA、Mistral、Qwen などのオープンモデルを独自のサーバーで使用します。

メリット: データプライバシー、コスト管理 (大規模な使用)、カスタマイズ。
デメリット: インフラストラクチャが必要、パフォーマンスはトップクラスの商用オファリングに匹敵しない場合がある、管理がより複雑。
実際には: 社内企業システム、規制対象の業界、研究室。

パス C: Hugging Face Transformers。PyTorch API を使用して、オープンモデルを直接ロード、トレーニング、および推論します。

メリット: 最大限の柔軟性、ファインチューニングと分析が可能。
デメリット: 運用用に最適化する必要がある、GPU が必要。
実際には: 研究、プロトタイピング、特殊なモデルの開発。

3 つのパスの関係: これらのパスは相互に排他的ではありません。実際には、これらすべてを組み合わせることができます。たとえば、OpenAI API でプロトタイプを作成し、Hugging Face で特殊なモデルをファインチューニングし、vLLM を使用してローカルで運用して本番環境にデプロイします。

Hugging Face エコシステム

Hugging Face は、AI オープンソースコミュニティの中心にあります。2016 年にフランスのスタートアップとして始まり、現在ではオープン AI インフラストラクチャの標準となっています。

Model Hub

huggingface.co/models には、数十万の事前学習済みモデルが含まれています。LLM、Vision、Audio、Biology など、幅広いドメインをカバーしています。

注目すべきバイオ関連モデル:

facebook/esm2_t33_650M_UR50D: ESM-2 プロテイン言語モデル (パート 4 と 6 で言及)。
microsoft/biogpt-large: 生物医学 LLM。
allenai/scibert_scivocab_uncased: 科学論文 BERT。
dmis-lab/biobert-v1.1: PubMed で事前トレーニング済み。
InstaDeepAI/nucleotide-transformer-500m-human-ref: ゲノム Transformers。

主流の LLM:

meta-llama/Llama-3.1-70B-Instruct: Meta の大規模モデル。
Qwen/Qwen2.5-72B-Instruct: Alibaba、多言語で強力。
mistralai/Mistral-Large-Instruct-2411: Mistral ファミリー。

Transformers ライブラリ

これは、Model Hub からモデルをロードし、PyTorch/JAX/TF を使用して使用するための標準ライブラリです。

python

from transformers import AutoModel, AutoTokenizer

# モデルとトークナイザーをロードします (自動的にダウンロードされます)
model_name = "facebook/esm2_t33_650M_UR50D"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModel.from_pretrained(model_name)

# サンプルプロテインシーケンス
sequence = "MKTVRQERLKSIVRILERSKEPVSGAQLAEELSVSRQVIVQDIAYLRSLGYNIVATPRGYVLAGG"
inputs = tokenizer(sequence, return_tensors="pt")
outputs = model(**inputs)

# 各アミノ酸位置の埋め込み
embeddings = outputs.last_hidden_state  # 形状: (1, len+2, hidden_dim)

AutoClass: AutoModel、AutoTokenizer、AutoConfig など。モデル名のみを知っていれば、アーキテクチャを自動的に推測します。

Pipeline: 一般的なタスク (要約、分類、QA、生成) のためのショートカット。

python

from transformers import pipeline

qa = pipeline("question-answering", model="deepset/roberta-base-squad2")
result = qa(question="What is TP53?", context="TP53 is a tumor suppressor gene...")
print(result["answer"])

Datasets ライブラリ

トレーニングおよび評価データセットの標準ローダー。

python

from datasets import load_dataset

ds = load_dataset("nlphuji/mscoco_2014_5k_test_image_text_retrieval")

Accelerate

マルチ GPU、混合精度、および FSDP の複雑さを隠蔽するラッパー。

python

from accelerate import Accelerator

accelerator = Accelerator(mixed_precision="bf16")
model, optimizer, train_loader = accelerator.prepare(model, optimizer, train_loader)

for batch in train_loader:
    loss = model(**batch).loss
    accelerator.backward(loss)
    optimizer.step()

パート 12 の DDP および FSDP の設定を隠蔽します。

PEFT: パラメーター効率的なファインチューニング

大規模モデルのファインチューニングには、数百 GB の GPU メモリが必要です。PEFT (パラメーター効率的なファインチューニング) は、小さなアダプターのみをトレーニングします。

LoRA (Low-Rank Adaptation): 大きな重み行列に低ランク (ランク 4-16) のアダプターを追加します。元のパラメーターは凍結されます。

python

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16, lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    task_type="CAUSAL_LM"
)
model = get_peft_model(base_model, config)
# トレーニングパラメーターは、元のモデルの 1% 未満です。

効果: 24GB の GPU 1 台で 70B モデルのファインチューニングが可能になります。アダプターファイルのみを保存する必要があるため、デプロイが簡単です。

実践的なバイオの例: Llama-3 を LoRA を使用して生物医学コーパスでファインチューニングし、ドメイン固有のアシスタントを作成します。アダプターファイル (100〜500 MB) のみを管理する必要があります。

商用API：実用的な使い方

OpenAI

python

from openai import OpenAI

client = OpenAI()  # OPENAI_API_KEY 環境変数

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "あなたは分子生物学のアシスタントです。"},
        {"role": "user", "content": "TP53の機能を要約してください。"}
    ],
    temperature=0.3
)
print(response.choices[0].message.content)

Function Calling (パート9)。

python

tools = [{"type": "function", "function": {...}}]
response = client.chat.completions.create(
    model="gpt-4o", messages=messages, tools=tools
)

構造化された出力 (パート7)。

python

response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    response_format={"type": "json_schema", "json_schema": {...}}
)

主要なモデル：

GPT-4o: マルチモーダル。エージェントの標準。
GPT-4o mini: より安価で高速。大規模なタスク向け。
o1, o3: 推論に最適化されたモデル。複雑なロジックと数学的処理向け。

Anthropic Claude

python

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-3-5-sonnet-latest",
    max_tokens=1024,
    system="あなたは分子生物学のアシスタントです。",
    messages=[{"role": "user", "content": "TP53の機能を要約してください。"} ]
)
print(response.content[0].text)

ツール利用、プロンプトのキャッシュ、ビジョン、コンピューターの使用などをサポートします。パート7〜10で説明した機能のほとんどが含まれます。

主要なモデル：

Claude Opus 4.7, 4.8: 最高性能。複雑なタスク向け。
Claude Sonnet 5: バランスの取れた性能。ほとんどの実用的なアプリケーションに適しています。
Claude Haiku 4.5: 高速で安価。大規模な処理向け。

Google Gemini

python

import google.generativeai as genai

genai.configure(api_key="...")
model = genai.GenerativeModel("gemini-1.5-pro")
response = model.generate_content("TP53の機能を要約してください。")
print(response.text)

Geminiの機能: 100万以上のトークンを扱えるコンテキスト、強力なマルチモーダル機能（ビデオを含む）、手頃な価格。

3つのAPIの比較

	OpenAI GPT-4o	Claude Sonnet	Gemini 1.5 Pro
コンテキスト	128K	200K	1M+
推論能力	強い	非常に強い	強い
コーディング	強い	非常に強い	強い
マルチモーダル	画像、音声	画像	画像、ビデオ
価格	中程度	中程度～高い	低い
ツール利用	Function calling	ツール利用	Function calling
整合性	強い	非常に強い（CAI）	強い

実用的な選択: 正解はありません。チームの慣れ、特定のタスクのパフォーマンス、価格によって異なります。

ローカルモデルの提供

ローカルでの提供は、社内でのニーズ、プライバシー要件、および大量のユースケースで使用されます。

Ollama — 個人/小規模

オープンソースモデルをローカルのラップトップで簡単に実行できます。Mac、Linux、Windowsをサポートします。

bash

# インストール後
ollama pull llama3.1
ollama run llama3.1

APIも提供します。

python

import requests

response = requests.post("http://localhost:11434/api/generate", json={
    "model": "llama3.1",
    "prompt": "TP53の機能を要約してください。",
    "stream": False
})
print(response.json()["response"])

Ollamaの機能: GGUF量子化モデル（4ビット、5ビット、8ビット）をサポートします。Mac Apple Silicon向けに最適化されています。開発者や研究者によるローカルでの実験の標準です。

容量: Llama-3.1-8B Q4には5GB必要で、16GBのRAMを搭載したMacで実行できます。70B Q4には40GB必要です。M3 Maxと128GBのRAMを搭載したMacで実行できます。

vLLM — 本番環境での提供

本番環境規模のLLMの提供。連続バッチングとPagedAttentionを通じて、スループットを最大化します。

bash

pip install vllm
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4

OpenAI互換のAPIを提供します。既存のOpenAIクライアントを使用して呼び出すことができます。

python

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-70B-Instruct",
    messages=[...]
)

vLLMの機能: PagedAttention（メモリ効率の良いKVキャッシュ）、連続バッチング（GPUの利用率を最大化します）。スループットは、純粋なHugging Faceよりも10〜24倍高くなります。

TGI、SGLang、LMDeploy

vLLMの代替手段です。それぞれ異なる強みを持っています。

TGI（Hugging Face）： Hugging Faceのエコシステムと統合されており、簡単なDockerデプロイが可能です。
SGLang: 複雑な構造化されたプロンプト（RAG、エージェント）向けに最適化されています。
LMDeploy: 中国のコミュニティで強力です。QwenとInternLM向けに最適化されています。

Llama.cpp

C++をベースにした軽量な推論エンジンです。GGUFモデルを実行します。Ollamaの内部で使用されています。CPU、CUDA、およびMetal（Mac）をサポートします。個人の開発およびエッジデプロイメントに適しています。

埋め込みAPI — パート#8からの再利用

パート8で必要なRAGの埋め込みは、APIとローカルの両方の方法で取得できます。

API

python

# OpenAI
response = openai_client.embeddings.create(
    model="text-embedding-3-large",
    input="タンパク質配列の説明"
)
embedding = response.data[0].embedding  # 3072次元

# Cohere
co_response = cohere_client.embed(texts=["..."], model="embed-english-v3.0")

# Voyage AI（ベンチマークでトップのパフォーマンス）
voyage_response = voyage_client.embed(texts=["..."], model="voyage-3")

Hugging Face ローカル

python

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-large-en-v1.5")
embeddings = model.encode(["チャンク1", "チャンク2"])

生物学に特化したもの：

PubMedBERT sentence transformer: 生物医学のタスク向けにファインチューニングされています。
BioBERTベース: PubMedおよびMEDLINEでトレーニングされています。
ProtT5およびESM sentence embeddings: タンパク質配列に特化しています。

ファインチューニングのオプション

第8回では、ファインチューニングとRAG（Retrieval-Augmented Generation）を比較しました。ここでは、ファインチューニング自体のオプションについて説明します。

フルファインチューニング

すべてのパラメータを更新します。精度は高いですが、コストがかかります。

使用場面: 大量のドメインデータがある場合、または基本的なスタイルを大きく変更したい場合。
コスト: 70Bモデルの場合、GPU時間で数百万ウォンから数千万ウォンかかります。

LoRA/QLoRA

いくつかのアダプター層のみを学習させます。

使用場面: ほとんどの場合。少量データ、低コスト。
コスト: 70B LoRAの場合、1台のA100で数時間で完了します。

フル精度ファインチューニングAPI

OpenAIとAnthropicは、管理されたファインチューニングAPIを提供しています。

python

# OpenAIの例
job = openai_client.fine_tuning.jobs.create(
    training_file="file-abc",
    model="gpt-4o-mini-2024-07-18"
)

使用場面: 商用モデルをカスタマイズする場合。
コスト: データサイズとエポック数によって異なります。ほとんどの場合、数万ウォンです。

データ要件

LoRA: 500〜5000個のサンプルで、大きな改善が見込めます。
フルファインチューニング: 10,000個以上のサンプルが必要です。
継続的な事前学習: （大量のドメインテキスト）：数億から数十億トークンが必要です。

実践的なワークフロー

一般的なプロジェクトの流れ:

プロトタイプ: OpenAI/Anthropic API + プロンプトエンジニアリング。数日から1週間。
RAGの実装: ドメインデータのベクトルデータベース。第8回で説明。1〜2週間。
エージェント化: ツールとループ。第9回で説明。2〜4週間。
パフォーマンスの向上: ボトルネックを特定するためにプロファイリングを行います。
- 問題がプロンプトにある場合：より良いシステムプロンプトを使用します。
- 特定のスタイルが必要な場合：LoRAファインチューニングを使用します。
- プライバシーが懸念される場合：ローカルのオープンモデルに移行します。
- コストが懸念される場合：自己完結型システムを使用します。
本番環境へのデプロイ: モニタリング、エラー処理、レート制限、監査ログ。

生物学の研究室プロジェクトの例: 論文の要約アシスタントを開発します。

1〜2週目：OpenAI GPT-4o + PubMed RAGでプロトタイプを作成します。
3〜4週目：カンファレンスのプレゼンテーションからのフィードバックを収集します。
5〜8週目：BioBERT埋め込みを使用してドメインのパフォーマンスを向上させ、Claude Sonnetに移行します。
3〜4ヶ月：vLLM + Llama-3をローカルの研究室サーバーにデプロイします。データプライバシーを確保します。
6ヶ月以降：継続的なファインチューニングと引用検証レイヤーを強化します。

生物学における応用シナリオ

シナリオ1：タンパク質配列埋め込みパイプライン

第8回で説明したRAGを、タンパク質配列の検索に適用します。

python

from transformers import AutoTokenizer, AutoModel
import torch

model_name = "facebook/esm2_t33_650M_UR50D"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModel.from_pretrained(model_name).cuda().eval()

def get_protein_embedding(sequence):
    inputs = tokenizer(sequence, return_tensors="pt").to("cuda")
    with torch.no_grad():
        outputs = model(**inputs)
    # 平均プーリング（アミノ酸の位置の平均）
    return outputs.last_hidden_state.mean(dim=1).cpu().numpy()

# 複数のタンパク質を埋め込みます
proteins = ["MKTVRQ...", "MSPTQR...", ...]
embeddings = np.stack([get_protein_embedding(p) for p in proteins])

# ベクトルデータベースに保存し、類似のタンパク質を検索します

酵素活性やタンパク質間相互作用の予測に使用します。

シナリオ2：ドメイン固有のチャットボット（LoRA + vLLM）

LoRAを使用して、500個の研究室論文でLlama-3-8Bをファインチューニングし、vLLMで提供します。

1週目：500個の論文から、JSON形式のQAペアを作成します（GPT-4oで自動生成）。
2週目：Hugging Face + PEFTを使用してLoRAを学習させます。
3週目：vLLMでの提供とSlackボットとの統合。

内部の研究室の知識と最新の論文に最適化されたアシスタント。プライバシーとコストの点で優れています。

シナリオ3：マルチモーダル病理画像分析

ビジョン言語モデル（例：LLaVA）を使用して、病理スライド画像を分析し、テキストを生成します。

オープンソース：llava-hf/llava-v1.6-mistral-7b-hf
商用：GPT-4o Vision、Claude 3.5 Vision、Gemini 1.5 Pro

画像内の細胞の種類を識別し、自然言語による説明を生成します。第6回で説明したシナリオ3の実際的な応用です。

まとめ

モデルの使用方法には、商用API、オープンソースモデルのローカルでの提供、直接Hugging Faceの使用という3つの方法があります。これらは排他的ではなく、組み合わせることができます。
Hugging Face Hubは、オープンソースのモデルとデータセットの標準です。Transformers、Datasets、Accelerate、PEFTライブラリが利用可能です。
主要な商用APIは3つ：OpenAI（GPT）、Anthropic（Claude）、Google（Gemini）。コンテキスト、価格、専門分野が異なります。
ローカルでの提供: Ollama（個人）、vLLM（本番）、TGI、SGLang、llama.cpp。
LoRA/QLoRAを使用して、大規模モデルの低コストなファインチューニングを行います。100〜500MBのアダプター層のみを管理します。
実践的なワークフロー: プロトタイプ（API）-> RAG -> エージェント -> パフォーマンスの向上 -> 本番環境へのデプロイ。
生物学に特化したモデル: ESM、BioGPT、SciBERT、BioBERT、Nucleotide Transformerなど。Hugging Faceで直ちに使用できます。

📐 付録 — 専門家向けの実践的な最適化

難易度: 非常に難しい 対象読者: 実際に LLM をデプロイおよびファインチューニングした経験を持つ読者

A.1 LoRA の数式

元の重み行列 W ∈ ℝ^{d × d}。LoRA:

text

W_effective = W + ΔW = W + B · A

A ∈ ℝ^{r × d} (低ランクのダウン射影)
B ∈ ℝ^{d × r} (低ランクのアップ射影)
r ≪ d (例: r=16, d=4096)

学習可能なパラメータ: A と B のみ。2·r·d 個のパラメータ。元の d² 個と比較すると、2r/d ≈ 0.008 であり、大幅に少なくなります。

初期化: A ~ 正規分布, B = 0。トレーニングの開始時に、ΔW = 0 となります。

スケーリング:

text

W_effective = W + (α/r) · B · A

α は、ランクに関係なく、一貫した学習シグナルを保証するハイパーパラメータです。

A.2 QLoRA — 4ビットベース + LoRA

元のモデルは量子化され、4ビットで保存されます。LoRA アダプターは FP16 です。トレーニング中、元の重みの中で必要な部分のみが量子化解除されます。

NF4 (NormalFloat4): 正規分布で量子化を最適化した 4ビット浮動小数点数。
二重量子化: 量子化定数自体を再量子化し、さらなる削減を実現します。
ページングされたオプティマイザー: オプティマイザーの状態を CPU メモリにオフロードします。

効果: 24GB の GPU 1 台で 70B モデルをファインチューニングできます。この論文 (Dettmers et al., 2023) は、オープンモデルのファインチューニングの標準となっています。

A.3 vLLM のページングされたアテンション

エピソード #6 で説明した KV キャッシュの問題に対処します。

従来のアプローチ: 各リクエストは、リクエストされた最大コンテキストサイズに等しい連続したメモリを予約します。実際にその一部しか使用されなくても、予約されたサイズを減らすことはできず、メモリが無駄になります。

ページングされたアテンション: KV キャッシュをページ (例: 16トークン) に分割し、必要に応じて割り当てます。これは、オペレーティングシステムにおける仮想メモリシステムに似ています。

効果:

メモリ利用率が 60% から 96% 以上に向上
連続バッチングと組み合わせることで、スループットが 10〜24 倍に向上します。

A.4 連続バッチング

従来のアプローチ: バッチが完了するまで待ちます。バッチ内のすべてのリクエストは、同じステップに進みます。

連続: 各リクエストが完了するとすぐに、新しいリクエストに置き換えられます。GPU のアイドル時間を最小限に抑えます。

時間損失: プリフィルステップ (プロンプトの処理) は、リクエストの開始時に一度だけ発生します。連続するのはデコードステップのみです。

最近の進歩: チャンク化されたプリフィル (長いプロンプトを処理のためにチャンクに分割)、推測デコード (小さなドラフトモデルが候補の出力を生成し、その後、大規模モデルによって検証されます)。これにより、レイテンシーが 30〜50% 削減されます。

A.5 量子化

パラメータとアクティベーションを低いビット幅で保存します。

ポストトレーニング量子化 (PTQ): トレーニング後に量子化を実行します。高速です。

GPTQ: グループワイズの最小誤差量子化。4ビットの標準です。
AWQ (アクティベーションアウェア・ウェイト量子化): アクティベーションの分布を考慮します。GPTQ に代わるものです。

量子化対応トレーニング (QAT): トレーニング中に量子化をシミュレートします。より正確ですが、計算コストが高くなります。

FP8: H100 世代でサポートされています。最小限の精度損失で、速度とメモリが 2 倍に向上します。

A.6 サービスベンチマークのメトリック

スループット (リクエスト/秒): 1秒あたりに処理されるリクエストの数。

TTFT (Time To First Token): リクエストから最初のトークンまでのレイテンシー。ユーザーエクスペリエンスに影響します。

ITL (Inter-Token Latency): トークン間のレイテンシー。ストリーミング速度に影響します。

同時ユーザー: 同時に処理されるユーザーの数。

測定ツール: vllm/benchmarks, llmperf, guidance-serve。

A.7 実践的な RLHF ファインチューニング

TRL ライブラリ (HuggingFace): RLHF と DPO を実装します。

python

from trl import DPOTrainer, DPOConfig

config = DPOConfig(
    beta=0.1, learning_rate=5e-7,
    per_device_train_batch_size=4, num_train_epochs=1
)
trainer = DPOTrainer(
    model=model, ref_model=ref_model,
    args=config, train_dataset=preference_dataset,
    tokenizer=tokenizer
)
trainer.train()

完全な RLHF パイプライン: SFT → 報酬モデル → PPO。各ステップはそれ自体がプロジェクトです。DPO はこれを 1 つのステップに圧縮します。

A.8 命令チューニングのデータ形式

Alpaca 形式:

json

{"instruction": "...", "input": "...", "output": "..."}

ShareGPT 形式 (会話):

json

{"conversations": [
    {"from": "human", "value": "..."},
    {"from": "gpt", "value": "..."}
]}

チャットテンプレート: 各モデルによって形式が異なります。

python

tokenizer.apply_chat_template(messages, tokenize=False)
# "<|begin_of_text|><|start_header_id|>user<|end_header_id|>\n\n..."

A.9 データ洗練パイプライン

ファインチューニングのパフォーマンスは、データの品質に依存します。

重複の削除: MinHash と SimHash を使用して、類似した例を削除します。 品質フィルタリング: perplexity の閾値またはルールベースのルールを使用します。 多様性の確保: クラスタベースのサンプリングを使用します。 ラベルノイズの削減: 人によるレビューまたは複数のラベル付け者を使用します。

Constitutional AI 形式の自己改善: LLM が自分の回答を批判し、改善するデータでトレーニングします。エピソード #11。

A.10 本番環境でのモニタリング

LangSmith、Weave、Braintrust: LLM の可視化ツール。

ログ: プロンプト、レスポンス、時間、コスト、エラー。評価: 精度、根拠、安全性。自動化のために、LLM を評価器として使用します。 ドリフト検出: レスポンスの分布の変化を警告します。 A/B テスト: プロンプトとモデルのバージョンを比較します。

本番環境の LLM システムには不可欠なインフラストラクチャです。

参考文献

このエピソードで紹介したすべての内容、シナリオ、アナロジー、図は、BioPlaygroundによって作成されたものであり、以下の外部リソースは、これらの概念を学習する上で役立つ可能性があります。

Hugging Face 公式サイト: huggingface.co
Transformers ドキュメント: huggingface.co/docs/transformers
PEFT ドキュメント: huggingface.co/docs/peft
LoRA 論文: Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models" (ICLR 2022)
QLoRA: Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs" (NeurIPS 2023)
vLLM 論文: Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" (SOSP 2023)
Ollama: ollama.ai
OpenAI API: platform.openai.com/docs
Anthropic Claude API: docs.anthropic.com
Google Gemini API: ai.google.dev
TRL (RLHF): huggingface.co/docs/trl
ESM: github.com/facebookresearch/esm
BioGPT: github.com/microsoft/BioGPT

エピソード13で、今日のモデルエコシステムの全体像が完成しました。エピソード14では、AIコーディングエージェントの実際的な応用について解説します。

次回のテーマ

エピソード14 claude-code-and-cursor — AIコーディングエージェントの実践。Claude Code、Cursor、Windsurfを比較します。
エピソード15 bio-ai-integration — 第4段階。これまでのすべての内容をバイオパイプラインに統合します。

HuggingFaceと商用API：モデルエコシステムのマッピング

Hugging Face と商用 API: モデルエコシステムのマッピング

このトピックを修了すると

モデルを使用する 3 つのパス

Hugging Face エコシステム

Model Hub

Transformers ライブラリ

Datasets ライブラリ

Accelerate

PEFT: パラメーター効率的なファインチューニング

商用API：実用的な使い方

OpenAI

Anthropic Claude

Google Gemini

3つのAPIの比較

ローカルモデルの提供

Ollama — 個人/小規模

vLLM — 本番環境での提供

TGI、SGLang、LMDeploy

Llama.cpp

埋め込みAPI — パート#8からの再利用

API

Hugging Face ローカル

ファインチューニングのオプション

フルファインチューニング

LoRA/QLoRA

フル精度ファインチューニングAPI

データ要件

実践的なワークフロー

生物学における応用シナリオ

シナリオ1：タンパク質配列埋め込みパイプライン

シナリオ2：ドメイン固有のチャットボット（LoRA + vLLM）

シナリオ3：マルチモーダル病理画像分析

まとめ

📐 付録 — 専門家向けの実践的な最適化

A.1 LoRA の数式

A.2 QLoRA — 4ビットベース + LoRA

A.3 vLLM のページングされたアテンション

A.4 連続バッチング

A.5 量子化

A.6 サービスベンチマークのメトリック

A.7 実践的な RLHF ファインチューニング

A.8 命令チューニングのデータ形式

A.9 データ洗練パイプライン

A.10 本番環境でのモニタリング

参考文献

次回のテーマ

💬 質問・コメント