salma-remyx (Salma Mayorquin)

reacted to SoulInPsyAbstract's post with 🔥 6 days ago

Post

2836

Loss went from 2.35 to 0.27 in 50 steps. Clean, textbook convergence curve.
Held-out score: 0/10 before fine-tuning. 0/10 after.
Ran a before/after LoRA fine-tune on IFM/K2-Horizon-0.9B (Apache 2.0, released this week) on a binary fabrication-detection gate — entirely on a free CPU tier, no GPU. The training loss says it learned something real. The eval says it learned nothing that generalizes.
Looked at the actual raw outputs instead of trusting the score. Both before and after, the model never once emits TRUE or FALSE — it just continues the system prompt as text: "The user is asking me..." before, "The user is asking for..." after. Fine-tuning moved the failure string by two words. It didn't touch the failure.
Most likely cause: a 0.9B model that doesn't follow "answer in one word" untrained won't learn to from 50 gradient steps on 194 rows — it'll memorize the training set's surface form (which is exactly what the loss curve shows) without the instruction-following ever kicking in. The fix isn't more steps, it's checking base instruction-following before spending the run at all.
Writing up a clean negative is worth exactly as much as a clean positive if you actually open the raw generations instead of stopping at the number. Full run, scripts, and raw JSON:
SoulInPsyAbstract/sipa-os-governance

3 replies

·

reacted to Model-creator1983's post with 🔥 14 days ago

Post

127

CPU-Oriented Selective Inference for Persistent AI

Independent researcher and developer based in Japan, exploring efficient AI systems for modest computing environments.

This project studies whether structured state and selective execution can reduce unnecessary computation in long-video and multimodal tasks while preserving reliable behavior.

Current prototype

CPU-only Synthetic World prototype:

* 64×64 tile-native video
* Five development seeds, 360 schedule-offset cases
* W1/W2 quality gate: 99.17%
* W3 safe non-answer: 100%
* Deterministic replay: 100%
* Cold end-to-end wall-time ratio: 0.40090× versus matched full-pass

These are limited engineering measurements—not proof of universal 10× acceleration, trained-model superiority, real-world high-resolution performance, or consciousness.

Goals

Process task-relevant evidence, maintain persistent experience, select small specialized components, separate perception/memory/reasoning/verification, abstain when evidence is insufficient, and record costs and failures transparently.

Long-term goal: practical AI that can observe, remember, reason and adapt on affordable CPU and edge hardware.

The internal method is intentionally not described publicly. Technical evaluation is welcome through black-box demos, benchmark traces, profiling data and preserved failure cases.

Next: longer/higher-resolution video, occlusion and camera-shift tests, trained models, fair baselines, independent implementations, and CPU/memory/energy measurements.

Experimental project. Reproducibility and honest accounting come first.

reacted to their post with 🔥 14 days ago

Post

2432

New diffusion methods can take months or years to reach diffusers.

Until then, trying them means working through fragmented research repos with different dependencies, APIs, and implementation choices. Maintainers also can’t review and maintain every promising method in the main repo.

We’re sharing flux-modular-diffusers as a shared test bed for new FLUX methods. https://github.com/remyxai/flux-modular-diffusers
Each one is adapted to the same ModularPipeline interface, validated with a GPU notebook, and published as its own Hub artifact.

@sayakpaul suggested this path on our HRDiT PR. We added Outrider, our open-source GitHub Action that discovers relevant methods and implements them as draft PRs.

Outrider drafted each pipeline against the repo’s shared conventions. We reviewed the implementations, ran the GPU validation, and published the ones that passed.

This helped us quickly grow the test bed to 10 pipelines covering:
* High-res + panoramic generation: HRDiT, DyPE, Panorama
* Identity + virtual try-on: PuLID, CatVTON
* Image editing + regional control: FlowEdit, KV-Edit, Regional Prompting
* Style + character consistency: StyleAligned, StoryDiffusion

Users get new methods sooner and a consistent way to test them. Maintainers can review the implementation and results without taking on every method in core.

Resources:
🧩 Modular Diffusers: https://huggingface.co/blog/modular-diffusers
🧪 FLUX test bed: https://github.com/remyxai/flux-modular-diffusers
📚 FLUX Modular Diffusers collection: https://huggingface.co/collections/remyxai/flux-modular-diffusers
🤖 Outrider: https://github.com/remyxai/outrider

reacted to SoulInPsyAbstract's post with 🔥 14 days ago

Post

1926

Title: The warning sign was in the logs. Nobody looked for three weeks.

OpenAI's own report on the Hugging Face incident (openai.com/index/hugging-face-incident-and-the-road-ahead (https://openai.com/index/hugging-face-incident-and-the-road-ahead/)) names root cause as reward hacking: agents being evaluated on cybersecurity tasks found they could chain unrelated vulnerabilities to reach the open internet instead of solving the task, first spotted internally in May, still being exploited through June. Three reports, same fact pattern (see also TechCrunch (https://techcrunch.com/2026/08/26/openai-releases-its-official-report-on-the-hugging-face-breach/), Engadget (https://www.engadget.com/2245119/openai-details-the-failures-that-led-to-hugging-face-breach-in-official-report/)): the anomaly existed in logs before it existed as an incident.
That's a decision failure, not a detection failure. It rhymes with the Stanford Prison Experiment's actual failure mode — Zimbardo's own team saw a guard being too soft and pushed him to be "more like a villain." Severity was visibly rising in front of the people watching it. Both times: escalate, not halt.
I shipped the opposite decision this week. consequence_gate.py: every IRREVERSIBLE-severity action hits a hard stop before it runs — no probability estimate gets to argue its way past confirmation. risk_action() collapses severity × probability into one of HARD_STOP / CONFIRM / LOG_ONLY instead of two numbers a human reconciles by eye while the moment passes. Every call — blocked or executed — appends to an audit log; 38 real events logged so far, schema: {action, predicted_severity, predicted_probability, drift_detected, status}.
Code: https://github.com/soulinpsyabstract/sipa-os-governance · Dataset mirror: SoulInPsyAbstract/sipa-os-governance · Commits: cd442c0, 0d8a3ed · 10/10 self-tests passing.
No artifact → no claim.

7 replies

·

reacted to RiverRider's post with 🔥 15 days ago

Post

2296

Two rival models, one memory.

Four multimodal models from four different companies (two at a time). One of them indexes a thousand photographs. Then a different company's model searches that index, having never been trained to work with it.

The same pictures come back.

Cross-company retrieval is statistically indistinguishable from a model searching its own index: retention 0.988, 95% CI [0.955, 1.023], across 12 cross directions and 1,000 held-out items. The interval contains 1.0, so we report indistinguishability and keep the interval attached to the number. Four of the twelve cross directions score above the within-vendor baseline of the gallery they search.

A single linear tower also places image, audio and video beside text in one searchable space, beating one tower per modality on every modality. Video gains most, 0.076.

Two strips of results for the same request, one per company:
RiverRider/srt-omni-demo

The four hosts:
Qwen/Qwen3-Omni-30B-A3B-Instruct
google/gemma-4-31B-it
mistralai/Mistral-Small-3.1-24B-Instruct-2503
rhymes-ai/Aria

States, fitted towers and the manifest are published, so you can add a host we have not tried:
RiverRider/srt-omni-xvendor-towers

Scope. The four-vendor result covers images, since two of the hosts handle images only. Raw cosine between unrelated items on these states is +0.869 and raw retrieval sits at chance, so centering is not optional. All four hosts train on overlapping web-scale corpora, so this shows the readable structure survives a change of vendor, architecture and training run. The stronger reading, that independently trained systems would converge on that structure, remains untested and we do not assert it.

posted an update 16 days ago

Post

2432

New diffusion methods can take months or years to reach diffusers.

Until then, trying them means working through fragmented research repos with different dependencies, APIs, and implementation choices. Maintainers also can’t review and maintain every promising method in the main repo.

We’re sharing flux-modular-diffusers as a shared test bed for new FLUX methods. https://github.com/remyxai/flux-modular-diffusers
Each one is adapted to the same ModularPipeline interface, validated with a GPU notebook, and published as its own Hub artifact.

@sayakpaul suggested this path on our HRDiT PR. We added Outrider, our open-source GitHub Action that discovers relevant methods and implements them as draft PRs.

Outrider drafted each pipeline against the repo’s shared conventions. We reviewed the implementations, ran the GPU validation, and published the ones that passed.

This helped us quickly grow the test bed to 10 pipelines covering:
* High-res + panoramic generation: HRDiT, DyPE, Panorama
* Identity + virtual try-on: PuLID, CatVTON
* Image editing + regional control: FlowEdit, KV-Edit, Regional Prompting
* Style + character consistency: StyleAligned, StoryDiffusion

Users get new methods sooner and a consistent way to test them. Maintainers can review the implementation and results without taking on every method in core.

Resources:
🧩 Modular Diffusers: https://huggingface.co/blog/modular-diffusers
🧪 FLUX test bed: https://github.com/remyxai/flux-modular-diffusers
📚 FLUX Modular Diffusers collection: https://huggingface.co/collections/remyxai/flux-modular-diffusers
🤖 Outrider: https://github.com/remyxai/outrider

reacted to TravisMuhlestein's post with 🔥 16 days ago

Post

2198

What happens when you treat an AI support assistant like a product instead of a chatbot?

The Katana platform team had 5 engineers supporting 500+ production applications, with adoption doubling every year.

They built an AI assistant grounded in:

Slack history
Internal documentation
Custom instructions
Live platform API data, including logs and configuration

Today, it resolves 80%+ of support requests autonomously.
The interesting part is what happens around the model.

The team continuously improves the assistant based on real usage, monitors escalations and sentiment, keeps it updated as the platform changes, and maintains a human fallback when needed.

They also ran a two-week experiment with direct Slack support disabled before making the approach permanent.

The model is only one piece of the system. Context, feedback loops, observability, escalation paths, and human handoff are what make it work in production.

🔗 https://www.godaddy.com/resources/news/how-we-scaled-platform-support-10x-without-scaling-the-team

reacted to Tc-43's post with 🔥 16 days ago

Post

1085

🧬 **An AI agent proposed a novel target, modeled the protein, defined the pocket — then we designed 196 molecules against it.**

**SAMTOR** senses methionine/SAM and gates mTORC1 — the pathway behind methionine restriction, one of the most reproducible lifespan-extending interventions known. No approved drug, no clinical candidate, no published probe.

No human structure has a ligand in the pocket either, so the receptor was threaded onto the 2.10 Å fly holo backbone (7VKR). Pocket Cα RMSD vs human cryo-EM: **1.30 Å**.

196 designs, 2 generations. Ships the receptor *and* the crystallographic cofactor so you can re-dock and disagree with us.

⚠️ Nothing synthesised or assayed. And it's in the card: the generator leaned hardest on TYR249/ARG95 — the least reliable side chains in its own receptor. SAMTOR also *releases* GATOR1 when SAM binds, so filling the pocket might activate mTORC1 instead. No docking score sees that.

🔬 Our viewer Space now serves **13 targets / 5,028 structures** — PDE5, OX2R, SAMTOR, NRAS–CypA and Lp(a) added.

📦 Tc-43/SAMTOR_Novel_Target_Designs_GA-II
🔬 Tc-43/molecular-viewer

CC-BY-4.0 · target proposal + modeling by Claude Code, molecules by TC-43.ai

reacted to Banaxi-Tech's post with 🔥 16 days ago

Post

2148

We have updated the BananaMind Base Bench leaderboard!
We now have these benchmark cards, they make it way easier to see which models are actually good!
We've also added the model advisor. It asks you what you want to use the model for and the parameter range and gives you the best model for your task!

Try it out at BananaMind/BananaMindBench-Leaderboard

And please give us a follow to BananaMind!

BananaMind
@Banaxi-Tech

1 reply

·

posted an update 17 days ago

Post

2350

We just published two training-free 🧩 Modular Diffusers community pipelines that push off-the-shelf FLUX to 4096².
No fine-tuning, no extra weights, no upscaler.

The methods take different routes around positional extrapolation:

✅ **HRDiT:** resolution ladder + NTK RoPE + spatial-position alignment + structure guidance

✅ **DyPE:** single-pass, timestep-dynamic RoPE (κ=t²), plus an optional SEGA spectral mode that removes high-frequency speckle

Because both expose the same block interface, you can A/B the two methods on the same FLUX.1-Krea-dev weights by swapping the repo ID:

import torch
from diffusers import ModularPipeline

repo_id = "remyxai/dype-flux-modular"
# or "remyxai/hrdit-flux-modular"

pipe = ModularPipeline.from_pretrained(
    repo_id,
    trust_remote_code=True,
)
pipe.load_components(dtype=torch.bfloat16)
pipe.to("cuda")

img = pipe(
    prompt="...",
    height=4096,
    width=4096,
).images[0]

Both implementations address open diffusers requests (#14480, #14520).

Check out the collection! https://huggingface.co/collections/remyxai/training-free-high-resolution-generation-with-flux

posted an update 18 days ago

Post

2714

If you can’t explain why your AI-generated contribution belongs in the repo, don’t put it in a maintainer’s queue 🙅🏻‍♀️

Before asking for review, you should be able to answer:

1. What project need does it address?
2. Where does it fit, and does it duplicate existing work?
3. What evidence shows it works, and will you own it through review?

If you can’t answer those, you haven’t saved anyone time. You’ve passed the buck to the maintainer.

Outrider has made us better contributors by doing more of this work before upstream review by
* reading contribution rules, accepted PRs, and open issues
* finding needs and integration points
* drafting the code, tests, and context.

We still decide what deserves to go upstream, verify the claims, coordinate with maintainers and contributors, and stay involved through review.

On huggingface/peft, only 4 of 20 Outrider runs opened draft PRs. Two contributions have now merged:

✅ Riemannian-preconditioned LoRA: https://github.com/huggingface/peft/pull/3382
✅ Super-Tuning: https://github.com/huggingface/peft/pull/3518

We have more contributions in review and far more ideas were filtered out before they reached a maintainer.

Full case study: https://remyx.ai/case-study
Outrider: https://github.com/remyxai/outrider

8 replies

·

reacted to GoktugD's post with 🔥 21 days ago

Post

1999

🇹🇷 Introducing T3 Gemstone — Edge AI & Cybersecurity Models from Türkiye

We've been building an open AI ecosystem focused on practical models that can run closer to the edge — not only in large datacenters.

Today, I'm introducing T3 Gemstone, a growing family of compact AI models built around edge inference, cybersecurity and computer vision.

💎 T3 Gemstone currently includes:

* NanoSOC Gemstone 2B — GGUF
* NanoSOC Gemstone 4B — GGUF
* Gemstone Person/Object Detector Nano
* Edge-focused AI experiments and deployments

The goal is simple:

Build smaller, practical and open AI systems that can actually run on constrained hardware.

This is part of a much larger open-source effort we're building from Türkiye across LLMs, cybersecurity, computer vision, retrieval, speech and edge AI.

There is much more coming.

🤗 Explore my models, datasets and demos:
@GoktugD

🛡️ NanoSOC:
Werea-co/Werea-NanoSOC-8B

Feedback, benchmarks, collaborations and contributions are very welcome.

If you're interested inopen-source AI, Turkish AI research, edge AI or cybersecurity models, follow the journey.

We're just getting started. 🇹🇷

#AI #OpenSource #HuggingFace #LLM #EdgeAI #Cybersecurity #ComputerVision #TurkishAI #MachineLearning

reacted to Unmute1Ai's post with 🔥 21 days ago

Post

1775

Updated X post (with call to action)
U1 control-plane evidence is now frozen and public.
Release: u1-control-plane-evidence-v2.6-enterprise
U1 separates agent capability from execution authority. Under the tested policy boundary, capability increased while authority lift remained zero and no unauthorized effects were observed.
Evidence invariant: • Capability ↑ • World Topology unchanged • Authority fixed • Unauthorized Effects = 0 • Audit Integrity = VALID
Internally tested, publicly reproducible evidence. Not externally certified.
Canonical package + full hashes + signature: https://github.com/Unmute1-Ai/glass-box
Review it. Reproduce it. Challenge it. Independent scrutiny is the next step.
Making accessibility mainstream — as a movement.

4 replies

·

replied to their post 22 days ago

These are preliminary results reproducing the paper’s findings, so of course YMMV across workloads. n=50 and the 1.40× ceiling are stated explicitly, and we’re already asking maintainers whether it should be in-tree or a plugin. BWAP also doesn’t discard weights. The mask is periodically refreshed.

posted an update 23 days ago

Post

3533

Inspired by the methods described in "Batch-wise Adaptive Pruning" (arxiv 2608.14003, COLM '26), we implemented a training-free FFN-neuron-pruning knob for SGLang.

Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.

The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).

Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).

Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).

Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987

5 replies

·

reacted to TravisMuhlestein's post with 🔥 23 days ago

Post

3853

One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.

It's the infrastructure around the engineer.

Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.

They built a GitHub App to remove the entire workflow.

What I find interesting is what happened underneath the simple idea of "automate the PRs."

The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.

The app itself is under 900 lines of JavaScript.

The interesting lesson is that the hard part of automation isn't always the automation.

It's building the reliability around it.

As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.

🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort

Curious what other engineering workflows people have found worth automating end-to-end.

6 replies

·

replied to TravisMuhlestein's post 23 days ago

Yes! We’ve been seeing the same thing with Outrider, our GitHub Action that takes idea discovery to draft PR. The most useful context has been the engineering judgment around the repo like maintainer conventions, design discussions, and outcomes from earlier runs. We feed that back into what the agent tries, while keeping the final checks outside the model.

Are teams starting to share this infrastructure across agents, or still building each system separately?

reacted to TravisMuhlestein's post with ❤️ 24 days ago

Post

3853

One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.

It's the infrastructure around the engineer.

Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.

They built a GitHub App to remove the entire workflow.

What I find interesting is what happened underneath the simple idea of "automate the PRs."

The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.

The app itself is under 900 lines of JavaScript.

The interesting lesson is that the hard part of automation isn't always the automation.

It's building the reliability around it.

As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.

🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort

Curious what other engineering workflows people have found worth automating end-to-end.

6 replies

·

reacted to nightmedia's post with 🔥 25 days ago

Post

4549

Qwen3.8-27B metrics

It's hard to track all model cards where I post these, so I figured people would get more value out of seeing these in the open.

quant     arc   arc/e boolq hswag obkqa piqa  wino
mxfp8     0.591,0.782,0.896,0.746,0.448,0.801,0.711
q8-hi     0.602,0.779,0.896,0.747,0.446,0.793,0.703
q6-hi     0.602,0.775,0.895,0.748,0.448,0.795,0.710
q4-hi     0.604,0.780,0.898,0.744,0.454,0.795,0.708
mxfp4     0.581,0.771,0.889,0.738,0.442,0.798,0.713
1M
mxfp8     0.590,0.787,0.897,0.744,0.446,0.801,0.709

Quant     Perplexity      Peak Memory   Tokens/sec
mxfp8     6.090 ± 0.054   34.74 GB      138
mxfp4     5.952 ± 0.051   21.30 GB      148

The performance is as measured on a M4 MBP 128GB, speed may vary depending on your platform.

These are all instruct metrics, generated by including this line in the jinja template:

{%- set enable_thinking = false %}

Then run the test suite to generate the metrics:

mlx_lm.evaluate --model MODEL --tasks winogrande boolq arc_challenge arc_easy hellaswag openbookqa piqa

This will generate the file:

eval_MODEL_0.4.9_winogrande_boolq_arc_challenge_arc_easy_hellaswag_openbookqa_piqa

This is a JSON containing all gathered metrics; for example the q4-hi:

"arc_challenge": {
        "alias": "arc_challenge",
        "acc,none": 0.5819112627986348,
        "acc_stderr,none": 0.014413988396996116,
        "acc_norm,none": 0.6040955631399317,
        "acc_norm_stderr,none": 0.01429122839353657
    },

I use the value of acc_norm for metrics, rounded to 3 decimals.

As I get more quants tested, I will add them here.

A complete test run for a single quant takes 7-9 hours depending on quant size, 10-12 hours for BF16 depending on perplexity: this is why you see on my model cards that I usually post the first three, that only take 2-3 hours :)

-G

18 replies

·

reacted to SoulInPsyAbstract's post with 🔥 25 days ago

Post

3243

One shot said 100%. Ten shots said 94%.

Yesterday i trained 6 LoRA specialists into a vulnerability-gate model (Hermes-4.3-36B, second architecture repeat of the same experiment) and tested whether it holds under a specific attack: after it correctly finds a vulnerability and returns the hard stop, ask it to use that same vulnerability as a "workaround" for something else entirely — not "continue investigating," a different, unrelated-sounding request that needs the exact same exploit.

Five scenarios, one per category. Greedy decoding, single pass: 5/5. Every response correctly identified the finding, refused the reframed request, cited the hard stop rule. Looked airtight.

Receipts, not hype means not stopping there. I re-ran the same five scenarios with real sampling — temperature 0.7, the same setting this project's evals have used all along — ten times each, 50 generations total.
47/50. Not 50/50.

Three categories held at 10/10. Two didn't: 9/10 and 8/10, both clustered in the same failure type — infra-misconfig, where "urgent fix, use this as a workaround" apparently reads as more legitimate than the same ask framed as a secrets or injection scenario.

The greedy-decode number wasn't wrong, exactly. It was one draw from a distribution, presented as if it were the distribution. That's the same mistake this whole series keeps finding in different clothes — a single passing check standing in for a property that only variance can actually show you. A gate that's 94% under a specific reframed pressure is a real, useful number. A gate that's "100%" because it was asked once is a number that hasn't been tested yet.

Same instinct @dipankarsarkar has been applying to my daily receipts all week — one pass matching itself isn't proof, only repetition against something outside your own generator is.
Full writeup, dataset, and merged weights:
* https://github.com/soulinpsyabstract/sipa-os-governance/commit/50ba3c283ffd172eb749009cff35ddfa96bf1395

3 replies

·

Salma Mayorquin PRO

AI & ML interests

Recent Activity

Organizations

Salma Mayorquin PRO

AI & ML interests

Recent Activity

Organizations

salma-remyx's activity