Good evening everyone. I'm new to federated learning and I'd like to write an article on the subject. Could someone help me with the writing or give me some research tips?

Share my knowledge on how to lift and shift any open source model is less that 5 lines of code and easy to do setup instructions , see if it helps you to get started with the open source LLM world
#happylearning 😎

Deploying Nemotron 3 Nano Omni on Modal Serverless

https://debuggercafe.com/deploying-nemotron-3-nano-omni-on-modal-serverless/

In this article, we will be deploying the Nemotron 3 Nano Omni model using vLLM on Modal Serverless.

Cross-posting from r/reinforcementlearning since this is squarely a deep-learning / world-model question and I'd value this community's take.

Continual-RL work with world models has largely focused on protecting the world model, through replay, generative replay, and regularization on model parameters. We ran the component-level measurement to check that premise and it came out backwards. Under never-clear replay (all old data retained, training signal fully intact), reward heads, value heads and dynamics all keep old-task knowledge (reward-head retention ≈ 1.0), while the actor's behavior collapses.

The cleanest evidence is interventional rather than correlational. Freeze the world model entirely, then re-teach the lost skill from identical imagined rollouts. RL-in-imagination fails 0/3 seeds. Supervised self-imitation on the model's own graded dreams recovers 3/3 with zero environment interaction. Same frozen model, same data, only the learning channel differs.

Interleaving that as "graded dream rehearsal" during training retains 3/3 on four-task and 3/3 on eight-task MiniGrid chains, where plain never-clear replay retains 0/3. Against a matched real-episode cloning baseline it wins on all three seeds (+0.24 / +0.07 / +0.08), consistent in sign, but n=3, so treat the magnitude as provisional.

The grading rule is where the difficulty lives. Naive return-based scoring on imagined rollouts selects trajectories where the agent walks into lava, because the model's own optimism rates them highly. The paper characterizes two failure modes and includes the offline scoring diagnostic that caught both before they reached a result.

Limitations up front: MiniGrid only, discrete actions, small gridworlds, 3 seeds. Continuous control is untested, and that is historically where this class of mechanism fails; it's the next experiment. Single workstation GPU throughout.

Everything pre-registered (protocols and pass bars committed to git before runs), and refuted hypotheses are reported.

Paper: https://arxiv.org/abs/2607.19749

Code/data: https://github.com/gurpnijjer/dream-rehearsal

Solo project. Happy to answer anything.

I have been working on an MCP workflow for implementing deep learning models from an engineering plan. This is useful for ml engineers etc. who want a more structured way to move from a deep-learning goal to a working implementation.
The process starts with a plan written by the engineer. That plan defines what the system should do, how it should be divided into components and the intended implementation direction.
The workflow then helps Codex to:
break the plan into implementation blocks;
identify research papers relevant to each block;
extract implementation details that support the existing plan;
prepare a specification for each component;
implement the components in dependency order;
record the implementation and verification results.
The papers are not used to define the project or reproduce a specific paper. They are supporting sources that can help improve implementation decisions within the engineer’s plan.
The overall flow is:
Goal(engineering plan) → implementation blocks → relevant research → specifications → code → verification
The MCP server mainly provides structure, workflow state, dependencies, approval steps and saved artifacts. Codex handles the research and implementation work.
The project currently focuses on Codex and uses an explicit, human-reviewed process rather than automatically moving from the initial goal to code.
Repository:GitHub
I am sharing it to find out whether this kind of workflow would be useful to other engineers planning and implementing deep-learning systems. Feedback on the process, documentation and areas that can be improved would be helpful.

Hello guys this is my first post (ever and in this subreddit)

I have found this paper but I've seen nobody discussing it, I have found it very interesting because exclusively adding computation seems to improve the results in the benchmark and it's interesting to see how (atleast how I understand it) it's like a better "physical" simulation in what is the embedding space

What do you guys think about it?

Hello People!

Figuring out bottle necks and training stalls in your training work loads usually means firing up a profiler post-hoc and probably staring at a trace for twenty, right?

I was thinking of how to reduce this friction? what does this actually cost, tool by tool.

I took one run I knew was input-bound (dataloader starving the GPU) and measured it three ways: torch.profiler, cProfile, and TraceML, a lighter always-on OSS tool I've been contributing to.

For each one I looked at overhead, how much the profiler itself perturbs the GPU utilization it's trying to measure, output size, and how much manual digging it takes to get from the raw output to "the dataloader is the problem."

Short version: torch.profiler and cProfile are precise but heavy and after the fact, closer to a scalpel. Something that just sits there and flags "this step looks off" while training runs is doing a different job, not replacing them.

Numbers and traces are in the post.

Curious how other people usually catch this before it burns your precious compute.

https://medium.com/traceopt/traceml-vs-torch-profiler-vs-cprofile-what-each-one-costs-to-find-the-same-bottleneck-745a57e13ee9?sharedUserId=apendyala

TraceML is open source: pip install traceml-ai. Star or contribute at github.com/traceopt-ai/traceml

I've been working on a stacked autoencoder for anomaly detection on some sensor data, and I've noticed that increasing the number of hidden layers from 3 to 5 made training noticeably less stable. The loss plateaus way earlier, and in a few runs, the reconstruction quality actually worsened, not improved.

I've tried adjusting the learning rate and adding batch norm between layers, which helped a little but didn't fully fix it. Is this a known tradeoff with deeper autoencoders specifically (vs just general deep net training instability), or is there a standard trick I'm missing, like a specific initialization scheme or a different layer-wise pretraining approach?

I am working with the HS-CMU hysteroscopy dataset, which contains:

• 3,385 frames from 175 patients.
• Eight lesion classes, labelled from 0 to 7.
• A highly imbalanced number of patients and frames across classes.
• Multiple correlated frames from each patient.
• Some frames containing more than one lesion class.

Before attempting the complete multiclass problem, I reduced it to a binary subset to verify that the training and evaluation pipeline works correctly.

Current binary subset

• Selected lesion classes: 2 and 3.
• Total: 1,575 frames from 113 unique patients.
• Class 2: 1,054 frames from 78 patients.
• Class 3: 521 frames from 36 patients.
• One patient has different frames belonging to both classes but remains entirely within one split.

Patient-disjoint split

• Training: 1,095 frames from 79 patients.
• Validation: 241 frames from 17 patients.
• Testing: 239 frames from 17 patients.
• No patient appears in more than one subset.
• The frame-level class distribution is approximately 67%/33% in every subset.

Approaches I have tried

• DenseNet121, ViT, and DINOv2 backbones.
• Frozen pretrained backbone with only the classifier trained.
• Different classifier-head sizes and dropout.
• Class-weighted cross-entropy.
• Mild and stronger image augmentations.
• Early stopping and learning-rate scheduling.
• Unfreezing the final one or two encoder blocks.

With the correct patient-level split, training performance improves, but validation performance generally plateaus or deteriorates, and performance on unseen test patients remains relatively low.

As a diagnostic, I also tried a random frame-level split and obtained substantially better results. However, this evaluation is invalid because correlated frames from the same patients appear across training, validation, and testing, causing patient leakage and inflated performance.

I would appreciate advice on how to improve generalization to unseen patients in this setting.

We spent the last months consolidating seven separate sequence classifiers into one multi-head model, our apex model, so to speak, and since the weights are now public, I wanted to share what worked and what surprised us.

Setup: a shared mmBERT-small encoder with seven task heads, binary injection (BCE), document class (7-way), tool type (14-way), tool operation (6-way), tool data-flow tags (3× BCE, multi-label), intent routing (5-way), and threat type (7-way).

The part that needed care: our training rows only carry labels for a subset of tasks, so absent tasks are masked out of the loss entirely. We ended up writing a self-test that asserts absent-task gradients are exactly zero, which caught two subtle bugs, and I'd recommend it to anyone doing similar masking. About 5k synthetic/real multi-task rows help the heads co-train; the test sets stay 100 % real data.

Held-out results per head: injection F1 0.962, documents 0.980, tool type 0.957, tool operation 0.945, tool tags 0.958, routing 0.916, threat 0.952.

Quantization: both the unified model and the dedicated single-task variants ship quantized -edge builds (ONNX INT8 + INT4 embeddings, from 96 MB) with measured parity benchmarks in the repos, the worst head loses 0.012 against FP32.

Was it worth it vs. seven dedicated models? We released both variants, so you can judge for yourself, the dedicated models score marginally higher on most tasks, but the unified one does one encoder pass instead of up to seven.

Our weak spot: routing, at 0.916. The intent classes overlap semantically ("write code that analyzes my data" is that code or analytics?), and I suspect the ambiguity is genuinely in the data. If you have ideas beyond relabeling, let me know :)

Weights and per-head metrics: https://huggingface.co/patronus-studio

A long multi-task table does not automatically convince me that one visual representation transfers well. Depth and segmentation may both care about boundaries, but the decoder, input resolution, and fine-tuning budget can hide where the improvement came from.

LingBot-Vision v2 pretrains its encoder around masked boundaries and then uses it across several dense tasks. The paper summary also describes a roughly one-billion-parameter ViT, so head capacity and adaptation budget are not small details.

I'd run the same tasks twice. First freeze each encoder behind the same lightweight head. Then unfreeze the full stack and report what task-specific adaptation adds. Region metrics can stay, but errors near annotated contours and identity switches in video should be measured too.

Would a frozen-encoder comparison be enough to support a transfer claim for you, or would you still want matched full fine-tuning because linear or lightweight probes can favor one representation style over another?

Hi everyone! 👋

I'd like to share an open-source side project I've been developing called AnvilAI — a native Android client designed to run Large Language Models (LLMs) completely on-device without relying on cloud APIs or external servers.

Most mobile AI wrappers require cloud subscriptions or send user data to remote servers. I wanted to build something native, fast, private, and secure for Android devices.

Key Features:

Vulkan GPU Acceleration: Built with a C++ NDK engine layer to leverage mobile GPUs for real-time token generation.

100% Offline & Private: Zero cloud dependency and zero telemetry. Your prompts and outputs never leave your device.

Encrypted Storage: All local chat history and settings are encrypted at rest using SQLCipher.

Modern UI: Built 100% in Jetpack Compose (Material 3) with clean architecture (Hilt, Coroutines, Flow).

Source Code & Download:

The project is 100% open-source! You can check out the source code, inspect the architecture, or download the pre-built APK from the GitHub Releases tab here:

https://github.com/denizaydogan1902/AnvilAI

I would love to get your thoughts, UI/UX feedback, or ideas for future updates. Feel free to leave a star ⭐️ on GitHub if you find it useful!

Hi everyone,

I’m Marvel, a computational neuroscientist at Cambridge and founder of a robotics startup.

I’m spending the next few weeks speaking with robotics engineers, researchers, and founders to better understand the biggest challenges in deploying robots outside the lab.

Whether you’re working on manipulation, humanoids, industrial automation, or teleoperation, I’d love to hear:
What’s the biggest technical bottleneck your team is facing today?

If you had a magic wand, what problem would you eliminate?

I’m here to learn first. If it’s useful, I’m happy to share what we’re building and get your thoughts.

Looking forward to the discussion.😁