PreMarketML - Local Stock Market AI Predictor

Overview

PreMarketML is a local-only stock market prediction application designed for high-performance, dual-GPU analysis. It integrates ensemble ML models (LSTM, GRU, XGBoost, Random Forest, Transformer) for stock price prediction and utilizes multi-agent trading analysis through Ollama LLMs. The project prioritizes core functionality: ML training, charting, and AI trading agents, optimized for local GPU deployment, ensuring data privacy and performance without external cloud dependencies.

User Preferences

Preferred communication style: Simple, everyday language.

System Architecture

UI/UX Decisions

The application uses Streamlit for its reactive web interface, supporting dark and light themes. It is organized into 10 main workspaces with sub-tabs and interactive Plotly visualizations. st.session_state is used for managing application state.

Technical Implementations

All machine learning tasks are executed locally. PyTorch uses GPU for XGBoost/RandomForest/Transformer/Ensemble models. TensorFlow uses CPU-only for LSTM/GRU/BiLSTM models (via tensorflow-cpu package + tf_cpu_guard). Data preprocessing uses StandardScaler or MinMaxScaler with a sliding window approach. Multi-agent market analysis is facilitated by local Ollama LLMs through an OpenAI-compatible API. Key LSTM improvements include MCDropout, Conv1D+LSTM+MC Architecture, time-weighted training, and automatic batch optimization.

Feature Specifications

• Data Management: Live market data from Alpha Vantage and Kaggle datasets, with CSV upload support, auto-refresh, and smart caching. Prediction history is stored in SQLite.
• Prediction System: Utilizes LSTM/GRU/XGBoost/Random Forest/Ensemble models with Monte Carlo uncertainty.
• Market Insights: AI-driven analysis, narrative generation, and technical summaries.
• Options Lab: Black-Scholes-Merton pricing, Greeks analysis, and strategy building.
• Batch Lab: A queue-based system for batch analysis of multiple stocks with persistence via batch_jobs.db and a background worker supporting 6 model types.
• Full Report: Generates investor-friendly PDF/HTML/Markdown reports.
• Model Registry System: SQLite-based storage for trained model metadata and versioning.
• Remote Compute Offloading: Supports offloading heavy ML workloads to a personal FastAPI backend server.
• Compute Orchestrator: Hierarchical compute selection system routing tasks to the best available backend.
• Background Job System: Implements a "Run in background" toggle for predictions, queuing jobs to SQLite and processing them with a background worker for real-time progress tracking.
• AI Debate Optimizations: Features an OllamaClient wrapper, evidence pack builder, phase-parallel debate runner, and debate caching.
• DGX Spark Optimizations: Includes tf.data pipeline, batch autotune, mixed precision, resource-aware concurrency, structured logging, and unified job specifications.
• Hyperparameter Tuning System (v1.1.0): Comprehensive training configuration with 50+ parameters across all model types, featuring collapsible "Advanced Training Options" UI panels in both Predictions and Batch Lab tabs.

Hyperparameter Tuning System v1.1.0 Details

The TrainingConfigSchema v1.1.0 provides comprehensive hyperparameter configuration:

Core Parameters: epochs, batch_size, lookback_days, forecast_days, learning_rate, dropout Loss & Metrics: loss_function (mse/mae/huber), validation_metric Early Stopping: enabled, patience, min_delta, monitor LR Scheduler: enabled, factor, patience, min_lr RNN-Specific: gradient_clipnorm, weight_decay, dense_activation, num_layers XGBoost-Specific: subsample, colsample_bytree, gamma, min_child_weight, reg_lambda, reg_alpha, early_stopping_rounds Random Forest-Specific: max_features, min_samples_leaf, bootstrap Ensemble: ensemble_type (voting/bagging/stacking/blend), voting_weights

All trainers use config.get(key, default) pattern for backward compatibility with older configs.

System Design Choices

The application is 100% local-only, prioritizing data privacy and performance. There are no external authentication, payment processing, or cloud dependencies. The compute orchestrator manages task distribution across local GPU resources. The system also includes advanced optimizations for DGX Spark, such as pipeline versioning, Parquet-first data format, hybrid cuDF preprocessing, and XLA toggling for training stability.

External Dependencies

Machine Learning Frameworks

• TensorFlow-CPU: LSTM, GRU, BiLSTM model training (CPU-only via tensorflow-cpu package).
• PyTorch: Transformer models, GPU-accelerated (runs in NGC PyTorch container).
• XGBoost: Gradient boosting models, GPU-accelerated via PyTorch container.
• scikit-learn: Random Forest and data normalization.

Data Processing

• Pandas: Data manipulation.
• NumPy: Numerical operations.

Technical Analysis

• ta (Technical Analysis Library): Technical indicators.

Visualization & Web Framework

• Plotly: Interactive charts.
• Kaleido: PNG conversion of Plotly charts.
• Streamlit: Frontend and application server.

AI Services

• Dual Ollama Backend:
  • Thor (Jetson): Vision models, chart analysis.
  • GPU Server (x86 RTX A4500): Heavy LLMs, multi-agent analysis.
• OpenAI API: Optional intelligent CSV column mapping.

API Services

• Alpha Vantage API: Real-time and historical stock market data.

Data Sources

• Kaggle: S&P 500, MAANNG, and NASDAQ datasets.
• CSV file uploads: Manual data import.

3-Container GPU Architecture

All 3 containers use the same PyTorch NGC image (premarketml-ngc:25.12):

• web: Streamlit frontend
• batch_worker: Background ML/AI analysis jobs
• prediction_worker: Background prediction training jobs

GPU/CPU Split

• PyTorch: GPU-accelerated (XGBoost, RandomForest, Transformer, Ensemble models)
• TensorFlow: CPU-only (LSTM, GRU, BiLSTM models)

TensorFlow is forced to CPU via:

1. tensorflow-cpu package in requirements.container.txt (cannot use GPU even if present)
2. utils/tf_cpu_guard.py module that calls tf.config.set_visible_devices([], 'GPU') after import

Important: tf_cpu_guard does NOT set CUDA_VISIBLE_DEVICES (which would hide GPUs from PyTorch too).

Blackwell GB10 Optimizations

PyTorch TF32 is enabled for optimal Tensor Core performance:

torch.backends.cuda.matmul.allow_tf32 = True
torch.backends.cudnn.allow_tf32 = True
torch.backends.cudnn.benchmark = True

This avoids cuDNN/GPU conflicts on GB10/Blackwell while keeping PyTorch GPU-accelerated with TF32.

Docker Compose Configuration

services:
  web:
    image: premarketml-ngc:25.12
    gpus: all
    command: bash -lc "streamlit run app.py --server.address 0.0.0.0 --server.port 8501"

  batch_worker:
    image: premarketml-ngc:25.12
    gpus: all
    command: bash -lc "python batch_worker.py"

  prediction_worker:
    image: premarketml-ngc:25.12
    gpus: all
    command: bash -lc "python prediction_worker.py"

No WORKER_BACKEND environment variable needed - single image handles all model types.

Validation

Run self-test before starting:

python batch_worker.py --self-test

Expected output:

• torch.cuda.is_available() = True (PyTorch GPU enabled)
• tf.config.list_physical_devices('GPU') = [] (TF CPU-only)
• Exit code 0 = ready

Smoke Test Checklist (recommended after deploy)

1. Verify worker config:

python batch_worker.py --self-test

2. Confirm queue health:

python scripts/queue_status.py

3. Run a minimal batch:

• Run 1 ticker with technical_analysis only (fast, no GPU)
• Then run 1 ticker with lstm_prediction (validates TF CPU mode)
• Only after those succeed, run multi-ticker / overnight batches

Created with love, caffeine, and tears, hook a brotha up! https://buymeacoffee.com/danielcuevas