A local Companion is not one AI workload. Text, voice, images and 3D compete for different resources. This article goes beyond the feature name and looks at the practical customer experience, the engineering trade-offs and the decisions AVRE is using while the product moves from development builds toward a commercial release.
The GPU is doing several jobs
When someone asks whether a graphics card is 'good enough for AI,' the question is usually too broad. AVRE can involve a local language model, speech recognition, text-to-speech, image generation and a real-time 3D avatar. Each workload has a different memory and latency profile. A machine can run the language model perfectly and still stall when a heavy image model is loaded. Another machine may have plenty of raw GPU speed but too little VRAM for the chosen models.
This is why AVRE's resource manager matters. The product should not launch every engine at full size and hope the operating system sorts it out. It needs to understand which feature is active, which can wait, and which resource can be released when another subsystem needs the GPU.
What VRAM is actually storing
VRAM is the GPU's fast working memory. For a local language model it can hold model weights, attention/cache data and runtime buffers. Larger models and longer contexts usually require more memory. Quantisation can reduce the footprint by storing weights with fewer bits, but that does not make memory irrelevant. When the model does not fit, software may offload work to system RAM or CPU, which can dramatically change response speed.
The same GPU might also need textures, meshes and render targets for the 3D avatar. Individually those can be modest, but resource pressure matters most when features overlap. A Companion speaking while a local model is generating the next answer and an image job starts is a much more realistic test than running each engine in isolation.
Image generation changes the equation
Image generation often has a different memory profile from text inference. Resolution, model architecture, identity conditioning, adapters and upscaling can all add memory pressure. A user might have a smooth chat experience and then hit an out-of-memory error only when Generate Selfie is clicked. Treating that as a mysterious image bug would be poor design if the real cause is predictable GPU contention.
AVRE's intended approach is to schedule heavy image jobs and make success/failure visible. The app should not claim 'Generated companion photo' when no usable media result exists. Resource errors belong in diagnostics, while the customer sees a simple failure and can retry with an appropriate configuration.
Voice and avatar still count
Speech recognition and text-to-speech can be smaller than the language or image models, but latency matters. If TTS waits thirty seconds after the text is already visible, the Companion feels broken even if the synthesis eventually succeeds. The 3D renderer has a similar responsibility: it should remain smooth while speaking, but it should not consume maximum GPU power while hidden or while a heavier model is loading.
Stage 5 therefore treats the avatar as part of the resource plan. The final human model may be visually richer than the development puppet, but it still needs frame-rate limits, inactive-window behaviour and quality tiers. A beautiful avatar that makes the local AI unusable would not be a successful feature.
Why AVRE will not publish a fake compatibility score
A hardware checker that asks for the GPU name and returns a score such as 96/100 looks reassuring but can hide the real constraints. Useful guidance should say what AVRE version was tested, which language model, quantisation, context length, image settings, voice engines and avatar quality were active. It should distinguish 'starts successfully' from 'comfortable daily use.'
That is why the current hardware checker refuses to invent results. AVRE can build a database from tested configurations and then give customers an evidence-based profile. A buyer deserves to know whether the recommendation is measured or merely guessed.
What a buyer should prioritise
For local AVRE use, GPU VRAM, system RAM, fast SSD capacity, CPU performance and cooling all matter. The SSD stores local models and private media, and model files can be large. System RAM provides breathing room when some workloads are not fully GPU resident. Cooling matters because AI inference can sustain load for much longer than a short application burst.
The best computer is therefore the one that matches the intended feature combination. Someone who wants text and voice only may need far less hardware than someone who wants a large local model, high-resolution image generation and a detailed 3D avatar simultaneously. AVRE's eventual benchmark profiles should make that distinction explicit rather than pushing every customer toward the most expensive PC.
What this means for AVRE customers
The standard AVRE is aiming for is simple: a customer should be able to understand what a feature does, where the data goes, what hardware it uses and what happens when it fails without reading developer notes. That is why the public site now separates finished behaviour from planned behaviour and why manual testing can reject a technically present feature when the visible workflow is poor. Product documentation will continue to change as the release build becomes more stable, but those changes should make the promises more precise rather than quietly changing what the product is.