Tag: AI/ML

  • The July 2026 Agentic Coding Cheat Sheet: Frontier Tools, Cost Models, and Quota Mechanics – V2

    The July 2026 Agentic Coding Cheat Sheet: Frontier Tools, Cost Models, and Quota Mechanics – V2

    The tool sprawl in AI engineering has officially outrun our collective memory, at least it has mine.

    Between native terminal agents, newly minted desktop clients, and entirely divergent API cost models, keeping the ecosystem straight is a full-time job.

    I built this reference guide for a very simple reason: I needed a single, no-nonsense source of truth to track what tools each frontier provider actually offers right now, and exactly how running autonomous developer loops will affect my wallet.

    Here is the state of the stack as I know it and use it. Sure there are plenty of options I am missing.


    The Tooling Matrix: Interfaces, CLIs, and IDEs

    This matrix maps out exactly where each provider expects you to interact with their models, highlighting the shift toward dedicated desktop environments and autonomous terminal agents.

    Provider / EcosystemFlagship Web / Workspace InterfaceOfficial Desktop AppNative CLI / Terminal AgentIDE Integration Strategy
    GitHub CopilotGitHub.com & Copilot Workspace (Issue-to-PR sandbox)GitHub Copilot App (Native agent-centric control center)GitHub Copilot CLI (TUI via gh copilot with local execution capabilities)Official Extension (VS Code, JetBrains, Visual Studio, Neovim)
    Anthropic (Claude)Claude.ai (with Artifacts for rendering code/UI side-by-side)Claude Desktop App (Supports local filesystem/tool execution)Claude Code (State-of-the-art terminal agent for codebase refactoring)No official extension; relies on CLI or third-party tools like Cline/Continue
    OpenAI (ChatGPT)ChatGPT (utilizes Canvas for inline text and code editing)ChatGPT Desktop App (Mac & Windows)OpenAI API CLI (Primarily for asset, file, and model management)No direct IDE tool; serves as the model layer for Cursor, Aider, etc.
    Google (Gemini)Gemini Web InterfaceAntigravity 2.0 Desktop ClientAntigravity CLI (Replaces old gemini-cli; orchestrates parallel agent tasks)Gemini Code Assist & Antigravity plugins (VS Code, Android Studio, IntelliJ)
    DeepSeekDeepSeek Chat (V3 & R1 reasoning models)Mobile Apps (Relies on web wrappers for desktop)None natively (Relies on community tools like Ollama or Aider)Native integration into open-source extensions like Continue and Cline
    PerplexityPerplexity.ai (Pro search & “Pages” workspace)Perplexity Desktop (Mac & Windows)None (Relies on API keys for third-party scripts)None (Primarily used as a data-grounding search API)

    The Economic Matrix: Quotas, Costs, and Loop Behavior

    This is the most critical matrix, IMHO. As someone who is experimenting with numerous paid frontier model services, each with a limited budge, I am not all in on any service yet, and want to maximize my low-paid token tiers.

    This table explains how the subscription models and APIs.

    Provider / ServiceDeveloper Plan & Cost (USD)IDE / CLI Billing MechanismQuota / Rate Limit MechanicsThe “Agentic Loop” Behavior (The Cost Trap)
    GitHub CopilotPro: $10/mo
    Max: $100/mo
    Flat-rate subscription for native tools.Hybrid Metered: Unlimited standard completions + a fixed pool of premium model credits.The Safest Route: Because it’s integrated, Microsoft absorbs a massive amount of the token cost, but heavy loop usage will hit a speed throttle unless on the Max tier.
    Anthropic (Claude)Pro: $20/mo
    Max 5x: $100/mo
    Billed via web account or separate Pay-As-You-Go API.5-Hour Rolling Window: Dynamic usage budget that resets every 5 hours based on server demand.High Risk for Pro: Running Claude Code on a large infrastructure repository will hit your 5-hour limit fast. Full-time agentic workflows require switching to Claude Max or the raw API.
    OpenAI (ChatGPT)API Account
    (Pay-As-You-Go)
    BYOK (Bring Your Own Key): Paid per token used in Cursor, Aider, etc.Volumetric Tiers: Limits depend on lifetime account funding (Tiers 1–5), scaling from 200k to millions of tokens/min.Predictable but Costly: Perfect for episodic troubleshooting, but an out-of-control recursive autonomous loop can easily rack up a $20–$50 bill in an afternoon.
    Google (Gemini)Code Assist Standard
    ~$19/mo
    Flat-rate per user or metered hourly via Google Cloud.Concurrently Throttled: Throttles users if background parallel multi-agent loops request too much compute at once.Great for Standard Dev: Highly stable for individual coding, but hard to hook into un-vetted, third-party autonomous command-line tools.
    DeepSeekPlatform API
    (Pay-As-You-Go)
    BYOK: Funded via a pre-paid developer wallet.Wallet Funded: Strictly bound by whatever dollar amount you load into your account.The Economy Champion: Because of their unified architecture and heavy 90%+ prompt caching discounts, running heavy agentic loops costs literal pennies compared to western models. $10 can last a month.
    PerplexityPerplexity Pro
    $20/mo
    Subscription includes a small monthly API credit.Fixed Credit Ceiling: API access stops or charges your card when your small monthly search token allowance runs dry.Not For Coding Loops: Great for pulling real-time documentation or API schemas into your agent, but financially unviable for writing or refactoring code blocks.

    Understanding the Layers of Agentic LLM Tool Execution

    To expand this post, it is useful to define several concepts that are now common in agentic AI systems: tools, skills, MCP servers, local execution layers, and IDE-integrated actions.

    Out of the box, an LLM is primarily a reasoning and text-generation system. You can ask it questions, request explanations, have it draft a script, or ask it to review configuration, and it will respond with generated text. By itself, however, the model does not inherently have access to your operating system, local files, terminal, IDE, logs, repositories, ticketing systems, monitoring platforms, or infrastructure.

    That distinction is important.

    A hosted model may appear to have additional capabilities, such as reading uploaded documents, searching the web, generating files, or analyzing code, but those capabilities are usually provided by the surrounding platform, client application, or agent runtime rather than by the model alone.

    This is where concepts such as tools, skills, MCP servers, and agent runtimes become important. These components extend an LLM from a passive chatbot into an interactive agentic system. The model can reason about what needs to happen, request the appropriate tool, inspect the result, and continue working through a task. The runtime around the model is responsible for exposing those tools, enforcing policy, executing approved actions, and returning results back to the model.

    When discussing LLMs that can inspect logs, modify files, run scripts, query systems, or interact with development environments, it is important to separate the layers involved. These capabilities are often described broadly as “agentic AI,” but agentic behavior is usually the result of several distinct components working together.

    The model provides reasoning and structured tool-call requests. The orchestration layer manages the workflow, state, prompts, and tool-calling loop. The local execution layer performs approved actions against the operating system, filesystem, terminal, repository, or other target environment. IDE-integrated actions expose workspace-specific capabilities such as file editing, diagnostics, Git state, and terminal access. Skills provide reusable task-specific instructions or workflows. MCP servers provide a standardized way to expose tools, resources, and prompts to compatible AI clients.

    In other words, the LLM is tool-aware, but the surrounding runtime is tool-authoritative.

    The model may decide that it needs to read a log file, edit a configuration file, run a script, or inspect a repository. However, the runtime determines which tools exist, which actions are allowed, where those actions execute, what policy controls apply, and what results are returned to the model.

    The table below provides a high-level comparison of the major concepts involved in LLM-driven local execution and tool integration.

    LLM Agent Execution Layers and Integration Concepts

    ConceptFormal NameWhat It MeansWhat It Controls or ProvidesExample in Practice
    Tool callingTool calling / function calling / structured tool invocationThe model’s ability to request an external action using a defined schema instead of free-form text.Provides the structured interface between the LLM and external capabilities.The model requests read_file(path="/var/log/app.log") or run_tests(command="pytest").
    ToolAgent tool / callable tool / local execution toolA specific function or action that can be invoked by the agent workflow.Provides a single capability, such as reading a file, tailing logs, running a script, or checking Git status.tail_log, write_file, run_shell, git_diff, restart_service.
    AgentLLM agent / tool-using agent / agentic workflowThe loop that allows the model to plan, call tools, observe results, and continue until the task is complete.Coordinates reasoning, tool requests, observations, and final responses.The agent reads an error log, edits a config file, restarts a service, checks the result, and reports back.
    Agent orchestration frameworkAgent framework / workflow orchestration frameworkA framework used to build and manage the agent loop, tools, prompts, state, and execution flow.Provides abstractions for models, prompts, tools, memory, state, routing, and workflow control.LangChain, LangGraph, Semantic Kernel, AutoGen, CrewAI.
    Local execution layerGoverned local execution layer / OS execution layer / tool execution runtimeThe runtime component that actually performs approved actions against the local operating system or workspace.Controls OS-level access, command execution, filesystem changes, script execution, and result capture.Running journalctl, editing a YAML file, executing a validation script, or applying a patch.
    IDE-local actionsIDE agent tools / workspace tools / editor-integrated actionsTool capabilities provided inside an IDE or local coding assistant environment.Gives the agent access to files, terminals, diagnostics, search, Git state, and editor context within a workspace.Cursor, Cline, Continue, Zed, VS Code Chat, Aider, OpenHands.
    SkillsAgent skills / repo-local skills / workflow skillsPackaged instructions, scripts, conventions, or workflows that teach an agent how to perform a specific task in a specific context.Provides repeatable task guidance and project-specific operating instructions.A repo skill that tells the agent how to validate changes using shellcheck, pytest, yamllint, and ./health-check.sh.
    MCPModel Context Protocol / MCP server / MCP tool / MCP resourceA standard protocol for exposing tools, resources, and prompts to compatible AI clients.Standardizes how external systems provide capabilities and context to AI applications.An MCP server exposes filesystem access, GitHub issues, database queries, lab inventory, or monitoring data.
    Policy and guardrailsExecution policy / tool governance / approval policyThe rules that determine what tools are available, what actions are allowed, and whether approval is required.Controls access boundaries, command restrictions, file path restrictions, approval gates, logging, and auditability.Allow reading logs but require approval before modifying /etc/ or restarting a service.
    Observability and audit trailAgent observability / execution logging / audit trailThe record of what the agent requested, what was approved, what was executed, and what changed.Provides troubleshooting, reviewability, compliance, and rollback support.Logging each tool call, command output, file diff, approval decision, and final result.
  • Simple RAG with Ollama, OpenWebUI, and VectorDB on Ubuntu 22.04

    Simple RAG with Ollama, OpenWebUI, and VectorDB on Ubuntu 22.04

    Prerequisites

    I have already installed Nvidia proprietary drivers and the Nvidia Cuda Toolkit. I documented the install of the Cuda toolkit in an older post which can be found here.

    Since I have Nvidia GPUs in my host system, and I intend to run some services in containers, I want to make sure that I install the nvidia-container-toolkit. Instructions on how to setup the repo on Ubuntu 22.04 can be found here. Once you have setup the repo, you can follow the steps below, or just follow the instructions found in the link above.

    $ sudo apt-get install -y nvidia-container-toolkit

    I will be using Docker as my container runtime. So I need to configure the container runtime to use docker.

    $ sudo nvidia-ctk runtime configure --runtime=docker

    Now restart Docker.

    $ sudo systemctl restart docker

    Install Ollama

    Run the command below to install ollama as a service. You can also choose to run containerized ollama, however those steps are not documented here.

    curl -fsSL https://ollama.com/install.sh | sh

    Once complete, run the command below to confirm installation, and check version.

    $ ollama --version
    ollama version is 0.5.12

    Add the environment variable below to the ollama service file in order to listen on all interfaces. This way we can access remotely if needed.

    Environment=”OLLAMA_HOST=0.0.0.0″

    Edit the ollama service files and add the line above to the bottom of the file.

    $ sudo vi /etc/systemd/system/ollama.service

    The file should appear as shown below.

    [Unit]
    Description=Ollama Service
    After=network-online.target
    
    [Service]
    ExecStart=/usr/local/bin/ollama serve
    User=ollama
    Group=ollama
    Restart=always
    RestartSec=3
    Environment="PATH=/usr/local/cuda/bin:/home/cpaquin/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
    Environment="OLLAMA_HOST=0.0.0.0"
    
    [Install]
    WantedBy=default.target
    

    Now restart ollama and reload systemd

    $ sudo systemctl restart ollama.service
    $ sudo systemctl daemon-reload

    Confirm ollama is listening on all interfaces.

    $ netstat -a | grep 11434
    tcp6 0 0 [::]:11434 [::]:* LISTEN

    Test Connectivity from a remote host. If you are unable to reach the ip/port you may need to modify firewall on the remote system.

    $ telnet 10.1.10.14 11434
    Trying 10.1.10.14…
    Connected to 10.1.10.14.
    Escape character is '^]'.

    Install OpenWeb UI

    I am using the open-webui:cuda container as I am running dual Nvidia GPUs. I want OpenWeb-UI to bind to the primary interface on the host so that I can access it from my workstation.

    # docker run -d -p 10.1.10.14:3000:8080 --gpus all --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda

    The -v option in the command below will create a volume for OpenWeb-UI. You can verify with the command below

    $ docker volume ls
    DRIVER    VOLUME NAME
    local     open-webui
    

    Confirm that the container has started.

    $ docker ps

    If it has failed to start use “docker logs <container-id>” to troubleshoot.

    Now, in a web browser, navigate to the ip/port combo you entered in the docker run command shown above. You should be greeted with the OpenWeb-UI getting started page.


    Install ChromaDB

    Use the command below to instanciate the ChromaDB container. 10.1.10.14 is the ip of my host, adjust as needed to fit your needs

    $ docker run -d \
      --name chromadb \
      -p 10.1.10.14:8000:8000 \
      -v chroma_data:/chroma_db \
      --restart unless-stopped \
      chromadb/chroma

    Confirm you can curl api.

    curl http://10.1.10.14:8000/api/v1
    

    Reinstantiate OpenWebUI with ChromaDB Connectivity

    Stop current OpenWebUI container.

    $ docker stop open-webui

    Delete the container

    $ docker remove open-webui

    Recreate the container but add the following

    1. -e VECTORDB_PROVIDER=chroma
    2. -e CHROMADB_SERVER_HOST=”http://10.1.10.14:8000&#8243; (modify IP to fit your env)
    $ docker run -d -p 10.1.10.14:3000:8080 --gpus all \
    --add-host=host.docker.internal:host-gateway \
    -v open-webui:/app/backend/data \
    -e VECTORDB_PROVIDER=chroma \
    -e CHROMADB_SERVER_HOST="http://10.1.10.14:8000" \
    --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda

    Check to ensure that env variables were set correctly

    $ docker exec -it open-webui env | grep -i chroma
    VECTORDB_PROVIDER=chroma
    CHROMADB_SERVER_HOST=http://10.1.10.14:8000
    
    

    Setup RAG in OpenWebUI

    In order to setup RAG you will need to do the following.

    1. Create a Knowledge Base
    2. Upload files
    3. Create the Model that will use the Knowledge Base

    First we will create a knowledge base. Navigate to Workspace > Knowledge > + Create a Knowledge Base. Choose a name for your Knowledge base and add a description.

    We are going to name ours, Gordon Lightfoot

    Now select Create Knowledge

    Look real hard for the text “Drag and drop a file to upload or select a file to view”. This is where you w drag and drop your documents. We have two documents to add to our collection.

    You can also upload entire directories or sync with a directory

    Now navigate to Workspace > Models > + Add New Model. Imput a name for your custom model and choose a base model. I am choosing tinyllama for this test.

    Scroll down and select Save & Create

    Now let’s chat with our new model. Select Workspace and then select your new model (My Gordon Lightfoot Model)

    You are now ready to chat with your model

    Let’s ask it a question

    So there you go. A working RAG implementation with Ollama, OpenWebUI, and VectorDB. I am sure that there are a lot more features to explore here and I am sure I have a lot more tuning to do. But for now I am off to a good start.


    References

    1. https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html
    2. https://docs.openwebui.com/tutorials/tips/rag-tutorial/
  • Getting Started with RamaLama with Nvidia Cuda Support On Ubuntu 24.04

    Getting Started with RamaLama with Nvidia Cuda Support On Ubuntu 24.04

    Introduction to RamaLama

    Streamlining AI Deployment with OCI Containers

    RamaLama is an open-source project developed to simplify AI model deployment and management using OCI (Open Container Initiative) containers. Ramalama enables seamless execution of AI workloads across different hardware configurations, supporting both GPU-accelerated and CPU-based environments.

    By leveraging container engines like Podman and Docker, RamaLama includes all necessary dependencies, eliminating complex installation and dependency nightmares.

    Ramalama integrates with AI model registries such as Hugging Face and Ollama, providing flexibility in model selection. Key features include automatic GPU detection, CPU fallback, and optional direct execution on the host system.

    Prerequisites

    Updating Ubuntu

    First let’s confirm our Ubuntu version

    $ sudo lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 22.04.5 LTS
    Release:	22.04
    Codename:	jammy
    

    Run the two commands below to update your package cache and install any updates. Reboot if required.

    $ sudo apt-get update
    $ sudo apt-get upgrade -y

    Installing podman

    $ sudo apt -y install podman
    # sudo podman --version
    podman version 5.0.3

    Installing Nvidia Drivers

    Assuming you added third-party repos at build time, we should be able to check the suggested NVIDIA driver version. Do so with the command below

    $ nvidia-detector
    nvidia-driver-545

    The command below confirms that we do not have an NVIDIA driver loaded.

    $ cat /proc/driver/nvidia/version
    cat: /proc/driver/nvidia/version: No such file or directory

    Now let’s install the NVIDIA driver.

    $ sudo ubuntu-drivers --gpgpu install

    And we need to install the nvidia-utils package. Make sure the package version matches your installed driver.

    $ sudo apt install nvidia-utils-535-server

    Now reboot.

    Once your system is back up. Run the command below to verify that the drivers installed correctly. At the top of the output you should see your driver version and CUDA API version

    $ sudo nvidia-smi

    You must configure the persistence daemon (nvidia-persistenced) to start at boot and run continuously. Otherwise, the driver may unload, causing the Tesla GPUs to deinitialize, requiring a full reinitialization when nvidia-smi is executed. Additionally, failing to keep nvidia-persistenced running could lead to more severe issues, such as GPU crashes, depending on the workload.

    Enable and start the service below

    $ sudo systemctl start nvidia-persistenced
    $ sudo systemctl status nvidia-persistenced
    

    Installing Nvidia Cuda Toolkit

    Run the command below to install the nvidia-cuda-toolkit from the default Ubuntu repos.

    $ sudo apt install nvidia-cuda-toolkit -y

    Now test to ensure proper install and that new binary files are in your path.

    ~# nvcc --version
    nvcc: NVIDIA (R) Cuda compiler driver
    Copyright (c) 2005-2021 NVIDIA Corporation
    Built on Thu_Nov_18_09:45:30_PST_2021
    Cuda compilation tools, release 11.5, V11.5.119
    Build cuda_11.5.r11.5/compiler.30672275_0
    

    Configuring Podman with Nvidia Cuda Support

    Following along with this document from the RamaLama github page, we first need to install the nvidia-container-toolkit.

    First configure the repo. Note that this is one command. See here for more info.

    $ sudo curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
      && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
        sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
        sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

    Refresh the repos

    # sudo apt-get update

    Then install the toolkit

    $ sudo apt install nvidia-container-toolkit -y

    Then run the command below to create the CDI spec file

    $ sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

    Now lets check the detected devices

    $ nvidia-ctk cdi list

    My two Telsa T4s have been detected

    INFO[0000] Found 5 CDI devices                          
    nvidia.com/gpu=0
    nvidia.com/gpu=1
    nvidia.com/gpu=GPU-1d877ac8-5df1-34b0-4f86-59945e37d2ba
    nvidia.com/gpu=GPU-9491a3e6-ea29-ba4e-4403-083244d5575c
    nvidia.com/gpu=all
    

    Test the install/config

    $ sudo podman run --rm --device=nvidia.com/gpu=all fedora nvidia-smi

    Installing Python pip

    Lets first make sure that python 3 is installed

    $ python3 --version
    Python 3.12.7

    Now we need to install the virtual-env module for python

    $ sudo apt install python3.10-venv

    Installing RamaLama via Pip in a Python Virt Env

    Create a directory for ramalama, and cd to that directory

    $ mkdir ramalama && cd ramalama

    Create virtual env and source to activate

    $ python3 -m venv --upgrade-deps venv
    $ source venv/bin/activate

    Now pip install

    $ pip install ramalama

    Now run a model as a test

    $ ramalama run instructlab/merlinite-7b-lab

    In another window, run the commands shown below to view the ramalama container running in your python virtual env. Note that the output of podman ps will be empty unless your “activate” your virtual env.

    $ source venv/bin/activate
    $ podman ps

    Screenshot below


    Example CLI Commands

    Pull a model.

    $ ramalama pull ollama://mistral

    List downloaded models.

    $ ramalama list
    NAME                             MODIFIED       SIZE   
    ollama://mistral:latest          42 seconds ago 3.83 GB
    ollama://merlinite-7b-lab:latest 10 hours ago   4.07 GB
    

    Run a model

    $ ramalama run mistral:latest

    Info on ramalama itself. Output will tell you detected GPUs and what driver is being used.

    $ ramalama info

    –dryrun flag provides the podman command used to serve/run a model

    $  ramalama --dryrun run instructlab/merlinite-7b-lab 
    podman run --rm -i --label ai.ramalama --name ramalama_6buqEjuCUm --env=HOME=/tmp --init --security-opt=label=disable --cap-drop=all --security-opt=no-new-privileges --label ai.ramalama.model=instructlab/merlinite-7b-lab --label ai.ramalama.engine=podman --label ai.ramalama.runtime=llama.cpp --label ai.ramalama.command=run --pull=newer -t --device /dev/dri --device nvidia.com/gpu=all -e CUDA_VISIBLE_DEVICES=0 --network none --mount=type=bind,src=/home/cpaquin/.local/share/ramalama/models/ollama/merlinite-7b-lab:latest,destination=/mnt/models/model.file,ro quay.io/ramalama/cuda:latest llama-run -c 2048 --temp 0.8 --ngl 999 /mnt/models/model.file 
    
    

    There are a whole load of other topics that I will eventually get into with ramalama

    1. GPU Support/Enablement
    2. RAG
    3. Whisper

    More to come at a later date. In the meantime, take a look at the “Resources” section below.

    Additional Video

    Resources

    1. https://github.com/containers/ramalama
    2. https://github.com/containers/ramalama/blob/main/docs/ramalama.1.md
    3. https://developers.redhat.com/articles/2024/11/22/how-ramalama-makes-working-ai-models-boring
    4. https://developers.redhat.com/blog/2024/12/17/simplifying-ai-ramalama-and-llama-run
    5. https://www.linkedin.com/pulse/ollama-much-try-ramalama-surya-rekha-tw5kf/
  • Essential Commands to Monitor Nvidia GPUs in Linux

    Identify Your GPU Via the Linux CLI

    Identify that your card is recognized by the OS via the CLI command below, hwinfo

    # hwinfo --gfxcard --short
    graphics card:                                                  
                           nVidia TU104GL [Tesla T4]
                           nVidia TU104GL [Tesla T4]
                           Matrox G200eR2
    
    Primary display adapter: #58
    

    Or you can see similar output with lshw

    # lshw -C display
      
      *-display
           description: 3D controller
           product: TU104GL [Tesla T4]
           vendor: NVIDIA Corporation
           physical id: 0
           bus info: pci@0000:43:00.0
           logical name: /dev/fb0
           version: a1
           width: 64 bits
           clock: 33MHz
           capabilities: pm bus_master cap_list fb
           configuration: depth=32 driver=nvidia latency=0 mode=1280x1024 visual=truecolor xres=1280 yres=1024
           resources: iomemory:3800-37ff iomemory:3810-380f irq:106 memory:d0000000-d0ffffff memory:38000000000-3800fffffff memory:38110000000-38111ffffff memory:d1000000-d13fffff memory:38010000000-3810fffffff memory:38112000000-38131ffffff
    

    Nvidia-smi

    Nvidia System Management interface (nvidia-smi) is a cli command which facilitates management and monitoring of Nvidia GPUs (mainly Tesla, GRID, Quatro, and Titan products). It ships with Nvidia GPU drivers on Linux. It is an extension buildt on the Nvidia Management Library. Official documentation for nvidia-smi can be found here.

    The output comprises two tables. The first table provides comprehensive details about all detected GPUs (e.g., one GPU in the provided example), while the second table enumerates the processes actively utilizing the GPUs. Below are detailed explanations of each parameter:

    • Temp (Temperature): Indicates the GPU core temperature in Celsius. Typically, temperature regulation is managed by data center infrastructure or external cooling solutions. Values like “44°C” are normal operating conditions, but sustained temperatures exceeding 90°C should trigger immediate action to prevent hardware degradation.
    • Perf (Performance State): Represents the current performance state of the GPU, ranging from P0 (highest performance) to P12 (lowest performance).
    • Persistence-M (Persistence Mode): Specifies whether the NVIDIA driver remains loaded in memory even in the absence of active processes like nvidia-smi. When “On,” this mode reduces driver load latency for GPU-dependent applications such as CUDA workloads.
    • Pwr: Usage/Cap (Power Usage/Capacity): Displays the current power draw of the GPU relative to its total power capacity, measured in Watts.
    • Bus-Id: Represents the PCI bus address of the GPU in the format domain:bus:device.function (hexadecimal). This identifier is critical for targeting specific GPUs in systems with multiple devices.
    • Disp.A (Display Active): Denotes whether memory on the GPU is allocated for display purposes. An “Off” value signifies no display context is associated with the GPU, making it dedicated to compute tasks.
    • Memory-Usage: Indicates memory utilization on the GPU, expressed as the amount of memory in use versus total available memory. Machine learning frameworks like TensorFlow may preallocate the full GPU memory capacity upon initialization, irrespective of immediate requirements.
    • Volatile Uncorr. ECC (Volatile Uncorrected ECC): Tracks uncorrected memory errors since the last driver initialization. Error Correction Code (ECC) is designed to detect and correct memory errors, ensuring data integrity during GPU operations.
    • GPU-Util (GPU Utilization): Reports the percentage of time over the sample interval during which one or more kernels actively used the GPU.
    • Compute M. (Compute Mode): Specifies the GPU’s compute mode. In “Default” mode, multiple processes can access the GPU concurrently. Other modes may restrict access to a single process or prohibit access entirely.
    • GPU (Index): Enumerates the GPUs detected in the system. The index corresponds to the NVML (NVIDIA Management Library) device index, enabling precise identification in multi-GPU environments.
    • PID (Process ID): Lists the process identifier of applications utilizing GPU resources.
    • Type: Describes the context of GPU usage—“C” for Compute tasks, “G” for Graphics tasks, and “C+G” for combined Compute and Graphics contexts.
    • Process Name: Identifies the executable or application utilizing GPU resources.
    • GPU Memory Usage: Reports the GPU memory utilized by each individual process.

    Use the -a switch for more detail

    Sample Nvidia-SMI Commands

    Query memory, free memory, and used memory

    # nvidia-smi --query-gpu=index,name,uuid,memory.total,memory.free,memory.used --format=csv
    index, name, uuid, memory.total [MiB], memory.free [MiB], memory.used [MiB]
    0, Tesla T4, GPU-9491a3e6-ea29-ba4e-4403-083244d5575c, 15360 MiB, 14928 MiB, 2 MiB
    1, Tesla T4, GPU-1d877ac8-5df1-34b0-4f86-59945e37d2ba, 15360 MiB, 14928 MiB, 2 MiB
    

    Query Temperatures

    # nvidia-smi --query-gpu=name,temperature.gpu --format=csv
    name, temperature.gpu
    Tesla T4, 34
    Tesla T4, 30
    

    Query PCI Slot

    # nvidia-smi --query-gpu=index,name,pci.bus_id --format=csv
    index, name, pci.bus_id
    0, Tesla T4, 00000000:02:00.0
    1, Tesla T4, 00000000:43:00.0
    

    Show Numa Affinity

    Non-Uniform Memory Access (numa) is a term used on systems with more than one bus/CPU. In the example below my GPU is installed in the numa node local to CPU0. use the flag “topo -m”


    Show Running Stats with dmon

    The dmon flag is unsed to show running statistics for one or more CPUs at 1s intervals. Dmon accepts a slew of options which are explained here.

    Below are the available base metrics and associated metric letter.

    SWITCHDESCRIPTION
    pPower Usage and Temperature
    uUtilization
    cProc and Mem Clocks
    vPower and Thermal Violations
    mFB, Bar1 and CC Protected Memory
    eECC Errors and PCIe Replay errors
    tPCIe Rx and Tx Throughput

    The nvidia-smi dmon command is also able to query available GPM (GPU Performance Monitor) metrics as shown in the example below

    #nvidia-smi dmon --gpm-metrics <gpmMetric1, gpmMetric2, ... ,gpmMetricN>
    <gpmMetricX> R

    The table below shows some of the available metrics and associated metric number. A complete list of metrics can be found here.

    METRICVARDESCRIPTION
    Graphics Activity = 1
    SM Activity  = 2
    SM Occupancy = 3
    Integer Activity=4
    Tensor Activity = 5
    DFMA Tensor Activity= 6
    HMMA Tensor Activity = 7
    IMMA Tensor Activity= 9
    DRAM Activity = 10
    FP64 Activity= 11
    FP32 Activity= 12
    FP16 Activity= 13
    PCIe TX= 20
    PCIe RX= 21
    NVDEC 0-7 Activity= 30-37
    NVOFA 0 Activity= 50
    NVJPG 0-7 Activity   = 40-47
    NVLink Total RX= 60
    NVLink Total TX= 61
    NVLink L0-17 RX= 62, 64, 66, …, 96
    NVLink L0-17 TX = 63, 65, 67, …, 97

    Enable persistence mode to reduce initialization overhead and keep the GPU active and running.

    # sudo nvidia-smi -pm 1
    Enabled persistence mode for GPU 00000000:43:00.0.
    All done.

    NVtop

    More info on nvtop can be found here

    $ sudo apt install nvtop

    Output example below


    GPUstat

    A wrapper of sorts for nvidia-smi. More info here.

    # apt install gpustat -y

    Output below

    galactica    Thu Feb  6 22:43:59 2025  535.183.01
    [0] Tesla T4 | 36°C,   0 % |     2 / 15360 MB |
    [1] Tesla T4 | 30°C,   0 % |     2 / 15360 MB |
    

    Installing the Nvidia Container Toolkit on Ubuntu 22.04

    The NVIDIA Container Toolkit is a set of tools that enables the use of NVIDIA GPUs within Docker and other container runtimes. It allows GPU-accelerated applications to run inside containers by providing the necessary drivers, libraries, and runtime components. Instructions for installing the Nvidia Container Toolkit are below. The official Nvidia doc can be found here, where you can also find guides for installing via DNF/Yum or Zypper

    ~# curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
      && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
        sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
        sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
    deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://nvidia.github.io/libnvidia-container/stable/deb/$(ARCH) /
    #deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://nvidia.github.io/libnvidia-container/experimental/deb/$(ARCH) /
    

    Now refresh packages list

    ~# sudo apt-get update

    Now install the Container Toolkit

    # sudo apt-get install -y nvidia-container-toolkit

    Configure the NVIDIA-Container Toolkit with Containerd

    For Ubuntu, the default runtime is containerd. In the example below we configure integration with containerd. Which modifies /etc/containerd/config.toml

    #sudo nvidia-ctk runtime configure --runtime=containerd
    #sudo systemctl restart containerd

    or use docker as shown below

    Configure the NVIDIA-Container Toolkit Configuring with Docker

    The nvidia-ctk command modifies the /etc/docker/daemon.json file on the host. The file is updated so that Docker can use the NVIDIA Container Runtime.

    # sudo nvidia-ctk runtime configure --runtime=docker

    I have also seen that it may be necessary to add default-runtime parameter directly to the file “/etc/docker/daemon.json“.

    Run the command below to see what runtimes Docker is using

    docker info | grep "Runtime"
     Runtimes: io.containerd.runc.v2 nvidia runc
     Default Runtime: runc

    Make a backup copy of /etc/docker/daemon.json

    # cp /etc/docker/daemon.json /etc/docker/daemon.json.ORIG

    Modify the file as shown below.

    # cat daemon.json
    {
        "runtimes": {
            "nvidia": {
                "path": "/usr/bin/nvidia-container-runtime",
                "runtimeArgs": []
             } 
        },
        "default-runtime": "nvidia" 
    }

    Restart Docker

    # systemctl restart docker

    Check the output of docker info and ensure that the nvidia is the default runtime

    # docker info | grep "Runtime"
     Runtimes: io.containerd.runc.v2 nvidia runc
     Default Runtime: nvidia
    

    Find your Nvidia Devices in /dev

    # sudo ls -la /dev | grep nvidia
    crw-rw-rw- 1 root root 195, 0 Feb 4 03:54 nvidia0
    crw-rw-rw- 1 root root 195, 1 Feb 4 03:54 nvidia1

    NGC CLI

    NVIDIA NGC (Nvidia GPU CLoud) CLI is a command-line interface tool for managing Docker containers in the NVIDIA NGC Registry. Download the CLI here.

    Once downloaded, unzip the Zip file and make the binary executable

    chmod u+x ngc-cli/ngc && chmod u+x ngc-cli/ngc

    Add the binary path to your path

    echo "export PATH=\"\$PATH:$(pwd)/ngc-cli\"" >> ~/.bash_profile && source ~/.bash_profile

    You will need an Nvidia Cloud account and and API key, follow the setup guide here to get started.

    Then docker login as shown below using your API key as your password

    # docker login nvcr.io
    Username: $oauthtoken
    Password: 
    WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
    Configure a credential helper to remove this warning. See
    https://docs.docker.com/engine/reference/commandline/login/#credentials-store
    
    Login Succeeded
    

    nvidia-ctk

    A Container Device Interface (CDI) device is a standard way to manage container hardware access. More specifically it is used to assign GPU to containers through the Nvidia Container Toolkit

    Run the command below to generate the CDI specification file

    #  sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

    Then run the list command below to see what GPUs were detected.

    # nvidia-ctk cdi list
    INFO[0000] Found 5 CDI devices                          
    nvidia.com/gpu=0
    nvidia.com/gpu=1
    nvidia.com/gpu=GPU-1d877ac8-5df1-34b0-4f86-59945e37d2ba
    nvidia.com/gpu=GPU-9491a3e6-ea29-ba4e-4403-083244d5575c
    nvidia.com/gpu=all

    Running a Sample Docker Workload

    Run the command below to test to make sure docker is working properly

    # sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

    The command above should run nvidia-smi once and then exit.

    GPU Burn With Docker

    Pop a second terminal window, run nvtop and run the command below. You should see load on your GPUs. In the example below, 60 represents the number of seconds to run the test.

    # sudo docker run --gpus all --rm oguzpastirmaci/gpu-burn 60

    See below. GPUs running at 100% load.


    More Commands

    Reference

    1. https://org.ngc.nvidia.com/setup/installers/cli
    2. https://docs.nvidia.com/deploy/nvidia-smi/index.html
    3. https://taozhi.medium.com/monitor-nvidia-gpu-by-nvidia-smi-cli-56198fbf8e62
    4. https://www.gpu-mart.com/blog/monitor-gpu-utilization-with-nvidia-smi
    5. https://programmersought.com/article/84455484104/
    6. https://docs.nvidia.com/deploy/driver-persistence/index.html
    7. https://www.incredibuild.com/integrations/cuda#:~:text=Compute%20Unified%20Architecture%20(CUDA)%20is,tasks%20on%20GPU%20using%20CUDA.
    8. https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html
    9. https://docs.nvidia.com/deploy/nvml-api/group__nvmlGpmEnums.html
    10. https://docs.nvidia.com/deploy/pdf/NVML_API_Reference_Guide.pdf
    11. https://docs.nvidia.com/deploy/nvidia-smi/index.html
    12. https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html
    13. https://hub.docker.com/r/oguzpastirmaci/gpu-burn

  • Unleashing the Power of OpenWebUI: A Step-by-Step Guide to Installing and Configuring OpenWebui on Ubuntu 22.04

    Unleashing the Power of OpenWebUI: A Step-by-Step Guide to Installing and Configuring OpenWebui on Ubuntu 22.04

    In this post we will install openWebUI on Ubuntu 22.04 and configure it to act as the front end for Ollama (which is already running locally).

    Note that we are not going to be using containers, rather we will install and run OpenWebUI as a service, much as we did with Ollama in a previous post.

    Installation via Pip

    Create virtual env.

     $ sudo python3.12 -m venv ~/Downloads/workspace/open-webui/

    Install open-webui.

    $ sudo ~/Downloads/workspace/open-webui/bin/pip3 install open-webui

    Create systemd service file.

    $ sudo vi /usr/lib/systemd/system/open-webui.service

    See contents below. Note how ExecStart points to the open-webui binary in our virtual env.

    Refresh systemd via the command below.

    $ sudo systemctl daemon-reload

    Now configure our new service to start at boot and enable it now.

    $ sudo systemctl enable --now open-webui.service
    Created symlink /etc/systemd/system/multi-user.target.wants/open-webui.service → /usr/lib/systemd/system/open-webui.service.

    If you need are experiencing a failure or need to test, just run the ExecStart command manually and watch for errors.

    $sudo /home/cpaquin/Downloads/workspace/open-webui/bin/open-webui serve

    Open-WebUI should be listening on port 8080 on all interfaces. We can see this when we start it manually as we did above.

    INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

    Now restart via systemd to ensure everything is up and running nice and clean.

    $ sudo systemctl status open-webui.service

    Logging into the WebUI

    Open a browser window and navigate to the IP address of your system. Or if running locally you can use the loopback address (127.0.0.1). Note you may need to allow port 8080 via ufw if attempting to access from a remote host.

    Start by selecting “Get Started”

    Create a local admin account

    OpenWebUI should automatically detect your installation of ollama and allow you to load any downloaded model.

    Testing with A Newly Installed Model

    Lets pull a new model and make sure that OpenWebUI makes the new model available.

    $ sudo ollama pull smollm

    After refreshing our browser window, we can now see that the smolln model is available.

  • Installing the GPU Power Supply Expansion Board into the Dell T620

    Installing the GPU Power Supply Expansion Board into the Dell T620

    Introduction

    I recently picked up a couple of used Dell T602s for my homelab for AI/ML project work. Dell Tower form factor servers are very attractive to homelabbers due to their availability, their low costs, the fact that they are rather low noise, and due to the fact that they are easily expandable. For example, the DVD rom drive in one of my machines is a standard 5 3/4″ form factor, which I replaced with an DVD burner I had laying around.

    One issue with utilizing a non-ATX powered server for AL/ML is the lack of additional power and cooling options for GPUs. The 16x PCI slots in the T620 provide 75w of power, enough for some older GPUs (like the Tesla T4 – which I will try to install later), however in the case of the T4 it is passively cooled so additional cooling is required. We will deal with additional cooling in another post in the future, for now let’s focus on getting the power we need for a certified GPU (more on this down below).

    What you need is a Dell GPU Power Supply Expansion Module (VDY5T) (and cables PN=3692K). However, it’s almost impossible to obtain one specifically for the T620 (VDY5T), however you can pick up one up for the T630 (X7C1K) on ebay. I have read that others have been successful when doing so. So I picked up one for myself along with a couple of cables to see if I had the same results…

    As a matter of fact, after a cursory glance, and some google-foo, I am not convinced that these parts are not interchangeable. Below you see an ebay item listed as compatible with either machine (not that you should trust ebay sellers). I will continue to do research and once I test my machine I will add more information to this post in the near future. For now, let’s get to the installation steps.

    Pages: 1 2