SiteHost has launched a New Zealand-hosted AI Platform aimed at organisations that want to use generative AI through an API without sending prompts and documents to an offshore processor. The practical offer is straightforward: access to a locally operated Qwen model, embedding and reranking services, billed by token rather than through a fixed subscription or a customer-owned GPU deployment.
The announcement, published by IT Brief, positions data residency as the main differentiator. SiteHost’s own technical documentation supports the central claim: it says models, API routing and billing run on the company’s New Zealand infrastructure, and that request bodies are neither retained nor used to train models. But the documentation also adds an important operational detail absent from the launch framing: SiteHost keeps per-key, per-hour usage records for three months and uses a backend Key-Value cache that can persist computed prompt data across requests when customers reuse a session identifier.
That does not negate the promise that SiteHost is not storing customers’ raw request bodies. It does mean that organisations treating “no retention” as a complete answer for sensitive-data handling need to distinguish between prompt text, billing metadata, and the transient or reusable model-state cache created during inference.
The new service gives New Zealand businesses a hosted alternative to two familiar choices: pay an overseas AI vendor, or buy and operate GPUs themselves. SiteHost says every request stays within its New Zealand data centres and that its vLLM model-serving deployment has telemetry disabled. It also says the API, routing and billing layers are maintained in-house.
For a business that has ruled out offshore processing, that architecture matters more than a generic “cloud AI” label. New Zealand’s Privacy Act 2020 includes Information Privacy Principle 12, which regulates disclosure of personal information to foreign entities. Keeping AI processing in New Zealand can remove one cross-border disclosure issue from the design of an internal search, transcription, document-review or support-assistant system.
It does not remove the rest of the privacy and security work. A business still needs a lawful purpose for handling personal information, access controls, retention rules, incident processes and clear disclosure to the people whose data it processes. Locality also does not automatically answer contractual questions for regulated customers, including what SiteHost is permitted to log, how security incidents are handled, or how data is deleted from any operational cache.
SiteHost’s broader compliance page says the company is regularly audited and offers privacy and data-processing documentation for its services. The AI Platform documentation reviewed for this launch, however, does not spell out a platform-specific cache-retention period, eviction process, or customer control for clearing cached inference state. Those are procurement questions, not minor implementation details, when prompts may contain client files, medical notes, HR records or source code.
That three-part combination is enough to build a conventional retrieval-augmented generation system: generate embeddings for internal documents, retrieve likely matches for a question, rerank the candidate results, and pass the selected material to the Qwen inference model. For a company searching policy manuals, product documentation, call transcripts or a private knowledge base, that is a more coherent starting point than simply exposing a chatbot endpoint.
SiteHost says it serves models with their full context windows and avoids the more aggressive quantisation methods often used to reduce GPU memory and operating costs. The company has also committed to keeping each hosted model available for at least a year, followed by a three-month deprecation period. That commitment is unusually useful in a market where a model replacement can quietly change output format, prompt behaviour, quality and cost.
The limitation is capability breadth. SiteHost’s own inference documentation warns that mid-sized models can be impressive but are not as capable as state-of-the-art offerings. Qwen 3.6 27B may fit summarisation, restructuring, classification, transcription workflows and grounded internal search; it should not be treated as a drop-in substitute for every premium closed model used for difficult coding, complex reasoning, high-stakes analysis or broad multilingual work.
The company has not published independent benchmarks, throughput figures, concurrency limits or service-level commitments for the platform in the material reviewed. A 262,000-token window is valuable for large documents, but SiteHost itself notes that longer contexts consume more tokens and increase response time. Buyers need to test the workload they actually intend to run, especially where multiple employees or automated jobs will share the service.
That should make a basic move relatively simple for applications already using a compatible chat-completions client. In many cases, the code change will amount to replacing the base URL, API key and model name. SiteHost also documents streaming responses, API-key restrictions by model, capability and IP address, plus per-key request-rate and cost limits.
The compatibility claim needs a practical qualification. An OpenAI-compatible request format does not make Qwen 3.6 27B operationally identical to an OpenAI model. Prompt instructions, structured-output behaviour, reasoning settings, safety behaviour, tool calling, vision handling and output quality can all vary. SiteHost’s embedding endpoint is explicitly described as only partially compatible with OpenAI and Cohere-style embedding requests.
The sensible migration path is therefore to move a non-critical workflow first, preserve its existing test set, and compare outputs and latency against the incumbent service. A software team should also test error handling and streaming under load before changing a production endpoint. The value here is interoperability with common tooling, not a promise of identical model behaviour.
The headline input price should not obscure where an application’s bill is likely to accumulate. At the upper published rates, one million input tokens plus one million generated output tokens would cost NZ$3.04. Reasoning can materially increase output-token usage: SiteHost says a model’s internal reasoning process counts toward output tokens, even where a user expects only a short final answer.
That makes the service financially attractive for episodic jobs such as a back-catalogue of recorded meetings, a one-time document conversion project, or an internal search prototype that has unpredictable demand. It is less automatically compelling for an always-on customer-facing assistant that produces long responses at high volume. In that case, customers must measure their input-to-output ratio, context size, retries and reasoning use rather than comparing only a token-price headline.
SiteHost’s billing system records aggregate cost by API key and model in the control panel. More detailed usage information is retained on a per-key, per-hour basis for three months, after which only a total remains. This is operationally helpful for cost allocation and investigating spikes, but it is also the part of the service that remains stored after prompt content is discarded.
This is a normal performance technique for transformer inference. Reprocessing a long conversation or document from scratch is expensive; a Key-Value cache lets the model reuse prior computation. But the technical distinction matters: the cached representation is not a copy of the original prompt body, yet it is derived from that prompt and remains useful precisely because it represents earlier context.
SiteHost has not publicly stated how long those cached blocks remain available, whether they are cleared when a session ends, whether they are ever written beyond GPU or server memory, or whether customers can disable session reuse. Until it does, security teams should treat session pinning as an opt-in performance feature and ask for the cache lifecycle in writing before using it with sensitive prompts.
The launch gives New Zealand organisations a credible local API option for retrieval, summarisation and other bounded AI workloads, with useful compatibility and a model-stability commitment that many hosted AI services lack. Its strongest case is not that it matches every frontier model; it is that it offers a locally operated, controllable service for teams that need to keep their AI data path inside New Zealand and can validate Qwen 3.6 27B against the work they actually need done.
That does not negate the promise that SiteHost is not storing customers’ raw request bodies. It does mean that organisations treating “no retention” as a complete answer for sensitive-data handling need to distinguish between prompt text, billing metadata, and the transient or reusable model-state cache created during inference.
SiteHost is selling jurisdiction and operating control
The new service gives New Zealand businesses a hosted alternative to two familiar choices: pay an overseas AI vendor, or buy and operate GPUs themselves. SiteHost says every request stays within its New Zealand data centres and that its vLLM model-serving deployment has telemetry disabled. It also says the API, routing and billing layers are maintained in-house.For a business that has ruled out offshore processing, that architecture matters more than a generic “cloud AI” label. New Zealand’s Privacy Act 2020 includes Information Privacy Principle 12, which regulates disclosure of personal information to foreign entities. Keeping AI processing in New Zealand can remove one cross-border disclosure issue from the design of an internal search, transcription, document-review or support-assistant system.
It does not remove the rest of the privacy and security work. A business still needs a lawful purpose for handling personal information, access controls, retention rules, incident processes and clear disclosure to the people whose data it processes. Locality also does not automatically answer contractual questions for regulated customers, including what SiteHost is permitted to log, how security incidents are handled, or how data is deleted from any operational cache.
SiteHost’s broader compliance page says the company is regularly audited and offers privacy and data-processing documentation for its services. The AI Platform documentation reviewed for this launch, however, does not spell out a platform-specific cache-retention period, eviction process, or customer control for clearing cached inference state. Those are procurement questions, not minor implementation details, when prompts may contain client files, medical notes, HR records or source code.
The launch model catalogue is useful, but narrow
At launch, SiteHost is offering one general inference model: Qwen 3.6 27B. Its documentation lists the model as multimodal, instruction-trained and available with a 262,000-token context window. It is accompanied by Qwen 3 VL Embedding 8B and Qwen 3 VL Reranker 8B, intended for semantic retrieval systems rather than conversational generation.That three-part combination is enough to build a conventional retrieval-augmented generation system: generate embeddings for internal documents, retrieve likely matches for a question, rerank the candidate results, and pass the selected material to the Qwen inference model. For a company searching policy manuals, product documentation, call transcripts or a private knowledge base, that is a more coherent starting point than simply exposing a chatbot endpoint.
SiteHost says it serves models with their full context windows and avoids the more aggressive quantisation methods often used to reduce GPU memory and operating costs. The company has also committed to keeping each hosted model available for at least a year, followed by a three-month deprecation period. That commitment is unusually useful in a market where a model replacement can quietly change output format, prompt behaviour, quality and cost.
The limitation is capability breadth. SiteHost’s own inference documentation warns that mid-sized models can be impressive but are not as capable as state-of-the-art offerings. Qwen 3.6 27B may fit summarisation, restructuring, classification, transcription workflows and grounded internal search; it should not be treated as a drop-in substitute for every premium closed model used for difficult coding, complex reasoning, high-stakes analysis or broad multilingual work.
The company has not published independent benchmarks, throughput figures, concurrency limits or service-level commitments for the platform in the material reviewed. A 262,000-token window is valuable for large documents, but SiteHost itself notes that longer contexts consume more tokens and increase response time. Buyers need to test the workload they actually intend to run, especially where multiple employees or automated jobs will share the service.
OpenAI compatibility lowers integration effort, not migration risk
For developers, SiteHost’s most immediately useful decision is to expose standard OpenAI-compatible inference endpoints, including/v1/chat/completions and the older /v1/completions route. Its documentation shows the official OpenAI Python package being pointed at SiteHost’s API base URL, while it also provides PHP and Python client libraries of its own.That should make a basic move relatively simple for applications already using a compatible chat-completions client. In many cases, the code change will amount to replacing the base URL, API key and model name. SiteHost also documents streaming responses, API-key restrictions by model, capability and IP address, plus per-key request-rate and cost limits.
The compatibility claim needs a practical qualification. An OpenAI-compatible request format does not make Qwen 3.6 27B operationally identical to an OpenAI model. Prompt instructions, structured-output behaviour, reasoning settings, safety behaviour, tool calling, vision handling and output quality can all vary. SiteHost’s embedding endpoint is explicitly described as only partially compatible with OpenAI and Cohere-style embedding requests.
The sensible migration path is therefore to move a non-critical workflow first, preserve its existing test set, and compare outputs and latency against the incumbent service. A software team should also test error handling and streaming under load before changing a production endpoint. The value here is interoperability with common tooling, not a promise of identical model behaviour.
The pricing model favours bursty internal workloads
According to IT Brief, SiteHost is charging from NZ$0.09 per million input tokens, rising to NZ$0.28 per million input tokens for Qwen 3.6 27B, with output pricing reaching NZ$2.76 per million tokens. The company is offering the service without an upfront fee or stated minimum spend.The headline input price should not obscure where an application’s bill is likely to accumulate. At the upper published rates, one million input tokens plus one million generated output tokens would cost NZ$3.04. Reasoning can materially increase output-token usage: SiteHost says a model’s internal reasoning process counts toward output tokens, even where a user expects only a short final answer.
That makes the service financially attractive for episodic jobs such as a back-catalogue of recorded meetings, a one-time document conversion project, or an internal search prototype that has unpredictable demand. It is less automatically compelling for an always-on customer-facing assistant that produces long responses at high volume. In that case, customers must measure their input-to-output ratio, context size, retries and reasoning use rather than comparing only a token-price headline.
SiteHost’s billing system records aggregate cost by API key and model in the control panel. More detailed usage information is retained on a per-key, per-hour basis for three months, after which only a total remains. This is operationally helpful for cost allocation and investigating spikes, but it is also the part of the service that remains stored after prompt content is discarded.
The cache detail deserves a direct answer from SiteHost
SiteHost’s documentation says raw request bodies are never traced or stored. Separately, its inference documentation explains that the input-processing stage places computed input blocks into a backend Key-Value vector cache, and that customers can reuse a session ID to remain on the same backend and benefit from that cache across requests.This is a normal performance technique for transformer inference. Reprocessing a long conversation or document from scratch is expensive; a Key-Value cache lets the model reuse prior computation. But the technical distinction matters: the cached representation is not a copy of the original prompt body, yet it is derived from that prompt and remains useful precisely because it represents earlier context.
SiteHost has not publicly stated how long those cached blocks remain available, whether they are cleared when a session ends, whether they are ever written beyond GPU or server memory, or whether customers can disable session reuse. Until it does, security teams should treat session pinning as an opt-in performance feature and ask for the cache lifecycle in writing before using it with sensitive prompts.
The launch gives New Zealand organisations a credible local API option for retrieval, summarisation and other bounded AI workloads, with useful compatibility and a model-stability commitment that many hosted AI services lack. Its strongest case is not that it matches every frontier model; it is that it offers a locally operated, controllable service for teams that need to keep their AI data path inside New Zealand and can validate Qwen 3.6 27B against the work they actually need done.
References
- Primary source: IT Brief New Zealand
Published: 2026-08-06T23:00:00+00:00
Loading…
itbrief.co.nz - Related coverage: kb.sitehost.nz
Loading…
kb.sitehost.nz - Related coverage: kb.sitehost.nz
Loading…
kb.sitehost.nz - Related coverage: sitehost.nz
Loading…
sitehost.nz - Related coverage: docs.sitehost.nz
Loading…
docs.sitehost.nz - Related coverage: sitehost.nz
Loading…
sitehost.nz - Related coverage: trustpilot.com
Loading…
www.trustpilot.com - Related coverage: cafca.org.nz
Loading…
www.cafca.org.nz - Related coverage: nzinitiative.org.nz
Loading…
www.nzinitiative.org.nz - Related coverage: privacy.org.nz
Loading…
www.privacy.org.nz