Knowledgebase

Managed Local AI is a scoped service for private AI workloads that should run close to your data instead of depending on a public chatbot account. Typical work includes GPU and runtime readiness, model selection, private access, monitoring, update planning, and practical usage guidance.

The current server class is suitable for focused local AI workloads, especially quantized chat models, embeddings, reranking, classification, extraction, and RAG pipelines. Large frontier-model behavior, high concurrency, long contexts, and heavy image or video generation need careful sizing and may need a different architecture.

The current support server profile has a NVIDIA RTX 4000 SFF Ada GPU with 20 GB VRAM. Verified 2026-08-03 UTC: the NVIDIA driver and kernel module are aligned, Ollama answers on the local API, and the representative gpt-oss:20b text-model smoke passed at 4k context.

This is useful feasibility evidence for private text workloads. Commercial RAG, agent, multi-user, and long-context claims still require a workflow-specific benchmark on the live server before production activation.

GPU device files can be held by internal worker services, so disruptive driver, module, or runtime work is planned in a maintenance window instead of being changed during an active support session.

It proves that the installed server can load gpt-oss:20b through Ollama and return a controlled text answer from the GPU-backed runtime. It confirms the driver, model file, Ollama API path, and basic inference loop work together.

It does not prove a full customer workflow. Retrieval quality, document ingestion, permissions, repeated-use latency, logging, backups, and failure handling still need a project-specific benchmark.

A model that answers one prompt is not the same as a reliable business assistant. For RAG and agent projects we test real documents, real questions, retrieval quality, citation quality, refusal behavior, privacy boundaries, and response time.

A local AI service depends on more than the GPU card. We verify that the operating system can see the GPU, the runtime stack is compatible, the inference service starts cleanly, the selected model fits, and a real prompt or retrieval task returns a usable answer.

If the server cannot currently load and answer with the target model, the project is not sold as a live inference service. The first paid scope becomes diagnosis, repair, model selection, and benchmark evidence. Production activation only starts after a smoke test proves that the selected workflow runs on the actual server.

Yes, that is the point of the local approach when the workload fits. Documents, prompts, indexes, and generated answers can stay on infrastructure we operate or manage for you. We still define access rules, retention, backups, and any optional external API use during onboarding.

We start with the business task, data sensitivity, expected users, target response time, and budget. Then we check the server baseline, run a representative benchmark, and launch only when the measured result supports the production scope.

Start smaller than you think. For many business workflows, retrieval quality, clean source documents, and reliable prompts matter more than choosing the largest model. We compare model size, quantization, context length, concurrency, latency, and cost before recommending a recurring plan.

Often yes, but not without limits. A single server can host a compact chat model, embedding jobs, a vector index, and a private RAG interface when usage is controlled. We separate background indexing from live chat, set upload and context limits, and monitor VRAM, RAM, disk, and response times.

Useful inputs are the business process, example questions, ideal answers, document types, approximate volume, update frequency, expected users, privacy requirements, and any existing server or authentication constraints. This lets us quote a realistic baseline review or benchmark instead of guessing.

Team RAG is a private assistant that answers questions from approved company documents. The system retrieves relevant source context and asks the model to answer from that evidence, which is useful for support drafts, internal process questions, policy lookup, and sales preparation.

PDF, DOCX, Markdown, plain text, HTML exports, CSV notes, ticket exports, and curated website pages can usually be processed. Database-backed systems are normally exported as selected records instead of giving the assistant unrestricted database access.

Yes, when the workflow is designed for visual evidence. A visual RAG workflow can extract useful text, generate descriptions, and store image-aware evidence next to normal documents. Qwen3-VL-Embedding and Qwen3-VL-Reranker are candidates we can benchmark, but production use still depends on the actual data, latency target, and server readiness.

We use conservative prompts, source references, real test questions, and failure review. RAG is not a magic truth engine: if the source material is wrong, outdated, or missing, the system must be corrected at the source or retrieval layer.

We design around least privilege. Smaller teams may use one curated assistant. Larger teams may need separate indexes, groups, or identity-provider integration so users only retrieve sources they are allowed to see.

The best first dataset is a focused collection that answers a real recurring question. Avoid unreviewed file dumps, conflicting versions, documents users are not allowed to see, and huge archives before retrieval quality has been measured.

The RAG Retrieval Quality Audit is available as a separate one-time Team RAG Retrieval Quality Audit in the cart for a bounded pre-purchase review. The current default EUR checkout price is €431 one-time; confirm the final total at checkout. The included scope is up to 25 representative files, maximum 200 pages total, and 15 fixed questions. Extra files, pages, questions, or rework are quoted separately.

The recurring Team RAG plan is the next step after a successful audit. When the recurring scope is approved within 30 days, the €431 audit fee is credited against the Team RAG setup fee and confirmed before provisioning. If you need help preparing a limited corpus, use the benchmark intake before ordering.

We test a representative document set, fixed user questions, retrieval results, citation quality, reranker gains, permissions, and privacy considerations. The output is a go, narrow, repair, or stop recommendation. On the current EZOS server profile, production local inference is only promised after the exact workflow smoke passes on the live server.

The Visual Document AI Intake is a €431 one-time pilot for up to 10 representative files or images, maximum 50 pages total, and one defined extraction workflow. We compare a Docling/OCR baseline with a qwen3-vl:8b visual reasoning smoke test, then provide a field-level error table and unsupported-layout notes. There is no page-volume SLA; extra pages, fields, layouts, or rework are quoted separately before work continues.

The baseline is security-conscious setup, SSL, backup planning, update coordination, uptime monitoring, and a clear support path. Exact scope depends on the software stack and the business impact of downtime.

We define what is backed up, how often, where it is stored, retention, and how restore testing works. Backups may include web files, database dumps, configuration, uploaded assets, DNS notes, and selected service configuration.

When monitoring is part of the plan, we can watch HTTP status, certificate expiry, selected error logs, disk pressure, and service-specific signals. For AI and custom applications, we prefer a health check that proves useful work, not just HTTP 200.

Email and high-volume sending require a readiness review. We check consent, sender reputation, DNS policy, bounce handling, complaint handling, queue limits, and abuse controls before production mail is moved.

Security is part of the operating model. We look at access, updates, backups, exposed services, logs, secrets handling, and practical incident recovery. The depth of review depends on the plan and risk level, but findings should stay actionable.

Older hosting accounts often carry outdated documentation, unused services, and names from retired products. We do not keep public guidance for products we no longer offer. Current articles focus on active EZOS.Hosting services and the server stack actually in use.

Yes, after a baseline review. We check access, backups, update state, exposed services, disk layout, monitoring, and business criticality before making production changes.

Usually SSH with sudo or a defined privileged path, provider or control-panel access when DNS or rescue mode may be needed, application admin access if the app itself must change, and a current backup or permission to create one.

Yes, if the server and driver stack are supportable. GPU AI issues often involve kernel modules, driver packages, userspace libraries, runtime services, model storage, and reverse proxy configuration. We verify with a real model or health check before calling a repair complete.

We start with an inventory of domains, databases, files, mail, cron jobs, DNS, certificates, and external dependencies. Then we decide what should be kept, retired, or rebuilt, test the target environment, and keep rollback options until the new setup is verified.

We do not promise responsibility for unknown custom code, unlicensed software, unsupported operating systems, unverified third-party plugins, workloads that violate rules or law, or performance the hardware cannot deliver.

Before risky production work we identify the real host, service, repository or webroot, check the current state, create or confirm a rollback path, make the smallest useful change, and verify from the user-facing endpoint.

For driver, kernel, firewall, and storage work we prefer a maintenance window.

Use the business problem first. Choose Managed Local AI or Team RAG for private AI work, Business Secure Hosting for safer production hosting, and BYO Server Management when you already have infrastructure that needs operational care.

Simple reviews can usually start after order confirmation and access handover. Production migrations, security-sensitive systems, GPU runtime work, and AI deployments need a baseline check before implementation work is scheduled.

Include the affected domain or service, expected result, actual result, exact error text, when it started, recent changes, business impact, urgency, and the safe access handover method. Exact URLs and timestamps are usually more useful than screenshots alone.

Use the agreed secure handover path for credentials, keys, or privileged access. Temporary access should use least privilege, expiration, and logging. Keep passwords and private keys out of public pages and ordinary email threads.

The next useful step is usually a short clarification or access checklist. Use the ticket portal for project details, attach exact errors when relevant, state deadlines and business impact, and do not send passwords in plain text.

Scope can change when the system reality changes. If work is smaller than expected, we reduce scope. If the server is riskier than expected, we explain the added work before continuing. Billing terms depend on the product and already delivered work.