AI on kenji.blog

Casos de uso y código de ejemplo de la API más reciente de Microsoft.Windows.AI

Fri, 11 Sep 2026 18:00:00 +0900

Casos de uso y código de ejemplo de la API más reciente de Microsoft.Windows.AI: Explorando las profundidades de Windows Copilot Runtime

1. Introducción: La nueva era de Windows con IA integrada de forma nativa

En los últimos años, la evolución de la tecnología de IA ha sido notable, y se ha producido un rápido cambio de paradigma desde la utilización de grandes modelos de lenguaje (LLM) en la nube hasta la inferencia de IA en dispositivos de borde (PC locales). El núcleo de esto es “Windows Copilot Runtime” proporcionado por Microsoft para Windows 11 y la API “Microsoft.Windows.AI” para operarlo.

El desarrollo de aplicaciones utilizando APIs en la nube (como OpenAI y Azure OpenAI) es fácil, pero conlleva desafíos como la latencia, la privacidad y los costos continuos. Por otro lado, al ejecutar modelos de IA localmente, puede lograr aplicaciones de latencia ultrabaja que funcionan incluso sin conexión, sin que los datos confidenciales salgan del dispositivo.

En este artículo, explicaremos exhaustiva y detalladamente cómo implementar funciones de IA local, que serán esenciales en el desarrollo futuro de aplicaciones de Windows, utilizando ejemplos de código práctico en C# y C++, desde la arquitectura hasta el ajuste de rendimiento. No se trata solo de llamar a la API, sino de profundizar en los detalles técnicos avanzados, como la utilización del hardware subyacente (NPU y GPU) y la integración con DirectML.

2. Descripción general de la arquitectura y Windows Copilot Runtime

Windows Copilot Runtime es una serie de pilas de IA diseñadas para permitir a los desarrolladores integrar fácilmente modelos de IA en Windows y obtener el mejor rendimiento. Este tiempo de ejecución abstrae la aceleración de hardware a nivel del sistema operativo y proporciona una interfaz unificada a los desarrolladores.

graph TD App["Aplicación de Windows (C# / C++)"] --> API["APIs de Microsoft.Windows.AI"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (Capa del SO)"] WCR --> SLM["Modelos Locales (Phi-Silica, etc.)"] ORT --> DML["Proveedor de Ejecución DirectML"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (Unidad de Procesamiento Neuronal)"] DXCore --> GPU["GPU (Unidad de Procesamiento Gráfico)"] DXCore --> CPU["CPU"]

Como muestra el diagrama de arquitectura anterior, las aplicaciones pueden acceder directamente a los modelos de lenguaje pequeños (SLM: Phi-Silica, etc.) integrados en el sistema operativo mediante el uso de la API de alto nivel Microsoft.Windows.AI. Además, cuando se utilizan modelos personalizados, es posible utilizar explícitamente la aceleración de hardware a través de ONNX Runtime y DirectML. Debido a que la capa del sistema operativo optimiza la distribución de las cargas de trabajo a la CPU, GPU y NPU, los desarrolladores pueden crear aplicaciones de IA de alto rendimiento sin tener que preocuparse profundamente por las diferencias de hardware.

3. Aceleración de hardware y evaluación matemática de la NPU

Los PC Copilot+ más recientes están equipados con una NPU (Unidad de Procesamiento Neuronal), un procesador especializado en el procesamiento de IA. El rendimiento de una NPU generalmente se evalúa en TOPS (Tera Operations Per Second).

En la inferencia de modelos de IA, especialmente la capacidad computacional de la multiplicación de matrices (GEMM: General Matrix Multiply) determina el rendimiento. El rendimiento máximo teórico del hardware $P_{\text{peak}}$ se aproxima mediante la siguiente fórmula.

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

Donde,

$f$ es la frecuencia de reloj de la NPU (Hz)
$N_{\text{cores}}$ es el número de núcleos en la NPU
$N_{\text{MACs/core}}$ es el número de unidades MAC (Multiplicación-Acumulación) por núcleo
El último $2$ se debe a que una sola operación MAC cuenta como dos operaciones (FLOPs/OPs) de multiplicación y suma.

Por ejemplo, para una NPU con una frecuencia de 1.5 GHz, 4 núcleos y cada núcleo con 4096 MACs,

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

Queda demostrado matemáticamente que este rendimiento supera los 40 TOPS, que es el requisito para un PC Copilot+ con Windows 11.

Además, la inferencia de los modelos de IA, especialmente de los LLM (fase de decodificación), tiende a estar limitada por la memoria (Memory-Bound). El ancho de banda teórico de la memoria del sistema $BW$ se calcula de la siguiente manera.

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

En el caso de una memoria LPDDR5x-8533 ($f_{\text{mem}} = 8533 \text{ MT/s}$) y un bus de 128 bits ($W_{\text{bus}} = 128$), el ancho de banda es de aproximadamente $136 \text{ GB/s}$. En la optimización de aplicaciones de IA, es importante cómo ahorrar este ancho de banda, por lo que la cuantización (Quantization) del modelo, que se describe más adelante, es indispensable.

4. Configuración del entorno de desarrollo

Para utilizar la API de IA de Windows más reciente, debe preparar el siguiente entorno y cadena de herramientas.

SO: Windows 11 versión 24H2 o posterior (se recomienda encarecidamente un dispositivo equipado con NPU que cumpla con los requisitos del PC Copilot+)
SDK: Windows App SDK (versión v1.5 o posterior compatible con la extensión de IA)
Entorno de desarrollo: Visual Studio 2022 (v17.10 o posterior), con cargas de trabajo de desarrollo de escritorio con C++ y desarrollo de escritorio de .NET
Paquetes: Instale Microsoft.Windows.AI y Microsoft.ML.OnnxRuntime.DirectML a través de NuGet

1
2
3
4
5
6


<!-- Ejemplo de configuración de .csproj -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. 【Deep Dive 1】Utilización de modelos de lenguaje locales (Phi-Silica) con C#

Windows Copilot Runtime incluye “Phi-Silica”, un modelo de lenguaje pequeño y altamente eficiente desarrollado por Microsoft, como un componente estándar del sistema operativo. Esto permite el procesamiento avanzado del lenguaje natural (resumen de texto, generación de código, chatbots) en un entorno sin conexión, sin tener que descargar modelos del tamaño de gigabytes de la red.

A continuación, se muestra un código de ejemplo avanzado en C# para construir una IA de chat utilizando el espacio de nombres Microsoft.Windows.AI.Generative. Admite respuestas en streaming y genera texto en tiempo real sin bloquear el hilo de la interfaz de usuario (UI).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// Inicializa el modelo de lenguaje. Verifica la disponibilidad de la NPU y carga el modelo en el dispositivo óptimo.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("Comprobando los requisitos del sistema y la disponibilidad del modelo de IA local (Phi-Silica)...");

 // Comprueba si el modelo está disponible en el sistema (si no es compatible, puede solicitar la descarga)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"El modelo de IA local no está disponible actualmente. Estado: {availability}");
 }

 // Crea una instancia del modelo (en este momento se realiza la asignación al espacio de memoria y la inicialización de la NPU)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("Inicialización del modelo de lenguaje completada. La aceleración de hardware a través de DirectML está activa.");
 }

 /// <summary>
 /// Recibe el prompt del usuario y genera una respuesta en streaming.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[Entrada del usuario]: {prompt}\n[Asistente de IA]: ");

 // Establece los hiperparámetros para la generación
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // Construye el contexto de la conversación
 var context = new LanguageModelContext();
 context.AddSystemMessage("Eres un asistente de IA avanzado que se ejecuta directamente en la NPU local de Windows. Piensa lógica y paso a paso, y responde de forma concisa.");
 context.AddUserMessage(prompt);

 try
 {
 // Llamada a la API de inferencia en streaming
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // Itera de forma asíncrona los fragmentos devueltos como IAsyncEnumerable
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // Imprime el token generado (fragmento) en la consola en tiempo real
 // En el caso de una aplicación de UI, refleje esto en un TextBox o similar usando DispatcherQueue aquí
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[La generación fue cancelada por el usuario o el sistema]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[Se produjo un error fatal: {ex.Message}]");
 }
 }
 }
}

5.1 Explicación de la arquitectura en la implementación de C#

El núcleo de este código es la validación previa a la ejecución mediante LanguageModel.CheckAvailabilityAsync() y el streaming asíncrono mediante GenerateResponseStreamAsync. Cuando Copilot Runtime, que se ejecuta en segundo plano en el sistema operativo, recibe esta llamada a la API, inicia internamente ONNX Runtime y selecciona el Proveedor de Ejecución óptimo (DirectML + NPU en muchas de las PC más nuevas) según la configuración del sistema.

Los desarrolladores pueden integrar tuberías de inferencia de IA de última generación en sus aplicaciones con unas pocas líneas de código C#, sin tener que preocuparse en absoluto por la forma del tensor del modelo, la implementación del tokenizador o la gestión de la memoria de la caché KV.

6. 【Deep Dive 2】Inferencia rápida de modelos personalizados con C++ y DirectML

Para manejar dominios específicos que no pueden ser cubiertos solo por el modelo de lenguaje estándar del sistema operativo (por ejemplo, segmentación de imágenes propia, reconocimiento de voz, modelos personalizados de detección de objetos, etc.), los desarrolladores deben operar directamente ONNX Runtime y DirectML, que se encuentran en la capa inferior de Microsoft.Windows.AI.

Al usar C++, es posible optimizar la asignación de memoria al límite y extraer el rendimiento máximo de la NPU/GPU. A continuación se muestra la implementación principal de una tubería avanzada de inicialización e inferencia para ejecutar un modelo personalizado en formato ONNX (por ejemplo, YOLOv8) utilizando DirectML en C++.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // Optimización del número de hilos
 sessionOptions.SetIntraOpNumThreads(1);
 // Establece el nivel de optimización del gráfico al máximo
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. Añadir el Proveedor de Ejecución DirectML (DML EP)
 // device_id = 0 es el adaptador recomendado predeterminado del sistema (NPU o GPU de alto rendimiento)
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[Info] Proveedor de Ejecución DirectML conectado exitosamente." << std::endl;
 } else {
 std::cerr << "[Warning] Error al obtener la API de DirectML. Ejecutando en modo fallback de CPU." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. Cargar el modelo y crear la sesión
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] Modelo ONNX cargado exitosamente y gráfico de cálculo compilado." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] Fallo en la carga del modelo: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. Crear el búfer del tensor de entrada
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. Obtención dinámica de los nombres de los nodos de entrada y salida
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. Ejecución de la inferencia (se descarga a la NPU/GPU a través de DirectML)
 std::cout << "[Info] Iniciando la ejecución del motor de inferencia..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. Obtener y analizar el tensor de resultados
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] Inferencia completada: " << duration.count() << " ms" << std::endl;
 std::cout << "[Result] Número de elementos en el tensor de salida: " << outputSize << std::endl;
 // *Después de esto, implemente el procesamiento para dibujar bounding boxes o NMS (Non-Maximum Suppression) para el tensor de salida
 }
};

int main() {
 try {
 // Ruta del modelo ONNX a ejecutar
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // Datos de imagen de prueba para la inferencia (tamaño de lote 1 x 3 canales x 640 x 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "El programa terminó de forma anormal: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 La importancia de la gestión de la memoria y la inferencia sin copia (Zero-Copy) en C++

La mayor ventaja de usar DirectML con C++ es que permite una estrecha integración con DirectX 12 (DX12). El código anterior incluye la copia de datos desde la memoria de la CPU estándar desde un punto de vista educativo, pero en los motores de juegos reales y las aplicaciones de procesamiento de video, hay muchos casos donde las imágenes (texturas) ya se mantienen en el espacio de memoria de la GPU o la NPU usando DX12.

En este caso, al utilizar la función de vinculación avanzada de OrtDmlApi, puede realizar “Inferencia Sin Copia (Zero-Copy Inference)”, que mapea directamente los recursos de DX12 como tensores de ONNX Runtime. Como resultado, la sobrecarga de transferencia de datos entre el bus PCIe (el consumo del ancho de banda $BW$ descrito anteriormente) desaparece por completo, y la velocidad de fotogramas en el procesamiento de video en tiempo real mejora drásticamente.

7. Optimización del rendimiento y mejores prácticas

A continuación se resumen las estrategias de optimización esenciales al desarrollar aplicaciones de IA de primer nivel utilizando la API de IA de Windows y DirectML.

7.1 Cuantización de modelos (Quantization) y Olive Toolkit

Para liberar el verdadero poder de la NPU, es un requisito absoluto cuantizar (Quantization) los pesos y las activaciones del modelo de IA de FP32 (punto flotante de precisión simple) a INT8 o INT4. La arquitectura de la NPU está especializada en operaciones de enteros y, en comparación con FP32, INT8 logra teóricamente 4 veces el rendimiento y un ahorro de energía significativo.

Al utilizar la cadena de herramientas Olive (ONNX Live) proporcionada por Microsoft, los modelos como PyTorch se pueden optimizar automáticamente para entornos Windows. Olive brinda un fuerte soporte para la optimización de atención especial para modelos Transformer y la compilación de gráficos por hardware.

7.2 La compensación entre el procesamiento por lotes y el streaming interactivo

En las llamadas a la API, al agrupar múltiples solicitudes de inferencia (procesamiento por lotes), se puede aumentar la eficiencia de utilización (Compute Utilization) de la NPU. Sin embargo, en el caso de las interfaces de usuario interactivas, como los chatbots, el tiempo hasta que se muestra el primer token (TTFT: Time To First Token) determina la experiencia del usuario (UX) más que el rendimiento (throughput). Por lo tanto, en la interfaz de usuario interactiva, la mejor práctica es establecer el tamaño del lote (batch size) en 1 y priorizar el diseño de generación en streaming.

7.3 Tareas en segundo plano y coordinación con el SO

La inferencia de IA consume una gran cantidad de energía local y recursos del sistema. Se requiere coordinar con la App Lifecycle API de Windows e implementar un mecanismo para suspender (Suspend) las tareas de inferencia de baja prioridad o reducir el consumo de recursos cuando la aplicación pasa a segundo plano.

sequenceDiagram participant User as "Usuario" participant App as "App de Windows (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "Hardware NPU" User->>App: "Ingresa el prompt" App->>API: "GenerateResponseStreamAsync()" API->>OS: "Despacho del trabajo de inferencia" OS->>ORT: "Solicitud de ejecución del gráfico" ORT->>NPU: "Ejecución de la lista de comandos a través de DirectML" NPU-->>ORT: "Cálculo completado (1 token generado)" ORT-->>OS: "Resultado del tensor" OS-->>API: "Texto decodificado" API-->>App: "Fragmentos de IAsyncEnumerable" App-->>User: "Dibujo de texto en tiempo real en la UI" Note over ORT,NPU: "Repetir rápidamente este bucle hasta completarlo"

Este diagrama de secuencia ilustra la belleza del procesamiento asíncrono, donde los datos se transmiten de manera fluida desde el hardware de la NPU en la capa más baja hasta la capa de presentación de la aplicación, sin bloquear en absoluto el hilo de la interfaz de usuario.

8. Perspectivas futuras y la evolución de Windows AI

La API Microsoft.Windows.AI y Copilot Runtime están experimentando una rápida evolución en curso. Se esperan los siguientes cambios de paradigma en futuras actualizaciones para desarrolladores:

Integración nativa del SO para API multimodales: Procesamiento simultáneo y sin problemas no solo de texto, sino también de audio, imágenes e incluso transmisiones de video en vivo, ofreciendo inferencia de IA intermodal de forma estándar a nivel de SO.
Soporte a nivel de sistema para RAG (Retrieval-Augmented Generation): Vinculación de documentos personales en la PC local y el índice de Windows Search con el modelo de IA dentro de un entorno seguro del SO (sandbox), permitiendo la construcción de un asistente de IA personal súper avanzado con protección total de la privacidad del usuario.
Escalado dinámico de recursos de la NPU: Cuando múltiples aplicaciones de IA operan simultáneamente (por ejemplo, cancelación de ruido en segundo plano y generación de código en primer plano), el programador del kernel de Windows cambiará dinámicamente el contexto de ejecución de la NPU para garantizar la QoS (Calidad de Servicio).

9. Conclusión: El futuro de las aplicaciones transformadas por la IA local

Copilot Runtime de Windows 11 y la API Microsoft.Windows.AI han aportado un arma extremadamente poderosa llamada “IA local” a todos los desarrolladores de Windows. Ya no es necesario depender completamente de las API en la nube. Es posible eliminar la latencia, proteger firmemente la privacidad y ofrecer a los usuarios una experiencia de IA de próxima generación que funcione completamente incluso sin conexión.

Aprovechando el conocimiento explicado en este artículo sobre la integración de modelos de lenguaje estándar del sistema utilizando C#, la evaluación matemática del rendimiento y la optimización extrema del hardware utilizando C++ y DirectML, cree usted mismo las aplicaciones de Windows “nativas de IA” de próxima generación. Las infinitas posibilidades que brinda la IA se extienden justo más allá del código que escriba.

※ Nota: Este artículo ha sido escrito sobre la base de las versiones preliminares de la API y las especificaciones más recientes a partir de septiembre de 2026. Debido a las actualizaciones de Windows, las especificaciones de la API y los requisitos de hardware pueden cambiar, por lo que al momento de la implementación asegúrese de consultar también la documentación oficial de Microsoft Learn.

¡No necesitas Python! Construí un motor de inferencia de IA solo con C++

Fri, 11 Sep 2026 17:00:00 +0900

1. Introducción: ¿Por qué dejar Python y crear un motor de inferencia de IA en C++?

En el desarrollo de IA moderno, Python es el estándar de facto. Gracias a la ventaja de frameworks potentes como PyTorch o TensorFlow, puedes construir, entrenar e inferir redes neuronales complejas con unas pocas líneas de código. Sin embargo, detrás de estos frameworks, lenguajes de bajo nivel como C++ y CUDA se encargan del procesamiento computacional pesado. Python simplemente juega el papel de “pegamento” (glue).

Entonces, ¿por qué molestarse en eliminar Python y crear un motor de inferencia de IA usando únicamente C++? Hay varias razones de peso para ello.

Rendimiento extremo y baja latencia: Puedes eliminar por completo la sobrecarga causada por el GIL (Global Interpreter Lock) de Python y su tipado dinámico. Especialmente en sistemas que requieren tiempo real, un retraso de milisegundos puede ser fatal.
Facilidad de implementación (Deployment): Construir un entorno de Python (una enorme colección de bibliotecas, un infierno de dependencias) en el entorno del usuario final es extremadamente difícil. Con C++, solo necesitas distribuir un único binario ejecutable enlazado estáticamente (un .exe o binario ELF).
Compatibilidad con dispositivos Edge: En entornos con recursos estrictamente limitados, como teléfonos inteligentes, dispositivos integrados o Raspberry Pi, no hay margen para ejecutar un entorno de ejecución de Python que consume varios gigabytes de memoria.
Control directo del hardware: C++ permite el control a bajo nivel, como la temporización de la asignación de memoria, el uso explícito de instrucciones SIMD y la optimización de las transferencias de memoria con la GPU.

En este artículo, basándome en gran medida en la arquitectura de la biblioteca “GGML” desarrollada por Georgi Gerganov, explicaré el proceso de construir desde cero un motor de inferencia para ejecutar modelos de lenguaje grande (LLM) usando solo C++, sumergiéndonos en las profundidades técnicas.

2. Visión general de la arquitectura del motor de inferencia

El procesamiento de inferencia de IA es esencialmente una “sucesión de enormes cálculos matriciales”. Para ejecutar esto de manera eficiente, un motor de inferencia debe estar compuesto por los siguientes componentes.

graph TD A["Datos de Entrada (Tokens/Imágenes)"] --> B["Gestión de Tensores"] B --> C["Grafo de Computación (DAG)"] C --> D["Memory Arena y Asignador"] C --> E["Planificador y Pool de Hilos"] E --> F["Backend de CPU (AVX2/ARM NEON)"] E --> G["Backend de GPU (CUDA/Metal)"] F --> H["Resultados de Salida"] G --> H

Gestión de Tensores (Tensor): Gestiona las estructuras de datos de matrices multidimensionales y el stride de cada dimensión.
Grafo de Computación (Computation Graph): Representa las operaciones de cada capa de la red neuronal como un Grafo Acíclico Dirigido (DAG).
Memory Arena (Arena de Memoria): Un mecanismo de gestión de memoria preasignada para evitar la sobrecarga de la asignación de memoria dinámica (malloc o new).
Backend: Implementaciones de cálculos (kernels) optimizadas para hardware específico, como CPU o GPU.

Ensamblaremos estos componentes utilizando las poderosas características de C++ (plantillas, aritmética de punteros, RAII, etc.).

3. El secreto de la gestión de memoria: Memory Arena y Alineación SIMD

La gestión de memoria en un motor de inferencia es uno de los factores más importantes directamente relacionados con el rendimiento. Durante la inferencia, especialmente al pasar a través de cada capa de un modelo Transformer, se genera una enorme cantidad de tensores intermedios. Si se asignan y liberan cada vez con el malloc estándar, la fragmentación del montón (heap) y los cambios de contexto del sistema operativo causarán caídas drásticas y fatales en la velocidad.

Por lo tanto, adoptamos el enfoque de un “Memory Arena”. Este es un método en el que se calcula (o se fija) y se asigna de una sola vez la cantidad máxima de memoria necesaria al inicio de la inferencia, y luego la memoria se extrae simplemente incrementando un puntero.

3.1 La importancia de la alineación

Las CPU modernas admiten instrucciones SIMD (Single Instruction, Multiple Data). Ejemplos son AVX2/AVX-512 de Intel/AMD y NEON de ARM. Estas instrucciones procesan datos de 256 bits (32 bytes) o 512 bits (64 bytes) a la vez, pero la memoria de datos objetivo debe estar alineada (alineación) a un límite de bytes específico (generalmente 32 o 64 bytes).

A continuación se muestra un ejemplo de implementación en C++ de un Memory Arena considerando la alineación.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // Usa posix_memalign en sistemas POSIX, o _aligned_malloc en Windows
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // Cálculo de alineación (buscar el padding)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena se quedó sin memoria");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // Liberar memoria es tan simple como reiniciar el puntero (O(1))
 }
};

De esta manera, al crear un tensor, siempre se obtiene memoria a través de esta arena. Al final de cada paso de inferencia (por ejemplo, después de generar un token), simplemente llamando a reset(), la memoria se puede reutilizar instantáneamente.

4. Estructura de datos de tensores y la magia de los Strides

Un tensor es un concepto que generaliza escalares, vectores y matrices. Lo importante en la implementación es que, mientras los datos reales se ubican en la memoria como un arreglo unidimensional contiguo, tiene el concepto de un “Stride” para interpretarlo como multidimensional.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // Para cuantización
 INT4 // Para cuantización
};

struct Tensor {
 int n_dims; // Número de dimensiones
 int64_t ne[4]; // Número de elementos en cada dimensión (Number of Elements)
 size_t nb[4]; // Stride en cada dimensión (Number of Bytes)
 DataType type; // Tipo de dato
 void* data; // Puntero al payload

 // Para el grafo de computación
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

El stride nb[i] representa la distancia en bytes en la memoria entre elementos adyacentes en la dimensión i. Por ejemplo, si una matriz con un número de elementos $M \times N$ (FP32, 4 bytes por elemento) se almacena en orden Row-Major (prioridad de fila), los strides serían los siguientes:

nb[0] = 4 (bytes) : Movimiento en dirección de las columnas
nb[1] = $N \times 4$ (bytes) : Movimiento en dirección de las filas

Aprovechando esto, puedes lograr operaciones como “Transposición (Transpose)” y “Vista (View)” simplemente intercambiando los valores de los strides, sin implicar copias de memoria. Es sumamente elegante y rápido.

5. Construcción del Grafo de Computación (DAG) y Evaluación Perezosa

Al igual que PyTorch, nuestro motor de inferencia también adopta una Evaluación Perezosa (Lazy Evaluation), similar a “Define-by-Run”. Es decir, cuando se llama a una función de cálculo, no realiza el cálculo en ese momento, sino que solo construye un grafo (dependencias entre nodos).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b a menudo está transpuesta
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

El flujo del proceso de inferencia es el siguiente.

graph LR A["Definir Tensores"] --> B["Construir Grafo mediante Operaciones"] B --> C["Ordenamiento Topológico"] C --> D["Asignar Memoria para Salidas"] D --> E["Ejecutar Nodos en Orden"]

Al evaluar el grafo (forward pass), se utiliza el ordenamiento topológico para procesar los nodos en orden comenzando por aquellos sin dependencias. Si es solo inferencia, no es necesario mantener gradientes para backpropagation, por lo que la gestión de memoria es muy sencilla.

6. El núcleo de las matemáticas y la optimización: Producto de Matrices (GEMM)

Más del 90% de la carga computacional de la inferencia de IA se gasta en la multiplicación general de matrices (GEMM: General Matrix Multiply). Tanto el mecanismo de atención, que es el núcleo del modelo Transformer, como las redes feed-forward (FFN), son en última instancia enormes multiplicaciones de matrices.

El producto $C = A B$ (de tamaño $M \times N$) de dos matrices $A$ (tamaño $M \times K$) y $B$ (tamaño $K \times N$) se expresa matemáticamente de la siguiente manera.

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

Si se implementa ingenuamente usando un triple bucle, habrá frecuentes fallos de caché y no se logrará rendimiento.

6.1 Bloqueo de caché y optimización SIMD en la CPU

La estrategia básica para acelerar GEMM en la CPU es la siguiente:

Loop Tiling (Bloqueo de Caché): Divide las matrices en pequeños bloques que caben en las cachés L1/L2 para el cálculo.
Empaquetado de Datos: Reorganiza internamente los datos para que el patrón de acceso a la memoria sea contiguo.
Uso de SIMD: Usa comandos FMA (Fused Multiply-Add) como _mm512_fmadd_ps en AVX-512, manejando múltiples cálculos de multiplicación y suma en un solo ciclo de reloj.

A continuación se muestra un ejemplo de un Producto Punto (Dot Product) de vectores simplificado, utilizando C++ y SIMD Intrinsics.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


#include <immintrin.h> // Para instrucciones AVX

// Producto punto rápido FP32 usando AVX2
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // Procesar 8 elementos a la vez (256 bits = 32 bytes = 8 * 4 bytes)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // Instrucción FMA: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // Suma horizontal de los valores en el registro SIMD
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // Procesamiento del resto
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

Incluso con este pequeño ajuste, puedes obtener un aumento de velocidad de varias a decenas de veces en comparación con una implementación ingenua.

7. Superando la barrera del hardware: Integración de Backends CUDA y Metal

Aunque solo con la implementación pura en C++ funcionará de manera decente en la CPU, para ejecutar modelos enormes como LLMs a una velocidad práctica (por ejemplo: generar 20 tokens o más por segundo), la capacidad de cálculo en paralelo de la GPU es indispensable. Por lo tanto, introducimos una capa de abstracción de backend en nuestro motor.

7.1 Abstracción del Backend

Usamos el polimorfismo de C++ para permitir el intercambio del ejecutor (Executor) de las operaciones.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // Ejecución de diversas operaciones
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 Implementación del Backend de NVIDIA CUDA

Para aprovechar la GPU de NVIDIA, implementamos un backend usando la extensión C++ de CUDA. Aunque es posible escribir tus propios kernels, para la multiplicación de matrices, la mejor opción es usar “cuBLAS”, la mejor biblioteca proporcionada por NVIDIA.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // En CUDA, el orden por defecto es Column-Major, por lo que hay que tener cuidado con los parámetros
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // Se asume que src1 está transpuesta

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

Como las transferencias de datos (cudaMemcpy) entre la memoria de CUDA y la del host (CPU) son muy costosas, es vital diseñar un sistema que mantenga todos los pesos y tensores intermedios en la VRAM el mayor tiempo posible durante la inferencia.

7.3 Backend de Apple Silicon (Metal)

Recientemente, los chips M1/M2/M3 (Apple Silicon) de Mac son excelentes máquinas de inferencia de IA. La razón radica en su “Memoria Unificada”. Como la CPU y la GPU comparten la misma área de memoria, las transferencias de memoria de alto costo entre el host y el dispositivo a través de un bus PCIe, como en el caso de CUDA mencionado antes, son completamente innecesarias.

Para llamar a Metal desde C++, se usa Objective-C++ (archivos .mm) como puente, o la biblioteca metal-cpp. Escribiremos el kernel usando Compute Shaders de Metal (descrito en un archivo .metal de forma similar a C++).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Shader de Metal (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // Simplificado
 }
 C[row * n + col] = sum;
 }
}

En el entorno de Apple Silicon, también se proporciona una biblioteca optimizada para multiplicación de matrices llamada MPS (Metal Performance Shaders), por lo que usarla en un entorno de producción puede lograr velocidades de inferencia asombrosas.

8. Procesamiento específico del modelo Transformer: Attention y Caché KV

Los LLM de vanguardia, como LLaMA 2/3 y GPT, se basan en la arquitectura Transformer. Para implementar esto en C++, la construcción del “Scaled Dot-Product Attention” expresado en la siguiente fórmula es indispensable.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Además, en la generación de tokens autorregresiva (Autoregressive), es necesario mantener los resultados de cálculos de los tokens pasados (Key y Value). Esto se denomina “Caché KV (Key-Value Cache)”.

graph TD T["Token Actual"] --> Q["Consulta (Query)"] T --> K["Clave (Key)"] T --> V["Valor (Value)"] K --> KCache["Añadir a la Caché KV"] V --> VCache["Añadir a la Caché KV"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["Escalar (1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["Vector de Contexto"]

Para asignar memoria de la caché KV, asignamos en la arena de memoria por adelantado espacio suficiente para la longitud máxima de contexto (por ejemplo, 4096 u 8192 tokens) y lo operamos como un búfer circular (ring buffer). Esto evita las reasignaciones en cada paso de generación.

También, implementamos para la Codificación Posicional (Positional Encoding) el método “RoPE (Rotary Position Embedding)” que es el principal estándar reciente. Este es un método para incrustar información de posición como un vector de rotación en el espacio complejo, y la optimización de las llamadas a las funciones sin y cos en C++ (por ejemplo, mediante el uso de tablas de búsqueda) es clave para el rendimiento.

9. Optimización extrema mediante Cuantización de Modelos (Quantization)

Si cargas un modelo de gran escala (por ejemplo, un modelo LLaMA de 7 mil millones de parámetros) en FP32 (punto flotante de 32 bits), consumirá aproximadamente 28 GB de memoria (VRAM) solo para sus pesos. Además, al incluir la caché KV y los buffers de inferencia, puede sobrepasar fácilmente los 30 GB, haciendo que sea imposible de ejecutar en una GPU convencional de consumo.

Aquí es donde entra en juego la “Cuantización (Quantization)”. También es el verdadero valor del formato GGML.

La cuantización es una técnica que reduce intencionalmente la precisión de los pesos.

FP16 (16-bit): Reduce el tamaño a la mitad. Casi sin pérdida de precisión.
INT8 (8-bit): Un cuarto del tamaño. Pérdida menor de precisión.
INT4 (4-bit): Un octavo del tamaño. Usando técnicas propias de bloqueo y factores de escala, es posible hacer inferencias prácticas.

En el lado del motor de inferencia, se leen los pesos comprimidos como INT4 (o INT8) de la memoria, y justo después de cargarlos en los registros de la CPU o GPU, se descomprimen (Dequantize) a FP16 o FP32 para realizar los cálculos.

Sorprendentemente, resulta más rápido reducir la cantidad de datos que se leen desde la memoria, incluso si esto significa aumentar la cantidad de cálculos. Esto se debe a que, en el hardware moderno, el cuello de botella de la tarea de inferencia no es la “Capacidad de Cálculo (Compute Bound)” sino el “Ancho de Banda de la Memoria (Memory Bandwidth Bound)”. Con un motor implementado en C++ utilizando la cuantización INT4, es posible ejecutar localmente LLMs de manera fluida incluso en dispositivos como un MacBook Air con 8 GB de RAM unificada.

10. Ajuste de rendimiento: Arquitectura NUMA y Pool de Hilos

Cuando se realiza inferencia utilizando la CPU, el multiprocesamiento (multithreading) es obligatorio. Sin embargo, no es óptimo simplemente instanciar y lanzar muchas std::thread.

En los servidores multisocket modernos o en las CPU de gama alta como los Ryzen Threadripper, se adopta la arquitectura NUMA (Non-Uniform Memory Access). Acceder a la memoria que está físicamente cerca de un determinado núcleo de CPU (memoria local) es rápido, pero acceder a la memoria vinculada a otro procesador es extremadamente lento.

En un motor de inferencia avanzado en C++, se utilizan las siguientes técnicas:

Thread Pinning: Se fija cada hilo a un núcleo de CPU específico (configuración de Affinity) para evitar la pérdida de caché debido a los cambios de contexto.
Asignación consciente de NUMA: Asegura la memoria en el mismo nodo NUMA donde se encuentra el hilo que procesará los datos.
Pool de Hilos con Work-Stealing: Implementa un planificador eficiente que divide cada nodo del grafo de computación en pequeñas tareas, de manera que los hilos inactivos roben automáticamente tareas de otros para ejecutarlas.

Al dominar esto, es posible mantener el uso de la CPU pegado a cerca del 100% y lograr un rendimiento cercano al máximo teórico.

11. Conclusión: El placer de impulsar la IA con el “músculo” de C++

Python, sin duda, es conveniente. En investigación, desarrollo o creación de prototipos, no hay lenguaje que se le iguale en productividad. Sin embargo, en el momento en que se pasa a la fase de “hacer que el modelo ya construido funcione en el mundo real, de manera eficiente, en cualquier dispositivo”, es ahí donde C++ brilla.

Manipular los bytes de memoria directamente, presionar los registros al límite con instrucciones SIMD, luchar contra el ancho de banda de la VRAM de la GPU y ver cómo el motor de inferencia que has creado escupe textos (tokens) en un español natural en la consola, otorga un sentido de logro y una “alegría pura como ingeniero” que jamás obtendrías al solo llamar a model.generate() en un framework de Python.

Aunque la tecnología de la IA a menudo se considera una “Caja Negra” (Black Box), el simple hecho de programar cada detalle con tus propias manos en C++, desde los cálculos de tensores hasta la asignación de la memoria, te permite comprender profundamente los verdaderos mecanismos detrás de cómo los LLMs “piensan”.

Si tienes conocimientos básicos de C++ y un fuerte interés en la tecnología de IA actual, definitivamente deberías intentar construir tu propio motor de inferencia desde cero. El código fuente de GGML o llama.cpp será el mejor libro de texto en vivo que puedas tener.

¡Vamos, deshazte del pesado entorno de ejecución de Python y ejecuta la IA de vanguardia con los músculos de C++!

Cómo ajustar TinyLLaMA lo más rápido posible en un entorno local (On-Premises)

Fri, 11 Sep 2026 16:00:00 +0900

1. Introducción: ¿Por qué TinyLLaMA y entornos locales ahora?

La evolución de los modelos de lenguaje grande (LLM) avanza a un ritmo vertiginoso, y en consecuencia, el número de parámetros de los modelos sigue expandiéndose a escalas de cientos de miles de millones. Si bien los modelos gigantes como GPT-4 o Claude 3 ostentan un rendimiento inigualable, los costos computacionales de inferencia y entrenamiento, así como las preocupaciones sobre seguridad y privacidad de datos al usar APIs externas, se han convertido en grandes obstáculos para las empresas. Especialmente en tareas que manejan datos internos confidenciales o información personal, enviar datos a APIs de LLM públicas en la nube a menudo es inaceptable desde el punto de vista del cumplimiento normativo (como GDPR o APPI).

Aquí es donde los modelos de lenguaje pequeños (SLM: Small Language Models) y el funcionamiento local en entornos On-Premises están ganando protagonismo. Entre ellos, “TinyLLaMA” destaca por su tamaño compacto de tan solo 1.1B (1.100 millones) de parámetros, pero habiendo sido pre-entrenado con un inmenso conjunto de datos de aproximadamente 3 billones de tokens, ofreciendo un rendimiento asombroso en comparación con modelos de su misma clase.

En este artículo, proporcionaremos una guía completa para ajustar (fine-tune) TinyLLaMA en un entorno local (servidores locales o estaciones de trabajo) para tareas específicas de su empresa de la manera “más rápida y eficiente”. Cubriremos exhaustivamente desde los fundamentos matemáticos hasta las últimas tecnologías de optimización, incluyendo código de implementación específico en PyTorch.

2. Arquitectura y características de TinyLLaMA

TinyLLaMA sigue la arquitectura LLaMA (Large Language Model Meta AI) desarrollada por Meta. Aunque mantiene el número de parámetros en 1.1B, utiliza la misma pila tecnológica que LLaMA 2, lo que le otorga una compatibilidad de ecosistema extremadamente alta.

Componentes arquitectónicos principales

RMSNorm (Root Mean Square Normalization): Un método de normalización que omite la resta de la media del cálculo tradicional de LayerNorm, mejorando la eficiencia computacional. Mejora el rendimiento (throughput) manteniendo la estabilidad del entrenamiento.
Función de activación SwiGLU: En la red neuronal prealimentada (Feed Forward Network - FFN), adopta SwiGLU en lugar de las tradicionales ReLU o GELU. Matemáticamente, esto se expresa como: $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ Aquí, $\otimes$ representa el producto elemento a elemento (producto de Hadamard), y la función Swish es $\text{Swish}(z) = z \cdot \sigma(\beta z)$. Esto mejora significativamente la capacidad de representación.
RoPE (Rotary Position Embedding): Un método que combina las ventajas de la codificación de posición absoluta y la codificación de posición relativa. Posee un alto rendimiento de generalización incluso cuando se expande la longitud de la secuencia.
Grouped Query Attention (GQA): Un enfoque intermedio entre Multi-Head Attention (MHA) y Multi-Query Attention (MQA) que, al agrupar los cabezales (heads) de las claves (keys) y valores (values), ahorra ancho de banda de memoria y mejora drásticamente la velocidad de inferencia.

El siguiente diagrama Mermaid muestra el flujo de datos general de TinyLLaMA y la estructura del bloque Transformer.

graph TD A["Texto de Entrada"] --> B["Tokenizador (BPE)"] B --> C["Capa de Incrustación (Embedding)"] C --> D["Bloques Transformer (x22 Capas para TinyLLaMA)"] D --> E["RMSNorm (Final)"] E --> F["Proyección Lineal (Tamaño del Vocabulario)"] F --> G["Probabilidades de Salida (Softmax)"] subgraph "Anatomía del Bloque Transformer" D1["Estado Oculto de Entrada"] --> D2["RMSNorm"] D2 --> D3["Atención de Consulta Agrupada (GQA)"] D3 --> D4["Suma Residual"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU FFN"] D6 --> D7["Suma Residual"] D7 --> D8["Salida a la Siguiente Capa"] D1 -.-> D4 D4 -.-> D7 end

3. El avance del ajuste fino: LoRA y QLoRA

Realizar un ajuste fino (fine-tuning) con todos los parámetros en un entorno local consume decenas de GB de VRAM (memoria de video) para mantener el estado del optimizador y los gradientes, incluso con un modelo de 1.1B. Para entrenar eficientemente con recursos limitados, es imprescindible usar “LoRA”, una técnica de PEFT (Parameter-Efficient Fine-Tuning), y su extensión cuantizada, “QLoRA”.

3.1 Fundamentos matemáticos de LoRA (Low-Rank Adaptation)

LoRA es una técnica que fija (congela) las matrices de peso pre-entrenadas y aproxima la cantidad de actualización de esos pesos ($\Delta W$) como el producto de dos matrices pequeñas de bajo rango.

Supongamos que los pesos pre-entrenados son $W_0 \in \mathbb{R}^{d \times k}$. En un fine-tuning completo, actualizaríamos el propio $W_0$ a $W_0 + \Delta W$, pero en LoRA descomponemos la matriz de actualización $\Delta W$ de la siguiente manera:

$$ \Delta W = B \times A $$

Aquí, $B \in \mathbb{R}^{d \times r}$ y $A \in \mathbb{R}^{r \times k}$, donde $r$ es un hiperparámetro llamado Rango (Rank) y es un valor muy pequeño (usualmente 8, 16, 32, etc.) que satisface $r \ll \min(d, k)$.

El cálculo del paso hacia adelante (forward pass) es el siguiente:

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

En el estado inicial, la matriz $A$ se inicializa aleatoriamente con una distribución normal (distribución gaussiana), y la matriz $B$ se inicializa como una matriz cero. Por lo tanto, $\Delta W$ es cero al inicio del entrenamiento, lo que permite comenzar a entrenar manteniendo completamente la salida del modelo base.

graph LR X["Vector de Entrada x"] --> W0["Peso Pre-entrenado Congelado (W_0)"] X --> A["Matriz LoRA Entrenable A (r x k)"] A --> B["Matriz LoRA Entrenable B (d x r)"] W0 --> Add["Suma de Vectores"] B --> Add Add --> Y["Vector de Salida h"]

3.2 La innovación de QLoRA (Quantized LoRA)

QLoRA lleva el enfoque de LoRA un paso más allá cuantizando el modelo base $W_0$ a precisión de 4 bits (NormalFloat 4, NF4) antes de cargarlo en la memoria. Esto reduce drásticamente el consumo de VRAM.

QLoRA incorpora tres tecnologías importantes:

Cuantización NormalFloat de 4 bits (NF4): Un tipo de datos teóricamente óptimo para pesos que siguen una distribución normal.
Doble Cuantización (Double Quantization): Cuantiza las constantes de cuantización (factores de escala) mismas, ahorrando aún más memoria.
Paged Optimizers: Utiliza la función de memoria unificada de NVIDIA para trasladar temporalmente el estado del optimizador a la RAM de la CPU cuando la VRAM escasea.

Como resultado, el ajuste que normalmente requiere 16GB a 24GB de VRAM se puede ejecutar con holgura incluso en GPUs de nivel de consumidor (como RTX 3060 de 12GB o RTX 4070).

4. Requisitos de hardware y configuración en entornos locales

Los requisitos de hardware al ajustar TinyLLaMA (1.1B) con QLoRA se mantienen muy bajos.

Especificaciones de hardware recomendadas

GPU: NVIDIA RTX 3060 (12GB), RTX 3090/4090 (24GB), o NVIDIA A10G/A100, etc. Funcionará con al menos 8GB de VRAM, pero se recomiendan 12GB o más para aumentar el tamaño del lote (batch size).
CPU: Una CPU moderna de 8 núcleos o más (Intel Core i7/i9, AMD Ryzen 7/9).
RAM: 32GB o más (importante como destino de paginación desde la VRAM cuando se usan Paged Optimizers).
Almacenamiento: SSD NVMe (para acelerar la carga de conjuntos de datos y guardar el modelo).

Configuración del entorno de software

Este es un procedimiento de configuración asumiendo un entorno Ubuntu 22.04 LTS. Utilizaremos Python 3.10 o superior.

1
2
3
4
5
6
7
8
9


# Creación y activación de un entorno virtual
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# Instalación de PyTorch (para CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Instalación de bibliotecas relacionadas con Transformers
pip install transformers datasets peft trl accelerate bitsandbytes

5. Técnicas de optimización para el ajuste más rápido

Para completar el ajuste de la manera “más rápida” posible, no basta con ejecutar un script; es necesario combinar las siguientes técnicas de optimización.

5.1 Flash Attention 2

El mecanismo de Atención estándar tiene una complejidad computacional temporal y espacial de $O(N^2)$ con respecto a la longitud de la secuencia $N$. Flash Attention 2 optimiza el acceso a la memoria entre la SRAM de la GPU y la HBM (High Bandwidth Memory), resolviendo los cuellos de botella de entrada/salida (IO) sin reducir la cantidad de cálculos, lo que multiplica la velocidad de entrenamiento por varias veces y reduce drásticamente el consumo de memoria.

5.2 Gradient Checkpointing (Puntos de control de gradientes)

En lugar de guardar en la VRAM todas las activaciones intermedias calculadas en el paso hacia adelante, este método guarda solo algunas y recalcula las necesarias durante el paso hacia atrás (backward pass). Aunque el tiempo de cálculo aumenta aproximadamente un 20%, el consumo de memoria se reduce drásticamente. Esto permite establecer un tamaño de lote mayor, mejorando el rendimiento (throughput) general en consecuencia.

5.3 Entrenamiento de Precisión Mixta (Mixed Precision Training) y Bfloat16

Para maximizar el uso de los Tensor Cores de la GPU, los cálculos durante el entrenamiento se realizan en bfloat16 (Brain Floating Point). A diferencia de float16, su longitud de bits para el exponente es la misma que en float32, por lo que el riesgo de desbordamiento (overflow o underflow) es extremadamente bajo y el entrenamiento es estable.

6. Práctica: Código de ajuste fino QLoRA para TinyLLaMA

Ahora explicaremos un script de PyTorch para el ajuste más rápido que incorpora todas las optimizaciones anteriores. Aquí utilizaremos el SFTTrainer de la biblioteca trl (Transformer Reinforcement Learning) de Hugging Face.

6.1 Preparación del conjunto de datos y carga del modelo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. Especificar el modelo y el tokenizador
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. Configuración de cuantización a 4 bits para QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # Realizar cálculos en bfloat16
)

# 3. Cargar el modelo (Habilitar Flash Attention 2)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # La clave para la máxima velocidad
)

# 4. Cargar el tokenizador
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # Configurar en 'right' para evitar bugs durante el entrenamiento fp16/bf16

6.2 Aplicación del adaptador LoRA y formato del conjunto de datos

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# 5. Preparación para entrenamiento en k bits y habilitación del Gradient Checkpointing
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. Configuración de LoRA
peft_config = LoraConfig(
 r=16, # Rango
 lora_alpha=32, # Factor de escala
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # El rendimiento mejora al apuntar a todas las capas Lineales
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Ejemplo de salida: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. Cargar el conjunto de datos (Aquí usamos un conjunto de datos de instrucciones en japonés como ejemplo)
# En la práctica, cargarías archivos JSONL privados locales, etc.
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 Formatea las cadenas de texto para que coincidan con el formato ChatML o plantillas de prompts
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 Ejecución del entrenamiento

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


# 8. Configuración de los argumentos de entrenamiento
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # Aumentar si hay VRAM disponible
 gradient_accumulation_steps=2, # Tamaño de lote efectivo = 8 * 2 = 16
 optim="paged_adamw_32bit", # Ahorro de VRAM gracias a Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # Entrenamiento de precisión mixta (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 pasos para pruebas. En producción, especificar el número de épocas
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. Iniciar el entrenamiento con SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # Ajustar según la longitud de entrada esperada
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. Guardar el adaptador LoRA
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

7. Evaluación de rendimiento y solución de problemas

Estos son los problemas más comunes que se enfrentan al entrenar en un entorno local y sus soluciones.

Ocurre un OOM (Out Of Memory):
- Reducir per_device_train_batch_size a 1.
- Aumentar gradient_accumulation_steps para mantener el tamaño del lote efectivo.
- Reducir max_seq_length de 2048 a 1024 o 512.
La pérdida (Loss) no disminuye o diverge:
- La tasa de aprendizaje (learning_rate) podría ser demasiado alta. Intente reducirla de 2e-4 a algo como 5e-5.
- Si está usando Float16 en lugar de Bfloat16, es posible que esté ocurriendo un underflow en los gradientes. Asegúrese de que bf16=True esté configurado.
Se generan cadenas de texto extrañas durante la inferencia:
- Verifique que padding_side="right" esté configurado correctamente. Además, es necesario asegurarse de que el formato del conjunto de datos (tokens especiales como <|im_start|>) coincida con el utilizado durante el pre-entrenamiento del modelo base.

8. Despliegue del modelo después del ajuste (Deployment)

Una vez completado el ajuste, lo que se guarda no es “todo el modelo base”, sino solo el “Adaptador LoRA (pesos diferenciales)” de unos pocos MB a decenas de MB. Para realizar inferencias a alta velocidad, es necesario fusionar (merge) estos pesos LoRA en el modelo base original y exportarlo como un modelo único.

Script de fusión de modelos

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# Cargar el modelo y el adaptador en FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# Fusionar los pesos y guardar
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

Inicio de un servidor de inferencia ultrarrápido con vLLM

Al desplegar en un entorno local, para maximizar la velocidad de inferencia (Tokens por segundo), recomendamos encarecidamente usar vLLM o TGI (Text Generation Inference) en lugar del pipeline estándar de Hugging Face. vLLM utiliza la tecnología PagedAttention para evitar la fragmentación de la memoria de la GPU, mejorando drásticamente la capacidad de procesar solicitudes concurrentes.

El siguiente diagrama Mermaid muestra el pipeline desde el entrenamiento hasta el despliegue del servidor de inferencia.

graph TD A["Datos Privados en Crudo"] --> B["Preprocesamiento y Formateo (JSONL)"] B --> C["Ajuste Fino QLoRA (SFTTrainer)"] C --> D["Pesos del Adaptador LoRA (.safetensors)"] D --> E["Fusionar con Base TinyLLaMA 1.1B"] E --> F["Modelo Fusionado"] F --> G["Desplegar vía Servidor vLLM"] G --> H["Endpoint de API / UI (Ej. Chatbot)"]

Iniciar un servidor API con vLLM se completa con el siguiente comando:

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

Con esto, se establecerá un endpoint compatible con la API de OpenAI en su entorno local, permitiéndole aprovechar la IA local de manera segura y rápida.

9. Conclusión

En este artículo, explicamos el método para realizar un ajuste fino de la manera más rápida y eficiente en memoria en un entorno local, centrándonos en “TinyLLaMA”, que es liviano con 1.1B de parámetros pero de alto rendimiento.

Gracias a LoRA / QLoRA, es posible realizar un ajuste fino auténtico de LLM incluso en GPUs de consumidor.
Al aprovechar Flash Attention 2 y Gradient Checkpointing, el tiempo de entrenamiento y el consumo de VRAM se optimizan al límite.
El despliegue utilizando vLLM logra un alto rendimiento (throughput) incluso en entornos de producción.

Operar un LLM localmente en entornos On-Premises no solo protege la confidencialidad de los datos, sino que también se convierte en su arma más poderosa para construir IA especializada para dominios específicos (legal, médico, regulaciones internas de la empresa, etc.) a bajo costo. Por favor, utilice esta guía como referencia para entrenar su propio TinyLLaMA personalizado.

¿Cómo deberían sobrevivir los programadores en la era de la IA?

Fri, 11 Sep 2026 15:00:00 +0900

¿Cómo deberían sobrevivir los programadores en la era de la IA? El fin de la codificación y el amanecer de una nueva ingeniería

En la actualidad, en 2026, el campo del desarrollo de software se encuentra en un período de cambio sin precedentes. Hasta hace unos pocos años, el concepto de “la IA escribe código” se limitaba a su papel como “herramienta auxiliar” para los programadores, como la generación de código boilerplate (código repetitivo) y el autocompletado de funciones en el mejor de los casos. Sin embargo, con la asombrosa evolución de los grandes modelos de lenguaje (LLM), la situación ha dado un vuelco radical. La IA moderna no es simplemente una “máquina de escribir inteligente”, sino que se ha transformado en un “ingeniero junior autónomo” con la capacidad de ensamblar instantánea y autónomamente sistemas completos, desde el frontend hasta la lógica del backend, el diseño del esquema de la base de datos e incluso la construcción de pipelines de CI/CD, con solo proporcionarle un documento de definición de requisitos.

En una era así, ¿cómo deberíamos sobrevivir nosotros los “programadores” e “ingenieros de software”? A medida que el valor económico del acto mismo de “escribir código” se deflacta rápidamente, los “codificadores” que simplemente conocen la sintaxis (gramática) de un lenguaje de programación específico y están familiarizados con las API de un framework en particular están siendo rápidamente eliminados del mercado.

En este artículo, analizaremos con extremo detalle las estrategias de supervivencia para los programadores en la era de la IA desde perspectivas técnicas, matemáticas y filosóficas. Esto no es solo una teoría sobre la carrera profesional, sino una redefinición de la disciplina de la ingeniería de software en sí misma.

1. La historia de la abstracción (Abstraction) y la redefinición de la “programación”

Al repasar la historia de la ingeniería de software, nos damos cuenta de que siempre ha sido una historia de “abstracción (Abstraction)”. Siempre hemos construido capas para describir sistemas más complejos en un lenguaje más cercano al humano.

Los primeros científicos de la computación utilizaban tarjetas perforadas para manipular directamente los interruptores del hardware físico, dando instrucciones a las computadoras en código máquina (secuencias de 0 y 1). Más tarde, apareció el lenguaje ensamblador, que permitió operar el hardware con mnemónicos que los humanos podían entender fácilmente. A medida que avanzaba la época, surgieron lenguajes de alto nivel como C y Fortran, que lograron encapsular los detalles complejos del hardware, como la gestión de memoria y los registros de la CPU. Posteriormente, con los lenguajes modernos que aparecieron, como Java, Python, Ruby y TypeScript, los programadores pudieron concentrarse más en “qué queremos que haga la computadora (What)” en lugar de en “cómo hacer que la computadora funcione (How)”.

La aparición de la IA (LLM) es el cambio de paradigma más reciente y más grande en esta historia de abstracción. Si la evolución de los lenguajes de programación fue la “ocultación del hardware”, la evolución de los LLM es la “ocultación de la sintaxis (gramática)”.

graph TD A["Código Máquina / Tarjetas Perforadas (1940s)"] --> B["Lenguaje Ensamblador (1950s)"] B --> C["Lenguajes Compilados de Alto Nivel (1970s)"] C --> D["Lenguajes Gestionados / de Scripting (1990s)"] D --> E["Lenguaje Natural a través de LLMs (2020s)"] E --> F["Agentes de IA Autónomos (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

La era en la que los desarrolladores manipulaban punteros preocupándose por las fugas de memoria o escribían cientos de líneas de código repetitivo para el procesamiento de análisis de JSON ha terminado. El estándar de “programación” en 2026 es definir sistemas utilizando el lenguaje natural (japonés, inglés, español, etc.), el lenguaje con el nivel más alto de abstracción para la humanidad.

2. Modelo matemático de la productividad: Surfeando la ola del crecimiento exponencial

Evaluemos cuantitativamente el aumento de productividad que aporta la IA utilizando un modelo matemático. La productividad individual $P_{traditional}$ en el desarrollo de software tradicional podría modelarse como una combinación lineal del nivel de habilidad individual $S$, la experiencia en el dominio $E$ y la eficiencia de las herramientas $T$.

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

Sin embargo, en el desarrollo moderno impulsado por IA, la capacidad de la IA $A(t)$ actúa como un “poderoso multiplicador (Multiplier)” que amplifica la capacidad humana. Dado que las capacidades de la IA crecen exponencialmente (la versión de IA de la Ley de Moore) a lo largo del tiempo $t$, la productividad en la era de la IA $P_{AI}(t)$ se puede expresar mediante la siguiente ecuación:

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

Aquí, cada variable significa lo siguiente:

$\alpha$: Coeficiente base de productividad humana
$S_{core}$: Las “habilidades centrales humanas” no reemplazables por la IA (diseño de arquitectura, comprensión de requisitos de negocio, juicio ético, etc.)
$A(t)$: Capacidad absoluta de los modelos de IA (recuento de parámetros, ventana de contexto, capacidad de razonamiento) en el momento $t$
$\beta$: Coeficiente que indica la eficacia con la que se pueden aprovechar las herramientas de IA (calidad de la ingeniería de prompts o sofisticación de los flujos de trabajo colaborativos con la IA)

La visión clave derivada de esta fórmula es que en un mundo donde $A(t)$ aumenta exponencialmente, el impacto de las habilidades tradicionales, como la velocidad de escritura pura o la memorización de un lenguaje específico, en la productividad general se vuelve minúsculo. En cambio, el coeficiente $\beta$ para aprovechar el crecimiento exponencial de la IA, y $S_{core}$, el área que la IA no puede cubrir, se convierten en los factores dominantes que determinan el valor de mercado de un ingeniero.

3. Probabilidad de automatización de tareas (Probability of Automation)

Entonces, ¿qué tipo de tareas se automatizarán y qué tipo de tareas quedarán en manos de los humanos? La probabilidad $P_{auto}(T)$ de que una tarea determinada $T$ sea completamente automatizada por IA se puede formular de la siguiente manera:

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$: Previsibilidad de la tarea (cuántos patrones existen en los datos históricos)
$\text{Complexity}(T)$: Complejidad de la tarea
$\text{Context Dependency}(T)$: La fuerza del “contexto implícito (conocimiento específico del dominio o relaciones humanas)” del que depende la tarea
$\lambda$: Tasa de progreso tecnológico de la IA

Las tareas que son altamente predecibles y poco dependientes del contexto, como escribir el procesamiento de enrutamiento de una API o crear una pantalla CRUD simple, tienen un $P_{auto} \approx 1$ y estarán casi completamente automatizadas. Por otro lado, las tareas con una dependencia del contexto extremadamente alta, como “¿cómo integramos de manera segura los sistemas heredados existentes con los nuevos microservicios?” o “¿cómo diseñamos un flujo de autenticación que satisfaga las demandas del departamento legal sin comprometer la experiencia del usuario?”, son difíciles de automatizar.

4. Retorno de la sintaxis (gramática) a la arquitectura (estructura)

Separar claramente en qué es buena la IA y en qué son buenos los humanos es un requisito absoluto para la supervivencia.

graph LR Sub1["Dominios de Excelencia de la IA"] Sub2["Dominios de Excelencia Humanos"] A["Generación de Código a partir de Especificaciones"] --> Sub1 B["Corrección de Errores de Sintaxis y Bugs"] --> Sub1 C["Generación de Boilerplate / Pruebas"] --> Sub1 D["Análisis de Logs y Reconocimiento de Patrones"] --> Sub1 E["Diseño de Arquitectura de Sistemas"] --> Sub2 F["Resolución de Requisitos Ambiguos"] --> Sub2 G["Negociación entre Equipos"] --> Sub2 H["Juicio Ético / Responsabilidad"] --> Sub2

La IA supera a los humanos en la “optimización local”. Los humanos no tienen ninguna posibilidad contra la velocidad y precisión con la que se escribe una sola función, una sola clase o un solo módulo. Sin embargo, la IA es muy vulnerable a la “optimización global” y al “contexto faltante (Missing Context)”.

Los programadores del futuro deben cambiar su papel de “trabajadores que escriben código” a “arquitectos que orquestan innumerables componentes generados por IA”. Tener una visión general del sistema completo, dónde trazar los límites de los microservicios, cómo resolver el compromiso entre disponibilidad y consistencia en el Teorema CAP para adaptarlo al contexto del negocio, y cómo controlar la deuda técnica. Estos son trabajos intelectuales de alto nivel que solo pueden ser realizados por humanos que comprenden el panorama general y los objetivos del negocio.

5. La definición de requisitos es la “verdadera ingeniería de prompts”

El término “ingeniería de prompts”, que escuchamos a menudo últimamente, se malinterpreta con frecuencia como “un truco para engañar a la IA y obtener el resultado deseado”. Sin embargo, la esencia de la ingeniería de prompts en el desarrollo de software es, sin lugar a dudas, la “ingeniería de requisitos avanzada (Requirements Engineering)”.

Para dar instrucciones a la IA en lenguaje natural y hacer que genere el software deseado, los siguientes elementos deben ser estrictamente articulados:

Propósito (Why): ¿Por qué se necesita esta característica? ¿Cuál es el valor empresarial?
Restricciones (Constraints): Requisitos de rendimiento (latencia, rendimiento), requisitos de seguridad, restricciones de costos.
Casos Extremos (Edge Cases): Procesamiento alternativo (fallback) para cuando el usuario proporciona una entrada inesperada.
Interfaces (Interfaces): Especificaciones de integración con los sistemas existentes.

Las instrucciones vagas (prompts) solo generarán sistemas vagos y frágiles. La capacidad de escuchar profundamente para descubrir “lo que el cliente realmente quería”, organizar requisitos contradictorios y crear especificaciones lógicamente consistentes (prompts). Esta es la “habilidad de codificación” más poderosa en la era de la IA. Los programadores pasarán cada vez más tiempo enfrentándose a archivos de Notion o Markdown en lugar de editores de código, describiendo con precisión cómo debería ser el sistema mediante texto.

6. La ventaja abrumadora del conocimiento del dominio (Domain Knowledge)

Dado que la IA se ha entrenado en código fuente abierto y documentos públicos de todo el mundo, está bien versada en tecnologías y algoritmos web generales. Sin embargo, hay datos a los que la IA no puede acceder. Esas son las “reglas de negocio específicas de tu empresa” y el “conocimiento del dominio profundamente arraigado en una industria específica (médica, financiera, manufacturera, etc.)”.

Por ejemplo, supongamos que estás desarrollando un sistema de historia clínica electrónica en una startup médica. La IA sabe “cómo crear una interfaz de usuario tabular en React” y “la estructura de datos general de HL7 FHIR”. Sin embargo, no ha aprendido el conocimiento tácito de “en un departamento médico específico del Hospital A, en qué orden ven los médicos los datos de los pacientes, y qué tipo de interfaz de usuario minimizaría el riesgo de errores médicos”.

En un mundo donde la tecnología misma se mercantiliza (se convierte en un bien de consumo común), el verdadero valor de los ingenieros nace en la intersección de la “tecnología” y el “dominio de negocio”. En lugar de competir solo con la destreza técnica, los individuos que posean una profunda experiencia en un dominio específico, como la medicina, las finanzas, la logística o el entretenimiento, y que puedan resolver los problemas de ese dominio utilizando la poderosa herramienta de la IA, liderarán el mercado del futuro.

7. El “Problema del Tranvía” en el desarrollo de software: ¿Quién asume la responsabilidad?

A medida que aumenta nuestra dependencia de la IA, nos enfrentamos a graves problemas filosóficos y éticos. Este es el problema de “dónde recae la responsabilidad” en la ingeniería de software.

Si el código generado de forma autónoma por la IA causa un error grave en un entorno de producción, lo que resulta en millones de dólares en pérdidas para una empresa, o si causa un mal funcionamiento en un sistema médico que afecta vidas humanas, ¿quién asume la responsabilidad? ¿La empresa que desarrolló el modelo de IA? ¿O el ingeniero que ingresó el prompt? No se puede “despedir” ni “arrestar” a la IA.

No importa cuánto avance la tecnología, el papel de los “humanos” como el sujeto que asume la “responsabilidad legal y ética (Accountability)” por el impacto que los sistemas tienen en la sociedad no desaparecerá. De hecho, cuanto más se convierta el proceso de generación de código en una caja negra, mayor será la pesada responsabilidad de los humanos como “aprobadores finales (Approvers)” y “supervisores (Supervisors)” de los sistemas.

Auditar si la arquitectura y el código propuestos por la IA cumplen con los estándares de seguridad, no tienen problemas éticos (están libres de sesgos) y cumplen con las normativas, y luego dar la luz verde final. El acto de “asumir la responsabilidad” en sí mismo se convierte en una parte importante del trabajo del ingeniero.

8. Programación en parejas con IA y gestión de la carga cognitiva (Cognitive Load)

A medida que trabajamos junto a la IA, la naturaleza de la “carga cognitiva (Cognitive Load)” humana también está cambiando. La carga cognitiva al escribir código desde cero es completamente diferente de la carga cognitiva al “leer y revisar” cientos de líneas de código desconocido generado por la IA.

Según la teoría de la carga cognitiva en psicología, cuando se procesa información compleja que no coincide con los esquemas existentes (estructuras de conocimiento en la mente), la memoria de trabajo humana se agota rápidamente. El código generado por IA a veces contiene optimizaciones avanzadas que a un humano no se le ocurrirían, mientras que otras veces contiene “alucinaciones (hallucinations)” que ignoran el contexto.

Para evitar esto, es necesario sistematizar el proceso de revisión de la IA.

sequenceDiagram participant H as "Ingeniero Humano (Arquitecto)" participant A as "Agente de IA" participant S as "CI/CD & Pruebas" H->>A: "Definir requisitos y restricciones estrictas" A->>H: "Proponer Arquitectura y Código Inicial" Note over H,A: Fase de Revisión: Alta Carga Cognitiva H->>A: "Criticar opciones de diseño, solicitar refactorización" A->>S: "Generar Código Final y Hacer Push" S-->>H: "Resultados de Pruebas Automatizadas y Análisis Estático" H->>H: "Aprobación Final y Asunción de Responsabilidad"

Los humanos necesitan perfeccionar al máximo la habilidad de “lectura rápida y detección instantánea de fallas lógicas (Code Reading & Auditing)” incluso más que la habilidad de “escribir”. La importancia del Desarrollo Guiado por Pruebas (TDD) es aún mayor en la era de la IA. El enfoque principal será que un humano u otra IA escriba código de prueba estricto antes de dejar que la IA escriba el código, y luego haga que la IA corrija el código hasta que pase las pruebas.

9. Estrategia de supervivencia concreta: Qué aprender a partir de mañana

Basado en el análisis realizado hasta ahora, presento un plan de acción concreto para que los programadores sobrevivan a la era de la IA.

Reaprender a fondo los “fundamentos” de la tecnología: Puedes dejar cómo usar frameworks a la IA. Sin embargo, un profundo conocimiento de cómo funcionan los sistemas operativos, los protocolos de red (TCP/IP, HTTP/3), la estructura interna de las bases de datos (B-Tree, niveles de aislamiento de transacciones), las estructuras de datos y algoritmos es absolutamente necesario. Para juzgar si el resultado de la IA es correcto, es indispensable una base sólida en ciencias de la computación.
Dominar la arquitectura en la nube y los sistemas distribuidos: Concéntrate en cómo combinar recursos en la nube como AWS, GCP y Azure para construir sistemas escalables, en lugar de código individual. Comprende el concepto de IaC (Infrastructure as Code) como Terraform y cultiva la capacidad de diseñar todo el sistema como código.
Conviértete en un experto en tu dominio de negocio: Aprende profundamente el modelo de negocio, las regulaciones legales y la psicología del comportamiento del usuario de la industria a la que perteneces. Ve más allá de los límites de un ingeniero y ten una perspectiva más cercana a la de un Product Manager (PM).
Perfecciona las habilidades de comunicación y facilitación: El proceso de resolver la “ambigüedad” entre humanos y lograr consensos no puede ser reemplazado por la IA. Las habilidades blandas de interactuar con las partes interesadas y descubrir los verdaderos problemas serán las habilidades más valiosas.
Usa la IA al máximo como un “colega”: En lugar de temer a la evolución de las herramientas de IA, utilízalas como tu arma más poderosa. Utiliza rutinariamente los últimos LLMs y agentes de codificación de IA para acumular el “conocimiento tácito” de dónde falla la IA y cómo ajustar los prompts para extraer el máximo rendimiento.

Conclusión: No temas, surfea la ola

La automatización de la programación por parte de la IA no significa la “muerte” de la profesión de programador. Más bien, es un “Renacimiento” que nos libera del “trabajo no esencial” en el desarrollo de software, como la corrección de errores tipográficos, la solución de problemas de configuración del entorno y la escritura de aburrido código repetitivo (boilerplate).

A lo largo de la historia, cuando apareció el telar automático o cuando apareció el software de hojas de cálculo (Excel), se extendió el pesimismo de que los trabajos desaparecerían. Sin embargo, la realidad es que a medida que la productividad mejoró drásticamente, se creó nueva demanda y nacieron trabajos más sofisticados. Lo mismo sucederá en el mundo del software. A medida que se vuelva posible “construir sistemas a bajo costo”, el software penetrará en todas las áreas que antes no estaban informatizadas debido a los altos costos, y los problemas (What) que los ingenieros tendrán que resolver se expandirán infinitamente.

A nosotros, los programadores, se nos da ahora la oportunidad de evolucionar de artesanos que escriben código a “directores de orquesta” que comandan la poderosa inteligencia de la IA. En lugar de quedarnos en la orilla temerosos de la ola tecnológica, vamos a montarla rápidamente y zarpar hacia un viaje para crear sistemas más grandes y valiosos. La era de la IA es exactamente la era en la que comienza la “ingeniería” en su verdadero sentido.

Guía de desarrollo de modelos de IA a pequeña escala (como TinyLLaMA) con C++

Fri, 11 Sep 2026 14:00:00 +0900

Guía de desarrollo de modelos de IA a pequeña escala (como TinyLLaMA) con C++

En los últimos años, el interés por ejecutar grandes modelos de lenguaje (LLM) en entornos locales ha crecido rápidamente. Especialmente, los modelos pequeños como TinyLLaMA (1.1B parámetros) pueden realizar inferencias a velocidades prácticas incluso en dispositivos periféricos (edge devices) con recursos limitados o computadoras portátiles comunes (incluyendo entornos Windows). Mientras que el desarrollo con Python y PyTorch es la corriente principal, cuando se busca el rendimiento máximo y la eficiencia de memoria, la combinación de C++ y “ggml”, una biblioteca de tensores basada en C, se ha convertido en el estándar de facto.

En este artículo, explicaremos en gran detalle el proceso de desarrollo para construir un motor de inferencia desde cero (o comprender profundamente la estructura interna del existente llama.cpp) para cargar TinyLLaMA y generar texto usando C++.

1. ¿Por qué C++ y ggml?

En la fase de entrenamiento de IA, Python tiene una ventaja abrumadora debido a su flexibilidad y rico ecosistema. Sin embargo, en las fases de despliegue e “Inferencia”, C++ se convierte en una opción poderosa por las siguientes razones:

Reducción de sobrecarga: Se puede eliminar por completo la sobrecarga del entorno de ejecución y del Global Interpreter Lock (GIL) de Python.
Eficiencia de memoria y asignación por arenas: Al poder controlar manualmente la asignación y liberación de memoria, se evitan los picos impredecibles causados por el recolector de basura.
Acceso directo al hardware: Se pueden invocar directamente funciones intrínsecas SIMD como AVX-512, AVX2 y ARM NEON para maximizar la capacidad de procesamiento de la CPU.
Eliminación de dependencias: ggml es una biblioteca C/C++ sin dependencias (Zero dependencies), y se puede compilar fácilmente incluso en un entorno MSVC en Windows siempre que haya un compilador.

2. Visión general de la arquitectura

El flujo completo del pipeline de inferencia se muestra en el siguiente diagrama Mermaid. Es un proceso continuo que comienza con el texto de entrada del usuario hasta que se genera el siguiente token final.

graph TD A["Texto de entrada del usuario"] --> B["Tokenizador BPE"] B --> C["Matriz de IDs de tokens"] C --> D["Búsqueda en la capa de incrustación"] D --> E["Bloques Transformer"] E --> F["RMSNorm"] F --> G["Capa LM Head"] G --> H["Matriz de Logits"] H --> I["Módulo muestreador"] I --> J["Siguiente token ID"] J --> K["Detokenizador"] K --> L["Fragmento de texto de salida"] J -.-> |"Añadir al contexto"| C

Al ser un modelo autorregresivo, el token de salida se añade de nuevo al contexto y circula como entrada para la predicción del siguiente token (la parte punteada del diagrama).

3. Formato del modelo y mapeo de memoria (mmap)

La mayor barrera al manejar los pesos de una red neuronal gigante es la E/S del disco y el consumo de memoria. En la implementación de C++, esto se resuelve mediante el mapeo de memoria (mmap).

3.1 Cómo funciona el mapeo de memoria y su implementación en Windows

Al utilizar mmap, el contenido del archivo se puede mapear directamente en el espacio de memoria virtual del proceso.

Copia cero (Zero-copy): Los datos se cargan directamente desde el disco a la caché de páginas del kernel, sin que ocurran copias adicionales al espacio de usuario.
Carga bajo demanda (Page Fault): En el instante exacto en que la CPU accede a esa dirección de memoria, se produce un fallo de página y solo el fragmento necesario (típicamente 4KB) se carga en la memoria física.

En un entorno Windows, en lugar del mmap de POSIX, se utilizan las API Win32 CreateFileMapping y MapViewOfFile.

sequenceDiagram participant OS["Sistema Operativo Windows"] participant RAM["Memoria Física"] participant App["Aplicación C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Puntero de dirección de memoria virtual" App->>App: "Leer datos del tensor en el puntero" OS->>RAM: "Fallo de página / Cargar página desde el disco" RAM-->>App: "Datos listos para cálculo SIMD"

3.2 Estructura binaria del formato GGUF

GGUF (GPT-Generated Unified Format), convertido a partir de formatos como .safetensors de Hugging Face, es el formato definitivo para la inferencia. Tiene un diseño binario estricto como el siguiente:

Bytes Mágicos: 0x46554747 (GGUF).
Versión: Número de versión del formato.
Conteo de tensores y metadatos: Número de tensores y pares clave-valor de metadatos.
Metadatos (Pares clave-valor): Claves con prefijo de longitud de cadena y valores tipados.
Información del tensor: Nombre de cada tensor, número de dimensiones, tipo de datos (FP16, Q4_K, etc.) y posición de desplazamiento (offset) en el archivo.
Relleno (Padding): Relleno insertado para que los datos del tensor se alineen en límites específicos (generalmente 32 o 64 bytes). Es indispensable para un acceso a memoria rápido con instrucciones SIMD (especialmente AVX).
Datos del tensor: Matriz de datos de pesos reales alineados.

4. Base matemática de TinyLLaMA y algoritmos en C++

TinyLLaMA incorpora varios ingenios arquitectónicos avanzados para mejorar la eficiencia. Explicaremos las representaciones matemáticas para implementarlos correctamente en C++.

4.1 RMSNorm (Root Mean Square Normalization)

Reduce el costo computacional omitiendo el centrado de la media de LayerNorm y realizando solo el escalado de la varianza.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ es el número de dimensiones y $\gamma$ es el tensor de escalado entrenado. Al implementar en C++, se optimiza calculando primero rápidamente la suma de los cuadrados de la matriz usando _mm256_fmadd_ps de AVX2, y multiplicando por la raíz cuadrada inversa (por ejemplo, con la instrucción _mm256_rsqrt_ps).

4.2 RoPE (Rotary Position Embedding)

Es una técnica para aplicar la información de posición de los tokens como una rotación en el espacio del tensor. Se puede ver como una rotación en el plano complejo, y aplica la siguiente rotación a los pares de dimensiones adyacentes $(x_1, x_2)$ del vector $x$.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Aquí, $m$ es el índice de posición absoluta del token y $\theta$ es la frecuencia base precalculada. En ggml, se ejecuta en paralelo simplemente añadiendo el operador ggml_rope durante la construcción del grafo de inferencia.

4.3 Grouped-Query Attention (GQA)

En la Atención Multicabezal normal (Multi-Head Attention, MHA), se tiene el mismo número de cabezas para Query, Key y Value. Sin embargo, TinyLLaMA adopta Grouped-Query Attention (GQA) para reducir drásticamente el ancho de banda de la memoria y el consumo de caché KV.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

En GQA, múltiples cabezas de Query comparten una sola cabeza de Key/Value. En la implementación de C++, antes de ejecutar el producto matricial ggml_mul_mat, se requiere una operación para transmitir (broadcast) los tensores KV de acuerdo con el número de Queries.

4.4 Función de activación SwiGLU

En la capa de la Red Feed-Forward (FFN), se utiliza SwiGLU en lugar de GELU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

En el grafo computacional, se expresa combinando el operador ggml_silu y ggml_mul.

5. Construcción del grafo computacional y gestión de memoria con ggml

ggml adopta un enfoque de “Definir y Ejecutar” (Define-and-Run), donde construye un grafo computacional estático para la inferencia y luego lo evalúa.

5.1 ggml_context y el asignador de arena

La característica más singular de ggml es la “asignación por arena”, que no realiza ninguna asignación dinámica de memoria (malloc o new) dentro del bucle de inferencia. Al inicializar, se reserva una gran área de memoria contigua (arena), y cada vez que se llama a funciones como ggml_new_tensor, el puntero de esta área se incrementa. Cuando se completa un paso de inferencia, simplemente se restablece el puntero de asignación a su posición inicial, completando instantáneamente la asignación de memoria para el siguiente paso de inferencia.

5.2 Ejemplo concreto de construcción de grafo

En cada paso de inferencia, se construye un grafo computacional en memoria como el siguiente:

graph TD A["ID de Entrada de Tokens"] --> B["Búsqueda de Embedding"] B --> C["ggml_rms_norm"] C --> D["Proyecciones Q / K / V"] D --> E["Posicional ggml_rope"] E --> F["Almacenar Caché KV"] E --> G["Cargar Caché KV"] G --> H["Autoatención"] H --> I["Escala y Softmax"] I --> J["Salida de Atención"] J --> K["Proyección de Salida"] K --> L["Añadir Residual"]

6. Cuantización y optimización para Windows / SIMD

Manejar TinyLLaMA (1.1B) en FP16 requiere aproximadamente 2.2GB de memoria, pero mediante cuantización de 4 bits (como Q4_K), se puede comprimir drásticamente a unos 600MB.

6.1 Arquitectura de cuantización por bloques

ggml no cuantiza todo el tensor uniformemente, sino en unidades de “bloques”. En el formato Q4_0, 32 valores FP16 se agrupan en un bloque.

Factor de escala: 1 valor FP16 (2 bytes)
Datos cuantizados: 32 valores de 4 bits (16 bytes) Esto minimiza el impacto de los valores atípicos (outliers) locales.

6.2 Aceleración del producto punto con AVX2

Al compilar para las CPU x86 más recientes en entornos Windows, se utilizan banderas del compilador como /arch:AVX2 y el procesamiento SIMD se realiza con el siguiente flujo:

Carga: Cargar datos cuantizados de 4 bits desde la memoria a registros AVX de 256 bits.
Expansión y desempaquetado: Expandir los valores de 4 bits a Int8 o Int16 usando máscaras de bits y operaciones de desplazamiento.
Descuantización: Multiplicar por el factor de escala para convertir a punto flotante.
Operación FMA: Ejecutar en paralelo la operación de multiplicación y suma (multiply-add) con los valores de activación y _mm256_fmadd_ps (Fused Multiply-Add).

7. Detalles de implementación de la caché KV

En la generación autorregresiva, la “caché KV” para omitir el cálculo de las Keys y Values de los tokens pasados es una función esencial.

Los puntos clave para la implementación en C++ son los siguientes:

Reserva previa del tensor: Se inicializa un enorme tensor para la caché KV con la longitud máxima del contexto (ej: 2048 tokens) (se recomienda FP16).
Copia por desplazamiento: Cuando se realiza el cálculo para la posición del token $N$, los vectores K y V obtenidos en ese paso se almacenan en la fila $N$ del tensor de la caché KV usando ggml_cpy u otras funciones.
Creación de vista durante la atención: Al calcular la atención, se crea una “vista” que apunta solo a la parte de los tokens del 0 al $N$-ésimo y se pasa al producto matricial.

8. Tokenizador BPE y decodificación

La cadena de entrada se trata como una secuencia de bytes UTF-8 y se compara con un vocabulario predefinido. En C++, para acelerar la búsqueda en el vocabulario, se implementa un árbol Trie (árbol de prefijos) o algoritmos que utilizan colas de prioridad.

A partir de los logits generados por el LM Head, se escalan las probabilidades usando el parámetro Temperature, los candidatos se filtran usando métodos Top-K o Top-P (Nucleus Sampling), y se utiliza un número aleatorio para determinar el siguiente token final.

9. Inicio del proyecto en C++ (Entorno Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Configuración de banderas de optimización y AVX2 para Windows (MSVC)
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Ejemplo de comando de compilación en PowerShell:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Resumen

Implementar desde cero un motor de inferencia para modelos de IA pequeños como TinyLLaMA usando C++ y ggml es una excelente oportunidad para descubrir la caja negra del aprendizaje profundo y aprender la belleza del control de hardware de bajo nivel. Disfrutemos plenamente de la esencia de la programación de sistemas, como la carga con copia cero mediante mapeo de memoria, la optimización SIMD y la construcción de la caché KV, mientras abrimos camino hacia el futuro de la IA periférica (Edge AI).

【Introducción a la implementación de RAG】Cómo hacer que una IA local lea tus propios documentos

Fri, 11 Sep 2026 13:00:00 +0900

Introducción

En los últimos años, la evolución de los Grandes Modelos de Lenguaje (LLM) ha sido notable, con inteligencias artificiales como ChatGPT y Claude infiltrándose en nuestras vidas y trabajos. Sin embargo, los LLM generales tienen una clara debilidad: solo conocen la “información pública en el momento de su entrenamiento”. Naturalmente, no pueden responder preguntas sobre “documentos privados” como reglamentos internos de la empresa, notas personales o materiales de proyectos no publicados. Si se les fuerza a responder, aumenta el riesgo de que generen mentiras plausibles que no se ajustan a los hechos (alucinaciones).

Por lo tanto, la arquitectura tecnológica que está experimentando una adopción explosiva en todo el mundo en este momento es RAG (Retrieval-Augmented Generation: Generación Aumentada por Recuperación). Al utilizar RAG, es posible proporcionar de forma dinámica conocimientos propios al LLM desde una base de datos externa, permitiéndole generar respuestas precisas y fundamentadas basadas en dichos conocimientos.

Además, al manejar información confidencial de empresas o individuos, el envío de datos a API basadas en la nube como las de OpenAI a menudo no está permitido por las políticas de seguridad. Lo que se necesita en estos casos es la construcción de un “RAG local” combinado con una IA local (un LLM que opera de manera autónoma en tu propia PC o en un servidor on-premise).

En este artículo, explicaremos exhaustivamente desde la teoría fundamental de RAG hasta métodos específicos para implementar un RAG local con Python, los antecedentes matemáticos (cómo funciona la búsqueda vectorial) y técnicas avanzadas para poner el sistema en producción.

1. Arquitectura general de RAG

RAG no es un modelo de IA único, sino una arquitectura de sistema en la que múltiples componentes colaboran entre sí. Se divide principalmente en dos fases: la “Fase de ingesta (importación de datos)” y la “Fase de recuperación y generación (búsqueda y generación)”.

El siguiente diagrama de Mermaid muestra la imagen general del sistema RAG.

graph TD subgraph "Fase de Ingesta (Preparación previa)" Doc["Documentos propios (PDF, TXT, etc.)"] --> Loader["Cargador de documentos"] Loader --> Splitter["División de texto (Chunking)"] Splitter --> EmbedModel1["Modelo de incrustación (Embedding)"] EmbedModel1 --> VectorDB["Base de datos vectorial"] end subgraph "Fase de Inferencia (Al consultar el usuario)" User["Pregunta del usuario (Consulta)"] --> EmbedModel2["Modelo de incrustación (Embedding)"] EmbedModel2 --> QueryVector["Vector de consulta"] QueryVector --> Search["Búsqueda de similitud (Búsqueda vectorial)"] VectorDB --> Search Search --> Context["Extracción de fragmentos relevantes (Contexto)"] User --> PromptBuilder["Construcción del prompt"] Context --> PromptBuilder PromptBuilder --> LocalLLM["LLM Local"] LocalLLM --> Answer["Generación de respuesta final"] end

Fase de ingesta (Preparación previa)

Carga de documentos: Se leen datos no estructurados como archivos PDF, Word o de texto.
Chunking (División de texto): Se dividen los textos largos en fragmentos significativos (chunks) para que se ajusten al límite de entrada del LLM (ventana de contexto) y para mejorar la precisión de la búsqueda.
Embedding (Vectorización): Se introducen los fragmentos divididos en un modelo de incrustación (Embedding Model) y se convierten en matrices numéricas (vectores) de cientos a miles de dimensiones.
Almacenamiento en la base de datos: Los vectores convertidos se vinculan con los datos de texto originales y se guardan en una base de datos vectorial (Vector DB).

Fase de inferencia (Tiempo de ejecución)

Vectorización de la consulta: Se vectoriza la pregunta del usuario usando el mismo modelo de incrustación de la fase de preparación.
Búsqueda de similitud: Se calcula la similitud entre el vector de consulta y los vectores de los documentos en la base de datos para recuperar los fragmentos de texto con mayor relevancia (cercanía semántica).
Construcción del prompt: Los textos relevantes recuperados se combinan con la pregunta del usuario como “contexto (conocimiento de fondo)” para crear el prompt de entrada para el LLM.
Generación de la respuesta: El LLM, tras recibir el prompt aumentado, genera una respuesta basándose en la información de contexto proporcionada.

2. Entendimiento profundo de la búsqueda vectorial y las incrustaciones (Embeddings)

El núcleo de RAG es la “búsqueda vectorial (búsqueda semántica)”. Mientras que la búsqueda por palabras clave tradicional (como BM25) se basa en coincidencias exactas y frecuencias de palabras, la búsqueda vectorial se basa en la “similitud de significado”. Por ejemplo, palabras diferentes como “perro” y “cachorro”, o “PC” y “ordenador”, aparecerán en los resultados si su significado es parecido.

¿Qué es un modelo de incrustación (Embedding Model)?

Un modelo de incrustación es una red neuronal que toma textos en lenguaje natural como entrada y emite un vector denso (Dense Vector) de longitud fija. Los modelos comunes (como text-embedding-3-small o el de código abierto multilingual-e5-large) mapean el texto a vectores de números reales de 384 o 1024 dimensiones.

En este espacio multidimensional (espacio latente), el modelo está entrenado para que los textos con significados similares tengan distancias más cortas en las coordenadas espaciales.

Antecedentes matemáticos del cálculo de similitud: Similitud del coseno

Cuando una base de datos vectorial busca documentos relevantes, la métrica de distancia más comúnmente utilizada es la similitud del coseno (Cosine Similarity). A diferencia de la distancia euclidiana (distancia espacial absoluta), la similitud del coseno se centra en el “ángulo entre dos vectores”. Es altamente adecuada para calcular la similitud de textos, ya que no se ve tan afectada por la longitud del texto (la norma del vector).

Expresado matemáticamente, la similitud del coseno entre los vectores $\mathbf{A}$ y $\mathbf{B}$ es la siguiente:

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ representa el producto escalar (Dot Product).
$\|\mathbf{A}\|$ representa la norma L2 (longitud) del vector $\mathbf{A}$.
$n$ es el número de dimensiones del vector.

La similitud del coseno toma valores entre -1 y 1.

Cercano a 1: La dirección de los dos vectores es casi la misma (sus significados son muy similares).
Cercano a 0: Los dos vectores son ortogonales (no están relacionados).
Cercano a -1: Los dos vectores apuntan en direcciones opuestas (significados opuestos).

Las bases de datos vectoriales recientes (Chroma, FAISS, Qdrant, etc.) adoptan un algoritmo de búsqueda de vecino más cercano aproximado (ANN) llamado HNSW (Hierarchical Navigable Small World), que está optimizado para buscar documentos con una alta similitud de coseno entre millones de datos vectoriales en milisegundos.

3. Pila tecnológica para construir un RAG local

Para construir un RAG local completo que no dependa de la nube, aprovechamos el ecosistema de código abierto. A continuación se presentan las pilas tecnológicas recomendadas:

Modelo de lenguaje (LLM)
- Herramienta: Ollama o Llama.cpp
- Modelo: Modelos abiertos ligeros y de alto rendimiento como Llama-3-8B-Instruct, Gemma-2-9B-It, Qwen2-7B-Instruct. Para tareas en japonés, son adecuados modelos ajustados al japonés como Llama-3-ELYZA-JP-8B.
Modelo de incrustación (Embedding)
- Modelo: intfloat/multilingual-e5-large o BAAI/bge-m3. Si se ejecuta localmente, lo común es descargarlo desde Hugging Face y ejecutarlo con Sentence-Transformers.
Base de datos vectorial (Vector DB)
- ChromaDB: Basado en Python y extremadamente fácil de configurar. Ideal para el desarrollo local.
- FAISS: Una biblioteca de búsqueda vectorial rápida desarrollada por Meta.
- Qdrant / Milvus: Orientado a entornos de producción de mayor escala.
Marco de orquestación
- LangChain: El estándar de facto para encadenar componentes (Chain).
- LlamaIndex: Un marco de conexión de datos especializado especialmente en RAG.

En esta ocasión, lo implementaremos con la combinación más sencilla de introducir: LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings.

4. Tutorial de implementación: Construcción de un RAG local completo con Python

A partir de aquí, construiremos el RAG local mientras escribimos código Python real. Asegúrate de tener Ollama instalado en tu PC y ejecutándose en segundo plano con antelación. Además, obtén un modelo en Ollama (ej. ollama run llama3).

Paso 1: Instalación de las bibliotecas necesarias

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Paso 2: Visión general del código de implementación

A continuación, se muestra un script de Python completo para leer un archivo PDF, vectorizarlo y hacer que un LLM local responda preguntas basadas en él.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. Cargar el documento
 print("Cargando el documento...")
 # Especifica la ruta del PDF que deseas cargar
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. División en fragmentos (Text Splitting)
 # Divide en un tamaño adecuado para no romper el significado del texto
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # Número máximo de caracteres por fragmento
 chunk_overlap=50, # Número de caracteres superpuestos con el fragmento anterior y siguiente (evita la ruptura del contexto)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"Se ha dividido en {len(chunks)} fragmentos.")

 # 3. Inicialización del modelo de incrustación (Local HuggingFace Model)
 # Usando un modelo multilingüe fuerte en japonés (y otros idiomas)
 print("Cargando el modelo de incrustación...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # Si tienes GPU, usa 'cuda' o 'mps'
 )

 # 4. Construcción de la base de datos vectorial (Chroma)
 print("Construyendo la base de datos vectorial...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # Creación del recuperador (Retriever). Configurado para obtener los 3 mejores documentos relevantes
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. Inicialización del LLM local (Ollama)
 print("Conectando al LLM local...")
 # Asegúrate de haber obtenido el modelo de antemano con 'ollama pull llama3' o similar
 llm = Ollama(model="llama3")

 # 6. Definición de la plantilla del prompt
 prompt_template = """Eres un asistente excelente, experto en los reglamentos y la información interna de la empresa.
Usa únicamente el siguiente contexto (información de fondo) para responder a la pregunta del usuario detalladamente en español.
Si no puedes encontrar la respuesta en el contexto, no adivines; responde honestamente con un "No se puede determinar a partir de la información proporcionada".

【Contexto】
{context}

【Pregunta】
{question}

【Respuesta】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. Construcción de la cadena RAG
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # Configura si deseas devolver la fuente de información
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. Ejecución de la pregunta
 query = "Cuéntame sobre las condiciones de pago de gastos de transporte para el trabajo remoto."
 print(f"\nPregunta: {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【Respuesta】")
 print(result['result'])
 print("\n---")
 print("【Fuentes consultadas】")
 for doc in result['source_documents']:
 print(f"- Página {doc.metadata.get('page', 'desconocido')}: {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

Explicación de los puntos clave del código

RecursiveCharacterTextSplitter: Es el separador más recomendado para dividir el lenguaje natural. Intenta dividir en el orden de párrafo (\n\n), línea (\n) y punto (。), dividiendo el texto para que se ajuste al chunk_size especificado mientras se mantiene el significado en la medida de lo posible. Al configurar el chunk_overlap, se evita que se rompa el límite del contexto y se pierda información.
HuggingFaceEmbeddings: intfloat/multilingual-e5-large es un modelo de incrustación de código abierto muy potente que soporta múltiples idiomas. Permite vectorizar texto en la memoria local sin conexión, sin utilizar una API en la nube (como text-embedding-ada-002 de OpenAI).
ChromaDB: Dado que funciona en memoria o en el almacenamiento local (basado en SQLite), no requiere la configuración de un servidor de base de datos complejo. Al especificar un persist_directory, se puede omitir el proceso de vectorización en ejecuciones posteriores y cargar la base de datos desde el disco.

5. Técnicas avanzadas de RAG (Advanced RAG Techniques)

El sistema básico de RAG (Naive RAG) construido en el tutorial anterior funcionará, pero si se requiere una alta precisión de respuesta en un entorno de producción, será necesario introducir técnicas avanzadas como las siguientes.

5.1 Búsqueda Híbrida (Hybrid Search)

La búsqueda vectorial es buena capturando el “significado”, pero a veces puede tener dificultades con búsquedas estrictas de palabras clave como “nombres propios específicos”, “números de modelo de productos” o “identificadores de empleados”. Por lo tanto, se puede reducir drásticamente las omisiones de búsqueda ejecutando en paralelo la búsqueda semántica basada en vectores y la búsqueda por palabras clave usando algoritmos como BM25, y luego integrando los resultados de ambos (usando técnicas como Reciprocal Rank Fusion; RRF).

5.2 Reclasificación (Re-ranking)

La búsqueda vectorial es rápida, pero no siempre evalúa la idoneidad contextual exacta. Una canalización general para mejorar la precisión de la búsqueda es la siguiente:

Búsqueda inicial (First-stage Retrieval): Se recuperan de 20 a 30 fragmentos relevantes de la base de datos vectorial, buscando de forma amplia y superficial.
Reevaluación (Re-ranking): Se utiliza otro modelo de aprendizaje automático más pesado llamado Cross-Encoder (por ejemplo, bge-reranker) para introducir los pares de la consulta del usuario y los fragmentos recuperados, y recalcular la puntuación de adecuación semántica.
Selección: Solo los 3 a 5 mejores resultados con las puntuaciones más altas se pasan como contexto final al prompt del LLM.

Con este enfoque, se evita pasar información de ruido irrelevante al LLM, aumentando significativamente la precisión (Precision) de la respuesta.

graph LR Query["Consulta"] --> VSearch["Búsqueda vectorial (Top 20)"] VSearch --> Reranker["Modelo reclasificador (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["Top 3 de alta precisión"] TopK --> LLM["Generación por LLM"]

5.3 Chunking semántico y búsqueda de documentos primarios

Existe una técnica llamada “Semantic Chunking” (división semántica) que en lugar de dividir el texto mecánicamente con un número fijo de caracteres, utiliza IA para detectar cambios en el significado de las oraciones y dividir allí. Además, la técnica del “Parent Document Retriever” (Búsqueda de documentos primarios) permite lograr búsquedas altamente precisas vectorizando unidades muy pequeñas (como oraciones) para la búsqueda, pero al pasarlo al LLM, proporciona el “párrafo original grande (documento primario)” que contiene esa oración, entregando un contexto suficiente al LLM.

6. Retos y contramedidas al operar un RAG local

Existen obstáculos específicos al construir y operar RAG en un entorno local.

Agotamiento de VRAM (Memoria de video): Para ejecutar un LLM local a una velocidad práctica (decenas de tokens por segundo), es necesario cargar el modelo en la VRAM de la GPU. Ejecutar un modelo de clase 8B en fp16 (punto flotante de 16 bits) requiere aproximadamente 16 GB de VRAM. Sin embargo, al usar tecnología de cuantización (Quantization) (compresión a 4 bits u 8 bits, como los formatos GGUF o AWQ), es posible que funcione lo suficientemente rápido incluso con 8 GB de VRAM (como en una PC de juegos típica). Llama.cpp y Ollama son compatibles con estos formatos cuantizados por defecto.
Límite de la ventana de contexto: Si la cantidad de contexto recuperado es demasiada, puede exceder el límite de entrada (límite de tokens) del LLM o causar que el modelo olvide la información en el medio (fenómeno de “Lost in the middle”). Es esencial ajustar el número de fragmentos a extraer y realizar una selección rigurosa utilizando la técnica de reclasificación mencionada anteriormente.
Gestión de la frescura de los datos: Si se actualiza el documento de origen, los vectores correspondientes en la base de datos vectorial también deben ser actualizados o eliminados (operaciones CRUD). Dado que ChromaDB soporta actualizaciones basadas en el ID del documento, es práctico gestionar los valores hash de los archivos y establecer un proceso por lotes que sincronice solo las diferencias.

Conclusión

RAG (Generación Aumentada por Recuperación) es un potente paradigma que evoluciona a la IA de ser un asistente generalizado a un “experto personal exclusivo” o un “especialista en tareas internas de la empresa”.

Hemos visto que incluso con requisitos altamente confidenciales donde no se pueden usar servicios en la nube, es relativamente fácil construir un entorno “RAG local” completo combinando ecosistemas de código abierto como Ollama, LangChain y ChromaDB.

Basándote en el entendimiento matemático del espacio vectorial explicado en este artículo, y enfoques avanzados como la división de texto y la reclasificación, te animamos a desarrollar tu propio sistema de IA utilizando tus propios datos. La velocidad de evolución de la IA local es asombrosa, y el sistema que construyes hoy puede ser actualizado instantáneamente reemplazando el modelo por uno más ligero e inteligente que aparezca mañana.

En este blog continuaremos publicando artículos en profundidad sobre la tecnología de IA y RAG. Si tienes preguntas o comentarios, por favor déjalos en la sección de comentarios.

¡Comparación exhaustiva de las API de ChatGPT, Gemini y Claude! ¿Cuál deberías elegir?

Fri, 11 Sep 2026 12:00:00 +0900

¡Comparación exhaustiva de las API de ChatGPT, Gemini y Claude! ¿Cuál deberías elegir?

La evolución de la tecnología de IA ha sido asombrosa y, especialmente en el campo de los modelos de lenguaje grande (LLM: Large Language Model), ChatGPT de OpenAI (serie GPT), Gemini de Google y Claude de Anthropic están en una intensa batalla a tres bandas por la supremacía. A partir de 2026, cada compañía está lanzando nuevos modelos y funciones de API en cuestión de meses, o incluso semanas. Para los desarrolladores y arquitectos de TI de las empresas, la pregunta de “¿qué API integrar en nuestro producto?” se ha convertido en una decisión extremadamente importante que determina el éxito de un proyecto.

En este artículo, compararemos y explicaremos en detalle las API de estos tres grandes proveedores de IA desde la perspectiva del desarrollador. Iremos más allá de una simple enumeración de especificaciones y cubriremos desde el diseño de la arquitectura, la estructura detallada de precios y el análisis matemático de la latencia (retraso), hasta ejemplos de implementación específicos en Python y Node.js, así como las últimas técnicas de optimización de costos como el caché de prompts.

Esperamos que esta guía sea completa para ayudar a los lectores a seleccionar la API de LLM más adecuada para sus casos de uso y construir aplicaciones de IA escalables y rentables.

1. Filosofía y diseño de la arquitectura de la API de cada LLM

Al hacer una selección tecnológica, es fundamental entender primero qué tipo de filosofía impulsa la construcción de los modelos y las API de cada empresa.

1.1 OpenAI (ChatGPT)

Con la misión de lograr la “Inteligencia Artificial General (AGI)”, OpenAI lidera constantemente los estándares de facto de la industria. Ofrece una variedad de modelos adaptados a diferentes casos de uso, como GPT-4o, GPT-4o-mini y el modelo especializado en inferencia o1. Su ecosistema es el más maduro, contando con la mayor cantidad de bibliotecas y documentación, tanto oficiales como no oficiales.

1.2 Google (Gemini)

Bajo la premisa de “AI First” (IA primero), Google aprovecha al máximo la escalabilidad de su propia infraestructura (redes de TPU). La mayor característica de Gemini 1.5 Pro/Flash es su abrumadora ventana de contexto (longitud de contexto) de hasta 2 millones de tokens, lo que le permite procesar simultáneamente documentos muy largos o varias horas de video y audio. La sólida integración con Google Cloud (Vertex AI) también resulta muy atractiva para las empresas.

1.3 Anthropic (Claude)

Anthropic es una empresa fundada por ex miembros de OpenAI y adopta un enfoque único de seguridad llamado “IA Constitucional” (Constitutional AI). Los modelos Claude 3.5 Sonnet y Opus han ganado un apoyo entusiasta de muchos desarrolladores por sus altas capacidades de razonamiento, generación de código y, sobre todo, por sus “diálogos naturales y humanos” y su “bajo nivel de alucinaciones”.

2. Comparación exhaustiva de las especificaciones de las familias de modelos

Comparamos las especificaciones de los principales modelos a partir de 2026.

Proveedor	Modelo Principal	Longitud de Contexto Máxima	Principales Fortalezas	Casos de Uso Recomendados
OpenAI	GPT-4o	128K	Velocidad, reconocimiento visual, soporte de voz	Aplicaciones interactivas, tareas de propósito general
OpenAI	o1-preview	128K	Razonamiento lógico avanzado, matemáticas, programación	Generación de algoritmos complejos, usos en investigación
Google	Gemini 1.5 Pro	2,000K	Procesamiento de textos ultralargos, multimodal (video/audio)	Análisis de enormes bases de código, resumen de video
Google	Gemini 1.5 Flash	2,000K	Baja latencia, alto rendimiento (throughput), costo extremadamente bajo	Procesamiento en tiempo real, procesamiento por lotes de grandes datos
Anthropic	Claude 3.5 Sonnet	200K	Capacidad de codificación, generación natural de texto	Soporte en desarrollo de software, atención al cliente avanzada
Anthropic	Claude 3.5 Haiku	200K	Respuesta ultrarrápida, relación costo-rendimiento	IA de borde (Edge AI), chatbots en tiempo real

3. Profundización en la arquitectura: Detrás de las peticiones de la API

Cuando se hace una llamada a la API de un LLM, ¿qué tipo de procesamiento se lleva a cabo en el backend? Para optimizar el rendimiento, es necesario comprender esta arquitectura.

El siguiente diagrama de Mermaid muestra el panorama general desde el momento en que la aplicación cliente envía una solicitud a la API hasta que los tokens se devuelven en streaming.

graph TD A["Aplicación Cliente"] -->|HTTP/REST or gRPC| B["Puerta de Enlace API"] B --> C["Balanceador de Carga"] C --> D["Clúster de Inferencia"] D --> E["Tokenizador (BPE / SentencePiece)"] E --> F["Caché KV y Mecanismo de Atención"] F --> G["Bloques Transformer (Forward Pass)"] G --> H["Capa de Salida (Logits)"] H --> I["Muestreador (Temperature, Top-p, Top-k)"] I --> J["Destokenizador"] J -->|Respuesta en Streaming (Chunk)| A

3.1 Algoritmo de Tokenización

El texto ingresado en la API se divide internamente en unidades llamadas “tokens”.

OpenAI (tiktoken): Utiliza Byte-Pair Encoding (BPE). Se comprime de manera extremadamente eficiente, especialmente en inglés, pero en lenguajes no alfabéticos, como el japonés, el número de tokens tiende a inflarse.
Google (Gemini): Utiliza SentencePiece (Modelo de Lenguaje Unigrama). Es fuerte en multilingüismo y tiende a poder expresar textos, incluso en japonés, con un número relativamente menor de tokens.
Anthropic (Claude): Utiliza una versión personalizada de BPE. El soporte multilingüe se ha fortalecido y, a partir de Claude 3, la eficiencia de tokens en lenguajes como el japonés ha mejorado significativamente.

4. Análisis matemático del rendimiento y la latencia

En las aplicaciones en tiempo real, la latencia está directamente relacionada con la experiencia del usuario (UX). La latencia de la API de un LLM $T_{total}$ se puede modelar matemáticamente de la siguiente manera:

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

Aquí, cada variable tiene el siguiente significado:

$T_{network}$: Tiempo de ida y vuelta de la red (RTT).
$T_{TTFT}$ (Time To First Token): El tiempo que tarda en generarse el primer carácter. Depende en gran medida del costo de cálculo de la atención, que es proporcional al cuadrado de la longitud del prompt (número de tokens de entrada).
$N$: Número total de tokens de salida.
$T_{TPOT}$ (Time Per Output Token): Tiempo de generación por token. Al ser un modelo autorregresivo, se calcula secuencialmente, dependiendo de las salidas anteriores.

4.1 Complejidad computacional del mecanismo de autoatención

El costo computacional de la autoatención (Self-Attention) en la arquitectura Transformer aumenta de forma cuadrática en relación con la longitud de la secuencia de entrada $L$.

$$ \text{Complexity} = O(L^2 \cdot d) $$

Donde $d$ es el número de dimensiones del vector de incrustación (embedding). Debido a esta restricción, normalmente, a medida que el prompt se hace más largo, $T_{TTFT}$ empeora drásticamente. Sin embargo, Gemini 1.5 de Google emplea arquitecturas de optimización innovadoras como “Ring Attention” y “Block-wise Compute”, y logra generar el primer token en un tiempo razonable (de unos pocos segundos a unas decenas de segundos), incluso cuando se ingresa un texto largo de 2 millones de tokens.

5. Estructura de precios y estrategias de optimización de costos

El costo de la API se calcula fundamentalmente en base al número de tokens de entrada y tokens de salida.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

No obstante, en las API más recientes, se han introducido nuevos mecanismos para reducir drásticamente los costos.

5.1 Caché de Prompts (Prompt Caching)

Enviar un sistema de prompts (system prompts) extenso o grandes cantidades de documentos recuperados mediante RAG cada vez resulta en costos masivos. Para hacer frente a esto, cada empresa ofrece una función de caché.

En Anthropic (Claude) y Google (Gemini), al almacenar en caché bloques de texto específicos, se puede reducir significativamente el costo de entrada (hasta en un 90%).

El modelo de costo cuando se utiliza el caché sería el siguiente:

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

Aquí, el $Rate_{cache\_read}$ se establece en alrededor del 10% al 25% del $Rate_{in}$ normal. Gracias a esto, es posible operar chatbots de bajo costo manteniendo como conocimiento de fondo bases de código de decenas de miles de líneas.

5.2 API por Lotes (Batch API)

Para tareas que no requieren tiempo real (análisis de registros, clasificación de datos masivos, etc.), OpenAI y Anthropic ofrecen API por lotes. Es un mecanismo poderoso en el que, en lugar de recibir respuestas inmediatamente, se envían solicitudes agrupadas y se obtienen resultados dentro de las 24 horas, con un descuento del 50% de la tarifa normal de la API.

6. Experiencia del desarrollador (DX) y comparación de SDKs

Comparamos los SDKs (Kits de Desarrollo de Software) proporcionados por cada empresa desde la perspectiva de la eficiencia del desarrollo.

6.1 API de OpenAI

Es el más utilizado en general y la compatibilidad con bibliotecas de terceros (LangChain, LlamaIndex, etc.) es la más rápida. Además, gracias a la función Structured Outputs (Salidas Estructuradas), se garantiza la devolución de respuestas que cumplen al 100% con un esquema JSON, lo que facilita enormemente la integración de sistemas.

6.2 API de Anthropic (Claude)

La interfaz de su SDK es muy refinada y su definición de tipos en TypeScript tiene fama de ser muy fácil de manejar. En particular, la estructura de la Message API es intuitiva, permitiendo redactar de forma sencilla solicitudes multimodales que incluyan múltiples imágenes.

6.3 API de Google Gemini

Existen dos vías de acceso: mediante Google Cloud Vertex AI y mediante AI Studio (Google Gen AI SDK), lo cual puede ser un poco confuso para los principiantes. Sin embargo, el SDK de Vertex AI, dirigido a empresas, se integra completamente con IAM (sistema de autenticación y autorización) de GCP, permitiendo construir un entorno de desarrollo seguro.

7. ¡Práctica! Implementación de prueba de integración de múltiples API con Python

Aquí, implementaremos un script en Python que envíe peticiones asíncronas simultáneamente a las tres APIs de OpenAI, Anthropic y Gemini para comparar su latencia.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# Inicialización de los clientes
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "Por favor, explica los fundamentos de la computación cuántica y su impacto en la criptografía actual, de manera fácil de entender para un principiante."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # Uso del método asíncrono del SDK en Python de Gemini
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("Enviando peticiones a cada API de LLM...")

 # Ejecutar las 3 APIs en paralelo
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latencia: {latency:.2f} segundos")
 print(f"Respuesta (Extracto): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

Al ejecutar este script, se puede medir fácilmente qué modelo responde más rápido (minimizando $T_{total}$) en un entorno de red real.

8. Implementación de Tool Calling (Llamada a Funciones) con Node.js

Para hacer que un LLM funcione como un “agente de IA” que colabora con sistemas externos, y no solo como un chatbot, el Tool Calling (o Function Calling) es indispensable. A continuación, se muestra un ejemplo en el que se usa Node.js (TypeScript) para permitir que la API de OpenAI llame a una API del clima.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "Obtiene el clima actual de la ciudad especificada.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "Nombre de la ciudad (ej: Tokio, Nueva York)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "¿Cómo está el clima hoy en Tokio? ¿Necesito un paraguas?" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`El LLM solicitó la llamada a una herramienta: Nombre de la función = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`Argumentos: ${args.location}`);

 // Aquí es donde se implementaría el código para llamar a la API meteorológica real (ej: OpenWeatherMap)
 // const weather = await fetchWeatherFromAPI(args.location);

 // Luego se pasa el resultado obtenido de nuevo al LLM para generar la respuesta final
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet y Gemini 1.5 Pro también tienen capacidades de Tool Calling equivalentes, y aunque hay diferencias menores en cómo se definen los esquemas, el flujo básico es común en todos.

9. RAG vs Ventana de Contexto Larga: ¿Cuál se debe adoptar?

Actualmente, uno de los mayores debates en la arquitectura de IA empresarial es el problema de si “deberíamos usar RAG (Generación Aumentada por Recuperación) para incorporar conocimientos externos, o si deberíamos enviarle todo a una enorme ventana de contexto (Long Context)”.

Ventajas y Desafíos del RAG (Retrieval-Augmented Generation)

Ventajas: Es de bajo costo (ya que solo se ingresan en el prompt los fragmentos de datos necesarios) y es más fácil identificar el origen (fuente) de la respuesta.
Desafíos: Como depende de la precisión de la búsqueda semántica, no es adecuado para tareas de razonamiento avanzado en las que el contexto esté disperso en varios documentos (por ejemplo, “Analiza cronológicamente la causa raíz del retraso del Proyecto A a partir de todas las actas de reuniones del año pasado”).

Contexto Largo (ej. los 2 millones de tokens de Gemini 1.5 Pro)

Ventajas: No hay pérdida de información debido a la búsqueda. Incluso en la prueba de “Buscar una aguja en un pajar” (Needle In A Haystack: NIAH), Gemini 1.5 Pro y Claude 3.5 Sonnet pueden extraer información con una precisión de más del 99%.
Desafíos: El consumo de tokens es masivo, lo que aumenta los costos, y la latencia ($T_{TTFT}$) también aumenta.

Conclusión: La mejor práctica en 2026 es un “Enfoque Híbrido”. El diseño predominante utiliza RAG con bases de datos vectoriales para preguntas y respuestas rutinarias, y aprovecha el contexto largo (Long Context) usando el caché de prompts para tareas especializadas que requieran análisis complejos o revisiones exhaustivas de código completo.

10. Comparación de capacidades de procesamiento multimodal

En las aplicaciones de IA de próxima generación, se necesita la capacidad de comprender directamente imágenes, audio y video, además del texto.

sequenceDiagram participant User as "Usuario" participant Client as "App Frontend" participant API as "API LLM (Multimodal)" User->>Client: Subir Video y Prompt de Texto Client->>API: Enviar Bytes de Video/URI + Texto Note over API: Fragmentación de video y separación de audio Note over API: Modelo de Incrustación Multimodal API-->>Client: Devolver Resumen de Texto y Marcas de Tiempo Client-->>User: Mostrar Insights

OpenAI (GPT-4o): Su precisión en el reconocimiento de imágenes es extremadamente alta y se destaca en la lectura de planos dibujados a mano o gráficos complejos. Además, las interacciones de voz nativas de latencia ultrabaja (cientos de milisegundos) que usan su Realtime API son muy poderosas.
Google (Gemini 1.5 Pro): Supera ampliamente a los demás en el análisis de video. Es posible ingresar directamente un archivo de video de 1 hora (fotogramas + audio) y responder preguntas muy específicas como: “¿Cuál es el título del documento que sostiene la persona que aparece en el extremo derecho de la pantalla en el minuto 12:45?”.
Anthropic (Claude 3.5 Sonnet): Su capacidad de reconocimiento de imágenes (Visión) está al mismo nivel que GPT-4o y es excelente. Destaca excepcionalmente en el apoyo al desarrollo frontend, por ejemplo, entregándole una captura de pantalla de la interfaz de usuario con la instrucción “Genera el código del componente React de esta pantalla”.

11. Seguridad y cumplimiento de nivel empresarial

Al utilizar API de LLM en un entorno de producción, la mayor preocupación para las empresas es si “los datos de nuestra compañía se utilizarán para entrenar a la IA” y “si cumplen con los requisitos de cumplimiento corporativo”.

Las tres empresas han declarado claramente que los datos (prompts y respuestas) enviados a través de su API no se utilizarán para entrenar sus modelos (Zero Data Retention / No Training on Customer Data) (※ esto excluye a la UI del chat web gratuito dirigido a consumidores).

Para casos donde se requieran niveles de seguridad aún más altos:

OpenAI: A través del servicio de Azure OpenAI, se puede aprovechar la seguridad de nivel empresarial y los SLA de Microsoft, y realizar conexiones de red cerradas mediante Azure Private Link.
Google: Al usar Google Cloud Vertex AI, es posible realizar un aislamiento de red estricto utilizando VPC Service Controls, y proteger los datos mediante CMEK (Claves de Cifrado Gestionadas por el Cliente).
Anthropic: Al utilizarse a través de AWS Bedrock o Google Cloud Vertex AI, se puede aprovechar la robusta infraestructura de seguridad subyacente de estos proveedores de la nube.

12. Conclusión: Guía de elección definitiva según el caso de uso

Hemos comparado estas opciones desde varios ángulos, pero, en última instancia, la conclusión a “¿cuál debería elegir?” variará según el caso de uso.

Desarrollo de software complejo, generación de código, razonamiento avanzado: 👑 Ganador: Claude 3.5 Sonnet (Anthropic) Actualmente ofrece el mejor rendimiento en la comprensión del contexto del código, refactorización y creación de textos naturales y similares a los humanos. Su API es muy fácil de usar y su rentabilidad mediante el caché de prompts es excelente.
Análisis de documentos ultralargos, procesamiento en lote de video/audio: 👑 Ganador: Gemini 1.5 Pro (Google) Su ventana de contexto de 2 millones de tokens es un arma inigualable. Para tareas en las que sea necesario tener una visión completa de los datos, como analizar un manual en PDF de cientos de páginas o resumir la grabación de una reunión prolongada, nada se le iguala.
Versatilidad, velocidad de ejecución, salida estructurada estable (JSON): 👑 Ganador: GPT-4o / GPT-4o-mini (OpenAI) Maneja cualquier tarea sin problemas y ofrece el mayor soporte para herramientas de terceros. El ecosistema de OpenAI es indispensable si requiere de un análisis JSON confiable usando Structured Outputs o de un razonamiento lógico ultra avanzado a través de los modelos o1.

Recomendación de enrutamiento multimodelo (Multi-model Routing)

En lugar de depender de una única API (fijación con un proveedor / vendor lock-in), la tendencia a futuro es usar una arquitectura de “Enrutamiento LLM” (LLM Routing) que cambie dinámicamente el modelo según la dificultad e importancia de la tarea. Por ejemplo, se puede lograr el equilibrio óptimo entre costo y rendimiento usando los modelos económicos y rápidos GPT-4o-mini o Gemini 1.5 Flash para respuestas simples de usuarios, y delegando en Claude 3.5 Sonnet como respaldo solo cuando se determine que es necesario un procesamiento complejo.

La evolución de la IA no se detiene. Comprenda profundamente las fortalezas, debilidades y las características de la arquitectura de cada API para construir aplicaciones de IA flexibles y escalables.

【Último en 2026】Guía completa para ejecutar LLM locales en un entorno Windows

Fri, 11 Sep 2026 10:00:00 +0900

1. Introducción: ¿Por qué LLM locales en Windows ahora?

En 2026, la evolución de la IA generativa y los Grandes Modelos de Lenguaje (LLM) muestra un cambio de paradigma importante: desde servicios API gigantes en la nube hasta “LLM locales” que se ejecutan en PCs personales y entornos on-premise. Aunque las IA en la nube como GPT-5 de OpenAI o Claude 3.5 de Anthropic son extremadamente potentes, no todas las empresas o individuos pueden enviar todos sus datos a la nube. Desde el punto de vista de la privacidad, seguridad, latencia y los costes sostenibles a largo plazo, la demanda de LLM locales ha crecido explosivamente como nunca antes.

Especialmente en el entorno Windows, la evolución del ecosistema de LLM locales es notable. Hasta hace unos años, el sentido común dictaba que “el desarrollo y la ejecución de IA significaba Linux”, pero en 2026 Windows se ha transformado en una plataforma de IA extremadamente potente y accesible.

Este artículo, basado en las últimas tendencias tecnológicas de 2026, proporciona una guía completa para construir, operar y optimizar un LLM local en un entorno Windows. Cubriremos exhaustivamente desde una configuración simple con Ollama para principiantes, hasta una optimización extrema usando llama.cpp para usuarios avanzados, además de profundizar en el enfoque matemático del cálculo de VRAM, una comprensión profunda de la arquitectura y el fine-tuning local.

1.1 Tendencias tecnológicas que rodean a los LLM locales en 2026

Las principales tendencias que conforman el ecosistema actual de los LLM locales son las siguientes:

Adopción total del formato GGUF: El GGUF (GPT-Generated Unified Format), que integra metadatos y tensores en un solo archivo, se ha convertido en el estándar de facto. Esto permite que con solo descargar un archivo desde Hugging Face, se pueda ejecutar en cualquier entorno.
Democratización de la arquitectura MoE (Mixture of Experts): Se han lanzado numerosos modelos MoE de pequeña escala pero de alto rendimiento, que al activar solo ciertos expertos durante la inferencia, logran un rendimiento comparable al de modelos gigantes mientras mantienen bajo el uso de computación en PCs de consumo.
Abstracción y optimización avanzadas de los motores de inferencia: Herramientas como Ollama, LM Studio y AnythingLLM se han perfeccionado, eliminando la necesidad de que los usuarios se preocupen por dependencias complejas como la instalación de controladores CUDA. Además, el soporte nativo de FlashAttention 3 en Windows ha mejorado drásticamente la velocidad de inferencia.
Utilización de NPU y el auge de las PC Windows Copilot+: Incluso en laptops sin GPU, la tecnología para ejecutar pequeños LLM (SLM: Small Language Models) con bajo consumo energético utilizando la NPU (Neural Processing Unit) integrada ha alcanzado una etapa práctica.

2. Requisitos de hardware y preparación del SO

Para ejecutar un LLM local a una velocidad práctica (más de 15-30 tokens por segundo), la selección del hardware es lo más importante.

2.1 Configuración de hardware recomendada

Con la evolución de los PC con IA, las especificaciones requeridas también están cambiando.

SO: Windows 11 Pro (24H2 o posterior). Indispensable para utilizar las funcionalidades completas de WSL2, la gestión avanzada de memoria y las últimas API de DirectML.
CPU: Intel Core Ultra serie 200 o superior, o AMD Ryzen serie 9000 o superior. Si se utiliza la inferencia por CPU de forma combinada, es esencial una comunicación de memoria de gran ancho de banda.
RAM: Mínimo 32 GB, recomendado 64 GB o más. El ancho de banda de la memoria principal (MB/s) se convierte en el cuello de botella decisivo durante la inferencia por CPU o la descarga (offloading). Una memoria rápida como DDR5-6000 o superior es ideal.
GPU: NVIDIA RTX serie 4000/5000. Lo más importante en los LLM locales no es el rendimiento de cálculo, sino la “capacidad de VRAM”.
- Entrada: RTX 4060 Ti (versión de 16 GB) - La mejor relación calidad-precio. Ideal para modelos de clase 8B a 14B.
- Gama media: RTX 4070 Ti SUPER (16 GB) / RTX 4080 SUPER (16 GB)
- Gama alta: RTX 4090 (24 GB) / RTX 5090 (32 GB) - Necesaria para ejecutar modelos cuantizados de clase 30B a 70B.
Almacenamiento: NVMe SSD PCIe Gen4 o Gen5. Reduce drásticamente el tiempo de carga de modelos de decenas de GB.

2.2 Configuración de WSL2 (Windows Subsystem for Linux 2)

Aunque muchas herramientas GUI funcionan de forma nativa en Windows, WSL2 es muy útil para el desarrollo con Python, la compilación de las últimas herramientas y el fine-tuning LoRA que veremos más adelante. En los entornos modernos de Windows 11, simplemente instalando el controlador NVIDIA en el host, la GPU (CUDA) se puede utilizar de forma transparente desde WSL2.

Abre PowerShell con privilegios de administrador y ejecuta lo siguiente:

1
2
3
4
5


# Instalación de WSL2 y el último Ubuntu
wsl --install -d Ubuntu-24.04

# Actualización del kernel
wsl --update

Después de la instalación, ejecuta nvidia-smi dentro de la terminal de WSL2. Si la GPU se reconoce correctamente, ha sido un éxito.

3. Arquitectura del LLM local y mecanismo de inferencia

Comprender cómo el modelo genera texto en un entorno local y su estructura interna es extremadamente útil para la resolución de problemas y la optimización.

El siguiente diagrama Mermaid muestra la ruta de inferencia típica de un LLM local.

graph TD User["Entrada del usuario (Prompt)"] --> Tokenizer["Tokenizador (Tokenizer)"] Tokenizer --> Embedding["Capa de incrustación (Embedding)"] subgraph "Bloque Transformer (x Capas)" Embedding --> Attn["Auto-atención (Self-Attention)"] Attn --> KVCache["Caché KV (Retención Key/Value)"] Attn --> FFN["Red feed-forward (FFN)"] end FFN --> Logits["Cálculo de logits (Logits)"] Logits --> Sampler["Muestreador (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["Token de salida"] OutputToken --> |"Generación autorregresiva"| Tokenizer OutputToken --> Decoder["Detokenizador (Detokenizer)"] Decoder --> FinalOutput["Texto de salida final"]

3.1 Dos fases: Prefill y Decode

La generación de texto por parte de un LLM se divide en dos fases con diferentes características computacionales:

Fase de Prefill (Procesamiento del prompt): Fase en la que todo el prompt introducido se procesa y comprende a la vez. Dado que es posible el cálculo paralelo, la capacidad de cálculo de la GPU (FLOPS) está directamente relacionada con la velocidad. Si el prompt es largo, esta fase puede tardar varios segundos.
Fase de Decode (Generación de tokens): Fase en la que se predice un token a la vez y se pasa a la siguiente entrada (autorregresiva). Dado que el cálculo paralelo está limitado en esta fase, el ancho de banda de la VRAM (Memory Bandwidth) de la GPU se convierte en un cuello de botella decisivo.

4. Cálculo del consumo de VRAM y comprensión matemática del tamaño del modelo

Para determinar correctamente “qué modelos pueden ejecutarse en mi PC”, es necesario comprender la fórmula para calcular la VRAM. Cuando ocurre un fallback hacia la memoria del sistema (RAM) debido a la falta de VRAM, la velocidad de inferencia se ralentiza de 10 a 100 veces.

4.1 VRAM base según el tamaño de los parámetros

Esta es la cantidad de memoria requerida para cargar los pesos (weights) del modelo en la VRAM. Se calcula usando el tamaño del modelo $P$ (número de parámetros, unidad: 1000 millones = 1B) y el número de bytes por parámetro $B$.

$$ V_{base} = P \times B \quad \text{(GB)} $$

Por ejemplo, al cargar un modelo de parámetros 8B (8 mil millones) en FP16 (punto flotante de media precisión, 16 bits = 2 bytes):

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

En otras palabras, incluso con una GPU de 16 GB de VRAM, se llega casi al límite solo con cargar el modelo.

4.2 La magia de la cuantización (Quantization)

Aquí es donde entra en juego la “cuantización”. Al reducir la precisión de los parámetros, el tamaño del modelo se reduce drásticamente. En el caso más común de la cuantización de 4 bits (ej: Q4_K_M), el promedio es de aproximadamente 0.55 bytes por parámetro.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

Gracias a esto, si se tienen 16 GB de VRAM, se puede ejecutar un modelo 8B con mucho margen.

4.3 Cálculo de la caché KV (Versión compatible con GQA)

Durante la inferencia, la “caché KV”, que retiene el contexto pasado, consume VRAM. En los modelos más recientes como Llama 3, se adopta GQA (Grouped Query Attention) para ahorrar memoria.

El consumo de la caché KV $V_{kv}$ (en gigabytes) se expresa mediante la siguiente fórmula matemática:

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

Simplificando, se puede calcular fácilmente usando el número de cabezales (heads) de Key y Value $h_{kv}$:

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

Donde:

$b$: Tamaño del lote (normalmente 1 para uso personal y local)
$s$: Longitud de la secuencia (longitud del contexto, ej: 8192)
$l$: Número de capas (ej: 32)
$h_{kv}$: Número de cabezales KV (ej: 8)
$d$: Número de dimensiones por cabezal (ej: 128)
$B_{kv}$: Número de bytes de la caché KV (2 para FP16)

Ejemplo de cálculo (Llama 3 8B, contexto 8192, caché FP16): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

Tenga en cuenta que cuanto mayor sea la longitud del contexto $s$, la VRAM requerida aumentará de forma lineal.

5. Práctica 1: Configuración más rápida y corta usando Ollama

Una vez entendida la teoría, ejecutemos un LLM en el entorno Windows. En 2026, la herramienta más amigable para el usuario es “Ollama”. Proporciona una CLI intuitiva tipo Docker.

5.1 Instalación y ejecución

Descarga el instalador para Windows desde el sitio web oficial de Ollama y ejecútalo.
Abre PowerShell e introduce el siguiente comando. Aquí usaremos llama3:8b, que soporta japonés.

1

ollama run llama3:8b

En la primera ejecución, se descargará el modelo. Una vez finalizado, podrás interactuar directamente en la terminal.

5.2 Creación de una IA personalizada mediante Modelfile

Puedes crear fácilmente una IA con una personalidad específica. Crea un Modelfile en cualquier ubicación.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
Eres un ingeniero de software senior muy talentoso.
Al responder a las preguntas de los usuarios, debes incluir siempre ejemplos de código y responder de forma lógica y concisa.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Ejecuta el siguiente comando para compilar y ejecutar tu propio modelo.

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Uso desde aplicaciones externas (Editores de IA)

Ollama expone un punto de conexión de la API compatible con OpenAI en http://localhost:11434. Simplemente configurando esta URL en los ajustes de backend de extensiones de VS Code como Cursor o Continue.dev y especificando un modelo como SeniorDev, obtendrás un potente asistente de programación local y gratuito.

6. Práctica 2: Ajuste de rendimiento extremo con llama.cpp

Si quieres probar opciones como una gestión detallada de la memoria o los últimos formatos (EXL2, cuantización IQ, etc.) lo antes posible, interactúa directamente con el motor central, llama.cpp.

6.1 Pasos para compilar llama.cpp

En un entorno Windows, lo mejor es compilar desde el código fuente utilizando CUDA Toolkit y CMake.

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# Configurar para CUDA y compilar
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 Inicio avanzado en modo servidor

Utiliza el ejecutable llama-server.exe compilado para alojar el modelo.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99: Descarga (offload) todas las capas posibles a la VRAM de la GPU.
--flash-attn: Habilita FlashAttention 3, logrando una mejora en la velocidad de inferencia y una reducción en el consumo de VRAM por parte de la caché KV.

7. Interfaz gráfica (GUI): Construcción de LM Studio y RAG local

Si no te sientes cómodo con la línea de comandos o si deseas realizar RAG (Generación Aumentada por Recuperación) de manera intuitiva, puedes usar una GUI.

7.1 LM Studio

LM Studio es una excelente aplicación que integra la búsqueda y descarga de modelos, verificación previa de los requisitos del sistema y una interfaz de chat. Simplemente con presionar el botón “Local Server” en la aplicación, se levantará una API compatible con OpenAI.

7.2 Arquitectura RAG usando AnythingLLM

Este es un diagrama de la arquitectura de un entorno RAG para cargar documentos internos o notas personales.

graph LR Document["Documentos (PDF, MD)"] --> Chunking["División en fragmentos (Chunking)"] Chunking --> EmbedModel["Modelo de incrustación (Embedding)"] EmbedModel --> VectorDB["Base de datos vectorial"] UserQuery["Consulta del usuario"] --> EmbedQuery["Incrustación de la consulta"] EmbedQuery --> VectorDB VectorDB --> |"Búsqueda de similitud"| RetrievedDocs["Extracción de documentos relevantes"] UserQuery --> PromptBuilder["Generador de prompts"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["LLM local"] LocalLLM --> Answer["Respuesta final"]

Si usas la versión de escritorio de AnythingLLM (Windows), simplemente configurando Ollama (LLM y Embedding) desde la pantalla de configuración y utilizando la VectorDB local (LanceDB), esta arquitectura se completará en minutos. Así nace una IA privada que no envía ningún dato al exterior.

8. Fine-tuning en Windows WSL2 (LoRA)

Si además de ejecutarlo localmente quieres que el modelo sea más inteligente con tus propios datos, es posible realizar fine-tuning mediante LoRA (Low-Rank Adaptation). En 2026, utilizando la biblioteca “Unsloth”, se puede completar el entrenamiento de un modelo 8B en unas pocas horas en un entorno WSL2 de Windows, incluso con 16 GB de VRAM.

Ejecuta lo siguiente dentro de Ubuntu en WSL2 para preparar el entorno:

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

Unsloth optimiza los núcleos CUDA al extremo, y en comparación con la biblioteca estándar de Hugging Face, la velocidad de entrenamiento es aproximadamente el doble, mientras que el consumo de VRAM se reduce a la mitad. Al abrir un Jupyter Notebook y cargar un conjunto de datos (formato JSONL), el entrenamiento de varias épocas es posible incluso en una RTX 4060 Ti con 12 GB-16 GB de VRAM.

9. Resolución de problemas de rendimiento

Estos son los problemas más frecuentes a los que te puedes enfrentar y sus soluciones.

1. La velocidad de inferencia es extremadamente lenta (1-2 tokens/s)

Causa: El modelo no cabe en la VRAM y se está descargando (offloading) a la memoria del sistema (RAM). Solución: Verifica la “Memoria dedicada de la GPU” en el Administrador de tareas. Si se ha alcanzado el límite, reduce el tamaño del contexto (-c) o utiliza un modelo con cuantización de menos bits (como Q4_K_M).

2. Error de “CUDA out of memory”

Causa: La VRAM se ha agotado por completo. Esto ocurre especialmente cuando la interacción se prolonga y la caché KV aumenta de tamaño. Solución: Limita intencionadamente el valor de num_ctx en el caso de Ollama, o de -c en el caso de llama.cpp a un número menor.

3. La generación en japonés (u otro idioma) es extraña

Causa: Incompatibilidad en la plantilla del prompt, o el modelo no es compatible. Solución: Asegúrate de usar un modelo que contenga Instruct en su nombre y verifica que la herramienta tenga seleccionada la plantilla correcta especificada por el creador del modelo, como el formato ChatML o Llama3.

10. Conclusión y perspectivas de futuro

En 2026, la construcción de un LLM local en un entorno Windows ya no es un privilegio reservado para unos pocos ingenieros. Gracias a la estandarización del formato GGUF, la aparición de ecosistemas sofisticados como Ollama o LM Studio y las optimizaciones de hardware como FlashAttention, cualquier persona puede obtener fácilmente un entorno de IA de nivel empresarial.

Aprovecha los siguientes puntos explicados en este artículo:

Elegir lógicamente el tamaño del modelo y el nivel de cuantización óptimos para las especificaciones de tu PC utilizando el cálculo matemático de la VRAM.
Construir el entorno lo más rápido posible con Ollama y mejorar drásticamente la productividad vinculándolo con un editor de IA.
Extraer el rendimiento límite del hardware mediante el control avanzado de parámetros en llama.cpp.
Construir un sistema RAG local y seguro para manejar datos confidenciales con AnythingLLM.
Fomentar tu propia IA personalizada con conocimientos especializados aprovechando Unsloth (WSL2).

La “democratización” de la IA ya no es una palabra de moda; es un sistema real que funciona en tu escritorio de Windows. Libérate de los costes de uso de API en la nube y los riesgos de filtración de información, e ingresa hoy mismo al poderoso y libre mundo de la IA privada.