JSON_INPUT_OPTIONS.md

📊 Opciones para Enviar JSON a Triton Server

Opción 1: JSON como String (ACTUAL) ✅

Esto es lo que estamos usando ahora

{
  "inputs": [{
    "name": "raw_features",
    "shape": [1],
    "datatype": "BYTES",
    "data": ["{\"Region\":\"Sub-Saharan Africa\",\"Country\":\"Chad\", ...}"]
  }]
}

Ventajas:

• ✅ Flexible: puede manejar cualquier estructura JSON
• ✅ Simple: un solo input
• ✅ Fácil de mantener

Desventajas:

• ❌ Requiere escape de caracteres
• ❌ El JSON va como string dentro del array

---

Opción 2: Múltiples Inputs Separados 🔄

Cada campo del JSON como un input separado

Configuración del modelo (preproc_profit/config.pbtxt):

input [
  { name: "region", data_type: TYPE_STRING, dims: [1] },
  { name: "country", data_type: TYPE_STRING, dims: [1] },
  { name: "item_type", data_type: TYPE_STRING, dims: [1] },
  { name: "sales_channel", data_type: TYPE_STRING, dims: [1] },
  { name: "order_priority", data_type: TYPE_STRING, dims: [1] },
  { name: "order_date", data_type: TYPE_STRING, dims: [1] },
  { name: "ship_date", data_type: TYPE_STRING, dims: [1] },
  { name: "units_sold", data_type: TYPE_FP32, dims: [1] },
  { name: "unit_price", data_type: TYPE_FP32, dims: [1] },
  { name: "unit_cost", data_type: TYPE_FP32, dims: [1] },
  { name: "total_revenue", data_type: TYPE_FP32, dims: [1] },
  { name: "total_cost", data_type: TYPE_FP32, dims: [1] }
]

Petición curl:

{
  "inputs": [
    { "name": "region", "shape": [1], "datatype": "BYTES", "data": ["Sub-Saharan Africa"] },
    { "name": "country", "shape": [1], "datatype": "BYTES", "data": ["Chad"] },
    { "name": "item_type", "shape": [1], "datatype": "BYTES", "data": ["Office Supplies"] },
    { "name": "units_sold", "shape": [1], "datatype": "FP32", "data": [1000.0] },
    { "name": "unit_price", "shape": [1], "datatype": "FP32", "data": [20.5] }
    // ... resto de campos
  ]
}

Ventajas:

• ✅ Cada campo tiene su tipo de dato específico
• ✅ No requiere escape de JSON
• ✅ Validación de tipos en Triton

Desventajas:

• ❌ Más complejo de mantener
• ❌ Requiere cambios significativos en el modelo
• ❌ Menos flexible para campos opcionales

---

Opción 3: Usar gRPC con Protobuf 🚀

Cliente gRPC con definición de tipos fuerte

Cliente Python con gRPC:

import tritonclient.grpc as grpcclient

client = grpcclient.InferenceServerClient("localhost:8001")

# Los datos se pueden estructurar más naturalmente
inputs = []
inputs.append(grpcclient.InferInput("raw_features", [1], "BYTES"))

# Crear el JSON normalmente
data = {
    "Region": "Sub-Saharan Africa",
    "Country": "Chad",
    # ...
}

# Convertir a bytes
inputs[0].set_data_from_numpy(np.array([json.dumps(data).encode()], dtype=object))

Ventajas:

• ✅ Mejor rendimiento que HTTP
• ✅ Tipos más estrictos
• ✅ Streaming support

Desventajas:

• ❌ Requiere cliente gRPC
• ❌ Más complejo para debugging

---

Opción 4: Custom JSON Handler 🎯

Crear un endpoint personalizado que acepte JSON nativo

Crear un proxy servidor (FastAPI):

from fastapi import FastAPI
import tritonclient.http as httpclient
import json

app = FastAPI()

@app.post("/predict")
async def predict(data: dict):
    # Recibe JSON nativo
    # Lo convierte al formato de Triton
    client = httpclient.InferenceServerClient("localhost:8000")
    
    # Preparar para Triton
    inputs = [httpclient.InferInput("raw_features", [1], "BYTES")]
    inputs[0].set_data_from_numpy(np.array([json.dumps(data)], dtype=object))
    
    # Llamar a Triton
    results = client.infer("preproc_profit", inputs=inputs)
    
    return {"prediction": results.as_numpy("processed_features").tolist()}

Uso:

curl -X POST http://localhost:8080/predict \
  -H "Content-Type: application/json" \
  -d '{
    "Region": "Sub-Saharan Africa",
    "Country": "Chad",
    "Item_Type": "Office Supplies",
    "Sales_Channel": "Online",
    "Order_Priority": "M",
    "Order_Date": "2024-11-23",
    "Ship_Date": "2024-11-26",
    "Units_Sold": 1000.0,
    "Unit_Price": 20.5,
    "Unit_Cost": 15.0,
    "Total_Revenue": 20500.0,
    "Total_Cost": 15000.0
  }'

Ventajas:

• ✅ JSON nativo sin escape
• ✅ API más amigable
• ✅ Puedes agregar validación adicional

Desventajas:

• ❌ Capa adicional de complejidad
• ❌ Latencia adicional
• ❌ Otro servicio para mantener

---

📝 Recomendación

Para tu caso, recomiendo:

1. Si necesitas simplicidad: Mantén la Opción 1 (actual) con JSON como string
2. Si necesitas JSON nativo en curl: Implementa la Opción 4 (proxy FastAPI)
3. Si necesitas máximo rendimiento: Usa la Opción 3 (gRPC)
4. Si tienes campos fijos y tipos estrictos: Considera la Opción 2 (múltiples inputs)

La mayoría de implementaciones en producción usan la Opción 1 o crean un proxy (Opción 4) para mayor comodidad.