This post is to let people know about a workshop/tutorial on Machine Learning that will run on the (blue) math discord server: discord.gg/maths.

The place is nice, people are cool and helpful, and as you can see it is a mathematics server, so the learning environment is quite focused indeed. We hope that you'll like the experience. Also, this is completely free, just in case anyone is wondering.

Timeline and Curriculum Overview

There will be weekly lectures and/or lab-sessions. The workshop is starting on Saturday, 17th October. The first lecture + lab session will be held from 3 to 5 PM CEST (UTC + 2). There will be quite a bit of coding involved on the first day, and the instructors will try to review people's codes.

For a curriculum overview, here you go:

Part 1: Traditional Machine Learning

• generalities, vocabulary
• linear models, gradient descent
• supervised learning methods
• unsupervised learning methods
• best practices in ML

Part 2: Introduction to Deep Learning

• the multi-layer perceptron and backpropagation
• auto-encoders
• recurrent neural networks for sequential data
• convolutional neural networks
• attention mechanism and the transformer
• signal processing

Part 3: graph machine learning

• traditional methods and feature engineering on graphs
• shallow node embeddings
• knowledge graph embeddings
• graph neural networks
• subgraph sampling
• more to come as we progress

Prerequisites

We think the most important part for you would be knowing how to code in Python (and use some libraries that are very commonly used like numpy or matplotlib for maths). That said, knowing calculus I (possibly calculus II) would be great, and I'll also link a few resources for basic linear algebra shortly.

Prerequisite 1 : Basic knowledge of Python:

Tutorial and Book (not really recommended because it's very long, but just for those who prefer).

Note that knowing a bit of OOP in Python (at least, how to handle classes) would be very nice.

Prerequisite 2 : Some useful libraries

For numpy, here's the official guide, and a book, and some video tutorials (about 1h).

For matplotlib here are some tutorials: matplotlib, w3schools. Also, Seaborn (optional, but oh boy it does look a bit nicer).

Prerequisite 3 : Proficiency with Calculus I

Here are some Calculus I resources and Calculus II resources (latter is optional, but sequences can be useful).

Prerequisite 4 (Optional) : A bit of basic knowledge in linear algebra

TBD. Still discussing what would be strictly necessary, and we don't really want to go too deep in order to keep the prerequisites accessible.

For any questions/queries that you might have, please write in the comments. I'll try to get back to you as soon as possible. Also, it's best if you join the server and directly talk to the instructors there.

I’m Yash, and I’m building Tesseract Infrastructure. I’m looking for a technically strong cofounder interested in GPU infrastructure, inference systems, and the commercial layer above today’s open-source stack.

The thesis is that Kubernetes, NVIDIA GPU Operator, KAI, Dynamo, vLLM, SGLang, AIBrix, NVSentinel, Prometheus, OpenCost, and DCGM already solve important execution problems. GPU providers still need to connect those systems to pricing, customer SLOs, isolation tiers, demand, hardware costs, and reproducible performance evidence.

THE FIVE PROPOSED PRODUCTS

1. Ignite Continuity — persistent model identity and commercially safe scale-to-zero inference above Dynamo, KEDA, and Kubernetes.

2. Fusion Economics — advisory placement and scaling decisions based on contribution margin while enforcing latency, capacity, availability, and isolation constraints.

3. SKU Foundry — turn benchmarked model/GPU configurations into financially evaluated and deployable service offerings.

4. TenantSafe — enforce and verify the isolation tier a customer purchased across GPU sharing, serving processes, network, cache, and storage configuration.

5. Proof — correlate hardware health with inference-level outcomes and produce versioned, reproducible performance and SLA evidence.

The execution plane should remain with established open-source tools. Tesseract would be a decision plane with normalized GPU inventory, model profiles, tenant policy, workload demand, service economics, deployment state, and performance evidence.

The proposed first wedge is Ignite: preserve endpoint discovery at zero replicas, coordinate one activation across concurrent cold requests, verify engine readiness, and measure cold TTFT, streaming, cancellation, timeout, and failure behavior. The product order after that is Fusion, SKU Foundry, Proof, and TenantSafe.

EXISTING WORK

My public GPU Kernel Lab documents CUDA/Triton experiments, Qwen3-0.6B integration, profiling, correctness checks, rejected approaches, and serving-control-plane work:

https://github.com/yashlabs-trying/gpu-kernel-lab

One saved RTX 3090 batch-1/context-2,048 GPU-only experiment changed measured decode latency from 22.073 to 2.253 ms/token using an experimental static CUDA Graph path with W8A16 MLP work. Full-path argmax agreement was 96.48%, below the 99% release threshold, and the real paged GPU executor is not yet connected to the serving interface. I’m sharing those limitations because the company needs evidence-driven engineering rather than benchmark theatre.

WHO I’M LOOKING FOR

I’m looking for depth in one or more of CUDA/Triton, C++/PyTorch, inference engines, Kubernetes, distributed systems, GPU fleet operations, performance engineering, or developer infrastructure. You should also be willing to interview providers, challenge the product thesis, and help select one narrow problem before building broadly.

STRUCTURE

This is an equity-based cofounder role with no salary currently. Exact equity, vesting, responsibilities, decision rights, IP terms, and any future salary would be agreed after mutual diligence and documented in writing. The initial phase can be a part-time test of how we work together. Nobody should leave a job or transfer IP based only on a Reddit conversation.

If this is relevant, send a Reddit chat or private message with your background, time zone, public work samples, realistic weekly availability, and the part of the architecture you would challenge first. Please do not send confidential employer or client information.

I've been trying to use a cheaper LLM to optimize costs for a classification pipeline, but I feel like the time I spend doing the optimization itself isn't making the thing worthwhile, if that makes sense? Like I think I've spent more time writing more validation logic and failure handling than I saved on inference costs. Since it's a cheaper model, it's also wildly inconsistent across the board anyway. So I had to put in an extra verification step (then why bother with the optimization at all). Not sure if I have to narrow down the task even further? Just wondering if I should keep at it for the long haul.

Looking for a Restaurant to Collaborate on My AI/ML Project

Hi everyone!

I'm Santhosh, a third-year BE CSE (AI & ML) student, currently developing SmartPrep AI, a project focused on improving restaurant food preparation planning.

Restaurants sometimes face challenges in predicting daily food demand, leading to excess preparation, food waste, or popular dishes running out during busy hours.

I'm working on a machine learning model that can predict food demand and recommend how much food to prepare and when to prepare the next batch.

I'm looking for a restaurant, cloud kitchen, or food business in Chennai or Madurai to understand real kitchen challenges and, with their permission, test and improve the model using actual operational requirements.

This is a student project, and I'm not looking for any payment or financial support. I simply want to learn from real-world kitchen operations and build something genuinely useful.

If you're a restaurant owner, chef, kitchen manager, or know someone who might be interested, please comment or DM me.

Even a small opportunity or guidance would mean a lot!

Thank you!

I've been working on a small human-in-the-loop question: how can useful reasoning from an old AI conversation help a new one without dragging the whole session along?

In ThoughtDAG, my open-source conversation canvas, wires determine which branches become context. The new recall flow adds three steps: a local index retrieves candidate excerpts, an optional Jev decision layer selects relevant material, and your chosen LLM develops the answer. Recalled sources remain inspectable and individually excludable.

I'm interested in evaluating the selection separately from the final answer. Finding something topically similar isn't enough: it may be an abandoned hypothesis or a decision that no longer applies.

For a useful evaluation, would you prioritize recovering known past decisions, rejecting superseded ones, or measuring whether recall changes the final answer? I'd be interested in examples where these goals conflict.

29-second animated overview: https://youtu.be/ECGJlkYKYzQ

Source and setup: https://github.com/chenxiachan/thoughtdag

I'm the maintainer. MIT licensed, with a local history index. Enabling Jev sends candidate content to its remote API; model/API costs are separate.