HuggingFace y APIs comerciales: trazando el mapa del ecosistema de modelos

Al finalizar este tema

Si en el capítulo 12 escribiste una red neuronal desde cero con PyTorch, en este capítulo aprenderás a utilizar cientos de miles de modelos ya entrenados que existen hoy en día. Desde el Hub de Modelos de HuggingFace y la librería Transformers, hasta las APIs comerciales de OpenAI, Anthropic y Google, pasando por el servicio local con Ollama y vLLM. Organizamos como un mapa el terreno de herramientas que todo desarrollador de IA actual debe conocer.

Este es el segundo capítulo sobre herramientas de la Fase 3. Sienta las bases prácticas para el capítulo 14 (agentes de codificación con Claude Code y Cursor) y el capítulo 15 (integración bioinformática).

Tres vías para utilizar modelos

Las tres vías principales para utilizar LLMs y transformadores en la práctica.

Vía A — API comercial. Llamadas a las APIs de empresas como OpenAI (GPT), Anthropic (Claude) y Google (Gemini).

• Ventajas: acceso inmediato a los mejores modelos, sin preocuparse por la infraestructura, actualizaciones automáticas.
• Desventajas: costes, privacidad de los datos, dependencia de la API.
• Uso práctico: la mayoría de las aplicaciones SaaS utilizan esta vía.

Vía B — Modelos de código abierto + servicio local. Ejecución de modelos abiertos como LLaMA, Mistral o Qwen en tu propio servidor.

• Ventajas: privacidad de los datos, control de costes (especialmente a gran escala), personalización.
• Desventajas: requiere infraestructura, el rendimiento puede no alcanzar el nivel superior de las APIs comerciales, complejidad operativa.
• Uso práctico: sistemas internos empresariales, industrias reguladas y laboratorios de investigación.

Vía C — HuggingFace Transformers. Carga, entrenamiento e inferencia directa de modelos abiertos mediante la API de PyTorch.

• Ventajas: máxima flexibilidad, posibilidad de ajuste fino (fine-tuning) y análisis.
• Desventajas: requiere optimización manual del servicio, necesidad de GPUs.
• Uso práctico: investigación, prototipado y desarrollo de modelos especializados.

Relación entre las tres vías. No son excluyentes. En la práctica se combinan. Por ejemplo: comenzar con la API de OpenAI para el prototipo → ajustar fino un modelo especializado con HuggingFace → servir localmente en producción con vLLM.

Ecosistema de HuggingFace

HuggingFace es el centro de la comunidad de código abierto en IA. Desde una startup francesa fundada en 2016, se ha convertido en el estándar de facto para la infraestructura de IA abierta.

Model Hub

huggingface.co/models contiene cientos de miles de modelos entrenados. Cubre todos los dominios: LLMs, visión por ordenador, audio, bioinformática, etc.

Modelos destacados relacionados con la biología.

• facebook/esm2_t33_650M_UR50D: Modelo de lenguaje de proteínas ESM-2 (mencionado en los capítulos 4 y 6).
• microsoft/biogpt-large: LLM para ciencias biomédicas.
• allenai/scibert_scivocab_uncased: BERT para artículos científicos.
• dmis-lab/biobert-v1.1: Entrenamiento previo en PubMed.
• InstaDeepAI/nucleotide-transformer-500m-human-ref: Transformador de genoma.

LLM convencionales.

• meta-llama/Llama-3.1-70B-Instruct: Modelo grande de Meta.
• Qwen/Qwen2.5-72B-Instruct: Alibaba, potente multilingüe.
• mistralai/Mistral-Large-Instruct-2411: Familia Mistral.

Biblioteca Transformers

Biblioteca estándar para cargar y utilizar modelos del Hub en PyTorch/JAX/TF.

from transformers import AutoModel, AutoTokenizer

# Cargar el modelo y el tokenizador (descarga automática)
model_name = "facebook/esm2_t33_650M_UR50D"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModel.from_pretrained(model_name)

# Ejemplo de secuencia proteica
sequence = "MKTVRQERLKSIVRILERSKEPVSGAQLAEELSVSRQVIVQDIAYLRSLGYNIVATPRGYVLAGG"
inputs = tokenizer(sequence, return_tensors="pt")
outputs = model(**inputs)

# Embedding de cada posición de aminoácido
embeddings = outputs.last_hidden_state  # shape: (1, len+2, hidden_dim)

AutoClass. AutoModel, AutoTokenizer, AutoConfig, etc. Conocer solo el nombre del modelo permite la detección automática de su arquitectura.

Pipeline. Atajos para tareas comunes (resumen, clasificación, QA, generación).

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"])

Biblioteca de Conjuntos de Datos

Cargador estándar para conjuntos de datos de entrenamiento y evaluación.

from datasets import load_dataset

ds = load_dataset("nlphuji/mscoco_2014_5k_test_image_text_retrieval")

Acelerar

Wrapper que oculta Multi-GPU, precisión mixta y FSDP.

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()

Oculta la configuración de DDP y FSDP del episodio #12.

PEFT — Ajuste fino eficiente en parámetros

El ajuste fino completo de modelos grandes requiere cientos de GB de GPU. PEFT (Ajuste Fino Eficiente en Parámetros) entrena únicamente pequeños adaptadores.

LoRA (Adaptación de Bajo Rango). Se añaden adaptadores de bajo rango (rango 4～16) a las matrices de pesos grandes. Los parámetros originales permanecen congelados.

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)
# Los parámetros entrenables son menos del 1 % del modelo original

Ventaja. Permite el ajuste fino de un modelo de 70B en una sola GPU de 24 GB. Solo se deben guardar los adaptadores, lo que facilita su implementación.

Caso práctico en biología. Ajuste fino con LoRA de Llama-3 en artículos científicos sobre biología → asistente especializado en el dominio. Solo es necesario gestionar archivos de adaptador de entre 100 y 500 MB.

API comercial — Uso real

OpenAI

from openai import OpenAI

client = OpenAI()  # Variable de entorno OPENAI_API_KEY

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "You are a molecular biology assistant."},
        {"role": "user", "content": "Summarize TP53 function."}
    ],
    temperature=0.3
)
print(response.choices[0].message.content)

Llamada de Funciones (Episodio #9).

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

Salidas Estructuradas (Episodio #7).

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

Modelos principales.

• GPT-4o: Estándar multimodal y de agentes.
• GPT-4o mini: Económico y rápido. Para tareas masivas.
• o1·o3: Modelos con razonamiento mejorado. Lógica y matemáticas complejas.

Anthropic Claude

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-3-5-sonnet-latest",
    max_tokens=1024,
    system="You are a molecular biology assistant.",
    messages=[{"role": "user", "content": "Summarize TP53 function."}]
)
print(response.content[0].text)

Soporte para Tool Use, Prompt Caching, Vision, Computer Use, entre otros. La mayoría de las funciones cubiertas en los episodios #7 a #10.

Modelos principales.

• Claude Opus 4.7·4.8: Máximo rendimiento. Tareas complejas.
• Claude Sonnet 5: Equilibrio. Uso general en la práctica.
• Claude Haiku 4.5: Rápido y económico. Procesamiento a gran escala.

Google Gemini

import google.generativeai as genai

genai.configure(api_key="...")
model = genai.GenerativeModel("gemini-1.5-pro")
response = model.generate_content("Summarize TP53 function.")
print(response.text)

Características de Gemini. Contexto de 1M+ tokens, multimodalidad potente (incluido vídeo), precio asequible.

Comparación de las tres APIs

Selección para la práctica. No hay una respuesta correcta. Evaluar conjuntamente la familiaridad del equipo, el rendimiento en tareas específicas y el precio.

Servicio de modelos locales

Servicio local cuando se requieren requisitos internos empresariales, privacidad o uso masivo.

Ollama — Para particulares y pequeñas escalas

Ejecuta fácilmente modelos de código abierto en portátiles locales. Compatible con Mac·Linux·Windows.

# Después de la instalación
ollama pull llama3.1
ollama run llama3.1

También se proporciona una API.

import requests

response = requests.post("http://localhost:11434/api/generate", json={
    "model": "llama3.1",
    "prompt": "Summarize TP53 function.",
    "stream": False
})
print(response.json()["response"])

Características de Ollama. Soporte para modelos cuantizados en formato GGUF (4-bit, 5-bit y 8-bit). Optimizado para Mac con Apple Silicon. Estándar para experimentación local por parte de desarrolladores e investigadores.

Reducción de capacidad. Llama-3.1-8B Q4 requiere 5 GB y puede ejecutarse en un Mac con 16 GB de RAM. Llama-3.1-70B Q4 requiere 40 GB. Es posible ejecutarlo en un Mac M3 Max con 128 GB de RAM.

vLLM — Servido para producción

Servido de modelos de lenguaje grandes (LLM) a escala de producción. Maximiza el rendimiento mediante continuous batching y PagedAttention.

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

Proporciona una API compatible con OpenAI. Se puede llamar usando clientes de OpenAI existentes.

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=[...]
)

Características de vLLM. PagedAttention (eficiencia de memoria del caché KV), continuous batching (maximización del uso de GPU). Un rendimiento 10 a 24 veces mayor en comparación con HuggingFace puro.

TGI, SGLang, LMDeploy

Alternativas al ecosistema vLLM. Cada una tiene sus propias fortalezas.

• TGI (HuggingFace): Integración con el ecosistema de HF, fácil implementación mediante Docker.
• SGLang: Optimización para prompts de estructuras complejas (RAG y agentes).
• LMDeploy: Fuerte apoyo por parte de la comunidad china. Optimizado para Qwen e InternLM.

Llama.cpp

Motor de inferencia ligero basado en C++. Ejecuta modelos GGUF. Se utiliza internamente en Ollama. Compatible con CPU, CUDA y Metal (Mac). Es favorable para el desarrollo personal y la implementación en dispositivos periféricos.

API de incrustaciones — Episodio #8 Reutilización

Las incrustaciones necesarias para RAG del Episodio #8 también siguen dos vías: API o local.

API

# OpenAI
response = openai_client.embeddings.create(
    model="text-embedding-3-large",
    input="protein sequence description"
)
embedding = response.data[0].embedding  # 3072-dim

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

# Voyage AI (entre los mejores de los benchmarks)
voyage_response = voyage_client.embed(texts=["..."], model="voyage-3")

HuggingFace local

from sentence_transformers import SentenceTransformer

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

Especializado en biología.

• Transformador de oraciones PubMedBERT: afinamiento específico para biomedicina.
• Basado en BioBERT: entrenado con PubMed y MEDLINE. Embeddings de oraciones ProtT5·ESM: especializados en secuencias de proteínas.

Opciones de afinamiento (Fine-tuning)

En el episodio #8 vimos el compromiso entre afinamiento y RAG. Aquí se presentan las opciones propias del afinamiento.

Afinamiento completo (Full Fine-tuning)

Actualización de todos los parámetros. Mayor precisión, pero más costoso.

• Cuándo: grandes volúmenes de datos del dominio; cambios fundamentales en el estilo.
• Costo: un modelo de 70B equivale a cientos de miles～decenas de millones de wones en tiempo de GPU.

LoRA·QLoRA

Entrenamiento solo de algunos adaptadores.

• Cuándo: la mayoría de los casos; con datos pequeños y de bajo costo.
• Costo: LoRA para 70B = unas pocas horas en una sola GPU A100.

API de afinamiento en precisión completa

OpenAI y Anthropic ofrecen APIs de afinamiento gestionadas.

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

• Cuándo: Personalización de modelos comerciales.
• Costo: Depende del tamaño de los datos y del número de épocas. En la mayoría de los casos, cuesta unos miles de wones.

Requisitos de datos

• LoRA: 500～5000 ejemplos son suficientes para una mejora adecuada.
• Ajuste fino completo (Full fine-tuning): Más de 10000 ejemplos.
• Preentrenamiento continuo (texto masivo por dominio): cientos de millones a miles de millones de tokens.

Flujo de trabajo profesional

Flujo típico del proyecto.

1. Prototipo: API de OpenAI/Anthropic + ingeniería de prompts. De unos días a 1 semana.
2. Implementación de RAG: Base de datos vectorial con documentos del dominio. Capítulo #8. 1～2 semanas.
3. Conversión en agente: Herramientas y bucles. Capítulo #9. 2～4 semanas.
4. Mejora del rendimiento: Perfilado para identificar cuellos de botella.
   • Si el problema está en el prompt → Mejorar el sistema de prompts.
   • Si se requiere un estilo específico → Ajuste fino con LoRA.
   • Si hay requisitos de privacidad → Migrar a modelos abiertos locales.
   • Si el costo por uso masivo es alto → Implementación propia (self-hosting).
5. Despliegue en producción: Monitoreo, manejo de errores, límites de tasa y registros de auditoría.

Ejemplo de proyecto de laboratorio de biología. Desarrollo de un asistente para resúmenes de artículos científicos.

• Semana 1-2: Prototipo con GPT-4o de OpenAI + RAG de PubMed.
• Semana 3-4: Recopilación de comentarios y retroalimentación en presentaciones académicas.
• Semana 5-8: Mejora del dominio mediante incrustaciones (embeddings) de BioBERT + migración a Claude Sonnet.
• Mes 3-4: Despliegue de vLLM + Llama-3 en el servidor local del laboratorio. Privacidad de los datos.
• Mes 6+: Ajuste fino continuo y fortalecimiento de la capa de verificación de citas.

Escenarios de aplicación biológica

Escenario 1 — Pipeline de incrustaciones de secuencias de proteínas

Aplicar el RAG del Capítulo #8 a la búsqueda de secuencias de proteínas.

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)
    # Agrupación media (media de las posiciones de aminoácidos)
    return outputs.last_hidden_state.mean(dim=1).cpu().numpy()

# Embeddings de varias proteínas
proteins = ["MKTVRQ...", "MSPTQR...", ...]
embeddings = np.stack([get_protein_embedding(p) for p in proteins])

# Guardar en una BD vectorial → buscar proteínas similares

Se utiliza en la predicción de actividad enzimática, predicción de interacciones proteína-proteína, entre otras aplicaciones.

Escenario 2 — Chatbot especializado por dominio (LoRA + vLLM)

Fine-tuning de Llama-3-8B con LoRA sobre 500 artículos de laboratorio, servido mediante vLLM.

• Semana 1: Generación de pares QA en formato JSON a partir de los 500 artículos (generados automáticamente con GPT-4o).
• Semana 2: Entrenamiento de LoRA con HuggingFace + PEFT.
• Semana 3: Servicio con vLLM e integración con bot de Slack.

Asistente optimizado para el conocimiento interno del laboratorio y los artículos más recientes. Ventajoso tanto en privacidad como en costos.

Escenario 3 — Análisis multimodal de imágenes patológicas

Análisis de imágenes de láminas patológicas junto con texto mediante modelos Vision-Language (por ejemplo, LLaVA).

• Código abierto: llava-hf/llava-v1.6-mistral-7b-hf
• Comercial: GPT-4o Vision, Claude 3.5 Vision, Gemini 1.5 Pro

Determinación del tipo celular a partir de imágenes y generación de explicaciones en lenguaje natural. Implementación práctica del Escenario 3 de la Parte #6.

Resumen clave

• Tres vías para el uso de modelos: API comercial, servicio local de modelos abiertos y HuggingFace directo. No son excluyentes; pueden combinarse.
• HuggingFace Hub es el estándar para modelos y conjuntos de datos abiertos. Incluye las bibliotecas Transformers, Datasets, Accelerate y PEFT.
• Las tres principales APIs comerciales: OpenAI (GPT), Anthropic (Claude) y Google (Gemini). Difieren en contexto, precio y áreas especializadas.
• Servicio local: Ollama (uso personal), vLLM (producción), TGI, SGLang y llama.cpp.
• Fine-tuning económico de modelos grandes mediante LoRA/QLoRA. Solo se gestionan adaptadores de 100 a 500 MB.
• Flujo de trabajo profesional: Prototipo (API) → RAG → Agente → Mejora del rendimiento → Despliegue en producción.
• Modelos especializados en biología: ESM, BioGPT, SciBERT, BioBERT, Nucleotide Transformer, entre otros. Disponibles para uso inmediato en HuggingFace.

Próximos conceptos

• Parte #14 claude-code-and-cursor — Implementación práctica de agentes de codificación con IA. Comparativa entre Claude Code, Cursor y Windsurf.
• Parte #15 bio-ai-integration — Fase 4. Integración de todo lo realizado hasta ahora en un flujo de trabajo biológico.

📐 Apéndice — Optimización práctica para expertos

Dificultad: Muy difícil (Very Hard) Dirigido a: Lectores con experiencia profesional en servicio y fine-tuning de LLMs en producción

A.1 Fórmula LoRA

Matriz de pesos original W ∈ ℝ^{d × d}. LoRA:

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

• A ∈ ℝ^{r × d} (proyección de rango bajo)
• B ∈ ℝ^{d × r} (proyección de rango alto)
• r ≪ d (por ejemplo: r=16, d=4096)

Parámetros de entrenamiento: solo A y B. 2·r·d en total. Mucho menos que el d² original, 2r/d ≈ 0.008.

Inicialización: A ~ distribución normal, B = 0. Al inicio del entrenamiento, ΔW = 0.

Escalado:

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

α garantiza una señal de aprendizaje constante independientemente de los hiperparámetros y el rango.

A.2 QLoRA — Base de 4 bits + LoRA

Almacena el modelo original cuantizado a 4 bits. El adaptador LoRA está en FP16. Durante el entrenamiento, solo se desquantizan las partes necesarias de los pesos originales.

• NF4 (NormalFloat4): float de 4 bits, cuantización optimizada para una distribución normal.
• Double Quantization: vuelve a cuantizar la propia constante de cuantización para ahorrar aún más.
• Paged Optimizer: descarga el estado del optimizador a la memoria de la CPU.

Efecto. Permite ajustar finamente un modelo de 70B en una sola GPU de 24 GB. El artículo original (Dettmers et al., 2023) ha establecido el estándar para el ajuste fino de modelos abiertos.

A.3 PagedAttention de vLLM

Resuelve el problema del caché KV descrito en la sección #6.

Enfoque tradicional. Cada solicitud reserva memoria continua igual al tamaño máximo del contexto solicitado. Aunque el uso real sea menor, no se puede reducir el tamaño reservado → gran desperdicio de memoria.

PagedAttention. Divide el caché KV en páginas (por ejemplo, 16 tokens) y las asigna solo cuando es necesario. Similar a la memoria virtual de los sistemas operativos.

Efecto:

• Eficiencia del uso de memoria: de ~60% a >96%
• Al combinarse con continuous batching, el rendimiento aumenta entre 10 y 24 veces

A.4 Continuous Batching

Enfoque tradicional: espera a completar el lote; todas las solicitudes dentro del lote avanzan al mismo paso.

Continuous: cada solicitud se reemplaza inmediatamente por una nueva al completarse. Minimiza la inactividad de la GPU.

Pérdida de tiempo. El paso de prefill (procesamiento del prompt) solo ocurre una vez al inicio de cada solicitud. Solo el paso de decode es continuo.

Avances recientes. Chunked Prefill (divide los prompts largos en chunks para procesarlos), Speculative Decoding (genera candidatos con un modelo draft pequeño → verificados por el modelo grande). Reducción de la latencia entre 30% y 50%.

A.5 Cuantización (Quantization)

Almacena parámetros y activaciones en menos bits.

Post-Training Quantization (PTQ). Cuantización después del entrenamiento. Rápido.

• GPTQ: cuantización por grupo con error mínimo. Estándar de 4 bits.
• AWQ (Activation-aware Weight Quantization): considera la distribución de las activaciones. Alternativa a GPTQ.

Quantization-Aware Training (QAT). Simulación de cuantización durante el entrenamiento. Más preciso, pero con mayor costo de entrenamiento.

FP8. Soportado en la generación H100. Pérdida mínima de precisión, velocidad y memoria duplicadas.

A.6 Métricas de benchmark de servicio

Throughput (solicitudes/segundo): número de solicitudes procesadas por segundo.

TTFT (Time To First Token): Retraso desde la solicitud hasta el primer token. Determina la experiencia del usuario.

ITL (Inter-Token Latency): Retraso entre tokens. Velocidad de transmisión en streaming.

Usuarios concurrentes: Número de usuarios procesados simultáneamente.

Herramientas de medición: vllm/benchmarks, llmperf, guidance-serve.

A.7 Fine-tuning con RLHF en la práctica

Biblioteca TRL (HuggingFace). Implementación de RLHF y DPO.

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()

Pipeline completo de RLHF: SFT → Modelo de recompensa → PPO. Cada etapa es en sí misma un proyecto. DPO comprime esto en una sola etapa.

A.8 Formato de datos para ajuste por instrucciones

Formato Alpaca:

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

Formato ShareGPT (conversación):

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

Plantilla de chat. Cada modelo tiene su propio formato.

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

A.9 Pipeline de limpieza de datos

El rendimiento del ajuste fino depende de la calidad de los datos.

Eliminación de duplicados. Eliminación de ejemplos similares mediante MinHash y SimHash. Filtrado de calidad. Umbral de perplejidad y reglas basadas en heurísticas. Garantía de diversidad. Muestreo basado en clústeres. Reducción del ruido en las etiquetas. Revisión humana y múltiples etiquetadores.

Mejora automática del formato de la IA Constitucional. Entrenamiento con datos generados por un LLM que critica y mejora sus propias respuestas. Capítulo #11.

A.10 Monitoreo en producción

LangSmith, Weave y Braintrust. Herramientas de observabilidad para LLM.

Registros: prompt, respuesta, tiempo, costo y errores. Evaluación: precisión, fundamentación (groundedness) y seguridad. Automatización mediante LLM-as-a-judge. Detección de deriva: alertas sobre cambios en la distribución de las respuestas. Pruebas A/B: comparación de prompts y versiones del modelo.

Infraestructura esencial para sistemas de LLM en producción.

Referencias

El contenido, los escenarios, las metáforas y los datos numéricos de este capítulo son desarrollos propios de BioPlayground; a continuación se presentan referencias externas que pueden ayudar en el aprendizaje conceptual:

• HuggingFace oficial: huggingface.co
• Documentación de Transformers: huggingface.co/docs/transformers
• Documentación de PEFT: huggingface.co/docs/peft
• Artículo original de 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)
• Artículo original de vLLM: Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" (SOSP 2023)
• Ollama: ollama.ai
• API de OpenAI: platform.openai.com/docs
• API de Anthropic Claude: docs.anthropic.com
• API de Google Gemini: ai.google.dev
• TRL (RLHF): huggingface.co/docs/trl
• ESM: github.com/facebookresearch/esm
• BioGPT: github.com/microsoft/BioGPT

El mapa del ecosistema de modelos de hoy se ha resumido en el capítulo #13. En el capítulo #14 se abordará el uso práctico de agentes de codificación con IA.