A graphics card can do useful work beyond games. For a developer, it can run a local model, generate document embeddings, transcribe recordings, or encode a tutorial while the CPU handles other tasks. The most productive starting point is a small project with an output you can evaluate.

This article uses an ASUS ROG Flow X13 GV302XI configuration as its reference. The hardware details below come from manufacturer specifications; they are not a completed driver check or benchmark of an individual machine. Confirm your detected adapters before reproducing the projects.

Know the hardware you are working with

• Integrated graphics: AMD Radeon 780M. AMD lists this graphics processor in the Ryzen 9 7940HS. Its first role in this setup is everyday display work. AMD processor specifications.
• Dedicated graphics: NVIDIA GeForce RTX 4070 Laptop GPU. ASUS lists 8 GB of GDDR6 VRAM and a maximum GPU power configuration of 60 W for the reference model. Those laptop limits matter when comparing it with desktop benchmarks. ASUS specifications.
• System memory: 32 GB in the reference configuration. This is a separate resource from dedicated VRAM. Your browser, editor, containers, and GPU applications still need system RAM.

Use the RTX as the initial compute target for these projects. Let the integrated graphics handle ordinary display duties where the system supports that arrangement. Applications need explicit support to distribute work across multiple GPUs; their memory should not be treated as one automatic pool.

Project 1: A local assistant for small coding tasks

Build a helper that explains a shell script, drafts tests for a short function, or summarizes a development log. Start with individual files and specific questions. This makes it easier to judge whether the answers are useful.

One modest starting model is Qwen2.5-Coder 3B through Ollama. Its listed Q4_K_M download is approximately 1.9 GB. That download size describes the model artifact; runtime memory also includes context and working buffers. It is a small baseline to test, rather than a promise of a particular response speed or coding quality. Model details.

Begin with one request at a time and a context setting of 2,048 tokens. While a request is running, inspect ollama ps: its processor column indicates whether the model is loaded on the GPU, in CPU memory, or split between them. Larger contexts and parallel requests increase memory requirements. Ollama memory guidance.

First deliverable: a repeatable set of five prompts using short scripts you understand. Record response time, peak VRAM, available system RAM, and whether the generated tests pass. Inspect the explanations for errors as well as useful suggestions.

Project 2: Search your Drupal documentation locally

Create semantic search across a small collection of project notes, module documentation, and deployment runbooks. A query such as "How do we restore the development database?" should retrieve the relevant passage even when it uses different wording.

The pipeline can stay simple: split documents into passages, generate embeddings, store the vectors with their source paths, and retrieve the closest matches for a question. Ollama provides an embedding endpoint and documents models including embeddinggemma and all-minilm. The GPU can accelerate supported embedding workloads; storage and search can remain on the CPU for this small prototype. Embedding documentation.

Start with 100 short documents and return the five most relevant passages with filenames. Compare the GPU and CPU on the same collection: setup and transfer overhead can make acceleration less valuable for very small jobs.

First deliverable: a search page that returns source passages. Prepare ten questions with known answers and check whether the correct document appears in the results. Add generated answers later, after retrieval works, so the model has relevant material to use.

Keep indexing and answer generation as separate jobs initially. That makes resource use easier to understand and avoids loading several models at once on an 8 GB card.

Project 3: Turn a recorded walkthrough into a transcript

Take a short technical walkthrough and produce a transcript with timestamps. The result can become draft documentation, subtitles, or searchable project notes.

faster-whisper is one option with NVIDIA CUDA support and reduced-precision inference modes. Begin with its small model, a batch size of one, and an appropriate supported GPU precision mode. Its installation documentation specifies the CUDA and cuDNN requirements for the installed version. Project documentation.

First deliverable: transcribe a ten-minute recording and review a two-minute segment manually. Record processing time and peak VRAM, then check accuracy for names, command-line options, and technical terms. Compare a CPU run if practical.

A transcript is a draft that needs editing. Faster processing is useful when it preserves enough accuracy to save you time. Keep recordings and generated notes in your chosen local workspace when using a local processing pipeline.

Project 4: Record a development tutorial with hardware encoding

Record a short demonstration of installing a Drupal project, debugging a request, or running a deployment. Hardware encoding is a direct way to use the GPU without adding an AI service.

In OBS Studio, select an available NVIDIA NVENC H.264 encoder. OBS explains that hardware encoding moves encoding work to a specialized GPU component and generally reduces the impact on CPU performance. OBS hardware encoding guide.

Start at 1080p and 30 frames per second. Record five minutes of the same activity using NVENC and, if practical, the x264 software encoder. Keep the capture resolution, frame rate, and activity the same, and document the encoder settings used for each test.

First deliverable: a recording with readable code and clear audio that does not disrupt editing. Compare CPU usage, recording or rendering lag in OBS, visible quality, and file size. A comparison needs those settings recorded because quality and compression vary by encoder and preset.

Choose the environment for one project

A Windows-native runtime is a straightforward starting point for a local model or OBS recording. WSL2 is useful when your application lives in a Linux development environment. Docker Desktop on Windows supports NVIDIA GPU access through its WSL2 backend, so you can also package a supported compute workload in a container. Docker GPU support.

For CUDA inside WSL, the NVIDIA driver is installed on the Windows host. NVIDIA explicitly instructs users not to install a Linux GPU driver inside WSL. The toolkit and application dependencies are separate from that driver. NVIDIA's WSL guide.

Native Linux is another environment to evaluate once a project has a working baseline. Use the same input, model, and workload when comparing platforms. Moving operating systems changes the setup; it does not expand the card's physical VRAM.

Keep the workload within the laptop's budget

Treat 8 GB as the total dedicated VRAM capacity, not a guarantee that every byte is free for a model. Graphics activity, runtime buffers, and other applications also use it. Start with one GPU project at a time, short inputs, and small batches. Expand only after measuring the complete workload.

For longer experiments, use the appropriate power supply and keep the laptop's cooling path clear. Compare runs with the same power mode and similar background activity. Available system RAM matters too: a machine already running editors, browsers, and several containers may have little room for an additional service.

Keep a short record of each experiment: detected GPU and driver, application version, input, settings, elapsed time, peak VRAM, available RAM, and output quality. The success criterion is a useful result with acceptable resource use.

Pick an output you already need

Start with tutorial recording if you want a practical result without managing models. Choose the small coding assistant if you want to learn local inference. Build document search when finding information is the recurring problem, or transcription when you already have recorded material to turn into notes.

Complete one project, measure it, and decide whether it earns a place in your regular workflow. Careful use of the hardware you already own can help you produce better documentation, support your team, and make future configuration decisions with evidence.