Scalable Implementation and Industry Practice

Introduction

Linear algebra is often introduced through vectors, matrices, eigenvalues, and linear transformations. In practical artificial intelligence and machine-learning systems, however, mathematical correctness is only the beginning. A model may be mathematically valid yet unusable because it exceeds available memory, transfers data inefficiently between devices, produces numerically unstable results, or cannot be reproduced and monitored in production.

Scalable implementation concerns the complete path from mathematical specification to reliable software. This includes choosing data representations, selecting libraries and hardware, exploiting parallelism, managing numerical precision, benchmarking realistically, and deciding whether to build a capability internally or purchase it from a vendor. The central engineering principle is that an implementation should be evaluated not only by its output, but also by its accuracy, latency, throughput, memory use, energy consumption, reproducibility, maintainability, and total cost.

This chapter connects linear algebra with contemporary computational practice. It focuses on dense and sparse workloads, CPUs and accelerators, distributed computation, numerical precision, benchmarking, deployment, governance, and strategic decision-making.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain how mathematical operations are mapped to software libraries and hardware.

2. Select suitable dense, sparse, batched, and distributed representations.

3. Analyze memory, computational complexity, bandwidth, and precision trade-offs.

4. Design reliable and reproducible linear-algebra experiments.

5. Construct meaningful benchmarks and interpret their results.

6. Evaluate deployment cost and reason about build-versus-buy decisions.

7. Identify operational, ethical, security, and governance risks in production systems.

From Mathematical Operation to Production Kernel

A mathematical expression such as

y = Ax

does not uniquely determine an implementation. Here, A is an m × n matrix, x is an n-dimensional vector, and y is an m-dimensional vector. The same operation may be implemented using a general-purpose CPU library, a GPU kernel, a sparse matrix routine, a distributed system, or a specialized accelerator.

A useful implementation chain is:

1. Mathematical specification: define the operation and its required accuracy.

2. Data representation: choose data types, layout, and whether the data are dense or sparse.

3. Algorithm: select an algorithm such as matrix multiplication, QR factorization, or iterative solution of a linear system.

4. Library primitive: map the algorithm to a tested routine, such as BLAS, LAPACK, vendor GPU libraries, or a machine-learning framework.

5. Execution platform: select CPU, GPU, TPU, FPGA, or distributed infrastructure.

6. Operational wrapper: add validation, logging, monitoring, error handling, and resource controls.

The use of a high-level framework does not remove these decisions. A call such as a matrix multiplication may invoke different kernels depending on matrix dimensions, data type, memory layout, device, and library version.

Standard Computational Libraries

The Basic Linear Algebra Subprograms (BLAS) provide standard interfaces for common operations. Level 1 operations involve vector-vector calculations, Level 2 operations involve matrix-vector calculations, and Level 3 operations involve matrix-matrix calculations. Level 3 operations usually offer the greatest opportunity for hardware utilization because they perform many arithmetic operations while reusing data in fast memory.

LAPACK builds higher-level numerical algorithms using BLAS. It provides routines for factorizations, least-squares problems, eigenvalue problems, and singular value decompositions. Modern implementations commonly rely on optimized vendor libraries, such as Intel oneMKL, AMD AOCL, NVIDIA cuBLAS, or equivalent open-source implementations.

Python libraries such as NumPy and SciPy provide convenient interfaces, while frameworks such as PyTorch and JAX support automatic differentiation, accelerator execution, and compilation. The mathematical result should remain the reference point: a framework call is an implementation choice, not a new mathematical definition.

Complexity, Memory, and Data Movement

For multiplying an m × k matrix by a k × n matrix using the conventional dense algorithm, the approximate arithmetic work is 2mkn floating-point operations (flops): mkn multiplications and mkn additions. This count describes computational work, not elapsed time.

For a square n × n matrix, conventional multiplication therefore requires approximately 2n³ flops and stores approximately n² elements per matrix. If each element occupies b bytes, one matrix requires b n² bytes of storage. Three such matrices require approximately 3bn² bytes, excluding temporary buffers and metadata.

For example, three 10,000 × 10,000 matrices in 32-bit floating point require:

3 × 10,000² × 4 bytes = 1,200,000,000 bytes,

or approximately 1.2 GB using decimal units. In practice, additional workspace and copies may make the actual requirement substantially larger.

Arithmetic Intensity and the Memory Wall

Arithmetic intensity is commonly defined as

arithmetic intensity = arithmetic operations / bytes moved.

It is measured in flops per byte. A high arithmetic intensity means that computation may be the limiting resource; a low arithmetic intensity means that memory bandwidth or data movement may dominate. This distinction explains why a theoretically powerful accelerator may perform poorly on a small or poorly organized operation.

The roofline model provides a conceptual bound:

performance ≤ min(peak compute performance, memory bandwidth × arithmetic intensity).

The units must be consistent. If peak compute performance is measured in gigaflops per second and bandwidth in gigabytes per second, arithmetic intensity must be expressed in flops per byte, with appropriate decimal or binary conventions.

The model is an upper-bound framework, not a guarantee. Synchronization, instruction overhead, cache effects, kernel-launch costs, communication, and imperfect utilization can reduce actual performance.

Memory Layout and Batching

Matrices may be stored in row-major or column-major order. A mismatch between the storage layout expected by an algorithm and the actual layout can cause strided access or hidden copies. Contiguous access generally improves cache behavior and device memory coalescing.

Batching combines many small operations into a larger operation. For example, multiplying a batch of vectors by the same matrix can reduce function-call overhead and improve accelerator utilization. Batching may increase throughput but also increase latency and memory consumption. In online services, micro-batching must therefore be tuned against service-level latency requirements.

Dense and Sparse Linear Algebra

Dense representations store every matrix element, including zeros. They are appropriate when most elements are nonzero or when regular memory access and highly optimized matrix multiplication are important.

Sparse representations store only nonzero values and structural information. Common formats include:

• COO: stores row indices, column indices, and values; useful for construction.
• CSR: stores values, column indices, and row pointers; effective for sparse matrix-vector multiplication.
• CSC: stores values, row indices, and column pointers; useful for column-oriented operations.
• ELL or blocked formats: can improve regularity on accelerators when nonzero patterns are predictable.

For a sparse matrix with nnz nonzero entries, sparse matrix-vector multiplication usually requires work proportional to nnz, rather than mn for an m × n dense matrix. However, the practical benefit depends on sparsity, index-storage overhead, access irregularity, and hardware support.

Suppose a 1,000,000 × 1,000,000 matrix contains 10,000,000 nonzero values. A dense 32-bit representation would require approximately 4 × 10¹² bytes, or 4 TB, before considering other arrays. A CSR representation with 32-bit values and 32-bit column indices requires approximately 8 × 10⁷ bytes for values and column indices, plus roughly 4,000,004 bytes for row pointers: about 84 MB before alignment and implementation overhead. This illustrates why sparse storage is essential for genuinely sparse problems.

Sparsity is not automatically beneficial. A matrix with 70 percent zeros may still perform better in dense form if the sparse format causes irregular memory access and the hardware has strong dense-matrix support. The decision should be benchmarked using the actual matrix pattern and operation.

CPUs, GPUs, and Other Accelerators

CPUs are flexible and effective for branching, irregular workloads, small problems, and latency-sensitive operations. They provide large caches and sophisticated control logic.

GPUs contain many arithmetic units and high memory bandwidth. They are effective for large, regular, parallel operations such as dense matrix multiplication, convolution, and batched factorizations. Their performance can be poor when workloads are too small, highly sequential, irregular, or dominated by host-device transfers.

Specialized accelerators may provide high efficiency for particular tensor operations, but they can impose constraints on supported data types, layouts, operators, or software environments. Accelerator selection should therefore consider the entire workload, not only peak theoretical throughput.

A practical decision sequence is:

1. Determine the dominant operation and matrix dimensions.

2. Estimate memory capacity and bandwidth requirements.

3. Identify latency, throughput, and accuracy targets.

4. Measure transfer and initialization overhead.

5. Benchmark representative workloads on candidate platforms.

6. Include software maturity, availability, energy, and cost.

Numerical Precision and Stability

Floating-point numbers approximate real numbers. A common model is

fl(x) = x(1 + δ), where |δ| ≤ u,

provided the result is normal and the operation does not overflow or underflow. Here, fl(x) is the computed representation, δ is a relative error, and u is the unit roundoff for the relevant format. The exact value of u depends on the format and rounding convention.

Common formats include FP64, FP32, FP16, bfloat16, and integer formats. Lower precision generally reduces memory and can increase throughput, but it reduces the range or resolution of representable values. bfloat16 has a wider exponent range than IEEE half precision but fewer fraction bits; FP16 generally offers more fraction bits than bfloat16 but a narrower exponent range. Exact behavior depends on hardware and software implementation.

Conditioning and Stability

The condition number measures sensitivity of a problem to perturbations. For an invertible matrix A in a chosen norm,

κ(A) = ||A|| ||A⁻¹||.

A large condition number means that small input errors may produce large output errors. This is a property of the mathematical problem. Numerical stability, by contrast, concerns how much additional error is introduced by the algorithm.

For this reason, explicitly computing A⁻¹ is usually inferior to solving Ax = b using a factorization or specialized solver. If A is nonsingular, LU factorization with pivoting may be used; if A is symmetric positive definite, Cholesky factorization is often appropriate; if least-squares stability is important, QR factorization is generally preferable to forming AᵀA, because forming the normal equations squares the condition number in the 2-norm relationship κ₂(AᵀA) = κ₂(A)².

Mixed Precision

Mixed-precision computation performs selected operations in lower precision while retaining higher precision for accumulation, scaling, factorization corrections, or final evaluation. It can provide substantial speed and memory benefits, but it requires validation.

Good practice includes:

• scaling inputs where appropriate;
• accumulating dot products in a wider format when supported;
• monitoring overflow, underflow, NaN, and infinity values;
• comparing against a higher-precision reference;
• testing worst-case, not only average-case, inputs;
• specifying acceptable error in application terms.

A numerically small error may be unacceptable in a safety-critical application, while a larger error may be harmless in a ranking system. Precision requirements must therefore be linked to consequences.

Distributed Linear Algebra

When a matrix or workload exceeds one device, data and computation can be distributed across multiple machines. Common decompositions include row-wise, column-wise, and two-dimensional block distributions. In a two-dimensional block distribution, a matrix is partitioned into rectangular blocks assigned to a process grid.

Distributed computation introduces communication. A simplified performance model for a message is

T_message = α + βs,

where α is latency, β is time per transmitted byte, and s is message size in bytes. A complete algorithm may involve many messages, synchronization points, and reductions. Consequently, reducing arithmetic work does not necessarily reduce total runtime if it increases communication.

Distributed matrix multiplication, factorization, and iterative methods must consider:

• partition balance;
• network bandwidth and latency;
• synchronization frequency;
• fault tolerance;
• data locality;
• checkpointing and recovery;
• consistency of results across processes.

Distributed systems are justified when the problem size or throughput requirement exceeds a single device, not merely because distributed infrastructure is available. A small workload can become slower and more expensive after serialization, network transfer, and orchestration overhead are included.

Reproducibility and Reliability

Reproducibility means that an experiment or service can be rerun under documented conditions and produce equivalent results within defined tolerances. Bitwise identity is stronger than numerical equivalence and may not be possible across hardware, parallel execution orders, compiler versions, or library implementations.

A reproducible linear-algebra workflow records:

• source-code version and dependency versions;
• operating system, compiler, drivers, and accelerator information;
• matrix dimensions, sparsity pattern, data distribution, and data-generation method;
• random seeds and random-number algorithms;
• precision, scaling, and solver settings;
• thread counts, process topology, and environment variables;
• timing methodology and warm-up procedure;
• correctness tolerances and reference outputs.

Parallel reductions may produce slightly different rounding because addition is not associative in floating-point arithmetic. A reliable test should therefore use tolerance-based comparisons. For vectors x and y, a common criterion is

||x − y|| ≤ atol + rtol ||y||,

where atol is an absolute tolerance, rtol is a relative tolerance, and the norm is explicitly specified. The tolerances should be justified by the data scale and application requirements rather than chosen merely to make tests pass.

Reliability also requires input validation, detection of invalid dimensions, controlled handling of missing or infinite values, resource limits, graceful failure, and observability.

Benchmarking as an Experimental Discipline

Benchmarking is an experiment, not a single timing command. A credible benchmark defines the workload, metric, environment, and method before measurement.

Important metrics include:

• Latency: time for one request or operation.
• Throughput: operations, samples, or bytes processed per unit time.
• Memory footprint: peak and steady-state memory use.
• Energy efficiency: work completed per unit of energy.
• Accuracy: error relative to a reference or task-level metric.
• Cost efficiency: useful work per monetary unit.

A simple throughput calculation is

throughput = completed work / elapsed time.

The units of completed work must be stated, such as requests per second or examples per second.

A sound benchmark should warm up the system, separate initialization from steady-state execution, repeat measurements, report variability, and use representative dimensions and sparsity patterns. Median latency is useful for typical behavior, while high percentiles such as p95 or p99 reveal tail performance. Results should state whether data-transfer time, compilation, allocation, and synchronization are included.

Benchmarking only a favorable matrix size is a common error. Performance should be measured across small, medium, and large workloads, because the optimal implementation may change with scale. Correctness must be checked alongside speed; an incorrect fast result is a failed implementation.

Deployment Cost and Capacity Planning

Deployment cost includes more than hardware purchase. Relevant components include:

• compute instances or accelerator time;
• storage and data transfer;
• software licenses and support;
• engineering and maintenance labor;
• monitoring, security, and compliance;
• energy and cooling;
• downtime and failure recovery;
• migration and retirement costs.

A simple total-cost model over a planning period is

TCO = acquisition cost + operating cost + labor cost + software cost + risk and transition cost.

This is an accounting model rather than a physical law. Each component should be defined consistently, and the time horizon should be stated. Cloud pricing may depend on reserved capacity, on-demand usage, minimum commitments, egress, and idle resources.

Capacity planning should use demand distributions rather than only average demand. A system designed for average load may fail during peaks, while a system sized permanently for the maximum may be uneconomical. Queueing, batching, autoscaling, and graceful degradation can improve utilization, but each introduces additional complexity.

Build-versus-Buy Decisions

A build-versus-buy decision compares internal implementation with purchasing, licensing, or consuming a managed service. The relevant question is not “Can the organization build it?” but “Which option produces the required capability at acceptable cost, risk, control, and time?”

A decision framework should examine:

1. Strategic differentiation: Is the capability central to competitive advantage?

2. Performance requirements: Are latency, throughput, precision, or hardware constraints unusual?

3. Data sensitivity: Can data be sent to an external provider?

4. Integration: How well does each option fit existing systems?

5. Total cost: Include development, operations, licenses, migration, and exit costs.

6. Vendor risk: Consider continuity, pricing changes, service limits, and lock-in.

7. Capability and staffing: Does the organization possess the required expertise?

8. Compliance and auditability: Can the solution meet regulatory and governance requirements?

A hybrid strategy is often sensible: use mature libraries and managed infrastructure for commodity capabilities while building only the components that provide meaningful differentiation or control. Open-source software is not cost-free; maintenance, security review, integration, and skilled labor remain responsibilities of the adopter.

Illustrative Case: Scaling a Recommendation Embedding Service

Background

A fictional online retailer uses a recommendation system that represents products and users as 768-dimensional vectors. Each request compares a user vector with a large collection of product vectors and returns the most similar items. The initial implementation stores vectors densely in FP32 on a CPU server.

Problem

The service meets accuracy requirements but has high latency during peak traffic. Memory usage is also increasing as the product catalogue grows. The engineering team must decide whether to optimize the existing service, purchase a managed vector-search service, or redesign the computation using accelerators and reduced precision.

Analysis

Each product vector requires

768 × 4 = 3,072 bytes

in FP32, excluding metadata and indexing structures. For 10,000,000 products, vector storage alone is approximately

10,000,000 × 3,072 = 30,720,000,000 bytes,

or about 30.72 GB in decimal units. Replicas, indexes, and working memory increase the practical requirement.

The team measures four alternatives using the same catalogue sample, request distribution, accuracy metric, and warmed-up protocol:

• optimized CPU implementation with cached data;
• GPU implementation with batched queries;
• FP16 storage with higher-precision accumulation where supported;
• managed external vector-search service.

The GPU option improves throughput but performs poorly for single requests because transfer and launch overhead dominate. Micro-batching improves throughput, but p99 latency violates the service target. FP16 reduces vector storage approximately by half, but the team validates that ranking quality remains within the agreed tolerance. The managed service offers rapid deployment but introduces recurring cost, data-transfer charges, and vendor dependency.

Approach and Solution

The organization chooses a hybrid design. Frequently accessed product vectors remain in a local, optimized index. Less frequently accessed data are served by the managed service. The local system uses reduced-precision storage, periodic higher-precision validation, and a CPU fallback for degraded accelerator availability. Monitoring records latency percentiles, memory utilization, ranking quality, error rates, and cost per thousand requests.

Outcome

The redesigned system satisfies the p99 latency target for normal traffic, reduces memory pressure, and preserves recommendation quality within the defined tolerance. The managed service is retained for overflow traffic rather than used for every request. This arrangement reduces operational risk while preserving an exit path.

Learning Points

The case demonstrates that the fastest kernel is not always the best system design. Data movement, batching, precision, service-level objectives, cost, and vendor risk must be evaluated together. It also shows why benchmark conditions must reflect production request patterns rather than only maximum theoretical throughput.

Challenges, Governance, and Ethical Considerations

Scalable numerical systems can fail in ways that are not visible through average accuracy. Silent precision degradation, biased data, undocumented vendor changes, and inadequate monitoring can affect users and organizations.

Important governance practices include:

• documenting data provenance and permitted uses;
• protecting sensitive vectors and embeddings, which may reveal user attributes;
• applying access control, encryption, retention limits, and deletion procedures;
• auditing third-party services and software dependencies;
• recording model, library, and hardware versions;
• testing for subgroup performance differences where outputs affect people;
• maintaining rollback and incident-response procedures;
• making service limitations and uncertainty visible to decision-makers.

Regulatory obligations vary by jurisdiction and application. Systems used in finance, healthcare, employment, education, or critical infrastructure may require stronger validation, traceability, security, and human oversight. Technical scalability does not justify processing data without lawful purpose or adequate protection.

Contemporary Directions and Best Practices

Current practice increasingly combines compiler optimization, automatic kernel selection, quantization, structured sparsity, accelerator-aware libraries, and containerized deployment. These developments can improve efficiency, but abstraction layers may conceal memory copies or precision changes. Engineers should inspect generated operations and profile real execution.

Recommended practices are:

1. Begin with a clear correctness reference implementation.

2. Measure before optimizing.

3. Use established numerical libraries rather than rewriting mature kernels without justification.

4. Choose dense or sparse formats from measured structure, not assumption.

5. Treat data movement as a first-class performance cost.

6. Validate reduced precision against task-level requirements.

7. Benchmark representative workloads and report variability.

8. Pin and record software, hardware, and configuration versions.

9. Separate offline throughput objectives from online latency objectives.

10. Include operational, security, energy, and total-cost considerations.

11. Design fallback, monitoring, and rollback mechanisms.

12. Reassess build-versus-buy decisions as scale, regulation, and vendor conditions change.

Chapter Summary

Scalable linear algebra translates mathematical operations into data representations, algorithms, libraries, hardware kernels, and operational systems. Dense methods provide regular, highly optimized computation, while sparse formats can reduce storage and work when sparsity is substantial and exploitable. CPUs, GPUs, and specialized accelerators differ in their strengths, and data movement often determines performance more than arithmetic count.

Memory capacity, bandwidth, arithmetic intensity, precision, conditioning, and numerical stability must be considered together. Mixed precision can reduce cost and increase speed, but only when supported by systematic validation. Distributed computation enables large workloads while introducing communication, synchronization, fault-tolerance, and reproducibility challenges.

Reliable benchmarking requires representative workloads, warm-up, repeated measurements, correctness checks, and explicit reporting of latency, throughput, memory, accuracy, and cost. Deployment decisions should include total cost of ownership, operational risk, governance, and vendor dependency. Build-versus-buy analysis is strategic: commodity capabilities may be purchased or reused, while differentiated or sensitive capabilities may justify internal development. Effective industry practice combines mathematical discipline, systems measurement, numerical awareness, and responsible governance.

Key Terms

Arithmetic intensity: The ratio of arithmetic operations to bytes moved.

BLAS: Standard interfaces for basic vector and matrix operations.

Condition number: A measure of a problem’s sensitivity to input perturbations.

CSR: Compressed Sparse Row matrix storage format.

Dense matrix: A matrix stored with all elements, including zeros.

Distributed linear algebra: Computation partitioned across multiple processes or machines.

Flop: A floating-point arithmetic operation.

GPU: A massively parallel processor suited to regular numerical workloads.

Latency: Time required to complete an operation or request.

LAPACK: A library of numerical linear-algebra algorithms built around BLAS.

Memory bandwidth: Rate at which data can be transferred between memory and processors.

Mixed precision: Use of different numerical precisions within one computation.

Numerical stability: The degree to which an algorithm avoids introducing excessive computational error.

Roofline model: A performance-bound model based on compute capacity and memory bandwidth.

Sparse matrix: A matrix containing many zero elements and represented by its nonzeros.

Throughput: Amount of useful work completed per unit time.

Total cost of ownership: Acquisition, operating, labor, software, transition, and risk costs over a stated period.

Unit roundoff: A bound associated with relative floating-point rounding error.

Review Questions

Short Answer Questions

1. Why can a mathematically efficient algorithm still perform poorly in production?

2. Distinguish dense and sparse matrix representations.

3. What is arithmetic intensity, and why is it useful?

4. Why is solving Ax = b generally preferable to explicitly computing A⁻¹?

5. Name four elements that should be recorded for reproducible experiments.

Long Answer Questions

1. Explain how matrix dimensions, memory layout, batching, and data movement affect accelerator performance.

2. Compare CPU, GPU, and distributed implementations for a large matrix multiplication workload.

3. Discuss the benefits and risks of mixed-precision linear algebra.

4. Describe a rigorous benchmarking methodology for an online linear-algebra service.

5. Explain the major factors in a build-versus-buy decision for an AI infrastructure capability.

Analytical / Application Questions

1. A 5,000 × 5,000 matrix is stored in FP32. Calculate the storage required for one copy and explain whether sparse storage is automatically preferable if 60 percent of its entries are zero.

2. A system has a 400 GB/s memory bandwidth and a kernel with arithmetic intensity of 2 flops/byte. Estimate its memory-bound performance ceiling and state the assumptions behind the estimate.

3. Design an evaluation plan for choosing between a local GPU service and a managed external service for vector search. Specify workload, accuracy, latency, cost, governance, and fallback measurements.

Multiple Choice Questions with Answers

Question 1

Which workload is generally best suited to a highly optimized dense matrix-multiplication kernel on a GPU?

A. A large, regular batch of matrices with substantial arithmetic reuse

B. A single tiny operation with irregular branching

C. A workload dominated by network synchronization

D. A sequential algorithm with no parallel subproblems

Correct Answer: A. A large, regular batch of matrices with substantial arithmetic reuse

Question 2

What does arithmetic intensity measure?

A. Memory capacity divided by processor frequency

B. Arithmetic operations divided by bytes moved

C. Latency divided by throughput

D. Number of matrix rows divided by columns

Correct Answer: B. Arithmetic operations divided by bytes moved

Question 3

For an m × k matrix multiplied by a k × n matrix, the conventional dense algorithm performs approximately how many floating-point operations?

A. mn

B. mk + kn

C. 2mkn

D. m + k + n

Correct Answer: C. 2mkn

Question 4

Which format is commonly effective for sparse matrix-vector multiplication when data are organized by rows?

A. CSR

B. RGB

C. FIFO

D. Dense row padding only

Correct Answer: A. CSR

Question 5

What is a major numerical risk of forming the normal equations for a least-squares problem?

A. They always require sparse storage

B. They square the condition number relationship

C. They eliminate all rounding error

D. They cannot use matrix multiplication

Correct Answer: B. They square the condition number relationship

Question 6

In the message-time model T_message = α + βs, what does α represent?

A. Message size

B. Bandwidth

C. Communication latency

D. Floating-point precision

Correct Answer: C. Communication latency

Question 7

Which practice most directly improves reproducibility?

A. Reporting only the fastest timing

B. Changing library versions between runs

C. Recording software, hardware, seeds, and configuration

D. Ignoring numerical tolerances

Correct Answer: C. Recording software, hardware, seeds, and configuration

Question 8

A benchmark’s p99 latency primarily describes:

A. The average arithmetic intensity

B. The slow-tail behavior of requests

C. The total memory capacity

D. The number of nonzero entries

Correct Answer: B. The slow-tail behavior of requests

Question 9

Which factor is least appropriate to ignore in a build-versus-buy analysis?

A. Vendor lock-in and exit costs

B. Only the initial purchase price

C. Data sensitivity and compliance

D. Internal maintenance capability

Correct Answer: B. Only the initial purchase price

Question 10

A 768-dimensional FP32 vector requires how much storage for its values alone?

A. 768 bytes

B. 1,536 bytes

C. 3,072 bytes

D. 6,144 bytes

Correct Answer: C. 3,072 bytes