TsMixer, AspNet, Deploy, ONNX
https://vkvideo.ru/playlist/-145052891_441/video-145052891_456247227?linked=1
https://drive.google.com/drive/folders/1ZOYpTUa82_jCcxIdTmyr0LXQfvaM9vIy
F:\downloads\Otus\ML\TsMixter
Я думаю что лучше будут сделать все в одном стэке технологий AspNetCore и не взаимодействоать с MLOps Python в реальном времени с обученной моделью.
1. Python MLOps - мы оставляем и выполняем в этой среде все необходимые действия для создания, обучения нейросетевой модели. Создаем универсальную модель.
2. Мы помещаем обученную модель в AspNetCore. Для использования этой модели в реальном времени. И в дальнейшем взаимодействие в реальном времени других проектов AspNetCore c этой моделью уже будет происходит в одинаковом стэке технологий. Поэтому нам будут доступны любые методы взаимодействия с этой моделью, потому что технология одна и та же.
Ваша идея — консолидировать ML‑логику внутри .NET‑экосистемы — вполне рациональна в ряде сценариев. Разберём плюсы, минусы, технические ограничения и практические способы реализации.
Почему это может быть выгодно
Ключевые преимущества:
Единый стек: нет межсервисных вызовов, очередей, контрактов API.
Простота деплоя: одно приложение вместо двух (или более) сервисов.
Низкая задержка: инференс выполняется в том же процессе, без HTTP/очередей.
Отладка: единый стек вызовов, общие логи, профилирование.
Безопасность: нет открытых API для ML‑модели.
Упрощённое CI/CD: один репозиторий, один пайплайн.
Критические ограничения
Что может помешать:
Отсутствие .NET‑реализаций моделей
Многие современные архитектуры (LLaMA, Stable Diffusion, YOLO v8 и др.) существуют только в Python (PyTorch/TensorFlow/Hugging Face).
Порт на .NET часто невозможен или требует огромных усилий.
Производительность инференса
Python‑фреймворки оптимизированы под GPU/TPU. В .NET аналоги (например, ONNX Runtime) могут уступать по скорости.
Для тяжёлых моделей (свыше 1 ГБ) задержка может стать неприемлемой.
Обновление моделей
Экосистема ML‑инструментов
Нет аналогов MLflow, Weights & Biases, TensorBoard в .NET.
Сложность мониторинга drift данных, качества предсказаний.
Технические варианты реализации
Вариант 1. ONNX Runtime (универсальный формат)
Как работает:
Обучаете модель в Python (PyTorch/TensorFlow/scikit‑learn).
Конвертируете в формат ONNX (torch.onnx.export, tf2onnx).
Деплоите ONNX‑модель в ASP.NET Core.
Используете Microsoft.ML.OnnxRuntime для инференса.
Плюсы:
Минусы:
Пример кода (.NET):
using Microsoft.ML.OnnxRuntime;
using Microsoft.ML.OnnxRuntime.Tensors;
var session = new InferenceSession("model.onnx");
var input = new DenseTensor<float>(new[] { 1, 784 });
var inputs = new List<NamedOnnxValue> { NamedOnnxValue.CreateFromTensor("input", input) };
var outputs = session.Run(inputs);
Вариант 2. TensorFlow.NET (прямая интеграция)
Как работает:
Плюсы:
Минусы:
Вариант 3. ML.NET (собственные модели)
Как работает:
Плюсы:
Полный контроль над кодом.
Интеграция с DI, логами, метриками.
Минусы:
Ограниченный набор алгоритмов (нет трансформеров, GAN и т.п.).
Подходит только для простых задач (классификация, регрессия).
Когда это оправдано
Выбирайте .NET‑инференс, если:
Модель небольшая (до 500 МБ) и не требует GPU.
Используется классический ML (логистическая регрессия, деревья решений).
Критична минимальная задержка (например, real‑time сканирование).
Команда владеет только .NET, нет Python‑специалистов.
Безопасность требует изоляции модели внутри приложения.
Когда лучше оставить Python
Не переводите в .NET, если:
Модель основана на трансформерах (BERT, GPT, CLIP).
Требуется GPU/TPU для инференса.
Планируются частые обновления модели.
Нужны инструменты MLOps (A/B‑тестирование, мониторинг drift).
Модель весит больше 1 ГБ.
Практические рекомендации
Протестируйте ONNX Runtime
Возьмите вашу Python‑модель, конвертируйте в ONNX, запустите в .NET.
Сравните скорость и точность с Python‑версией.
Оцените размер модели
Продумайте обновление моделей
Добавьте мониторинг
Логируйте входные данные, предсказания, время инференса.
Используйте IHostedService для фонового сбора метрик.
Рассмотрите гибридный подход
Итог
Ваш план возможен, но с оговорками:
ONNX Runtime — лучший компромисс для переноса Python‑моделей в .NET.
ML.NET подойдёт только для базовых сценариев.
TensorFlow.NET — рискованный выбор из‑за ограничений производительности.
Рекомендация:
Протестируйте ONNX‑конвертацию для вашей модели.
Замерьте метрики (скорость, точность, потребление памяти).
Если результаты удовлетворительны — переносите в ASP.NET Core.
Если нет — оставьте Python‑сервис с REST/gRPC‑API.
Я планирую использовать tsmixer
Использование TSMixer в ASP.NET Core‑экосистеме
TSMixer — современная архитектура для временных рядов (на базе трансформеров), изначально реализованная в Python (обычно на PyTorch/TensorFlow). Разберём, как интегрировать её в .NET‑проект с минимальными потерями.
Почему прямой перенос в .NET сложен
Нет native‑реализаций
Сложная архитектура
Зависимости от Python‑экосистемы
Варианты интеграции
Вариант 1. ONNX Runtime (оптимальный компромисс)
Схема:
Обучите TSMixer в Python (например, через tsmixer-pytorch).
Экспортируйте в ONNX.
Деплойте в ASP.NET Core через Microsoft.ML.OnnxRuntime.
Шаги:
Экспорт в ONNX (Python):
import torch
from tsmixer import TSMixer
model = TSMixer(...)
model.eval()
dummy_input = torch.randn(1, seq_len, n_features)
torch.onnx.export(
model,
dummy_input,
"tsmixer.onnx",
export_params=True,
opset_version=14,
do_constant_folding=True,
input_names=["input"],
output_names=["output"],
dynamic_axes={"input": {0: "batch_size"}}
)
Инференс в .NET:
using Microsoft.ML.OnnxRuntime;
using Microsoft.ML.OnnxRuntime.Tensors;
var session = new InferenceSession("tsmixer.onnx");
var input = new DenseTensor<float>(new[] { 1, seqLen, nFeatures });
for (int i = 0; i < seqLen; i++)
for (int j = 0; j < nFeatures; j++)
input[0, i, j] = normalizedData[i, j];
var inputs = new List<NamedOnnxValue> {
NamedOnnxValue.CreateFromTensor("input", input)
};
using (var results = session.Run(inputs))
{
var output = results[0].AsTensor<float>();
}
Плюсы:
Сохраняете Python‑обучение.
Минимальные изменения в .NET‑коде.
Поддержка GPU (через ONNX Runtime с CUDA).
Минусы:
Вариант 2. HTTP API (Python‑сервис + .NET‑клиент)
Схема:
Запустите TSMixer как FastAPI‑сервис на Python.
Вызывайте его из ASP.NET Core через HttpClient.
Python (FastAPI):
from fastapi import FastAPI, HTTPException
import torch
from tsmixer import TSMixer
app = FastAPI()
model = TSMixer(...).eval()
@app.post("/predict")
def predict(data: dict):
x = torch.tensor(data["sequence"]).unsqueeze(0)
with torch.no_grad():
y = model(x)
return {"prediction": y.squeeze().tolist()}
.NET (клиент):
public async Task<float[]> PredictAsync(float[][] sequence)
{
var payload = new { sequence = sequence };
var response = await _httpClient.PostAsJsonAsync("/predict", payload);
var result = await response.Content.ReadFromJsonAsync<PredictionResponse>();
return result.Prediction;
}
Плюсы:
Никаких ограничений на архитектуру модели.
Лёгкое обновление модели (передеплой Python‑сервиса).
Встроенные метрики (Prometheus в FastAPI).
Минусы:
Вариант 3. Docker‑контейнер с Python + IPC
Схема:
Упакуйте Python‑модель в контейнер с REST/gRPC‑API.
Запустите рядом с .NET‑приложением (в Kubernetes/Docker Compose).
Взаимодействуйте через локальный HTTP или Unix‑сокеты.
Плюсы:
Минусы:
Рекомендации
Начните с ONNX Runtime
Если ONNX не подходит — FastAPI
Для production — гибридный подход
Автоматизируйте пайплайн
Инструменты для мониторинга
ONNX: ONNX Model Checker, Netron (визуализация).
FastAPI: Prometheus + Grafana (задержка, ошибки).
.NET: Application Insights (логи, метрики).
Итог:
Для TSMixer в .NET‑экосистеме:
Попробуйте ONNX — если работает, это самый чистый вариант.
Иначе — FastAPI‑сервис — надёжно и масштабируемо.
Не пытайтесь переписывать TSMixer на C# — слишком трудозатратно и неоптимально.