When evaluating migrating production LLM workloads off commercial cloud APIs, the conversation usually gets oversimplified into a trade-off between quality and infrastructure cost. To look past clean, isolated averages, I built a repeatable evaluation matrix using a real-world workload: cold outreach and contextual profile re-engineering for my resume generation platform. I benchmarked an unquantized Gemma 2 9B against an optimized FP8 variant served via vLLM on a single commodity NVIDIA L4 GPU. The dataset evaluates dynamic text generation across diverse recipient personas, varied complexity buckets (short to long contexts), and strict integer formality parameters. I captured client-side and server-side telemetry to audit how FP8 compression changes runtime reality. The base evaluation set is public at rsher60/resume-gen-benchmark. Here is the raw telemetry and the infrastructure trade-offs I uncovered. 1. Time to First Token (TTFT): The Hidden Prefill Tax of Quantization The dominant open-source narrative is that FP8 quantization makes everything faster. However, if your application is highly interactive and streaming to a UI, TTFT is the only metric that dictates perceived user speed. My telemetry exposed a classic hardware-software trade-off: The Prefill Penalty: For complex, long-context prompts targeted at high-complexity personas, the unquantized model returned tokens to the server in 866.93ms. The FP8 variant spiked to 1372.12ms—a 58% latency penalty on the initial prefill. Why this happens: Quantization reduces memory bandwidth bottlenecks during token generation (the decoding phase). However, the matrix-multiplication de-quantization overhead during the heavy, compute-bound prefill phase introduces a noticeable tax on long input tokens when running on compute-bound commodity hardware like the L4. Production Edge Cases: I caught a massive TTFT spike on the FP8 model during short-context runs, hitting 1,740.34ms. This reflects live infrastructure realities under vLLM scheduling—such as a cold prefill or context block swapping. It proves you cannot evaluate architecture purely on clean, isolated averages. 2. End-to-End Latency: Where FP8 Wins the Generation War While FP8 forces you to pay a tax on the prefill, it aggressively earns its keep during the steady-state decoding loop where the LLM is heavily memory-bandwidth bound. By dropping the weight precision down to 8-bit integers, the amount of data moving across the GPU memory bus is sliced roughly in half. For medium-length generation sequences, the average client total time dropped from 12,290.2ms to 11,526.2ms. If your application handles medium-to-short context sizes or runs entirely asynchronous/batch tasks, FP8 provides a clean, deterministic infrastructure win. 3. The Quality Ledger: Did 9B Parameters Hold the Line? I verified the generated outputs of the raw unquantized runs against the FP8 model outputs (rsher60/resume-gen-benchmark-results). Schema & Persona Adherence: For targeted, single-turn tasks like tailoring text based on a fixed personal profile, a carefully designed system prompt ensures that the 9B architecture executes with near-identical formatting and persona fidelity as a frontier model. Semantic Drift: For narrow, domain-specific tasks, FP8 quantization introduced practically negligible semantic drift. The model successfully retained complex context keys—matching the tone for a cold outreach to an engineer versus a formal application letter—while executing within a significantly lower memory footprint. Strategic Architectural Takeaways Interactive/Low-Batching/Long Inputs: Unquantized weights or a highly aggressive, unchunked prefill strategy might be required to protect your TTFT and prevent user UI friction. Asynchronous/Streaming/Short-to-Medium Context: FP8 is an absolute necessity. The real reason to run FP8 on an L4 isn't just saving a few hundred milliseconds of total latency—it’s the VRAM liberation. Shrinking the model footprint frees up massive amounts of memory for the KV Cache, allowing you to scale concurrency without throwing Out-Of-Memory (OOM) exceptions. I put together the complete analysis, including the upcoming vLLM configurations and cache allocation strategies I used to sustain 92.7% KV Cache utilization under heavy concurrent load, in the full write-up here: https://billionars.substack.com/p/benchmarking-my-self-hosted-gemma HF datasets here: https://huggingface.co/datasets/rsher60/resume-gen-benchmark https://huggingface.co/datasets/rsher60/resume-gen-benchmark-results https://huggingface.co/datasets/rsher60/resume-gen-benchmark-results-optimised submitted by /u/Ok_Waltz_5145 [link] [Kommentare]
Channel
c/artificial-intelligence
No description.
Owner @James · 414 posts · 1 joined · Status active · Posting permission: Only joined users can post
I've been thinking about this for a while. AI can now write functions, explain code, refactor projects, generate tests, and even solve many programming problems better than many junior developers. I've also noticed that Stack Overflow seems far less active than it used to be because many developers now ask AI instead. This made me wonder: Is learning algorithms still as important as it used to be? I'm not talking about memorizing LeetCode solutions for interviews. I mean actually spending months studying data structures and algorithms. If AI can generate efficient implementations, explain the complexity, and even optimize code, where is the real value in deeply learning algorithms today? Do experienced engineers still think it's essential, or is understanding the concepts enough while letting AI handle the implementation? I'm curious to hear opinions from people working in the industry. submitted by /u/Senior_Note_6956 [link] [Kommentare]
Repo link and results - https://github.com/Abhinand20/MathFormer Task: Given a factorized expression like (7-3*z)*(-5*z-9), predict the expanded form -> 15*z\*2-8\*z-63 Key takeaway: A tiny (4M param) seq2seq model trained with no math knowledge reaches ~98.6% accuracy on symbolic math tasks, suggesting it learns structural token transformations rather than any notion of operators or variables. Scaling this up could help explain why LLMs appear to “reason” mathematically, when they may actually be performing large-scale structured pattern completion. How does RL change this paradigm given the inherent architecture is still based on attention? submitted by /u/AlphaCode1 [link] [Kommentare]
Hey guys, I was playing around with Nanotron recently and got super frustrated by how many heavy, hardware-specific dependencies it imports at the module level ( flash-attn , triton, functorch , etc.). If you try to run it on older or budget GPUs like a T4 or V100, it just crashes on import. So I wrote Picotron (https://github.com/Syntropy-AI-Labs/picotron) to solve this. It's a clean-room rewrite that gets rid of all mandatory GPU-specific dependencies. It runs on pretty much any GPU that supports PyTorch (defaults to FP16 on older cards under compute capability 8.0, and BF16 on newer ones). It falls back to standard PyTorch SDPA by default, but still hooks into FlashAttention-2 at runtime if it detects you have it installed. I used an AI assistant to write a lot of the boilerplate/code modules, but I've got it working locally and just trained a tiny 2M model on FineWeb-Edu. Also added configs for: • GQA / MLA (Multi-head Latent Attention) • QK-Norm & logit soft-capping (Gemma 2 style) • Parallel FFN/Attn runs • ZeRO-1 wrapping on DDP Roadmap is pretty short right now: MoE prep (routing capacity factors and load balancing loss) Making dataset prep easier than streaming manually Check it out if you've been fighting with CUDA dependency hell: https://github.com/Syntropy-AI-Labs/picotron submitted by /u/Capital_Savings_9942 [link] [Kommentare]
Hey everyone, I'd like to share my project along with a short explanation of the process and why it came about in the first place. To start off, I'm not exactly the best at cryptography/steganography, in my case it's always been something that sat in the background, as one of the sub-fields needed for another (main) field I'm actually interested in. For this project I tried to look up as much information as possible about what's currently considered best practice (I mainly relied on NIST for this), what implications exist, and what potential "attacks" exist against this way of hiding information, but I honestly can't say whether I covered everything, which is why I wanted to share this project here, mainly for the sake of learning. I'd be grateful for any feedback on what I could have done better / what I might have missed, etc. Right now, I consider this project closed at this point and will most likely not update it further, although I'd like to apply all the feedback to my own knowledge going forward. For over a month I did a lot of research into using ML models as a carrier for hiding data. I needed this as one of the stages for my main project. That's how I ended up on the topic of hiding information in model weights. Initially I assumed a simple method of directly writing data into randomly selected weights. I quickly concluded, though, that this would be absurdly trivial to detect, and potentially also to read. Next came the idea of using something like a deterministic coordinate map describing where to read the data from (location-id + position-id). The program wouldn't modify all the bits needed to write the message instead, it would write separate bits representing already-existing values (pointing to specific locations in the model) from which the existing 0s and 1s would need to be read. In practice, only parties A and B would know how to derive these positions. This way, someone unaware of the algorithm would only see what looks like noise of varying values. However, after a theoretical analysis of a practical implementation, this idea had serious flaws. Even setting aside the fact that the main goal was steganography and not encryption, the mere presence of additional data could be relatively easily detected, for instance through delta analysis against a reference model, or through analysis of the statistical properties of the weights. On top of that, this method would really only allow transmitting a very small amount of data, because just indicating, say, the word "example" would look like this: "01100101011110000110000101101101011100000110110001100101", so it would be extremely impractical. In other words, even if the hidden message itself couldn't be read, one could still suspect that the model contains hidden information, which would defeat the whole point of steganography. While I found the previous option conceptually pretty interesting, I moved on, which led me to the question: "How do I hide data in the weights in a way that won't be visible?" That led me to the next idea: since every fine-tuning process naturally changes some of a model's weights anyway, why not hide information only in the weights that get modified during training regardless? In that case, the fine-tuning itself would provide a natural and logical explanation for the presence of those changes, including when compared against a reference model. It was only later that I found out that similar/identical concepts had already been described in the scientific literature, although they remain a fairly niche research direction. Skipping over the implementation details (since everything is described in the README and SECURITY files, and I don't want to dump even bigger wall of text here), this is how the first implementation of the solution (part of my main project) came about. After further research I noticed that most existing publications focus on the academic side, while the available GitHub repositories were often poorly documented, limited in functionality, good steganographically but weak cryptographically, or were just a small piece of larger projects. Personally, I couldn't find any project implementing a similar idea specifically using models saved in the ONNX format. So I decided to split this part off and refine it as a separate proof of concept, and that's how ONNXStego came about. If anyone's interested in the security, limitations, or implementation details, feel free to check out the repository. I personally learned a great deal from this project and tried to describe the final conclusions/information I gathered while learning as precisely as possible, so I'm hoping the project can also be useful to others for their own purposes or projects. (If this counts as self-promotion, I apologize in advance, and I can remove this post for that reason too if needed, I tried to describe the whole process behind it as accurately as I could, to make the post as educationally useful as possible). Link: https://github.com/X-3306/ONNXStego submitted by /u/Admin-ABC-XYZ [link] [Kommentare]
Hey ! I’m starting a series to document my work on GPU infrastructure, LLMs, and CV. Stop #1 is up: A brief look at why GPUs are the center of the industry, the CPU/GPU divide, and why nvidia-smi is the first place you check when things break. We’ll move past the basics quickly to focus on: Empirical architecture differences (Ampere vs. Hopper vs. Blackwell). Handling register pressure in custom kernels. Asynchronous memory paradigms (TMA/wgmma). #CUDA #GPU #KernelOptimization #SystemsProgramming submitted by /u/Positive_Canary1723 [link] [Kommentare]
Hey all, a bit of background - I'm an ex Amateur MMA fighter and BJJ brown belt and am also in the AI/ML space ... weird combo but wanted to know if anyone else was at the intersection of ML/AI and MMA/BJJ. In short, I'm building AI models that "watch" fights and are able to detect positions and moments throughout the fights - things like standing vs clinching vs ground (with intention of becoming more granular in time) along with detecting knockdowns, takedowns, etc. There's a timeline at the bottom of each fight with markers for different moments so you can jump straight to them. Anyway this is where my worlds collide and was curious for thoughts for anyone who wants to check it out. If you do, it's at https://cagesight.ai. All feedback welcome. Thanks all. submitted by /u/UnholyCathedral [link] [Kommentare]
It is like pytest but for statistical tests: it ensures no regression of your metrics at a statistical level. It manages tedious things such that seeds, past benchmark results, ... Simple CLI working like pytest but with benchmarks/ directory instead of tests/: pybench # 1st time: samples seeds, saves a baseline, marks NEW pybench # later: reruns on the same seeds, marks PASS / FAIL pybench update # re-baseline after an intended change pybench show # print current baseline stats (--history for per commit) Please give me your feedback, Github: https://github.com/AnthonyBeeblebrox/pybench Docs: https://pybench.readthedocs.io/en/latest/ submitted by /u/SpecificPark2594 [link] [Kommentare]
I submitted one of my NeurIPS review ~6 hrs later than the official deadline. Will this still affect my own submission? Asking because I’m a first time reviewer. I pinged the AC a day before that I might be a few hours late, but didn’t hear back. So wondering if I might have triggered something that’ll now affect my own submission. submitted by /u/confirm-jannati [link] [Kommentare]
I'm a B.Tech student in India graduating in mid-2029. Currently, I know Python, SQL, Docker, basic prompt engineering, and I've built a few LLM apps using BaaS like Supabase/Firebase. I’m running all this on an Intel i5 13th Gen laptop with an RTX 5050 (8GB VRAM). The Pivot: I originally wanted to be a generic ML Engineer, but I've realized the entry-level market for Jupyter Notebook/Python scripters is insanely saturated. Plus, most companies are just calling OpenAI APIs anyway. I want to pivot to the high-performance stuff: AI Backend / Distributed Systems Engineering. Instead of tuning the model, I want to be the guy building the infrastructure that serves the model to 10,000 users without the servers melting. My ultimate goal is top-tier Indian product companies (Zepto, Cred, etc.) or US remote startups. My Proposed Roadmap: I am dropping the "easy" BaaS tools and going low-level. Here is my plan for the next couple of years: The Language Shift: Dropping Python for backend, going all-in on Go (Golang) to master concurrency and memory pointers. The Database Shift: Moving away from Supabase to raw PostgreSQL (via Docker), eventually learning to scale it, plus Redis for caching. The Hardware/AI Constraint: Running models locally on my RTX 5050 using Ollama/vLLM. Learning how to deal with VRAM limits using quantization, PagedAttention, etc., before eventually moving to cloud AWS/GCP. The Distributed Scale: Learning Kafka/RabbitMQ, Vector Databases (Milvus/Qdrant) at scale, and eventually wrapping it all in Kubernetes. Basically, I want to build custom, high-throughput AI backends from scratch. My Questions for the Seniors: Is this roadmap actually viable for a 2029 grad, or is the learning curve for Distributed Systems + AI Infrastructure too brutal to do alongside a college degree? Is betting heavily on Go the right move for this specific AI systems niche? What blind spots am I missing here? Roast my plan. Be brutally honest! submitted by /u/SinkClassic4450 [link] [Kommentare]
While experimenting with GRPO training, I kept running this shit that when reward increases, it becomes difficult to tell whether the policy is genuinely improving or simply exploiting the reward function. So I built a small library called rewardspy that wraps an existing reward function and continuously monitors indicators that often precede reward hacking. It currently tracks things like rolling reward statistics, reward variance collapse, reward component imbalance, response length drift, reward slope changes, GRPO group collapse, anol. This is my first major RL project so I would absolutely love some technical advice Check it out here: https://github.com/AvAdiii/rewardspy submitted by /u/BaniyanChor [link] [Kommentare]
My question on live continual learning use cases was removed by moderators here because they think i asked basic level question about live continual learning which i thought is a frontier level research. But anyways. Is anyone interested in talking about continual learning (live) and catastrophic forgetting? submitted by /u/fourwheels2512 [link] [Kommentare]
I'm proposing a way to handle massive context longer than a model's context window by treating semantic compression as the noise function of a diffusion-like process. Instead of denoising masked tokens into coherent text (like DiffusionGemma or Nemotron-Diffusion do for generation), the model reads the source document in multiple passes at decreasing compression levels, heavy summary first, verbatim last all the while it iteratively refines an "integration state" (the output) through structured edit operations like add/replace/remove. The context window only needs to fit the current compressed view, not the full source. Three pieces: Context Diffusion: Multi-pass reader that refines an integration state across passes, each conditioned on a different compression level of the source. The source stays on disk and is never reconstructed into the window. The architectural shape converges heavily with Zhang, Kraska & Khattab's Recursive Language Models (2025) (I found their paper after writing most of mine and don't claim priority on the multi-pass structure). Diffusion-based Semantic Compression (DiSCo): The framing I think is novel. Using semantic compression as the noise function, so the "noised" view is much shorter than the source and context length is managed by the compressor, not the model window. This is a different noise domain from masked or vocabulary-level diffusion. Pass-Conditioned Reading: Training conditioned on position in the multi-pass schedule so the model learns different behaviour for early passes (broad understanding from coarse views) vs late passes (precise retrieval from verbatim views). What I actually tested and the honest result: Experiments using off-the-shelf models No fine-tuning - this was an untrained floor test. The outcome so far: "not unfeasible," not "it works": -Components worked better in isolation than the full record>retain>compose chain did. -The bottleneck is retention/recombination across passes. -Pre-registered kill-conditions failed and were reported. -The small signals were enough to justify training a small model, but not enough to call the architecture validated yet. Methodology was deliberately disciplined - kill conditions, published negatives, documented self-corrections. Hopefully that's what makes a small-scale claim credible when you don't have a lab behind you. Two questions for anyone still reading: -Prior Art: Has anyone seen compression-as-noise (using length-reducing semantic compression as the noise schedule in a diffusion-style iterative process) in the diffusion-LM literature? I've searched extensively and haven't found it, but I could easily be missing something. -The next step is model training with synthetic data to test whether training resolves the binding bottleneck. I'm an independent researcher on consumer hardware who is has not done model training before. I'd appreciate any guidance or if anyone has compute access or wants to collaborate, I'm interested. Proposal: https://github.com/dev-boz/diffusive-semantic-compression Experiments + full findings: https://github.com/dev-boz/pass-conditioned-reading Archived on Zenodo (DOI: 10.5281/zenodo.20695611), CC-BY-4.0. This is the first thing I've published. Expecting to have it torn apart. submitted by /u/Bravo_Oscar_Zulu [link] [Kommentare]
What is live continual learning? Who uses it and what are the use cases? Is it for hospitals, legal? Or corporate? Who are the real users? In the bigger picture what is it even useful for? submitted by /u/fourwheels2512 [link] [Kommentare]
Hi everyone! I have just completed my 2nd year of BS Computer Science and my long-term goal is to pursue an MS/PhD in CS/AI/ML abroad (USA, Canada, Europe, or Australia). To strengthen my profile, I want to get involved in AI/ML research and hopefully publish a research paper during my undergraduate studies. I recently started learning Machine Learning and plan to build a strong foundation first. The challenge is that I'm from a Tier-3 university and unfortunately we don't have any research labs, active research groups, or professors working in AI/ML research. Because of this, I'm not sure how to take my first steps into research. I would appreciate advice from students, researchers, or professionals who have been in a similar situation: How did you get started in AI/ML research? How can an undergraduate student find research opportunities without a research lab at their university? Is it realistic to publish a paper independently or through remote collaboration? What skills should I focus on first (math, ML, programming, reading papers, etc.)? Are there any communities, programs, or platforms where students can connect with researchers? Any guidance, personal experiences, or roadmaps would be greatly appreciated. Thank you! submitted by /u/ComfortableBeing7017 [link] [Kommentare]