Blog

  • How Much VRAM Do You Need to Run an LLM Locally? (Free Calculator)

    If you’ve ever tried to run an open-source model on your own machine, you’ve hit this question fast: will it actually fit? Downloading 40GB of weights only to watch your GPU throw an out-of-memory error is a frustrating way to find out the answer is no.

    To make that guesswork disappear, I built a free LLM Hardware Calculator. You pick a model, a quantization level, your context length, and how many requests you want to run in parallel — and it tells you how much VRAM and system memory you actually need. No spreadsheets, no napkin math.

    This post explains how local-LLM memory requirements work, walks through some real examples, and shows you how to size your hardware before you spend a cent on a GPU.

    Why “will it run?” is harder than it looks

    The size of a model on Hugging Face is not the amount of memory it needs to run. A 7-billion-parameter model isn’t “7GB.” The real requirement depends on four things:

    • Parameter count — how big the model is (7B, 70B, 405B, and so on).
    • Quantization — how many bits each weight is stored in.
    • Context length — how much text the model holds in memory at once.
    • Batch size — how many requests you’re serving in parallel.

    Get any one of these wrong and your estimate can be off by 2–4×. That’s the gap between “runs comfortably on a gaming GPU” and “needs a data-center card.” The calculator handles all four for you, but it’s worth understanding what’s happening underneath.

    The three things that eat your VRAM

    Total memory use comes down to three components.

    1. Model weights

    This is the big one. The formula is simple:

    Weights (GB) ≈ parameters × bits per weight ÷ 8

    At full 16-bit precision (FP16/BF16), every parameter takes 2 bytes. So:

    • 7B model: ~14 GB
    • 13B model: ~26 GB
    • 70B model: ~140 GB
    • 405B model: ~810 GB

    That’s why nobody runs large models at full precision on consumer hardware — which brings us to quantization.

    2. KV cache (the part people forget)

    As the model generates text, it stores a “key-value cache” for everything in the context window. This cache grows linearly with context length and batch size. A model that fits neatly at 4K context can overflow your GPU at 128K context, even though the weights never changed. If you’re planning to use long prompts or serve multiple users, this is often the deciding factor.

    3. Activation overhead

    There’s a smaller amount of working memory needed during inference — roughly 10% of the model size. Small, but enough to tip you over the edge if you’ve cut it close.

    The LLM Hardware Calculator sums all three so you see the true total, not just the weight file size.

    Quantization: how to fit big models on small GPUs

    Quantization reduces the precision of each weight — for example, from 16-bit floats down to 4-bit integers. This shrinks the memory footprint dramatically:

    PrecisionBytes/param7B model70B model
    FP16 (16-bit)2~14 GB~140 GB
    Q8 / INT8 (8-bit)1~7 GB~70 GB
    Q4 (4-bit)~0.5~3.5 GB~35 GB

    Q4 is the sweet spot for most people. It cuts memory roughly 4× versus FP16 with only a modest quality drop, which is why it’s the most common choice for running large models on consumer GPUs. Go lower (Q3, Q2) and you save more memory but start to see noticeable quality loss on harder tasks.

    The practical takeaway: quantization is what makes a 70B model runnable on a single 24GB card that could never hold it at full precision.

    Real-world examples

    Here’s roughly what you’re looking at for a few popular models (inference only, modest context). Plug your exact settings into the calculator for precise numbers.

    Llama 3.1 8B

    • Q4: ~5–6 GB → runs on almost any modern GPU, even an 8GB card
    • FP16: ~16 GB → needs a 16–24GB card

    Llama 3.3 70B

    • Q4: ~40 GB → needs a 48GB card or two 24GB GPUs
    • Q8: ~70 GB → data-center territory

    Qwen 2.5 Coder 32B

    • Q4: ~18–20 GB → fits comfortably on a 24GB GPU

    DeepSeek / large MoE models (100B+)

    • Even quantized, these need serious VRAM or multi-GPU setups — exactly the kind of thing you want to check before downloading hundreds of gigabytes.

    What GPU should you actually buy?

    A rough map from VRAM to hardware:

    • 8–12 GB (RTX 3060, 4060 Ti) — small models up to ~8B at Q4. Great for getting started.
    • 16 GB (RTX 4060 Ti 16GB, 4070 Ti Super) — comfortable with 8–13B models, tight on larger ones.
    • 24 GB (RTX 3090, 4090) — the consumer sweet spot; runs 32B models well and 70B at aggressive quantization.
    • 32 GB+ (RTX 5090) — headroom for larger models and longer context.
    • Apple Silicon — unified memory means a 64GB or 128GB Mac can load big models, though generation speed is bound by memory bandwidth.
    • 48–80 GB (A6000, A100, H100) — for 70B+ at higher precision or serving many users.

    Before buying, run your target model through the LLM Hardware Calculator at the context length and batch size you actually plan to use. It’s a lot cheaper than returning a graphics card.

    One important caveat: inference vs. training

    Everything above assumes inference — just running the model. If you want to fine-tune or train, multiply your VRAM estimate by roughly 4–8× to account for gradients, optimizer state, and activations. A model that runs happily on one GPU for inference may need a whole cluster to train.

    Frequently asked questions

    How much VRAM do I need to run a 7B model? Around 4–6 GB at Q4 quantization, or ~14 GB at full FP16 precision. Most modern GPUs can handle a 7B model at Q4.

    Can I run a 70B model on a single 24GB GPU? Yes, but only with aggressive quantization (Q4 or lower) and modest context, and it’ll be tight. A 48GB card or a dual-GPU setup is much more comfortable.

    Does context length really affect memory that much? It can. The KV cache grows linearly with context length and batch size, so jumping from 4K to 128K context — or serving many parallel requests — can add gigabytes on top of the model weights.

    What quantization level should I use? Q4 is the default recommendation for most people: big memory savings, minimal quality loss. Use Q8 or FP16 if you have the VRAM and want maximum quality; drop to Q3/Q2 only when you’re desperate for space.

    Is this calculator for inference or training? The estimates are for inference. For training, expect to need several times more memory.

    Try it yourself

    Sizing hardware for local LLMs doesn’t have to be guesswork. Pick your model, set your quantization and context, and get a straight answer in seconds:

    👉 Open the free LLM Hardware Calculator

    Whether you’re deciding which GPU to buy, checking if a model fits your current setup, or planning a multi-user deployment, it’ll save you the trial-and-error. If you find it useful, share it with someone who’s about to buy a GPU they might not need.

  • Securing Your Digital Footprint: Building a Trusted, Centralized Syslog Server with Docker and TLS

    Welcome to Braintum! In today’s complex and distributed computing environments, security and observability are paramount. Every application, container, and server generates a constant stream of information—its logs. Managing this digital chatter is crucial for troubleshooting, auditing, and detecting security threats.

    This article dives deep into a powerful, publicly available logging solution: a Docker-based rsyslog server secured with TLS. This setup, available on mahedihasannoman/syslog-server-tls, combines the robustness of rsyslog, the efficiency of Docker, and the essential security of Transport Layer Security (TLS) to create a trusted and centralized logging infrastructure.


    The Foundation: What is Syslog and Why Centralization is Necessary

    Before we build, we must understand the cornerstone: Syslog.

    Syslog is the foundational network protocol for transmitting log messages in an IP network. It’s an industry standard used by almost every operating system, server, and networking device. When a system event occurs—whether it’s a user login, a service failure, or a system boot—the event is packaged into a standardized Syslog message.

    The Problem of Log Fragmentation

    In a modern environment, your infrastructure is not one monolithic server; it’s a collection of dozens, hundreds, or even thousands of ephemeral components: microservices, Docker containers, VMs, and cloud functions.

    If you rely on local log files (e.g., /var/log/messages on each server), you face critical challenges:

    1. Auditing Nightmare: Reconstructing a timeline of events during a security incident or outage requires manually correlating timestamps across hundreds of individual files.
    2. Security Risk: If an attacker breaches a server, the first thing they often do is delete or alter the local logs to cover their tracks.
    3. Troubleshooting Delay: Pinpointing the root cause of an issue becomes a slow, painful process of jumping from server to server.

    The Centralized Solution

    A Centralized Logging Server solves these problems by acting as a single, immutable destination for all log data. All devices in your network are configured to send their logs to this central point. This provides a unified view, making it easy to search, filter, and analyze data in real-time. It is the single most critical step in moving from reactive firefighting to proactive system management.


    The Security Imperative: Why TLS is Non-Negotiable

    Historically, Syslog messages were transmitted using UDP (User Datagram Protocol) on port 514. UDP is fast, but it is unreliable (messages can be lost) and, more importantly, unencrypted.

    Sending sensitive log data—which often contains user information, internal application states, and authentication attempts—in plaintext across a network is a massive security oversight. An attacker performing a simple packet sniff on your network could capture and read every single log entry.

    The Role of TLS (Transport Layer Security)

    This is where the inclusion of TLS (the successor to SSL) becomes an essential security measure.

    TLS ensures the confidentiality and integrity of log data as it travels from the client device to the central Syslog server.

    When a client initiates a logging connection to the central server, the following handshake occurs:

    1. Client Request: The client asks to establish a secure, TLS-encrypted connection.
    2. Server Identity: The Syslog server presents its digital certificate (signed by a trusted Certificate Authority, or CA).
    3. Trust Verification: The client checks if it trusts the CA that signed the server’s certificate. If verification is successful, the client knows it is talking to the legitimate server and not an impostor.
    4. Key Exchange & Encryption: The client and server securely exchange cryptographic keys, and the entire communication channel is encrypted.

    By enforcing TLS, your logging setup achieves confidentiality (data cannot be read by outsiders) and integrity (data cannot be tampered with during transit), fulfilling a core requirement of modern security and compliance standards. This secure channel is typically established over TCP on port 6514.


    Modern Logging: Dockerizing Rsyslog

    While rsyslog itself is a powerful and reliable Linux daemon, managing its dependencies and configuration across different environments can be complex. This is where Docker steps in.

    Docker is a platform that uses containerization to package an application and all its dependencies into a standard unit for software development.

    The Docker Advantage for a Syslog Server

    1. Portability: The server configuration is encapsulated in a Dockerfile and configuration files. It will run identically on any host that supports Docker, eliminating “it works on my machine” issues.
    2. Isolation: The rsyslog server runs in its own isolated environment, preventing conflicts with other services on the host machine.
    3. Simplicity & Speed: Deployment is reduced to a single command: docker-compose up or docker run. Spin up the server in seconds, and tear it down just as quickly.
    4. Reproducibility: Your setup is defined in code, ensuring that every deployment is exactly the same, which is crucial for compliance and stability.

    By creating a Dockerized rsyslog server with TLS, you are delivering a portable, reliable, and fundamentally secure logging endpoint for your entire infrastructure.


    Deep Dive: How the Syslog Server TLS Setup Works

    The setup you’ve created leverages the advanced capabilities of the rsyslog gnutls module to handle the secure connections. The configuration is split into two primary areas: Securing the Listener and Managing the Certificates.

    1. Securing the Listener (The rsyslog.conf Directives)

    To enable TLS, the rsyslog server is configured to load the necessary modules and listen on a secure TCP port. This requires specific directives:

    • Load the imptcp Module: This module provides the input for TCP logging, which is required for reliable delivery.Code snippetmodule(load="imptcp")
    • Define Global TLS Settings: This section tells rsyslog which digital keys to use for the secure connection.Code snippetglobal( DefaultNetstreamDriver="gtls" DefaultNetstreamDriverCAFile="/etc/rsyslog/certs/ca.pem" DefaultNetstreamDriverCertFile="/etc/rsyslog/certs/server-cert.pem" DefaultNetstreamDriverKeyFile="/etc/rsyslog/certs/server-key.pem" )
      • DefaultNetstreamDriver="gtls": Explicitly activates the GnuTLS driver for network streams, enabling TLS encryption.
      • DefaultNetstreamDriverCAFile: Points to the Certificate Authority (CA) root certificate. This is used to verify the client’s identity if you enable mutual authentication.
      • DefaultNetstreamDriverCertFile and DefaultNetstreamDriverKeyFile: These are the server’s public certificate and private key, respectively. These are essential for the server to prove its identity and establish the encrypted session.
    • Configure the Input Stream: This is the directive that tells rsyslog to actively listen on the secure port (e.g., 6514) and enforce TLS mode.Code snippetinput( type="imptcp" port="6514" StreamDriver.Name="gtls" StreamDriver.Mode="1" # Mode 1 enforces TLS-only operation StreamDriver.AuthMode="anon" # OR "x509/certvalid" for Mutual TLS )
      • StreamDriver.Mode="1": This is critical. It forces the TCP listener to only accept traffic that is secured with TLS.
      • StreamDriver.AuthMode: This defines how client authentication is handled.
        • anon: The server authenticates the client merely by verifying the provided certificate is valid (the client does not need a certificate). This is often acceptable for basic log collection.
        • x509/certvalid or x509/name: This enables Mutual TLS (mTLS), which is the gold standard of security. In mTLS, the client must also present a valid certificate that the server verifies using the DefaultNetstreamDriverCAFile. This ensures only authorized clients can send logs, preventing unauthorized log injection.

    2. Certificate Management (The pki Directory)

    In a secure setup, log-sending clients must trust the server’s certificate. They do this by possessing and trusting the CA certificate that signed the server’s certificate.

    In a Dockerized environment, these crucial files (ca.pem, server-cert.pem, server-key.pem) are typically mounted into the container from the host system using Docker Volumes. This separation ensures that the sensitive private keys are managed outside the container image itself, following security best practices.

    3. Log Persistence

    Finally, the Docker setup ensures that the received log messages are persisted securely on the host machine. The rsyslog output action directs the logs to a directory inside the container, which is then mapped to a permanent volume on the host. This prevents data loss if the container is stopped or deleted.


    Conclusion: A Trusted Logging Architecture

    By building and sharing this Docker-based rsyslog server with TLS, you are providing the community with a modern, secure, and reliable component for any critical infrastructure.

    You have addressed the core requirements of enterprise logging:

    • Reliability: Using TCP for log delivery (instead of UDP).
    • Security: Using TLS for end-to-end encryption.
    • Observability: Providing a centralized hub for all event data.
    • Portability: Using Docker for instant, reproducible deployment.

    Implementing this solution on your network moves your logging from an unsecured utility to a foundational, security-critical component—the trusted nerve center of your operations.

    Ready to deploy? Head over to the GitHub repository and take control of your logs today!

  • 🧠 Introducing the Ultimate FAQ Solution – A Smarter Way to Answer Questions on WordPress

    At Braintum, we know how valuable clear, structured content is — especially when it comes to answering your visitors’ questions. That’s why we created the Ultimate FAQ Solution — a powerful, flexible, and open-source WordPress plugin that makes FAQs easy to manage, display, and customize.

    Whether you’re running a blog, an e-commerce store, or an online course platform, this plugin helps you organize answers, reduce support requests, and improve user experience — all without writing a line of code.

    ✅ What Makes It the Ultimate FAQ Plugin?

    Here’s what you can expect:

    🎯 Grouping & Filtering

    Group your FAQs into categories and allow users to filter them in real-time. Great for product support, knowledge bases, or documentation pages.

    🧩 Shortcodes + Gutenberg Block Support

    Easily insert FAQs anywhere using shortcodes or our included Gutenberg block, with full control over display behavior, number of columns, order, title visibility, and more.

    ⚙️ Customizable Behavior

    Want toggle-style FAQs or always-visible answers? You choose. The plugin supports flexible display options that fit your site’s design and UX.

    🛒 WooCommerce Friendly

    Running an online store? You can create product-specific FAQs to improve customer confidence and reduce pre-sale questions.

    🔍 SEO & Accessibility Optimized

    Each FAQ is structured for search engines and screen readers, helping improve both visibility and usability.

    🚀 Use Cases

    • Help centers & knowledge bases
    • E-learning platforms with course-related FAQs
    • SaaS onboarding pages
    • WooCommerce product Q&A
    • Community forums

    👨‍💻 Developer-Friendly & Open Source

    We built Ultimate FAQ Solution with extensibility in mind. It’s open-source, cleanly coded, and ready for custom development. Fork it, extend it, or contribute to it — we welcome community collaboration!

    📥 Ready to Try It?

    You can download Ultimate FAQ Solution today for free. It’s fast to set up, easy to use, and built to scale with your content.

  • 🚀 Welcome to Braintum – Building Smarter Web Experiences

    At Braintum, we believe in crafting purposeful digital solutions that do more than just exist online — they engage, scale, and evolve with your business.

    Whether you’re launching your first content website, building an online learning platform, or looking to grow a vibrant community around your brand — we’re here to turn those ideas into reality.

    🌐 Who We Are

    Braintum is a web development company focused on building tailored digital platforms. Our team brings years of hands-on experience with:

    • Content-Rich Websites
    • Community & Membership Platforms
    • E-learning Systems
    • E-commerce Solutions

    We’re not just coders — we’re collaborators. We work closely with you to understand your goals, your users, and your long-term vision.

    🔧 Open-Source? We Love It.

    We’re proud creators of the Ultimate FAQ Solution — a powerful, open-source FAQ plugin for WordPress that helps site owners organize and display FAQs beautifully.

    With our plugin, thousands of WordPress sites make their content more accessible and user-friendly every day. And we’re just getting started.

    💡 What to Expect from This Blog

    This blog is our space to share:

    • Web development insights & tutorials
    • Plugin development tips
    • Best practices for WordPress, eCommerce, and more
    • Behind-the-scenes looks at our projects and process
    • Updates and feature drops from the Braintum team

    Whether you’re a business owner, a WordPress enthusiast, or just curious about the tech behind the web — we’ve got something for you.

    📨 Let’s Stay Connected

    Have a project in mind? Need help with your WordPress site?
    Contact us — we’d love to hear your story.

    Thanks for stopping by. Welcome to Braintum — where smart ideas meet solid code.