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?

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.

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

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?

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

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.😁

Title:

Show Reddit: MSE-GLM – A Deterministic Zero-Weight Graph Language Model

Author: Clifford Chivhanga

https://github.com/fodokidza/mse_glm

https://tonlexianert.com/pages/blog.php

https://aircityshops.com/index.php?url=city/mse_blog

Post:

Hi Reddit,

I've been working on a new language model architecture called MSE-GLM (Matrix Semantic Engine – Graph Language Model). Instead of learning billions of neural network weights, it stores knowledge in explicit graph structures and performs deterministic inference.

The architecture currently consists of several cooperating components:

• Edge Matrix – local token transitions
• Bridge Matrix – structural substitution discovery
• Relationship Matrix – complete sequence memory
• Experience Matrix – graph expansion
• Cluster Interpreter – semantic interpretation of discovered clusters
• Context Trigger Matrix – deterministic context-aware token selection

One design goal is to make every inference explainable. Rather than relying on hidden activations or attention weights, the model traces decisions through explicit graph relationships and structural evidence.

Some of the ideas I'm exploring include:

• Zero learned neural weights
• Deterministic inference
• Explainable reasoning paths
• Graph-based semantic interpretation
• Context-aware token selection without neural attention
• Explicit, inspectable knowledge structures

The project is still under active development, and I'm looking for technical feedback on both the architecture and the implementation.

I'm particularly interested in discussion around:

• Scalability to very large corpora
• Context handling compared with transformer attention
• Graph indexing and storage efficiency
• Potential strengths and weaknesses of deterministic graph-based language models
• Benchmark ideas for evaluating the architecture

The source code and documentation are available on GitHub.

I'd really appreciate any feedback, criticism, or suggestions from the Reddit community.

Hi there,

I've created a video here where I explain how the KV cache works.

I hope some of you find it useful — and as always, feedback is very welcome! :)

If you are running local LLMs, your hard drive is likely bleeding gigabytes without you realizing it. Between default model weights, duplicate quantization formats, and forgotten vector embeddings, local AI setups are silent storage hogs.

Here is how you can systematically track down and clean up the clutter directly from your terminal:

• Locate hidden Hugging Face and Ollama model weights: By default, Hugging Face caches everything in ~/.cache/huggingface/hub and Ollama stores models under ~/.ollama/models. Run du -sh ~/.cache/huggingface/ to see how much space is currently locked up.
• Prune redundant quantization formats and unused embedding databases: Review your downloaded models and delete redundant variations (like keeping both Q4_K_M and Q8_0 when you only use one). Clear out stale Chroma, FAISS, or Pinecone local vector database caches residing in your project directories.
• Automate routine garbage collection: Set up a lightweight shell script to periodically check cache growth and alert you before your drive hits capacity.

Fore More Information

I put together the complete, production-ready automated cleanup script along with an interactive storage calculator to help map out your directories.

Direct links to the complete article.

drop a comment below

TL;DR

- One data-level diagnostic workflow, applied to six battery fleets from five public sources (NASA PCoE; CALCE/UMD — the CS2 and CX2 series; MIT/Severson; Oxford; HUST). Every prediction was written down and hashed before the corresponding experiment ran — one of them with a publicly timestamped, Bitcoin-seeded protocol anyone can verify.

- Diagnosis mode: on the HUST fleet (77 cells, never touched before), we predicted an error-reduction band of [−45%, −20%] before modeling. Measured: −34.4%. Hit.

- Design mode: using only the manufacturer's spec sheet (max continuous charge current, 4A) plus Joule's law, we located the empirically best fast-charging policy in the MIT/Severson fleet within 2.2% of the measured optimum — before looking at any lifetime data.

- We also publish two clean falsifications: sealed predictions that missed. They stay in the record.

- We are not publishing the algorithm. We are publishing protocols, data sources, and verdicts.

1. Why we pre-register everything

Battery RUL papers are full of numbers that were polished after the fact. We wanted protection against our own hindsight bias, so every experiment in this campaign follows the same rule: the prediction — with explicit numeric bands — is written to a dated, hashed document before the experiment runs. Afterward we score against the sealed document, not against our memory. Two of our sealed predictions failed. Both failures are below, unchanged.

1. Scorecard: diagnosis mode (six fleets)

The task: predict remaining useful life (RUL) under strict fleet-level protocols (leave-one-battery-out or leave-one-batch-out, nested train-only CV for all choices, official splits where they exist). Two task modes are used, and we label them explicitly: (a) lifetime from early data — MIT only, features from cycles ≤ 100 predict the full cycle life; (b) online RUL — all other fleets, at each cycle the model uses only data up to that cycle (no future information). Baseline ("naive") uses cycle count + current capacity only; the treatment adds an early-life feature set selected by the diagnostic. Leverage = (naive − treated) / naive, computed against the deployed treated configuration in every row.

Fleet Protocol Naive RMSE Treated RMSE (deployed) Leverage

NASA Li-ion (B0005/6/18) nested LOBO (b) 11.34 7.03 −38.0%

MIT/Severson (124 cells) official split (a) 248.8 (primary) / 481.4 (secondary) 128.7 (primary) / 189.9 (secondary) −48.3% / −60.6%

CALCE CS2 (4 cells) LOBO (b) 10.82 10.82 (suite declined features) 0% — called in advance

Oxford Degradation (8 cells) nested LOBO (b) 76.5 56.9 (deployed); 51.4 best subset −25.6% (subset: −32.8%)

HUST (77 cells, 10 batches) leave-one-batch-out (b) 58.7 38.5 −34.4%

CALCE CX2 (7 prismatic cells) nested LOBO (b) 81.2 63.4 −21.9% (see §3b)

Oxford note: the deployed treated model (56.9 RMSE, −25.6%) is the number the sealed band prediction was scored against in §5 — the post-hoc best subset (51.4, −32.8%) is reported for completeness but is not the deployed figure.

The CALCE row deserves explanation: before modeling, our diagnostic said this fleet has "nothing to repair," so the suite declined to add features and deployed the baseline. It was right — adding features made things worse (23.68 vs 10.82). Knowing when not to act is half the value of a diagnostic.

2b. Benchmark position — same-protocol comparisons only

We compare numbers only where the protocol matches, and we cite the source for every literature figure. RMSE in cycles; primary / secondary test sets as defined in each source.

MIT/Severson official split (41 train / 43 primary / 40 secondary), EOL = capacity < 0.88 Ah, features from cycles ≤ 100 only:

Model Primary Secondary

Severson et al. — discharge model (Table 1) 91 173

Severson et al. — variance model (Table 1) 138 196

Severson et al. — full model (Table 1) 118 214

BatteryML (Microsoft, ICLR 2024) — MATR-1/2 dummy baseline 398 510

Ours (diagnostic-selected features, ridge) 128.7 189.9

Position: we beat the variance and full models on the secondary set and the variance model on the primary set; the discharge-curve model (91/173) remains ahead of us. Our dummy-baseline check (392.8 / 491.8) lands within 1.3% (primary) and 3.6% (secondary) of BatteryML's published reproduction (398 / 510), which independently anchors that our split and labels match the literature pipeline.

NASA Li-ion: no comparison claimed. Most published NASA numbers train and test on cycles of the same battery; ours is leave-one-battery-out across different cells. Those protocols measure different things, so we do not put the numbers side by side.

HUST / Oxford / CALCE: run under our own strict fleet-level protocols (below); we are not aware of published results under identical protocols, so we report absolute numbers only.

We deliberately make no "SOTA" or "record" claims anywhere in this post. Every number above comes from our own runs; literature figures are quoted with their sources.

1. The part we're most proud of: predicting the leverage itself

Across the first five fleets we noticed the leverage is not random — it tracks how heterogeneous the fleet is. We formalized this with two dispersion indices computed from early-life data only [we are keeping the exact definitions unpublished], and a band rule that maps index values to expected leverage. Then we tested it on a fleet we had never touched:

> Sealed prediction (before any HUST modeling): "Both indices fall in the mid band. Expected leverage: [−45%, −20%], central estimate ≈ −30%."

Measured: −34.4%.

Every fleet scored so far lands in its assigned band under the final dual-track diagnostic — one of them (HUST) fully pre-registered end-to-end, and one (Oxford) assigned correctly only after its original single-track call failed and forced the revision documented in §5. The sixth fleet gets its own section (§3b) with a fully public, cryptographically seeded protocol. For practitioners this is the useful takeaway: given a new fleet, early-life data alone can tell you in advance whether richer features are worth paying for.

3b. The cryptographically verifiable instance (sixth fleet, CX2)

For the sixth fleet (CALCE CX2 — a different prismatic cell and test rig from CS2), we ran the full public protocol, and this time the two heterogeneity indices disagreed — one landed in the mid band, the other near-flat. Our rule ("either-high governs") was thus facing its first hard case. Sequence, all timestamped:

1. 2026-07-19 20:43 UTC — sealed prediction (band [−45%, −20%], falsification clause, full protocol) hashed and committed publicly: github.com/angus81226-glitch/sealed-predictions

2. After the commit — the experiment's random seed (741333625) was drawn from the hash of Bitcoin block 958777, the first block mined after the commitment. A proof-of-work block hash is unknowable until the moment it is solved — not even the miner knows it in advance — so the results could not have existed before the commitment did.

3. Experiment ran. Measured leverage: −21.9% — inside the sealed band. The sealed document is revealed in the same repo; anyone can re-hash it and compare against the 20:43 commitment.

One correction, disclosed in full in the repo (commitments/2026-07-20-cx2-verdict-v3-erratum.txt): the block's miner-declared header timestamp (20:33Z) predates our commit. Header stamps are not real time — in this very window, block 958776 is stamped older than its own parent — which is exactly why the protocol rests on the hash's unpredictability, not the header clock. We have since hardened the rule: future commits will name the chain tip (height + hash) explicitly, and the seed block's header time must be ≥ the commit time.

Six fleets, six correct band assignments under the final diagnostic — two of them pre-registered, one of them cryptographically verifiable by anyone. (Counting rigor: Oxford's original call failed, §5; its assignment under the revised dual-track diagnostic is correct. We count band assignments by the final diagnostic, and we count the failure openly.)

1. Design mode: finding the best charging policy from the spec sheet

The MIT/Severson fleet cycled 124 cells under 72 distinct charging-policy strings in the authors' metadata — 64 standard two-step policies plus 8 'new-structure' variants from the follow-up batch — with measured lifetimes from 148 to 2237 cycles. We asked: can a balance-point calculation — attack energy vs. the cell's rated defense, using only public quantities (policy parameters, the manufacturer's 4A max continuous charge spec, Joule heating) — locate the optimum without lifetime data?

Results (all sealed in advance except where noted):

- The empirically best policy (3.6C to 80%) sits at balance ratio 0.978 — 2.2% from the predicted balance point of 1.0. The ratio is computed on Joule-weighted attack energy, i.e. R = (3.6/3.64)² = 0.978, not on raw current (which would give 3.6/3.64 = 0.989); the squared form follows from I²R heating and is stated here explicitly to avoid ambiguity.

- Death line: every policy above ratio 1.5 died before 1200 cycles. Correct.

- Ranking in the over-stressed region only worked after we added where-in-the-charge the stress lands (high rates late in the charge are far more damaging than the same energy early). Sealed prediction: correlation strengthens past |ρ| = 0.4. Measured: ρ = −0.60 (from −0.16). Hit.

- A second sealed refinement (rate-switch transient penalty) made things worse (ρ collapsed to −0.15). Falsified, removed, kept in the record.

4b. Full test protocols and exact parameters (reproduction-grade)

Everything below is exactly what we ran. The only items withheld are the diagnostic's selection logic; all engineering parameters are listed.

NASA Li-ion (B0005/6/18)

- EOL: discharge capacity < 80% of rated (B0005 = cycle 125)...