Chips & Supply · United States

SageMaker Inference now supports Multi-Instance GPU to maximize GPU utilization for model endpoints

Credited to AWS Machine Learning · aws.amazon.com · 4h ago

When you deploy a model to a GPU endpoint, the smallest unit of GPU you can request is one whole accelerator.

This constraint can cost you twice. First, you can’t host more models on an instance than it has accelerators. An ml.p4d.24xlarge has eight A100s, so it holds eight models, whether each one needs 40 GB or 14 GB. Second, and less obvious, it makes every deployment come down to a choice of which full GPU to deploy to. As your concurrency and prompt lengths grow, a full GPU on an older instance stops being enough, but a full GPU on a newer one is more than your model can use. You end up either under-served or paying for capability you never reach.

Today, Amazon SageMaker Inference supports GPU partitioning, which uses NVIDIA Multi-Instance GPU (MIG) to divide a physical GPU into independent partitions. Each partition receives a fixed share of the GPU’s compute units and a dedicated block of its memory, with isolation enforced in hardware. That changes both constraints: you can place a different model in each partition, and you can choose a fraction of a newer accelerator instead of a whole one of either generation.

This post covers both. The first part is the direct benefit: deploy more models than you have GPUs, with isolation between them. The second is the one customers ask about when the question turns to cost: how the granularity of partitioning helps you pick the right-sized unit, and what we measured when we did.

One thing to know before you read further: GPU partitioning works on endpoints that use inference components, the construct you use to deploy several models to one endpoint and set the compute each model gets. Partitioning builds directly on it. A partition is a resource a component asks for, in the same place it already asks for CPU and memory. If you haven’t used inference components, this post introduces them. Single-model endpoints, serverless endpoints, and heterogeneous instance pools cannot be partitioned.

What customers do today, and why each option falls short

If you have more models than accelerators, you have had three choices.

Run fewer, larger endpoints and batch harder – This raises utilization, but only when the models are interchangeable. A portfolio of fine-tuned variants or per-tenant models is not.

Use multi-model endpoints – These load and unload models from a shared GPU on demand, which fits sparse, bursty traffic. But models share the device without isolation, so a heavy request for one model affects the others. A model that isn’t loaded also pays a load penalty on first use.

Move to self-managed Kubernetes – This is where customers who need real GPU partitioning have gone. MIG works there, but you take on driver versioning, partition configuration, a device plugin, scheduling, and keeping it all consistent across a fleet. That’s a lot of work for a hardware capability your instances already have.

NVIDIA Multi-Instance GPU (MIG) splits one GPU into as many as seven instances, depending on the GPU. Each instance has its own compute, cache, memory and memory bandwidth. Because the split is in hardware rather than software, you get guarantees that other sharing methods can’t give:

Partitioning has boundaries worth knowing up front. The maximum number of partitions depends on the accelerator and never exceeds seven. MIG itself only allows a layout to change while its partitions are idle, and on SageMaker AI that means choosing a layout when you create the endpoint. A model that needs more than one GPU still needs whole devices. Within those boundaries, you get the isolation of separate GPUs without dedicating one to each model.

Partitioning without the platform work

Until now, getting MIG meant running the Kubernetes stack yourself. GPU partitioning on Amazon SageMaker AI removes that step: you pick a partition profile for your model, and SageMaker AI handles GPU configuration, placement and scaling. You get hardware-isolated GPU sharing on a managed endpoint, without having to run the platform underneath it.

Salesforce has been part of this work from the start, helping define the requirements and validating the initial implementation.

“NVIDIA MIG partitions a single GPU into multiple isolated instances, each with dedicated compute and memory resources. Salesforce sees this as an important capability because many inference workloads do not require an entire GPU. MIG would allow us to consolidate workloads safely, significantly improve GPU utilization, reduce inference costs, and maintain predictable performance and strong isolation. This capability would help us scale AI Inference more efficiently across different use cases. Salesforce has helped define requirements, validated the initial solution. We are now preparing to validate the solution with representative production workload and demonstrate strong customer demand with AWS. We believe MIG support would deliver meaningful technical and business value for enterprise customers.” — Richard Chang, Software Engineering Architect, Salesforce

How it works

GPU partitioning adds two optional fields to API calls you already make. There are no new API operations, no new resource types, and no new AWS Identity and Access Management (IAM) actions, and an endpoint that omits both fields behaves exactly as it does today.

AcceleratorPartitionLayouts goes on a production variant in CreateEndpointConfig and declares how each accelerator is divided:

An A100 has seven compute slices to divide. The preceding layout uses all seven, so each of the eight A100s on the p4d instance carries three partitions and the endpoint provides 24, eight of each type.

The carve applies uniformly. One layout entry describes how one accelerator is divided, and every accelerator on every instance in the variant is divided the same way. The list isn’t positional, so an entry doesn’t map to a specific GPU.

AcceleratorPartitionType goes on an inference component and selects which partition the model runs on:

Each component copy occupies one partition of the requested type. With eight partitions of each type on the instance, raising CopyCount places additional copies on free partitions. This is useful for a small model serving high concurrency, where a single process leaves the GPU waiting on requests.

NumberOfAcceleratorDevicesRequired is always 1 here. With a partition type set it means one partition rather than one accelerator. NumberOfCpuCoresRequired and MinMemoryRequiredInMb still describe host CPU and host memory, because GPU memory comes from the partition type.

Invocation doesn’t change. InvokeEndpoint addresses a model by inference component name, and the partition it occupies never appears in the request.

Partitioning happens while the endpoint is provisioned. When it reaches InService every accelerator is carved and the partitions are empty, which is a valid state as components land on them afterward. In our testing, carving accelerators added roughly 17 seconds to provisioning. The rest of the time is the usual instance launch and container pull.

Partition profiles by GPU

The profiles available to you are a property of the GPU, so start by finding out which GPU your instance type carries and look it up in NVIDIA’s supported MIG profiles, which is the authority on the full profile set and the combinations valid on one device.

P4d — NVIDIA A100; 40 GB; 7 / 8; mig-1g.5gb, mig-1g.10gb (see driver note), mig-2g.10gb, mig-3g.20gb, mig-4g.20gb, mig-7g.40gb; 7

P5 — NVIDIA H100; 80 GB; 7 / 8; mig-1g.10gb, mig-1g.20gb, mig-2g.20gb, mig-3g.40gb, mig-4g.40gb, mig-7g.80gb; 7

G7e — NVIDIA RTX PRO 6000 Blackwell Server Edition; 96 GB; 4 / 4; mig-1g.24gb, mig-2g.48gb, mig-4g.96gb; 4

Read the profile name as compute units followed by GPU memory: mig-3g.40gb takes three compute units and 40 GB. The granularity column is what limits a layout. An A100 and an H100 divide into sevenths on compute and eighths on memory, while G7 divides into halves and G7e into quarters. Profile names differ between GPUs even where the slice counts match, so don’t carry a layout from one instance family to another without checking it against this table.

Within those limits you have real choice. On a P4d or P5 you can carve seven of the smallest profile, or two 3g partitions, or the 4g plus 2g plus 1g layout used in the earlier example, or take the whole device as one. On a G7e you can take four of the smallest, or two 1g beside a 2g, or two 2g, or one whole device. On a G7, either two partitions or one.

The 3g profile is the one to know, because its two dimensions don’t match: it takes three of the seven compute units but four of the eight memory units. Two of them fill the GPU and nothing else will fit beside them.

The high-level rule: Every profile in your layout must be one your GPU offers, and the compute and memory units your profiles add up to must not exceed what one device provides. Both are checked when you create the endpoint configuration, and either one failing is a rejection rather than a fallback to a whole accelerator.

Driver note for P4d: mig-1g.10gb requires an R525 or newer NVIDIA driver, and the default P4d image ships 470.256.02. Request it on the default image and the carve fails without an error naming the profile. Set InferenceAmiVersion to al2023-ami-sagemaker-inference-gpu-4-1 on the production variant to get an image on the 580 driver line, which offers it.

Choosing a layout for your workload

Choosing well is a separate question from choosing a layout that is merely accepted. A partition hands you compute and memory in fixed proportions, and the two do different jobs during inference.

Compute units are what you need for prefill. Prefill reads the prompt and builds its representation. This is the compute-heavy phase, and it scales with the streaming multiprocessors, and so the TFLOPs, your partition holds. The longer your inputs and the more prompts arriving at once, the more it governs how quickly you return a first token.

Memory units are what you need for decode and for capacity. Generating tokens re-reads the model weights on every step, so decode is bounded by memory bandwidth rather than by math, and memory also caps how much KV cache you can hold. That cap in turn sets the context length you can serve and how many sequences you can serve concurrently.

Almost no real workload exercises only one of these, so the goal isn’t to pick a dimension but to choose a combination that supports your use case. Choose a profile whose proportions cover your heaviest phase while leaving the other adequately served. On the compute side, what matters is how long your prompts are and how many arrive at once. On the memory side, it’s your output length, your context window, and your concurrency.

Memory is the easier of the two to underestimate, because a partition has to hold three things and not just the model: the weights, which for an 8B model at FP16 are about 16 GB. The KV cache, sized for the context length and the number of concurrent sequences you intend to allow, which is the term people leave out and the one that grows with traffic. And 1–2 GB of runtime overhead for the CUDA context and the serving process. Add those up before choosing a profile, because a partition sized to the weights alone will load the model and then fail under load, or quietly serve a much shorter context than you configured. For a concrete reference point, that same 8B model at FP16 comfortably serves an 8,000-token context on a 40 GB partition.

Where MIG adds the most value

A portfolio of small and mid-size models – The direct case. Fine-tuned variants, embedding models, rerankers, and classifiers that each leave most of an accelerator unused now share one.

Multi-tenant model serving – When you host a model per customer, MIG gives you a hardware boundary between them: a process in one partition can’t read another partition’s memory or take its throughput. Scope the claim accurately, though. Models on the same instance still share host CPU, system memory, storage, networking, and endpoint routing, so partitioning is an isolation mechanism for the GPU and not a complete tenancy boundary.

Multi-stage pipelines on one instance – A transcription model, a diarization model, and a language model, or an embedder, a reranker, and a generator. Each stage is a separately addressable component on its own partition, and a network hop between stages disappears.

A small model in the request path – A safety classifier or guardrail model that has to run on every request but cannot justify an accelerator, with predictable latency because it isn’t time-slicing against the main model.

Challengers and canaries – Run a candidate model on a small partition beside the model serving production traffic instead of standing up a second endpoint.

Performance: A slice of a newer GPU against a whole older one

In addition to bin-packing, the other benefit you get is granularity on high-end GPUs: more GPU options to deploy a model onto, and the choice of which one is yours. Every supported accelerator becomes several sizes rather than one, so the practical way to think about it is that each profile is a GPU option in its own right, sitting alongside the whole accelerators you already choose between. That matters most when you are considering a larger or newer instance type, because moving up stops being all-or-nothing: you can take as much or as little of that bigger GPU as your workload needs, at any of the sizes it publishes, instead of paying for the whole accelerator.

To see whether that pays off, we compared one mig-3g.40gb partition of an H100 against one whole, uncarved A100-40GB. The two have comparable GPU memory, which makes it a clean way to see how powerful a slice of a more advanced instance can be.

We used genai-bench to generate load, driving both endpoints from the same client so the GPU is the only variable. Both sides ran Llama-3.1-8B-Instruct on production SageMaker real-time endpoints, one model replica each, with an identical container image, tokenizer, and client configuration. Both were invoked through the SageMaker AI native OpenAI-compatible route. We swept five traffic shapes, written D(input tokens, output tokens) and ranging from short prompts to long-context summarization, each across a concurrency ladder from 2 to 512.

Figure 1: Aggregate output tokens per second for one mig-3g.40gb partition of an H100 against one full A100-40GB, across five traffic shapes and a concurrency ladder from 2 to 512

Figure 2: Partition cost benefit per million output tokens against concurrency for the same five traffic shapes

Treat this as a case-by-case comparison, not a verdict. The useful mental model is to regard the available GPU fractions as GPU types in their own right. List them alongside whole accelerators, work out what your traffic actually demands of compute and of memory, and compare them on your own workload. For high-concurrency, long-input traffic the partition won on both performance and cost here. For short-input or low-concurrency workloads the whole A100 remained cheaper. Partitioning isn’t a one-size-fits-all answer. It gives you more sizes to choose from, so you can pick the one that fits your workload.

What to know before you commit to a layout

Partitioning changes the shape of an endpoint, and a few properties are worth understanding before you design one.

A component’s partition type is fixed for the life of that component. Moving a model to a different profile means creating a new component. Changing the endpoint’s carve means a new endpoint and a traffic migration, because updating an endpoint configuration doesn’t re-carve hosts that are already running. This makes partitioning a good fit for a stable portfolio and a poor one for a mix you reshuffle daily.

A requested profile has to exist in the endpoint’s layout. There is no fallback to a whole accelerator, so a component asking for a profile the variant didn’t declare is rejected.

Partitioning applies to real-time inference on inference component endpoints. Serverless endpoints and heterogeneous instance pools aren’t supported, and asynchronous invocation cannot address an inference component, so async workloads are out of scope.

You’re billed for the full GPU instance, as you are today. Partitioning raises how much of that instance you can use. It doesn’t change its hourly price.

Finally, a model that genuinely needs a full accelerator, or more than one, should keep having one. No partition spans accelerators.

Supported instances and Regions

GPU partitioning is available on the P4d, P5, G7, and G7e instance families. Support is at the family level, so smaller sizes within a family are covered.

It’s available in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland).

Instance availability varies by Region, so confirm that your chosen instance type is offered in your Region and that you have endpoint usage quota for it.

Getting started

To partition a GPU endpoint, work out the memory and compute each of your model’s needs, pick the profiles that fit, declare a layout on your endpoint configuration, and deploy each model as an inference component that requests a profile from that layout. Nothing about how you invoke your models changes.

For the API reference, the full profile tables for each instance family, and a step-by-step walkthrough, see GPU partitioning in the Amazon SageMaker AI Developer Guide.

To try it yourself, run the GPU partitioning sample notebook, which deploys several models onto partitions of a single GPU endpoint.

The broader change is worth keeping in mind as you plan capacity. Every supported accelerator is now several sizes rather than one. Whether a partition of a newer GPU or a whole accelerator of an older one is the right unit for a given model is no longer a question you need to answer by rounding up. It’s one you can measure.

About the authors

Shantanu Tripathi

Shantanu is a Software Development Engineer at AWS with experience in building large-scale AI/ML infrastructure. As a core engineer at Amazon SageMaker, he has worked on designing and optimizing scalable inference solutions for high-performance AI workloads. His broader experience spans distributed AI training libraries, Deep Learning Containers (DLCs), Deep Learning AMIs, and generative AI solutions. Outside of work, he enjoys theater and swimming.

Apoorva Chandra

Apoorva is a Product Manager on the Amazon SageMaker AI Inference team, where she focuses on the endpoint experience and hosting experience. She works with customers deploying generative AI models in production to make accelerated compute easier to obtain, more cost-efficient to run, and more predictable to operate. Outside of work, Apoorva enjoys hiking, exploring coffee shops, and spending time with friends.

Dmitry Soldatkin

Dmitry is a Worldwide Leader for Specialist Solutions Architecture, SageMaker Inference. In this role Dmitry is helping customers design, build and optimize generative AI and AI/ML solutions. Dmitry’s work covers a wide range of ML use cases, with a primary interest in generative AI, deep learning, and scaling ML across the enterprise. He has helped companies in many industries, including financial services, insurance, and telecommunications.

Chips & SupplyUnited States

IBM, AMD Mix Quantum and AI at U.S. National Lab

Credited to EE Times · eetimes.com7h ago

Useful

Alliance aims to accelerate the creation of scientifically relevant quantum computers by 2028 as part of the Department of Energy’s Quantum Genesis Mission. Leading quantum companies see error correction as a key step toward that goal.

IBM, AMD, and the U.S. Department of Energy (DoE)-funded Quantum Science Center (QSC) at Oak Ridge National Laboratory (ORNL) today announced a new quantum/AI platform to improve quantum error correction, an emerging focus for the industry.

Researchers are making advances in error correction, including early demonstrations that protect quantum information from noise. IBM claims quantum advantage using techniques with guaranteed correctness, showing that quantum computers integrated with classical computers can solve relevant problems better than classical systems alone. The partners aim to amp up progress by bringing more classical computing into the mix.

The project at the Oak Ridge laboratory co-locates IBM’s quantum computers, including the company’s most powerful quantum processor, the 120-qubit IBM Quantum Nighthawk, with ORNL’s Umbra HPC system, running AMD Instinct MI355X GPUs and 5th Gen AMD EPYC CPUs. AMD provides the classical computing foundation for research into error correction, decoding optimization, and software orchestration.

A quantum error is caused by disruptions to the delicate quantum state of a qubit, which operates near absolute zero. Qubits typically need temperatures between 10 and 20 millikelvin (–273.15°C or –459.67°F).

The co-designed platform under development at Oak Ridge in the U.S. state of Tennessee will let researchers evaluate how to knit together classical and quantum computing to advance quantum error correction. The effort supports the DOE’s Quantum Genesis Mission, which targets 100 logical qubits running 100,000 hard operations by late 2028. IBM said it has demonstrated experiments with up to 70 logical qubits and 438 hard operations. For the partners to reach the DoE target, they will need to achieve a roughly 230-fold increase in hard-operation count.

“Today, the question is how to accelerate and optimize error correction to build systems that scientists can use to tackle meaningful problems,” Jay Gambetta, IBM Research director, said in a press statement. “This new co-design platform for quantum error correction allows us to evaluate different approaches and determine the architectures, software, and workflows that will scale.”

Hard operations

In quantum computing, resource theory divides operations into easy (Clifford) and hard (non-Clifford) sets.

Non-Clifford operations are particularly resource-intensive in fault-tolerant quantum computing because they cannot generally be implemented as cheaply as Clifford operations and require additional error-correction resources, Seetharami Seelam, chief architect of Classical System Co-Design for Quantum-Centric Supercomputing at IBM, told EE Times.

All error-correcting codes admit instructions that are cheap to implement and others that are expensive. So, what is “hard” is a result of the choice of code on any given platform, Seelam noted.

The next era of computing will combine quantum computing with decades of innovation across the classical hardware and software ecosystem, AMD EVP Mark Papermaster said.

“We are advancing a holistic approach that integrates quantum processors, HPC, and AI,” Papermaster noted. “This co-design platform is an important step toward building the scalable, efficient computing infrastructure needed to make fault-tolerant quantum computing a reality.”

Solving quantum error-correction challenges is essential to making quantum computing a practical tool for scientific discovery, and that’s a priority for Oak Ridge National Laboratory, according to Travis Humble, director of the Quantum Science Center at ORNL.

Oak Ridge and AMD are partners in what was possibly the world’s first “exascale” computer.

Europe has led the concept of hybrid classical/quantum computing, as Czechia, France, Germany, Italy, Poland, Spain, the Netherlands, and Luxembourg are working to deploy on-site quantum computers that are integrated with classical supercomputing under the European High Performance Computing Joint Undertaking, the Center for Strategic & International Studies, a Washington, DC think tank, noted in a March 2026 report.

“IBM has been leading the way in developing quantum-centric supercomputing for several years, including a reference architecture for integrating quantum processors with CPUs and GPUs into HPC environments that has been used in deployments in both Europe and Japan,” Seelam said. “The ORNL collaboration represents an important next step in applying that approach in the U.S., bringing IBM quantum computers together with ORNL’s high-performance computing infrastructure and AMD CPUs and GPUs.”

Focus on error correction

Leading quantum computing companies see error correction as a critical step toward the first quantum applications that are scientifically and commercially relevant.

Through 2029, Quantinuum expects its Nexus quantum system to automate and simplify error correction, resource management, orchestration, and deployment, enabling developers to build and integrate increasingly capable applications at the logical level.

IBM and Quantinuum are among nine U.S. companies that got $2 billion from the administration of U.S. President Donald Trump to secure the nation’s quantum leadership.

Quantinuum’s Nexus system supports more than 200 organizations, a 45% increase this year, while total job submissions increased tenfold in the 12 months through August 2026 compared with the preceding 12-month period, the company said today in a press release.

“Quantum computers are on the brink of achieving fault tolerance at scale,” José Ignacio Latorre, director of Singapore’s Centre for Quantum Technologies, said in the press release. “It’s exciting: we are entering terra incognita for what we can compute. The new challenge is putting our high-level quantum algorithms into the right form to successfully run on error-corrected hardware. Developer platforms like Nexus help us bridge that gap between quantum algorithm design and deployment.”

IBM said Nighthawk’s high maximum circuit throughput and real-time pulse control enable researchers to test error-correction techniques. Researchers will compare what each technique requires in qubits, time, samples, and classical resources to learn where GPU accelerators, such as AMD’s nodes in the Umbra system, can help the most.

IBM said researchers can use the company’s quantum hardware to measure qubits mid-calculation and act on the results in real time, set the exact timing of the signals that protect qubits from noise, see exactly what the hardware ran, and work directly with raw measurement signals.

Solid partners

The new co-design platform for quantum error correction builds on IBM’s existing collaborations with ORNL and AMD.

Earlier this year, IBM and ORNL demonstrated how workloads running on quantum computers and ORNL’s Frontier supercomputer can simulate magnetic materials and calculate molecular configurations of promising materials for the production of fusion fuel.

IBM has been using AMD GPUs to accelerate the classical diagonalization step in sample-based quantum diagonalization (SQD), a key quantum-centric supercomputing workflow. Last year, the two companies demonstrated an algorithm that efficiently decodes quantum errors on AMD chips. IBM said the partners’ effort with error correction and HPC workflows may support IBM’s path to its Quantum Starling system, the company’s first fault-tolerant quantum computer

From Qubits to Workflows: Rethinking Quantum Computing

IBM Details Quantum, AI Developments in India

Quantum Roadmaps Are Finally Meeting Reality

Canada’s Quantum Sector Sets Sights on Commercialization

RELATED TOPICS: ERROR-CORRECTION SYSTEM, FAULT-TOLERANT QUANTUM COMPUTING, HYBRID QUANTUM COMPUTING, QUANTUM COMPUTING, SEMICONDUCTORS

COMPANIES: AMD, IBM QUANTUM, OAK RIDGE NATIONAL LABORATORY

Alan has worked as an electronics journalist in Asia for most of his career. In addition to EE Times, he has been a reporter and an editor for Bloomberg News and Dow Jones Newswires. He has lived for more than 30 years in Hong Kong and Taipei and has covered tech companies in the greater China region during that time.

Original · EE Times

Front

Chips & Supply · United States

BREIT deploys another $3.4bn into pre-leased QTS data-center developments

Credited to Rackline · Thomas Brennan of Rackline · sec.gov · 19h ago

Blackstone Real Estate Income Trust deployed another $3.4bn into pre-leased data-center developments in the third quarter, according to a Form 8-K that disclosed its third-quarter 2026 update. The capital went into projects at QTS, the data-center operating company in which BREIT holds a minority stake.

Unless otherwise noted, the figures are as of Sept. 30, 2026. BREIT said the third-quarter outlay brought year-to-date deployment into QTS developments to $9.1bn. The disclosure's marketing summary called that total "$9B+"; the $9.1bn figure appears in the accompanying footnote.

QTS leasing roughly doubled year over year in the third quarter, BREIT said, and trailing-twelve-month leasing reached the highest level in the company's history. Those leasing figures are attributed to Blackstone proprietary data. The update links the leasing pace to continued hyperscaler investment in digital infrastructure without naming tenants.

BREIT said QTS's $30bn development pipeline is pre-leased, in substantially all cases, to investment-grade technology companies on leases of 15 years or longer with annual rent escalators. The footnotes say the pipeline figure reflects total cost for committed projects as of Sept. 30, shown at 100% ownership, and that the leases are expected to generate stable cash flow upon completion.

QTS runs the data-center platform; BREIT is the capital vehicle. In 2021, BREIT and other Blackstone-managed vehicles formed a joint venture that acquired all outstanding common shares of QTS. As of Sept. 30, BREIT's ownership in QTS was 34.8%, and the QTS investment accounted for 29.0% of BREIT's real estate asset value. QTS operating and pipeline figures in the presentation are shown at 100% ownership.

BREIT cited a QTS land bank of 10,000 acres that it said is largely entitled and zoned. The trust said it is not investing in chips or servers and is instead putting capital into the long-lived physical infrastructure that supports that equipment.

Year to date through Sept. 30, BREIT said it sold about $7bn of non-core assets, including its remaining self-storage and manufactured-housing portfolios, and redeployed that capital into data centers and industrial real estate.

The Item 7.01 disclosure was furnished under Regulation FD and is not deemed filed for Section 18 of the Securities Exchange Act. BREIT also posted the full presentation on its website. The update shows BREIT still directing large incremental sums into pre-leased QTS developments that already represent 29.0% of its real estate asset value.