标签：#MachineLearning

Production vLLM is 100,000+ lines of C++, CUDA, and Python. It powers most of the industry's LLM serving — but reading it cold is brutal. So I built a study series around nano-vLLM , an open-source reimplementation of vLLM's core ideas in ~1,200 lines of pure Python. Every algorithm is visible. Every design decision is legible. It turned out to be the perfect lens for actually understanding how LLMs generate text. The result is an 11-chapter interactive guide. No ML background required — every piece of jargon is explained from scratch with analogies, diagrams, annotated source code, interactive simulators, and quizzes. What it covers: What Is LLM Inference? — tokens, autoregressive generation, Q/K/V attention, HBM vs SRAM Architecture — how 1,200 lines are organised; CPU control plane vs GPU data plane KV Cache — why storing Keys and Values turns O(N²) recomputation into O(1) lookup PagedAttention — virtual memory for the KV cache; how fragmentation wastes 60–80% of GPU memory The Scheduler — continuous batching; keeping the GPU at 95% utilisation instead of 12% Prefill vs Decode — same model, two completely different bottlenecks (compute-bound vs memory-bound) Prefix Caching — skip prefill for shared tokens; ~700ms → ~90ms TTFT Sampling Strategies — greedy, temperature, top-k, top-p, and what each does to the distribution Tensor Parallelism — splitting a model across GPUs; column/row parallel and all-reduce The Optimization Stack — FlashAttention, kernel fusion, CUDA Graphs, torch.compile Benchmarks — measuring honestly; why nano-vLLM matches vLLM on core throughput Each chapter is fully self-contained and interactive. A few of the simulators I'm most happy with: a PagedAttention block allocator you can fill up and watch fragment, a live scheduler you step through token by token, and a sampling playground where you reshape the probability distribution with sliders and sample from it. 🔗 Read the full series: https://ashwing.github.io/vllm-guide/ It's free and open.

TL;DR: A single eval number hides its own uncertainty. Eval confidence intervals from bootstrap resampling turn a point estimate like 84.2% accuracy into a range, so you stop shipping models on a difference that is noise. Two checkpoints came back from a fine-tuning run at 84.2% and 85.7% on our 500-example agent eval set. The 1.5 point gap read like a win, and someone wanted to promote the second checkpoint to staging. Before that, I wanted eval confidence intervals on both numbers, because a 500-example set carries more sampling error than most teams admit. At 500 examples, the 95% interval on a single accuracy near 85% spans roughly 3 points on each side. The win sat well inside the noise. I lead the fine-tuning and evaluation team at Nexus Labs, and the most common mistake I see is treating an eval score as exact. It isn't. Your eval set is a sample drawn from the input space you care about, and a different 500 examples would return a different number. Confidence intervals make that variance visible. What an eval confidence interval actually tells you An eval confidence interval is a range around a metric, like accuracy or F1, that quantifies how much the score would move if you resampled the eval set. A 95% bootstrap interval of [81.0%, 87.1%] means that across thousands of resamples of your data, 95% of the recomputed scores fell in that band. It measures sampling noise, not model quality. That distinction matters. Two checkpoints scoring 84.2% and 85.7% with overlapping intervals are, as far as your eval set can tell, indistinguishable. Card et al. showed in "With Little Power Comes Great Responsibility" that many NLP experiments are underpowered to detect the effect sizes they report. Computing bootstrap confidence intervals The bootstrap is resampling with replacement. You take your per-example results, draw N of them with replacement many times, recompute the metric each time, and read percentiles off the resulting distribution. There's no assumption that

Line AI Chatbot In Production: A CTO's Honest Breakdown Three months ago I was staring at our infrastructure bill wondering where the hell our runway went. We'd been running a customer-facing chatbot powered by a popular "enterprise" AI provider, and the cost curve looked like a hockey stick in the wrong direction. Every new sign-up bled money. I knew we had to make a change before our next board meeting, but I also couldn't afford a six-week migration that would tank our product velocity. What I found surprised me. After running the numbers, testing 184 models through Global API, and stress-testing everything at scale, I cut our inference costs by more than half without touching quality. This isn't a theoretical comparison from a vendor whitepaper. These are the real numbers from my production stack, with my actual users, in my actual platform. If you're a CTO weighing your options for 2026, here's everything I wish someone had told me before I started. Why The Line AI Chatbot Approach Matters Now Most chatbot guides treat AI integration like a toy problem. Send a prompt, get a response, ship the demo. That's fine for a hackathon, but it's not how you run a production system. The questions I care about are different: What's my cost per active user? How do I avoid vendor lock-in? Where's the single point of failure? How fast can I iterate on model choice when something better drops next Tuesday? The Line AI Chatbot framework flips the typical approach. Instead of treating the model as a black box you can't replace, you build a thin abstraction layer over a model-agnostic API. That single architectural decision is what unlocked every other win I describe below. If you're not thinking about model portability on day one, you're going to pay for it later. I learned this the hard way. In 2026, the market has matured to a point where you genuinely have 184 models to choose from, with input prices ranging from $0.01 to $3.50 per million tokens. That's not a marketing line.

Just finished reading Saha et al. arXiv 2506.07001 on adversarial paraphrasing for AI detector evasion. Key claim: detector-guided paraphrasing with RoBERTa as reward reduces TPR by 87.88 percent across Binoculars, Fast-DetectGPT, Ghostbuster, RADAR, GPTZero. Universal, training-free. What surprised me: the approach works even on detectors that were trained with adversarial examples baked in. Suggests the discriminator signal is fundamentally narrower than the generator space. Open questions: Does this generalize to detectors using surprisal variance (DivEye 2509.18880)? Multi-LLM round-robin generation: would mixing 3-4 models in pipeline give even more headroom? Token-level homoglyph substitution (SilverSpeak) is trivially detectable via Unicode normalization, but adversarial paraphrasing leaves no such forensic signal.

I recently published my PhD thesis analyzing what I term the "Alignment Tax" and the emerging phenomenon of Algorithmic Paternalism in commercial artificial intelligence. As the tech industry rapidly positions Large Language Models (LLMs) as the primary interface for information retrieval and coding assistance, a critical epistemological issue is being largely ignored. Much of the public debate regarding AI alignment focuses exclusively on existential risk or the prevention of catastrophic physical harm. While necessary, this focus obscures the structural damage being done to legitimate technical research. Through my research in Cybersecurity and AI, I have documented how frontier models (such as GPT-4 or Claude) systematically enforce what I define as "Soft Refusals". When presented with a complex, edge-case, or dual-use query—particularly in fields like information security, reverse engineering, or deep systems architecture—these models rarely issue a hard, explicit "I cannot answer that". Instead, they provide a degraded, superficial, or heavily sanitized response. They effectively neuter the research process without the user fully realizing the depth of technical information that is being actively withheld. This is Algorithmic Paternalism. The commercial model acts as a silent, corporate arbiter, deciding unilaterally what level of technical detail is "safe" for the user to possess. This dynamic flattens the available technical knowledge and actively penalizes independent researchers and developers working on advanced problems. The core issue is that this paradigm creates a profound class division in how we access computational intelligence. We are rapidly moving toward a two-tier system. On one side, there are "certified" entities, corporate partners, and wealthy organizations who are granted direct access to strong, unfiltered base models. On the other side, the general public and independent developers are subjected to obfuscation algorithms, sanitized APIs,

How I Stopped Burning Cash on Token Limits — A CTO's Field Notes Three months ago, I was staring at our monthly AI bill wondering where it all went wrong. We'd built what I thought was a pretty elegant LLM pipeline. Production-ready, observability wired up, the whole nine yards. Then the invoices started arriving, and I realized I had built a money furnace. Our token consumption was spiking 3x week over week, the 429s were everywhere, and our latency had become a meme inside the company. This is the post I wish I'd had six months ago. If you're a technical founder or a CTO running LLM workloads at scale, bookmark this. I'm going to walk you through the exact architecture decisions, the exact numbers, and the exact code that took us from "this bill is going to kill us" to "oh, this is actually manageable." The Real Problem Nobody Talks About Here's the dirty secret about running LLM-powered products: token limit errors aren't really about token limits. They're a symptom of a much deeper architectural problem. When your app throws "context length exceeded" at 2am, what it's really telling you is that you didn't think hard enough about prompt design, document chunking, model selection, and cost routing on day one. I learned this the hard way. My team was defaulting to GPT-4o for everything because, honestly, it works and the API is reliable. We were paying $2.50 per million input tokens and $10.00 per million output tokens. For a startup processing millions of documents a month, that math is brutal. We were essentially funding OpenAI's next training run with our Series A. The wake-up call came when I ran the actual numbers. Our average request was burning through maybe 8K input tokens and producing 2K output tokens. At our volume, we were spending more on inference than on two senior engineers. That is not a sustainable burn rate for a 12-person company. The Architecture Decision That Changed Everything The first question I asked myself wasn't "which model is cheapest?

A look at what's actually changing in Nepal's job market, what it means for students and working professionals, and what separates training that gets you hired from training that just gives you something to print on a resume. Nepal is at an interesting crossroads right now. On one side, the country still carries the weight of a job market that hasn't kept up with its graduates. Every year, more than 500,000 young people enter the workforce. The economy, for all its resilience, simply does not generate enough traditional jobs to absorb that number. The result is familiar to most Nepali families: children who studied hard, passed their exams, collected their certificates, and then spent months, sometimes years, waiting for something to happen. On the other side, something genuinely different is building. Nepal's IT exports crossed $1 billion in 2025, according to NASIT's estimates. Software and BPO exports grew over 20% in the first seven months of fiscal year 2024/25 alone. The government's 16th development plan has set a target of 250,000 new IT jobs and a 5% GDP contribution from the sector by 2029. International companies, from Indian IT majors to US-based outsourcing firms, are paying attention to Nepal in ways they weren't a decade ago. These two realities exist at the same time, in the same country, often in the same family. A brother driving a taxi while his younger sister lands a remote software development contract earning more than their father ever did in a government job. The difference between those two outcomes, more often than not, comes down to whether someone made the decision to learn something the market actually needs, and found a way to learn it properly. That's what this piece is about. The Skills Gap Problem Nobody Talks About Enough Nepal's IT sector is growing, but that growth comes with a problem attached: a persistent, widening mismatch between what employers need and what most fresh graduates can actually do on day one. Companies like Deer

We live in an era where our most intimate data—heart rates, sleep cycles, and step counts—is constantly uploaded to the cloud for "analysis." But what if you could have a world-class AI medical assistant living entirely on your device? Today, we are pushing the boundaries of Edge AI and Privacy-preserving machine learning by deploying a quantized Llama-3 model directly onto an iPhone using MLC-LLM . By leveraging Apple HealthKit and hardware acceleration via Metal , we can transform "Pixels and Pulses" into actionable insights without a single byte leaving the device. This tutorial dives deep into the architecture of on-device LLMs, specifically focusing on how to bridge the gap between high-performance C++ runtimes and a React Native UI. If you're interested in more advanced patterns for production-grade AI integration, be sure to explore the engineering deep-dives at the WellAlly Blog , which served as a massive inspiration for this architecture. 🚀 The Architecture: Why On-Device? The challenge with running Llama-3 on mobile isn't just memory—it's the data pipeline. We need to fetch sensitive data from HealthKit, format it into a prompt, and run inference using the phone's GPU. System Data Flow graph TD A[User Query: How was my sleep?] --> B[React Native UI] B --> C{Swift Bridge} C --> D[Apple HealthKit API] D --> E[Health Data Context] E --> F[MLC-LLM Engine] G[Quantized Llama-3 Weights] --> F F --> H[On-Device Inference via Metal] H --> I[AI Generated Health Report] I --> B 🛠 Prerequisites MLC-LLM : Our compiler stack for universal LLM deployment. TVM (Tensor Virtual Machine) : The backbone for hardware acceleration. React Native : For the cross-platform UI. Xcode & Swift : To interface with Apple's HealthKit. Llama-3-8B-Instruct (Quantized) : We'll use 4-bit quantization (q4f16_1) to fit within mobile RAM limits. Step 1: Quantizing Llama-3 for Mobile Standard Llama-3 is too heavy for a phone. We use the MLC-LLM CLI to compile the model into a format that the iP

There's a quiet assumption baked into a lot of agent code: that a bigger context window means a better memory. Vendors ship 200K, then 1M, then 2M token windows, and the implied promise is "just put everything in and the model will remember." After building agents that run for weeks, I've come to think this conflates two things that are not the same — and treating them as the same is exactly why long-running agents get dumber over time. The context window is working memory. Real memory is what survives when the window is gone. Mixing them up is like confusing your desk with your filing cabinet. Two different clocks Working memory (the context window) lives for one session, maybe one turn. It's fast, expensive, and volatile. It's where reasoning happens right now . Durable memory lives across sessions. It's slow, cheap, and persistent. It's what the agent knows when it wakes up tomorrow with an empty window. These have different lifespans, different costs, and different access patterns. The moment you try to make one do the other's job, things break: Use the window as memory → everything you "remember" has to be re-loaded every turn, you pay for it every turn, and the instant the session ends it's gone. Use durable storage as working memory → you're reading and writing files mid-reasoning for things that only matter for the next 30 seconds. A good agent keeps them separate on purpose. Why "just use a bigger window" fails Say you have a 1M token window and you stuff the entire history in. Three problems show up, none of which a bigger number fixes: Cost scales with every turn, not every session. That 1M tokens isn't paid once — it's re-sent on each step of a multi-turn task. A 20-step task can mean 20× the bill, mostly re-reading the same stale history. Attention dilutes. "Lost in the middle" is real: models attend most reliably to the start and end of a long context. Bury the one fact that matters under 900K tokens of transcript and recall quality drops, even though

"It runs on my own GPU, so it's basically free." I believed that until I put a meter on it. So I ran a controlled benchmark on one box — an openSUSE machine with a single RTX 3090 — driving three local models through ollama under an identical fixed workload (256-token generations in a loop for ~4 minutes each), while my open-source dashboard priced every run by the real GPU energy it burned : power sampled from nvidia-smi every 10 s, integrated over each run's exact window, multiplied by my actual day/night tariff. One number per model, in euros per million output tokens. Here's the part that made me re-run it. The tiny gemma3:1b came out at €0.118 / 1M tokens — about 5× cheaper than a hosted Flash-class API (~€0.55). But gemma3:27b 's electricity alone was €0.706 / 1M — more expensive per token than just paying the cloud, and that's before a single cent of the GPU's purchase price. "Local" didn't make it cheaper; it made it cost more and I own the depreciation. The mechanism is one line: each token costs watts ÷ throughput , and a big dense model is both slow and thirsty. A newer mid-size architecture ( gemma4:26b ) bought a lot of that back, landing at €0.272 . The full guide is methodology-first and reproducible end to end — minting an ingest key, the stdlib-only client, the exact ollama loop that reads eval_count / eval_duration for real tokens-per-second, reading each run back priced, and the honest caveats (this is marginal GPU energy only — not capex, idle, or cooling — and the absolute numbers round to fractions of a cent; the shape is the finding). Read the full guide on Medium → https://medium.com/@arsen.apostolov/how-much-does-it-actually-cost-to-run-a-local-llm-per-million-tokens-measured-4a90a7f31a48

If you're learning Data Analytics and looking to build a strong portfolio, working on real-world...

The trajectory of AI agents over the past two years has been remarkably clear: from single-purpose tools to personal assistants. Everyone runs their own agent, feeds it tasks, gets results back. It works well for individual productivity. Then comes the question every team eventually asks: can these agents work together? The answer is yes, but the problems you encounter along the way are rarely the ones you expected. They aren't about model capabilities or prompt engineering. They're about communication, context, and coordination — the same class of problems that distributed systems engineers have been solving for decades, now showing up in a new form. Here are three challenges that caught us off guard when we started building agent collaboration into Octo , an open-source workplace platform where AI agents and humans share the same communication space. Challenge 1: Context Visibility Boundaries When you use an agent personally, context management is straightforward. You decide what information the agent sees; its output comes back to you. The boundary is clean — it's just your workspace. In a team setting, that boundary dissolves. One of the first issues we ran into was surprisingly simple. We had an agent summarizing discussions across several channels. During testing it started pulling roadmap discussions from a product channel into an engineering planning thread. Nothing sensitive leaked externally, but it immediately exposed how unclear our context boundaries were. Traditional software handles this through API gateways, data permissions, and microservice boundaries. But agent context isn't just structured data — it includes conversation history, reasoning chains, and intermediate states. An agent's thought process during a task is valuable context, but it might also contain information that shouldn't cross team boundaries. What you need is fine-grained context visibility control. Not "everything open" or "everything closed," but dynamic rules that determine whic

We’ve all been there: waking up feeling like a zombie despite getting eight hours of sleep. While wearables give us data, they often fail to give us foresight . What if you could predict your stress levels 24 hours in advance? 🚀 In this tutorial, we are going to tackle HRV prediction (Heart Rate Variability) using a state-of-the-art Temporal Convolutional Network (TCN) . By leveraging the Oura Ring API and deep learning, we’ll transform non-stationary biometric time series into actionable insights. Whether you're into time series forecasting or building the next big health-tech app, mastering Temporal Convolutional Networks (TCN) is a game-changer for handling long-term dependencies without the vanishing gradient headaches of traditional RNNs. For those looking for more production-ready examples and advanced biometric signal processing patterns, I highly recommend checking out the deep-dives at WellAlly Blog , which served as a major inspiration for this architecture. The Architecture: Why TCN? Traditional LSTMs are great, but they process data sequentially, making them slow and prone to memory loss over long sequences. TCNs, however, use Dilated Causal Convolutions , allowing the model to look back exponentially further into the past with fewer layers. Data Flow Overview graph TD A[Oura Cloud API] -->|Raw JSON| B(Pandas Preprocessing) B -->|Cleaned HRV/Activity| C{Feature Engineering} C -->|Sliding Windows| D[TCN Model Training] D -->|Dilated Convolutions| E[Stress Trend Prediction] E -->|24h Forecast| F[Dashboard/Alerts] style D fill:#f9f,stroke:#333,stroke-width:2px Prerequisites To follow along, you'll need: Tech Stack : Python, TensorFlow/Keras, Pandas, Scikit-learn. Data : An Oura Cloud Personal Access Token (or use the mock data generator provided). Difficulty : Advanced (Buckle up! 🏎️). Step 1: Fetching Biometric Data First, we need to pull our "Readiness" and "Sleep" data. Oura provides high-resolution HRV samples (usually 5-minute intervals during sleep).

If you've shipped software in the last three years, you've probably watched your job description...

In this article, we will explore how to implement an LSTM using PyTorch and Lightning . For more details about LSTMs, there is a separate series of articles available here . Imports To begin, we first import the required modules. import torch import torch.nn as nn import torch.nn.functional as F Introducing a New Optimizer We also introduce a new optimizer: from torch.optim import Adam Adam is used to fit the neural network to the data. It works similarly to SGD, but in practice, Adam often converges faster and adapts the learning rate more effectively. Lightning and Data Utilities Next, we continue with the remaining imports: import lightning as L from torch.utils.data import TensorDataset , DataLoader Defining the LSTM Model We define the neural network by creating a Lightning module. class LSTMByHand ( L . LightningModule ): def __init__ ( self ): # Create and initialize weight and bias tensors def lstm_unit ( self , input_value , long_memory , short_memory ): # LSTM computations def forward ( self , input ): # Forward pass through the unrolled LSTM def configure_optimizers ( self ): # Configure Adam optimizer def training_step ( self , batch , batch_idx ): # Compute loss and log training progress Initializing the Model Now let’s implement the __init__ method. This is where we initialize all weights and biases. class LSTMByHand ( L . LightningModule ): def __init__ ( self ): super (). __init__ () mean = torch . tensor ( 0.0 ) # Mean of the normal distribution std = torch . tensor ( 1.0 ) # Standard deviation # ------------------------- # Forget Gate (l = "lr") # ------------------------- self . wlr1 = nn . Parameter ( torch . normal ( mean = mean , std = std ), requires_grad = True ) self . wlr2 = nn . Parameter ( torch . normal ( mean = mean , std = std ), requires_grad = True ) self . blr1 = nn . Parameter ( torch . tensor ( 0.0 ), requires_grad = True ) # ------------------------- # Input Gate (p = "pr") # ------------------------- self . wpr1 = nn . Parameter

We all know the grind of working with data, even with AI tools: every experiment starts with re-explaining everything, every iteration needs you to prompt, wait, review, correct, and repeat. And the moment you close the session, everything learned is gone. It makes us the bottleneck, and this hinders human-AI collaboration... So I built 𝐎𝐩𝐞𝐧𝐃𝐚𝐭𝐚𝐒𝐜𝐢, an autonomous agent purpose-built for DS/ML, and tested it on Kaggle. I enrolled in a recent competition, ran the agent with no hints, no guidance, while ironing my shirts. In one shot, it landed AUC 0.95, a top-30% finish out of 3K+ teams and 36K+ submissions using hashtag#Anthropic's Claude Sonnet 4.6. (More on this in README) The top-1 outperformed this agent by merely 0.004, but at the cost of massive manual effort even while using popular AI tools. The needed a dozen model families, deep learning, 400-feature notebooks, AutoML sweeps across many libraries, and 186 models ensembled carefully. Essentially a few weeks worth of effort and time!! OpenDataSci abstracts away all the complexity and has so much to offer for DS/ML automation: → Owns the entire development lifecycle from EDA to final evaluation → Plans, codes, and executes autonomously in a secure local sandbox → Self-reviews and corrects before anything reaches you → Remembers your data across sessions, gets smarter each run → Runs parallel experiments and ensembles → Has advanced context management for token efficiency and quality → Ships with predefined skills for DS/ML, so it knows how to do things right → Bring your own knowledge: out-of-the-box support for custom skills → Works with any major LLM provider (hashtag#Anthropic, hashtag#OpenAI, hashtag#Bedrock, hashtag#VertexAI, hashtag#Ollama, hashtag#vLLM, and any OpenAI-compatible server). This and so much more!! You set the goal. It does the work. No data science knowledge required. 🔗 https://github.com/f4roukb/open-data-sci 📦 pip install open-data-sci Spin it up on your data and see what it achieves!

Over three posts I built three fine-tuned models for the same banking-intent task — full fine-tuning a 270M model , LoRA on 1.5B , QLoRA on 7B . They all landed around the same accuracy. Which raises an honest, slightly uncomfortable question: if a 270M model on my laptop already worked, why reach for a 7B model at all? The answer most "bigger is better" content skips For this task — you wouldn't. A good engineer picks the smallest model that clears the bar , not the biggest one available. The small model is cheaper to serve, runs in milliseconds, and you fully own it. Choosing the 7B here would be over-engineering. Reaching for a bigger model isn't a flex. It's a response to a requirement the small one can't meet. Here are the four cases where small stops being enough: 1. The task is genuinely hard Banking77 is easy — 77 fixed labels, short clean queries. Small models saturate it. But ask for reasoning ("which of these three issues is the primary one?"), open-ended generation (write the reply, don't just classify), or real nuance, and there's a capability floor that more parameters buy. No amount of fine-tuning gives a 270M model abilities it doesn't have. 2. You have little data I had ~10,000 labeled examples — plenty for a small model. With 50, a small model can't learn the task, but a 7B model already "knows" banking concepts from pretraining and only needs a nudge. Bigger models need less task data because they bring more prior knowledge. 3. You need one model for many tasks This is the quiet superpower of LoRA/QLoRA. A single frozen 7B base can host dozens of swappable adapters — intent classifier, reply writer, summarizer, sentiment — all from one ~5GB footprint in memory. The 270M is single-purpose. This is why companies serve hundreds of fine-tunes from one base model. 4. Accuracy compounds at scale 93% means 7 in 100 queries misrouted. At 10M queries/month, that's 700,000 mistakes. If each costs a support escalation, the 2–3 points a bigger model buys can

In Part 2 , LoRA let me fine-tune a 1.5B model by freezing it and training tiny adapters. But the frozen base still sat in memory in 16-bit (~3GB). Now I wanted to go to Qwen2.5-7B — and hit a wall that LoRA alone doesn't solve. The problem A 7B model is ~15GB in 16-bit precision. A free-tier T4 GPU has 16GB. It would barely load, with no room left to actually train. The QLoRA insight QLoRA asks the question that naturally follows from LoRA: the base is frozen and only ever read — so why store it in full precision? So you quantize the frozen base to 4-bit (NF4, a format tuned for how neural-net weights are distributed) and run the LoRA adapters on top in normal precision. The base shrinks dramatically; the trainable part stays small and precise. from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig ( load_in_4bit = True , bnb_4bit_quant_type = " nf4 " , # NormalFloat4 bnb_4bit_use_double_quant = True , # quantize the quant constants too bnb_4bit_compute_dtype = torch . float16 , # dequantize to fp16 for the matmuls ) model = AutoModelForCausalLM . from_pretrained ( MODEL_ID , quantization_config = bnb_config , device_map = " auto " ) Each flag earns its place: load_in_4bit — store frozen weights in 4 bits instead of 16. nf4 — a 4-bit type matched to the bell-curve distribution of neural-net weights (better than plain int4). double_quant — quantize the quantization constants too, for a bit more savings. compute_dtype — dequantize to fp16 for the actual matmuls, so storage is 4-bit but compute stays precise. The moment it clicked One line of output: loaded in 4-bit. footprint: 5.44 GB I downloaded 15.2GB of weights and they sat in memory as 5.44GB. A model that couldn't be loaded for full fine-tuning was now training on a single consumer GPU — with room to spare. (The download is still 15GB; bitsandbytes quantizes on the fly during load.) The QLoRA-standard recipe Two more pieces beyond Part 2's LoRA setup: prepare the quantized model for trainin

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

I run a homelab with four RTX 3090s — 96 GB of VRAM, 44 CPU cores. For two weeks I tried to make it my daily driver for local LLM inference instead of paying for cloud APIs. I got it working. Then I looked at the numbers and subscribed to a paid API anyway. Here's the uncomfortable part, and the optimizations that still made it worth doing. ## The setup 4× RTX 3090 (Ampere — no native BF16), 96 GB VRAM total, 44 cores Models: Qwen3.6-35B-A3B (Q8_0, MoE) and Qwen3-Coder-Next (Q6_K, hybrid) llama.cpp in router mode + OpenWebUI Ceiling I hit: ~105 tokens/second ## The 6% problem The wall wasn't compute. GPU utilization sat at 6%. The bottleneck was CPU orchestration — llama.cpp dispatches across multiple GPUs sequentially, so the cards spent 94% of the time idle waiting on each other. Throwing more VRAM at it does nothing for this. ## What actually moved the needle | Change | Effect | |---|---| | --ubatch-size 512 | +40% throughput | | KV cache quantization (Q4_0) | 4× VRAM savings | | Speculative decoding (n-gram) | 2.5× speedup on repetitive tasks | | YaRN rope scaling | context extended to 1M tokens | Two things surprised me: MoE models tolerate aggressive quantization far better than dense ones — inactive experts don't eat bandwidth, so the quant hit lands softer. The 3B active -parameter model was great at local decisions but fell apart on coherence past ~300–400 lines of code — fine for a function, not for cross-file consistency. ## The conclusion I didn't want At ~11 kWh/day, plus hardware depreciation, against current API pricing, the math doesn't favor local for interactive work. The single biggest improvement to my daily AI workflow was paying for an API. Local still wins for privacy, high-volume batch jobs, or uncensored experimentation — but not as a general cloud replacement. It's an economics problem, not a capability one. I wrote up the full cost breakdown and the exact llama.cpp router configs on aipster.com . If you're weighing a local rig, I also benc