Use AI without sending your business data to an outside AI service. We build assistants, document tools, and workflows that run on your own hardware. We connect them to your systems, test them before release, and support them as agreed.
AI means the models, and the application built around them, run on hardware at your site. We select local large language models () and task-specific models, connect the data sources you approve, and build the application. Local hardware alone does not prove that data stays inside the agreed boundary, so we test the complete system before acceptance.
Custom hardware solutions
The hardware you need depends mainly on three things: the model, how much text it handles in one request (its ), and how many people use it at once. The tiers below are reference configurations, not fixed packages or stock listings. Custom-configured means we size the system to your workload and confirm , memory, storage, and model compatibility before purchase.
Based on current hardware pricing as of , subject to change. Prices are planning budgets in US dollars, not supplier quotes. Configuration and availability affect the final cost. Tax, delivery, deployment, and ongoing application support are separate.
Subject to availability. GPUs and complete systems may be backordered. Supplier lead times, configuration, testing, and shipping all affect when equipment arrives. We confirm availability and expected dates before ordering. If a part must be substituted, we recheck compatibility and ask for your approval first.
In this guide: three budget picks, DGX Spark clusters, model specifications and hardware fit, and a comparison with hosted AI.
Our default picks for text-first , which means using an already trained model to answer mostly text requests. The right choice is the smallest system that passes quality and load tests on your own tasks.
$2,000–$5,000Equipment budget bracket
NVIDIA RTX 5060 Ti
Our pick for one narrow text workflow: a workstation with the 16 version of this card.
Model to test first: Qwen3 8B at 8K .
Move up a tier when the chosen model, its context, or the number of simultaneous requests no longer fits.
See pros and cons$5,000–$15,000Equipment budget bracket
NVIDIA RTX 5090
Our general-purpose pick: 32 GB of in a single- deployment. Plan $7,000–$12,000 for the configured workstation.
Model to test first: Qwen3 30B-A3B at 16K context.
Choose DGX Spark instead when fitting a larger model matters more than speed. It holds more, but its lower memory limits how fast it generates text.
See pros and cons$15,000–$35,000Equipment budget bracket
NVIDIA RTX PRO 6000 Blackwell
Our pick for larger models on one GPU, with 96 GB of GPU memory. Plan $20,000–$35,000 for the configured workstation.
Model to test first: Llama 3.3 70B Instruct at 32K context.
Consider a cluster only when the model’s size or separate services make it worth running across several machines.
See pros and consThese picks and the pros and cons below are our reading of published specifications and model requirements, not benchmark results.
NVIDIA RTX 5060 Ti
Best fit: A focused pilot, an extraction pipeline, or a small local assistant.
NVIDIA RTX 5090
Best fit: A versatile CUDA workstation for applications whose models fit within 32 GB.
Model examplesQwen3 8BGemma 3 12B ITQwen3 30B-A3BQwen3 32B
NVIDIA DGX Spark (GB10)
Best fit: Testing larger models where memory capacity and a compact footprint matter more than top speed for a single request.
Model examplesQwen3 8BQwen3 32BLlama 3.3 70B Instruct
Apple M5 Ultra
Best fit: A desktop deployment built on inference software that supports Apple silicon.
Model examplesQwen3 8BQwen3 32BLlama 3.3 70B Instruct
Mac Studio specifications; Apple’s pricing and availability announcement.
NVIDIA RTX PRO 6000 Blackwell
Best fit: A larger-model application that benefits from one high-memory GPU and professional workstation support.
Model examplesQwen3 32BLlama 3.3 70B InstructQwen3 30B-A3B
2 × NVIDIA RTX PRO 6000 Blackwell
Best fit: A model too large for one GPU, or separate model services sharing one larger machine.
Model examplesLlama 3.3 70B InstructQwen3 235B-A22B
We specify the configuration, test models on your tasks, connect your data and software, and set up permissions and monitoring before handing the system over. Deployment dates depend on equipment delivery and site readiness.
Acceptance plan
Our proposal names what will be tested, who reviews the results, and what result qualifies the system for purchase and release.
Download a sample acceptance planBlank evaluation template, not a completed benchmark report.DGX Spark clusters
Several DGX Spark systems, or nodes, can be connected. Compatible software can split one large model across the nodes, or each node can run its own models and services. We compare clusters of 2, 3, 4, and 8 nodes below; the right layout depends on your workload.
Systems-only figures use NVIDIA’s published price of $4,699 per DGX Spark Founders Edition, reviewed September 15, 2026. Switches, cables, installation, tax, delivery, and support are extra.
Installed memory totals add up separate machines; they are not one shared pool. Each node needs room for its share of the model , plus , the operating system, and overhead. Adding nodes does not guarantee a proportional speed increase, or that another node takes over automatically when one fails.
Documented topology
Direct QSFP connection
Best fit: A compatible model too large for one Spark, or two independent AI services.
Documented topology
Direct cabling, without a switch
Best fit: Testing a larger sharded model, or separating inference, evaluation, and batch work.
Documented topology
Compatible high-speed Ethernet switch
Best fit: A compact multi-node deployment with a defined serving or evaluation workload.
Custom engineering review
Custom switched topology
Best fit: A feasibility study for independent serving groups, batch workloads, or a validated distributed runtime.
The version of Qwen3 235B-A22B is larger than one Spark’s memory. A pair has enough combined memory to try splitting it across both machines, but that does not show that it will fit or how fast it will run. For larger clusters, we test the actual model split, network, simultaneous load, and failure behavior before you commit to the equipment.
Plan a DGX Spark clustermodel reference
Open-weight models can be downloaded and run on your own hardware. The models below are representative examples with downloads you can inspect, not a ranking of the newest or best. We test a shortlist on your tasks, including the quality of the compressed () version and the license terms.
Same basis for every model: downloads, an , and one active request. Estimated memory covers the model, the cache, and the . Fitting in memory is not a production acceptance test.
Output speeds are unmeasured estimates based on memory , with 4K already in . They are not vendor benchmarks or promised performance. The in each table is a separate example used to size memory. How the estimates work.
Start small when the task has a narrow, testable output.
Best fit: Short, well-defined tasks with outputs you can check.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| Entry-level workstationNVIDIA RTX 5060 Ti | 8K tokensInput + output | ~5.5 | 50–101 Analytical estimate |
A useful baseline to evaluate before buying hardware for a larger model.
Best fit: The first text-model baseline for an internal assistant or extraction workflow.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| Entry-level workstationNVIDIA RTX 5060 Ti | 8K tokensInput + output | ~7.8 GiB | 27–55 tok/sAnalytical estimate |
| AI workstationNVIDIA RTX 5090 | 16K tokensInput + output | ~8.9 GiB | 111–222 tok/sAnalytical estimate |
| DGX Spark desktopNVIDIA DGX Spark (GB10) | 16K tokensInput + output | ~8.9 GiB | 16–33 tok/sAnalytical estimate |
| Apple silicon desktopApple M5 Ultra | 16K tokensInput + output | ~8.9 GiB | 74–149 tok/sAnalytical estimate |
Text and image model
Text and image understanding, document-image review.
View on Hugging FaceConverted to this format by the runtime’s maintainers. Image input also needs the 0.85 GB , and more or larger images add memory and .
Best fit: Tasks that need both text and image understanding.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| AI workstationNVIDIA RTX 5090 | 4K tokensInput + output | ~13.1 GiB | Benchmark requiredImage workload varies |
All expert weights must fit in memory. reduce the computation per token, not the download size or the memory needed.
Best fit: Testing a mixture-of-experts assistant on the 32 GB workstation tier.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| AI workstationNVIDIA RTX 5090 | 16K tokensInput + output | ~21.8 GiB | Benchmark required varies |
| Professional AI workstationNVIDIA RTX PRO 6000 Blackwell | 32K tokensInput + output | ~23.3 GiB | Benchmark requiredExpert routing varies |
Compare quality on your own tasks. Parameter count alone is not a quality score.
Best fit: A larger dense text model to compare against the smaller Qwen models.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| AI workstationNVIDIA RTX 5090 | 16K tokensInput + output | ~25.4 GiB | 30–60 tok/sAnalytical estimate |
| DGX Spark desktopNVIDIA DGX Spark (GB10) | 32K tokensInput + output | ~29.4 GiB | 4–9 tok/sAnalytical estimate |
| Apple silicon desktopApple M5 Ultra | 32K tokensInput + output | ~29.4 GiB | 20–40 tok/sAnalytical estimate |
| Professional AI workstationNVIDIA RTX PRO 6000 Blackwell | 32K tokensInput + output | ~29.4 GiB | 30–60 tok/sAnalytical estimate |
Dense text model
Larger local assistants and complex text tasks.
View on Hugging FaceA community of Meta’s model. Review the license and acceptable-use terms, not just the download format.
Best fit: A high-memory text-model evaluation alongside smaller alternatives.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| DGX Spark desktopNVIDIA DGX Spark (GB10) | 32K tokensInput + output | ~53.6 GiB | 2–4 tok/sAnalytical estimate |
| Apple silicon desktopApple M5 Ultra | 32K tokensInput + output | ~53.6 GiB | 9–19 tok/sAnalytical estimate |
| Professional AI workstationNVIDIA RTX PRO 6000 Blackwell | 32K tokensInput + output | ~53.6 GiB | 14–28 tok/sAnalytical estimate |
| Multi-GPU system2 × NVIDIA RTX PRO 6000 Blackwell | 32K tokensInput + output | ~53.6 GiB | Benchmark required layout varies |
Mixture of experts
Large-model evaluation on a high-memory system.
View on Hugging FaceA capacity example, not our default recommendation. the model across devices adds communication costs that only a complete system benchmark can measure.
Best fit: A deliberate large-model evaluation after smaller options miss the quality target.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Hardware | Working context | Estimated memory | Output speed at 4K |
|---|---|---|---|
| Multi-GPU system2 × NVIDIA RTX PRO 6000 Blackwell | 32K tokensInput + output | ~146.3 GiB | Benchmark requiredExpert routing varies |
In these local model profiles, K means 1,024 tokens. Context covers instructions, conversation history, retrieved passages, and the answer. Download sizes use decimal GB; memory estimates use GiB.
Precision is the number of bits used to store each number in a model. Fewer bits can reduce memory use and speed up , but can lower answer quality. The benefit depends on the model, hardware, and working together.
This guide’s estimates: Q4_K_M with an FP16 , not FP8 or FP4 benchmarks. A different format, such as , NVFP4, or an conversion, needs its own file-size, memory, speed, and quality checks. Advertised AI are not per second.
NVIDIA Blackwell: FP16/BF16, FP8, and FP4 support. NVFP4 needs a compatible model and runtime; the Q4_K_M examples in this guide use a different format.
Apple silicon: GGUF Q4_K_M through , or separate MLX models. MLX supports 4-bit and 8-bit formats; acceleration depends on the chip, model and runtime.
Technical references: NVIDIA: FP4 and NVFP4; NVIDIA: RTX runtime support; Hugging Face: GGUF formats; MLX quantization formats.
: Qwen3 30B-A3B activates about 3.3B per token, but its full 18.56 download still has to fit in memory. Do not size it like a 3B dense model.
Licensing: “” does not mean unrestricted. Qwen uses Apache 2.0 for these ; Gemma and Llama have their own terms. Check what each license allows for use and redistribution, and what it requires of fine-tuned versions.
Disk is not memory: A 20 GB model download does not mean a machine with 20 GB of memory is enough. Keep disk space for at least two model releases, images, document indexes, source files, and independent backups.
Hosted AI reference
ChatGPT, Codex, and Claude do not have one fixed speed. The model you select, its reasoning mode, the tools it uses, and how busy the service is all change the experience. The table below compares specific models through their instead, which gives a more useful reference.
Reference snapshot: . Speeds are approximate figures from Artificial Analysis for the listed provider and settings, with 10,000 input . specifications and prices are not the same as ChatGPT, Codex, Claude, or Claude Code subscription limits.
Not a like-for-like benchmark. The hosted figures are measured API observations; the local figures above are unmeasured planning estimates at 4K occupied . The comparison does not show equal speed, answer quality, or coding ability.
Scroll sideways for all columns. With a keyboard, focus the table and use the arrow keys.
| Model and API provider | Output speed | First answer | Context / | API input / output |
|---|---|---|---|---|
| GPT-6 AstraOpenAI, High reasoning | ~53 GPT-6 Astra benchmark | ~33.3 secBefore answer starts | 1.05M / 128K922K | $10.00 / $50.00$1.00 |
| GPT-5.6 SolOpenAI, High reasoning | ~55 tok/sGPT-5.6 Sol benchmark | ~9.3 secBefore answer starts | 1.05M / 128K922K max input | $4.00 / $20.00$0.40 cached input |
| GPT-5.6 TerraOpenAI, High reasoning | ~92 tok/sGPT-5.6 Terra benchmark | ~2.5 secBefore answer starts | 1.05M / 128K922K max input | $2.00 / $12.00$0.20 cached input |
| GPT-5.6 LunaOpenAI, Non-reasoning | ~109 tok/sGPT-5.6 Luna benchmark | ~0.9 secBefore answer starts | 1.05M / 128K922K max input | $0.20 / $1.20$0.02 cached input |
| Claude Fable 5.1Anthropic, High, default fallback | ~51 tok/sClaude Fable 5.1 benchmark | ~10.9 secBefore answer starts | 1M / 128KInput and output share context | $10.00 / $50.00$0.25 cached input |
| Claude Opus 5Anthropic, High, adaptive thinking | ~49 tok/sClaude Opus 5 benchmark | ~8.6 secBefore answer starts | 1M / 128KInput and output share context | $5.00 / $25.00$0.50 cached input |
| Claude Sonnet 5Anthropic, High, adaptive thinking | ~58 tok/sClaude Sonnet 5 benchmark | ~2.3 secBefore answer starts | 1M / 128KInput and output share context | $2.00 / $10.00$0.20 cached input |
| Claude Haiku 4.5Anthropic, Non-reasoning | ~81 tok/sClaude Haiku 4.5 benchmark | ~0.7 secBefore answer starts | 200K / 64KInput and output share context | $1.00 / $5.00$0.10 cached input |
Artificial Analysis reports a rolling 72-hour and normalizes to OpenAI tokens; prices and context limits use each model’s native tokens. The figures are a dated snapshot, not a service guarantee, and were not measured in the consumer apps. Benchmark methodology.
At 50 tokens per second, 500 output tokens take about 10 seconds once generation starts. Prompt processing, thinking, retrieval, and tool calls add time, and an that edits code and runs tests may make many model calls. Measure the time to finish a task, not just the speed of the text stream.
The table lists each model’s maximum, not space guaranteed for your documents. Instructions, conversation history, retrieved passages, and the answer all share that budget. Chat products and coding may reserve space, shorten history, or apply different limits, and which models you can use varies by plan and environment. Codex model options; Claude model specifications.
For the OpenAI models listed, when a prompt exceeds 272K input tokens, the entire request is charged at 2× the input and rates and 1.5× the output rate. Sol’s listed promotional pricing is available at least through November 21, 2026. The Claude models listed use standard pricing across their full context windows. Cache writes, faster service tiers, batch processing, tools, and regional options can change the bill. Prices are subject to change. OpenAI pricing; Anthropic pricing.
Running models locally avoids per-token charges, but equipment, electricity, software operations, storage, and replacement still cost money. Compare the cost of each accepted result at your expected workload, not the hardware price against a chat subscription.
These hosted models have no downloadable and no public sizing specifications for an build. We do not guess their parameter counts, , or / formats. The models above are separate choices, not local editions of ChatGPT or Claude.
The listed API models accept text and images and produce text. Voice, search, file handling, and code execution inside a product rely on additional services. Hosted and local models can both sit behind document retrieval and approved tools, but the application still has to provide access control, citations, validation, and action confirmation.
A hosted API sends each request to its provider, so review that provider’s retention, region, and contract terms. An on-premises design keeps processing on site only when retrieval, , logging, tools, and other dependencies stay inside the same boundary.
A smaller local model may suit a narrow task even when a hosted model is stronger overall. We test both with the same examples, acceptance criteria, and simultaneous load. Decide which model meets the requirement before choosing hardware for it.
The application around the model
The same machine can support more than a chat model. Each extra workload uses memory, storage, or processing time, so we size the whole application, not just the model file.
finds the relevant passages in your documents and gives them to the model with the question. The document library itself does not have to fit in the or .
Parsing, , , retrieval, and any run locally too. We apply source permissions before retrieval, keep citations, and handle document updates and deletions.
Storage example: 100,000 × 768 dimensions × 4-byte floats = 307.2 MB of raw . A million chunks = 3.07 . Text, metadata, index overhead, originals, and backups are extra. This is arithmetic, not a claim about how many documents a system can hold.
A vision-language model can interpret an image; OCR extracts text for search and structured processing. Choose based on the job, not the label “.”
Gemma’s is an additional file. Image resolution, page count, and batch size change memory and . Text token speeds do not predict pages per minute.
Vision runtime requirementsLocal speech recognition, extraction, and classification can run as separate services. Non-urgent work can wait in a queue so it does not compete with an interactive assistant.
We measure speech in minutes of audio processed per minute, stating the language and noise conditions. Training, image generation, and need separate sizing; the tiers above cover only.
An needs approved tools, identity, scoped permissions, action review, and recovery. A model’s ability to call tools is not permission to change a record.
Acceptance tests include multi-step delays and tool failures. Credentials stay outside the model, and we check whether a simpler workflow would do the job better.
APIs and agent integrationsFor Qwen3 8B, the for one request is about 1.13 at 8K or 4.5 GiB at 32K, before model and overhead. Four 32K requests running at once can need about 18 GiB of cache alone. RAG keeps prompts short by retrieving a focused set of passages instead of loading the whole library into every prompt.
How cache memory worksNo hardware benchmarks were run for this guide. The planning calculations use published specifications and exact file sizes from pinned model versions.
Estimated memory is the model files, plus one key/value , plus a stated allowance for the . Each tier keeps spare memory outside that estimate. Real runtime reservations, image processing, and can use more.
is a conservative pilot setting, not the largest possible window. Gemma’s 4K text-first example uses a separate allowance because its hybrid attention does not follow the simple full-cache calculation.
The dense-model range assumes 35–70% of advertised memory , divided by weight bytes plus cache bytes at 4,096 occupied . That efficiency range is an uncalibrated sensitivity assumption, meaning an assumed spread rather than a measured confidence interval.
It assumes the model is already loaded and fully accelerated, with one active request and no . It leaves out model loading, prompt processing, retrieval, tools, and time to first token. Compute limits, kernels, and memory traffic can put real results outside the range. We give no number for expert models, vision, or layouts, where this shortcut does not hold.
We pin the model, , runtime version, driver, , and hardware configuration. We test representative 2K, 8K, and longer prompts, then the intended simultaneous load.
We record answer quality, time to first token, output per request, total , peak memory, power, and failure recovery. Warm runs are repeated, and cold starts are tested separately.
Benchmarking referenceShowing that a model fits is not a claim of customer deployment, compatibility certification, or vendor partnership.
Discuss hardware and deploymentA map of where your data flows, a hardware specification, a model shortlist, a licensing review, a cost outline, and written acceptance criteria. We assess your existing equipment before recommending any purchase.
Local model serving, an interface or , and connections to approved internal sources. Retrieval, document processing, permissions, and review steps are included where the task needs them.
Deployment configuration, an inventory of versions and dependencies, evaluation results, administrator training, and step-by-step runbooks for updates, backups, recovery, and support.
We lead the technical work alongside your business and IT owners. Your team explains the task, approves access, reviews the pilot, and accepts the release. We agree on scope and cost before each stage, and a pilot is not a commitment to buy hardware or launch.
We walk through one real task with your team, such as finding answers in internal manuals or extracting fields from documents. We note who does the work, the exceptions, and what goes wrong today. Together we agree on what a good result looks like, including when the AI should ask for help or take no action.
Result: A focused scope, a named owner, and measurable acceptance criteria.
We trace where documents, prompts, outputs, logs, and backups go. With your IT and security owners, we decide who can access each source and whether the network is restricted or (fully offline). We design the interface, local processing, storage, and identity connections, and check whether retrieval from your documents is enough before considering .
Result: An architecture and data-flow map, with access rules and a pilot test plan.
We use fictional or redacted examples until access, storage, logging, and network controls are approved. We compare suitable licensed models on representative tasks, then test with separate evaluation examples, measuring accuracy, response time, concurrent use, and memory. If the results do not justify a build, we revise the approach or stop.
Result: Pilot findings, a model recommendation, and measured hardware requirements.
After budget approval, we reuse suitable equipment or help arrange the agreed hardware; the scope sets who buys and installs it. We configure storage, encryption, identity, backups, and network restrictions, and install approved, versioned models and dependencies through your permitted import process. We check power, cooling, capacity, and recovery arrangements before production data is introduced.
Result: A configured environment, verified dependencies, and an installation record.
We connect approved sources and prepare documents for local search or extraction. We build the application around your existing permissions and handle source updates, deletions, and revoked access. When an can take actions, we enforce permissions in application code, keep credentials outside the model, and require the agreed review before any change.
Result: A working application connected to approved internal systems.
Representative users from your team test ordinary tasks, missing information, and difficult cases. We check forbidden access attempts, outbound traffic, load, restarts, and offline operation where required, and rehearse backup restoration and . We document failures and resolve anything that blocks release under the acceptance criteria.
Result: An acceptance report with measured results, known limits, and a release decision.
With your approval, we release to a defined group before expanding access. We train users and administrators, monitor the agreed measures locally, and keep rollback available. We hand over the configuration, operating instructions, incident contacts, and a clear split of responsibility for hardware, software, and model behavior.
Result: An accepted deployment and a team prepared to operate it.
Your team or an agreed support arrangement owns this work; remote access is not assumed. Those responsible review quality, capacity, source freshness, and access as usage changes. They stage approved patches and model updates, then repeat quality and data-boundary tests before release. They also keep backups and recovery checks current.
Result: A maintenance schedule, named responsibilities, and controlled future releases.
These are illustrative build options, not claims about completed customer deployments. We start with one task and expand only when it earns its place.
Staff ask questions of approved policies, technical manuals, or research. Answers cite their sources, respect each user’s access, and say when the documents do not support an answer. The design handles source updates, deletions, and revoked access.
The application reads contracts, case files, or internal reports locally. It extracts fields, compares versions, and sends uncertain results to a reviewer instead of silently updating the record.
An assistant prepares a task or record change through approved . Credentials stay outside the model, actions are limited, and a person confirms consequential changes.
When no data may leave your site, prompts and documents are only part of the picture. We account for every component that handles your data and verify the agreed configuration before acceptance.
Model , , , and any agreed run locally. Outputs, attachments, and retrieval indexes are stored on site. No external inference endpoint, hosted , or automatic cloud fallback is allowed.
Logs, caches, backups, monitoring, and identity services stay inside the agreed boundary. We disable , crash uploads, external analytics, and automatic downloads, and we enforce network restrictions instead of relying on application settings alone.
We define with you who can view records, export files, use removable media, or administer the deployment. A strict on-site scope rules out remote viewing and off-site backups. Support then happens on site or through procedures your staff run, not through unapproved log or screen sharing.
We document which hardware and network services may process your data. A private cloud still uses off-site infrastructure, so it is not an on-site deployment and has different requirements.
The application and models run on hardware at your site, and connections to internal systems remain available. When data must stay on site, we also restrict outbound traffic and review user devices, identity, and backup locations.
Only documented connections are allowed, and we review any proposed external service on its own. If an exception processes business data off site, we do not describe the deployment as one where no data leaves your site.
The environment has no network connection to outside systems. Models and updates arrive through approved offline import procedures, with integrity checks, dependency review, and a plan. Whether this works depends on the complete hardware and software stack.
You do not need to have chosen a model or bought servers. We can assess first, deliver one application, or build a shared platform in stages.
We work out feasibility, the data boundary, hardware options, and total operating costs. You receive a pilot plan or a clear recommendation not to proceed. Implementation is a separate decision.
We take one workflow from a local pilot to an accepted production release, including installation, integrations, controls, documentation, and staff handoff.
We build shared model serving, identity, monitoring, and release controls for several applications. Capacity and use cases grow through separately approved stages, with an ongoing maintenance agreement if you need one.
We lead application architecture and delivery, coordinating with your IT team and with hardware or security specialists where needed. The agreement assigns responsibility for equipment, networking, model quality, updates, incidents, and support hours. We do not assume unattended remote access or 24/7 coverage.
It depends mainly on the model, its length, and how many requests run at the same time. Our guide on this page compares equipment budgets from a small 16 pilot to high-memory workstations and systems, with example model downloads and memory calculations. Fitting in memory is a planning check, not proof of useful speed or answer quality, so we benchmark the complete application before you buy. Implementation and support are priced separately.
No. stores searchable documents and an index separately, then passes selected passages to the model. still needs room for model , , and any embedding or reranking models running there. We also size document ingestion, access controls, storage, backups, and simultaneous requests as part of the application.
Yes. We can scope a fully local deployment with no external processing. The commitment covers a defined application and operating boundary, including logs, backups, identity, user devices, and support. Installing a local model alone does not prove it, so we test that configuration before acceptance and after any material change.
Yes. Our guide compares two-, three-, and four-node clusters that follow NVIDIA’s documented connection setups, plus an eight-node option that needs a custom engineering review. Node prices exclude networking and deployment. Combined memory is not automatically one usable pool, so we test the model, , network layout, and application together.
It depends on the task, so we test before recommending a production build. We compare task accuracy, source grounding, failure handling, speed, and capacity against your acceptance criteria. A smaller local model may fit a narrow task; other workloads may need more hardware, a different approach, or a decision not to proceed.
Usually not. We start with a suitable licensed model, approved retrieval sources, and a focused application. is an option only when measured task failures justify it and the data rights, compute, and evaluation are in place.
Yes, if they meet the workload’s requirements. We review processor and GPU support, memory, storage, power, cooling, backup power (UPS), expected concurrent use, and availability requirements, then benchmark the intended workload before you commit to equipment. The scope sets who buys and installs any hardware.
Not automatically. A fair comparison includes hardware, utilization, power, licenses, IT time, evaluation, support, and replacement costs. Where external processing is permitted, a hosted service may be the better choice. We do not promise savings or a payback period without a workload-specific calculation.
No. Location is one control, not a certification or a guarantee against misuse. Access, retention, endpoint security, vulnerabilities, exports, and human decisions still matter. Your security and compliance owners approve the required controls; we provide the agreed technical evidence.
Yes, if the chosen software stack supports offline operation. The plan covers approved model and software imports, integrity checks, staging tests, , and maintenance done on site or by your staff. Remote sessions or off-site diagnostic exports need explicit approval and may conflict with a strict on-site boundary.
Only a non-sensitive description of the task, your deployment restrictions, the approximate number of users, and your known infrastructure. This public website and its contact form are not an environment. Do not send confidential files, records, credentials, or network diagrams; we agree on a suitable review process first.