TensorFlow

TensorFlow is an open-source software platform for numerical computation and machine learning. It provides typed multidimensional arrays, operations implemented for different devices, mutable variables, automatic differentiation, graph execution, input pipelines, distributed execution, serialization, and deployment interfaces.^{[3][6][7][11][12][15][19]} TensorFlow is not a trained model, a dataset, a programming language, or a hosted cloud service. A TensorFlow program defines computations and state; its usefulness, accuracy, safety, and performance depend on the model, data, code, hardware, and operating environment supplied by its users.

Google released TensorFlow as open-source software in November 2015. It grew from work at Google Brain on DistBelief, an earlier distributed training system, but TensorFlow replaced DistBelief's neural-network-specific structure with a more general dataflow model.^[1][2] The original system could place a computation across CPUs, GPUs, and multiple machines, while exposing a common graph-based programming interface.^[3][4] TensorFlow 2.0, released in September 2019, made eager execution the default and integrated Keras as its principal high-level model API while retaining graphs through tf.function.^[5]

The core project remains on the TensorFlow 2 major-version line. At the research cutoff of July 28, 2026, the latest stable repository release was TensorFlow 2.21.0, released on March 6, 2026. Its official binary matrix supported Python 3.10 through 3.13; Python 3.9 support had been removed.^[23][24] Those details are release-specific, not permanent properties of TensorFlow, so installation and compatibility requirements should be checked against the documentation for the exact version and platform in use.

Scope and identity

TensorFlow Core is the runtime and programming system centered on tf.Tensor, operations, tf.Variable, differentiation, graph construction, device placement, distribution, and persistence.^{[3][4][6][7][11][15][19]} In ordinary use, the primary public interface is Python, backed by a substantial C++ runtime and device-specific kernels. Other language interfaces and companion projects have different API coverage and release schedules, so the existence of one TensorFlow operation in Python does not imply identical support in every binding or runtime.^[20]

The word "TensorFlow" is also used informally for a wider family of projects. That family includes Keras, TensorBoard, TensorFlow.js, LiteRT, TensorFlow Serving, and other libraries. They interoperate with TensorFlow Core in specific ways, but they are not interchangeable parts of one monolithic executable. For example, a Keras model can use TensorFlow as a backend, a SavedModel can expose functions to a serving process, and a compatible model can be converted for an on-device runtime. Each boundary introduces its own formats, supported operations, versions, and security assumptions.^{[17][19][27][28][29]}

Many TensorFlow APIs target deep learning and neural-network training, but the system is broader than those uses. Its primitive operations can express general differentiable numerical programs, stateful computations, data transformations, and inference workloads.^[2][3] Conversely, TensorFlow does not define the statistical meaning of a model or validate that its loss function, evaluation procedure, or deployment policy is appropriate.

Historical development

DistBelief was designed for large distributed neural-network training. Its 2012 primary paper described model parallelism, replicated training, asynchronous Downpour stochastic gradient descent, and distributed batch optimization across large compute clusters.^[1] Google's open-source launch record described DistBelief as tightly coupled to internal infrastructure and comparatively difficult to configure. TensorFlow was introduced as a second-generation system intended to be more general and portable.^[2]

The 2015 TensorFlow white paper described an interface in which a program constructs a directed dataflow graph. Nodes represent operations, edges carry tensors, and mutable state is represented explicitly. A client submits graph fragments for execution, while the runtime places operations on available devices and manages communication between them.^[3] The open-source release used the Apache License 2.0.^[2]

The 2016 OSDI system paper expanded the design account. It described graphs that represent computation, shared state, and mutations, with nodes placed across processes and heterogeneous devices. Unlike systems that built a fixed parameter-server abstraction into the runtime, TensorFlow allowed parameter management and update logic to be represented in the graph. The paper evaluated the system on workloads available at that time; its benchmark results document the 2016 implementation, not the performance of current TensorFlow releases.^[4]

TensorFlow 1.x generally asked Python users to construct a graph and then execute it through a session. This separation made deployment and whole-graph optimization possible, but it also made interactive debugging and data-dependent Python control flow difficult. TensorFlow Eager added immediate, define-by-run execution and tracing, producing a staged programming model that could move between imperative Python and graphs.^[8] TensorFlow 2.0 adopted eager execution by default, removed sessions from the normal workflow, and promoted tf.function, tf.Module, Keras, and SavedModel as central interfaces.^[5]

Later changes continued to move some previously bundled components across project boundaries. TensorFlow 2.16 made multi-backend Keras 3 the default implementation behind tf.keras and removed the Estimator API from TensorFlow Core.^[30] In 2024, Google renamed TensorFlow Lite to LiteRT and began moving its documentation and package identity toward a multi-framework on-device runtime.^[28] These changes are why code should be described against a specific TensorFlow, Keras, or companion-project version rather than against an assumed timeless ecosystem.

Core representation and state

A tensor is TensorFlow's basic value type. A regular tf.Tensor is a multidimensional array whose elements share one data type. Its rank is the number of axes, its shape records the length of each axis, and its size is the product of those lengths. Regular tensors are immutable: an operation produces another tensor rather than modifying a tensor's contents. TensorFlow also defines structured types for data that regular dense tensors do not represent efficiently, including sparse and ragged values.^[6]

Shape information can be partly static and partly known only during execution. Static shapes let APIs validate programs and let compilers specialize work before values are available. Dynamic dimensions allow a graph to accept inputs such as variable batch lengths.^[6][9] A function that is valid for one data type or shape is not necessarily valid for another, and many device kernels support only a subset of possible type and operation combinations.^[14]

tf.Variable is the standard representation for shared mutable state. A variable contains a tensor value that can be read and updated through operations such as assignment. Model parameters, optimizer accumulators, counters, and other persistent values are commonly variables. TensorFlow tracks variables attached to tf.Module and compatible higher-level objects, which supports checkpointing and export.^[7]

A computational graph contains operation nodes and tensor edges. An operation has a registered interface, such as input and output types and attributes, plus one or more kernels that implement it for particular devices or data types. State-changing operations make ordering and side effects part of the program, so a TensorFlow graph is not simply a static mathematical expression. Graphs also carry control dependencies, function definitions, device constraints, and metadata used by runtimes and serializers.^[3][4]

TensorFlow distinguishes the operation interface from its kernel. Two kernels may implement the same operation on a central processing unit and a graphics processing unit, while a third device may have no compatible kernel. This distinction helps explain both portability and portability failures: the graph can describe an operation independently of hardware, but execution still requires an available implementation for the chosen device, type, and build.^[3][14]

Execution modes and tracing

In eager execution, TensorFlow operations run as Python calls are evaluated and return concrete values. This mode supports ordinary control flow, interactive inspection, and conventional debuggers. Immediate execution is therefore useful during development, but it gives the runtime less opportunity to optimize a whole computation and incurs Python dispatch overhead for many small operations.^[8]

tf.function converts a Python callable that uses TensorFlow operations into a polymorphic graph function. On a call that cannot reuse an existing graph, TensorFlow traces the Python function and creates a specialized ConcreteFunction. Input data types, shapes, Python values, and other arguments can affect specialization. Later compatible calls reuse the graph rather than rerunning all Python code.^[9]

Tracing has observable consequences:^[9]

• Ordinary Python side effects run during tracing, not necessarily every time the graph executes.
• A Python value may be captured as a trace-time constant, while a tf.Tensor remains a graph input.
• New or incompatible argument signatures can cause retracing, adding latency and retaining additional graphs.
• Variables generally need to be created outside the repeatedly traced part of a function.
• Graph execution may omit operations that do not contribute to a returned value or another recognized side effect.

AutoGraph transforms a supported subset of Python control flow into TensorFlow graph operations. It lets tensor-dependent if statements and loops participate in a graph when their source is available and their constructs are supported. It is not a general compiler for arbitrary Python: external side effects, Python objects, iterators, exceptions, and dynamically generated code can behave differently or remain outside the graph.^[9][10]

The eager and graph paths are complementary rather than separate TensorFlow products. A typical program uses eager code to assemble modules and inspect values, tf.function to stage repeated compute-intensive steps, and serialized concrete functions for deployment. Correctness should be tested in the mode that will actually run in production because tracing, mutation, input signatures, and Python side effects can expose differences.^[8][9][19]

Automatic differentiation

TensorFlow provides automatic differentiation through tf.GradientTape. While a tape is active, it records differentiable TensorFlow operations involving watched values. Calling gradient then applies registered derivative rules to compute derivatives of a target with respect to selected sources. Trainable variables accessed inside a tape are watched by default; ordinary tensors can be watched explicitly.^[11]

For a scalar objective L, reverse-mode differentiation propagates an adjoint from each operation's outputs to its inputs. For an intermediate value x_i, one way to express the chain-rule accumulation is:^[11]

$$\bar{x}_i = \sum_{j \in \operatorname{succ}(i)} \bar{x}_j \frac{\partial x_j}{\partial x_i}, \qquad \bar{x}_i = \frac{\partial L}{\partial x_i}.$$

This process underlies backpropagation, but differentiation and parameter updating are separate. A tape computes derivatives; an optimizer uses them to update variables according to an algorithm such as gradient descent. TensorFlow does not guarantee that every operation is differentiable. Missing gradient registrations, integer-valued operations, discrete decisions, stopped gradients, disconnected paths, and numerical instability can all yield absent, zero, undefined, or unhelpful derivatives.^[11]

Tapes are normally consumed by one gradient calculation. Persistent tapes can support multiple calculations but retain more intermediate state until released. Nested tapes allow higher-order derivatives. Forward-mode accumulation is also available for cases where the number of inputs and outputs makes it suitable.^[11][33] Users still need to check derivative definitions, scaling, precision, clipping, and optimizer state for the problem at hand.

Input pipelines

tf.data represents input processing as a sequence of dataset sources and transformations. Sources can be created from in-memory tensors, files, generators, or other input systems. Transformations include mapping, filtering, shuffling, batching, caching, interleaving, repeating, and prefetching. A dataset is iterable in eager code and can feed Keras or custom training loops.^[12]

Input processing can dominate end-to-end training time even when accelerators execute the model quickly. The tf.data runtime can overlap preprocessing with model computation, parallelize reads and maps, interleave files, cache reusable work, and prefetch batches. Each optimization has constraints: caching consumes storage or memory, parallelism can reorder results, excessive concurrency can contend for resources, and prefetching cannot hide a producer that remains slower than its consumer.^[12][13]

Dataset cardinality and order are part of training semantics. Shuffling uses a bounded buffer, so it is not necessarily a uniform permutation of a dataset larger than that buffer. Repeating changes epoch boundaries unless the training loop specifies steps carefully. In distributed training, sharding policy determines which examples reach which workers. Stateful transformations and external generators can make restart and replay behavior hard to reproduce.^{[12][13][15][21]}

An input pipeline should therefore be measured separately from the model step. Useful checks include host utilization, accelerator idle time, file-read latency, transformation cost, batch shapes, element order, and the effect of caching or prefetching. A fast isolated kernel does not establish high application throughput if data delivery is the bottleneck.^[12][13]

Devices, compilation, and distribution

TensorFlow assigns operations to registered devices according to available kernels, explicit placement constraints, and runtime policy. If a compatible GPU kernel exists, an operation may be placed on a GPU; an operation without one may execute on the CPU. Transfers are needed when producer and consumer operations run on different devices, so more accelerator placement does not automatically mean faster execution.^[14]

Device support is build- and platform-specific. Official packages, drivers, compiler toolchains, accelerator libraries, and plugins must be mutually compatible. Custom operations add another application binary interface and kernel-coverage constraint. A program should inspect actual device visibility and placement rather than infer it from installed hardware.^[14][20][24]

XLA is a compiler for linear algebra used by multiple frameworks, including TensorFlow, JAX, and PyTorch. It originated inside TensorFlow and is now part of OpenXLA. For compatible TensorFlow functions, compilation can fuse operations, specialize shapes, reduce memory traffic, and generate device code. tf.function(jit_compile=True) is one interface for requesting compilation.^[16] Compilation has a setup cost, and unsupported operations, dynamic behavior, shape changes, or device limitations can prevent a function from compiling. Performance claims must include compilation and warm-up policy as well as steady-state execution.

For distributed training, tf.distribute.Strategy provides common interfaces for replicated, multi-worker, and parameter-server execution. Synchronous data-parallel strategies run model replicas on different devices, aggregate gradients or updates, and keep replicated variables aligned at defined synchronization points. In parameter-server training, a coordinator schedules functions on worker tasks, while parameter servers hold variables. Strategies differ in fault handling, consistency, communication, checkpoint coordination, and supported execution modes.^[15]

Distribution does not preserve efficiency automatically. Holding the per-replica batch size fixed while increasing replicas increases the global batch; holding the global batch fixed reduces each local batch. Collective communication, input imbalance, stragglers, coordinator overhead, host limits, and network topology can outweigh added compute. Numerical results can also differ because floating-point reductions occur in a different order. A distributed result should record strategy, replica count, global batch, hardware, interconnect, input sharding, failure policy, and timing method.^[15][21]

Tensor Processing Units have TensorFlow support through device runtimes and distribution strategies, but the existence of a TPU path does not mean that every TensorFlow operation or shape is efficient or supported there. The same limitation applies to GPUs and third-party devices. Kernel coverage, compiler support, precision, memory layout, and transfer cost remain workload-specific.^[14][15][16]

Model construction and the Keras boundary

TensorFlow Core can express a model directly with variables, functions, operations, tapes, and custom loops. Keras supplies a higher-level layer, model, loss, metric, optimizer, callback, training-loop, and serialization API. Since TensorFlow 2.16, Keras 3 is the default implementation used through tf.keras in supported installations.^[17][30]

Keras 3 is a multi-backend project. Code written only with its backend-neutral APIs can target TensorFlow, JAX, or PyTorch, subject to backend coverage and the behavior of custom components. Code that directly calls TensorFlow operations or depends on TensorFlow-specific objects is not automatically portable to another backend. Likewise, the statement that a model is "a Keras model" does not identify which backend executed it.^[17]

The boundary matters for saving and deployment. Keras has its own .keras model format. With Keras 3, exporting a TensorFlow SavedModel for serving is a distinct operation from saving a reloadable Keras model. A migration that changes TensorFlow or Keras versions must test custom layers, optimizer state, serialization, traced functions, and deployment consumers rather than assuming that the high-level object model is unchanged.^[17]

TensorFlow is also not limited to neural networks. Core operations can implement other numerical algorithms.^[2][3] The adjacent TensorFlow Decision Forests project supplies TensorFlow and Keras interfaces for training, running, and interpreting decision-forest models, but it remains outside this article's TensorFlow Core scope.^[31] An integration's existence does not make every algorithm part of TensorFlow Core.

Persistence and deployment interfaces

A training checkpoint stores variable values and object-tracking information needed to restore state. It normally does not contain a complete executable description of the computation. Restoring a checkpoint therefore requires compatible program structure and code that knows how to use those values.^[18]

A SavedModel contains a serialized TensorFlow program, variable values, and referenced assets. Named signatures expose concrete functions with specified tensor inputs and outputs. The on-disk directory can include a protocol-buffer model, a variables checkpoint, asset files, and a fingerprint. A SavedModel does not store arbitrary original Python source; it stores traced graph functions, so only the exported signatures and previously traced concrete functions are available after loading.^[19]

These formats serve different purposes:^{[17][18][19][28]}

Scroll sideways for more →

TensorFlow Serving is a separate model server that can load exported models and expose serving endpoints. A basic deployment uses SavedModel versions and a server process that watches an export path.^[29] Serving handles model loading and request execution, but production correctness also requires input validation, resource limits, authentication at the surrounding service boundary, monitoring, rollout policy, and rollback.

TensorFlow.js is a separate JavaScript machine-learning library for browsers and Node.js. It has JavaScript APIs, platform-specific backends, and conversion paths for some Python TensorFlow or Keras models.^[27] It should not be described as the full TensorFlow Python runtime running unchanged in a browser.

TensorFlow Lite, now LiteRT, is an on-device runtime and model format. Google announced the LiteRT name in September 2024 and retained the .tflite extension during the transition.^[28] The conversion tooling can accept SavedModel, Keras models, or concrete functions and write a .tflite FlatBuffer. Unsupported native operations may require selected TensorFlow operations, a custom operation, or a model change; quantization is an optional conversion technique rather than a universal requirement.^[35] A successful SavedModel export therefore does not guarantee successful or equivalent LiteRT conversion.

TensorBoard consumes logs and summaries to visualize metrics, graphs, profiles, embeddings, and other development data.^[32] It is an observability tool, not TensorFlow's training runtime. TensorFlow 2.21 removed TensorBoard as a required package dependency, so installations that need it must follow the release-specific packaging instructions.^[23]

These components may form part of an MLOps or model deployment system, but TensorFlow does not by itself provide data governance, experiment validity, artifact approval, online feature consistency, service authorization, drift policy, incident response, or regulatory compliance.^[19][22][29]

Versioning and compatibility

TensorFlow states that it mostly follows Semantic Versioning for its public API, with documented exceptions. Within a major release, compatible minor and patch updates are intended to preserve documented, nonexperimental public APIs, but numerical details, bugs, experimental symbols, error messages, distributed behavior, and some platform-dependent behavior can change. Private modules and implementation paths are not covered by the public API guarantee.^[20]

Compatibility has several layers:^[20]

• Source compatibility asks whether the same code imports and calls the same public symbols.
• Binary compatibility concerns compiled extensions and custom operations.
• GraphDef compatibility concerns serialized operation graphs and uses producer and consumer version metadata.
• SavedModel compatibility covers a broader exported program and its functions, variables, and assets.
• Numerical compatibility asks whether results remain within an application's required tolerance.
• Behavioral compatibility includes ordering, randomness, resource use, errors, and distributed coordination.

TensorFlow documents a SavedModel guarantee between adjacent major versions: a SavedModel supported in major version N can be loaded and executed in major version N + 1, provided it has not been modified in unsupported ways.^[20] This statement does not mean that every Python object, Keras optimizer, custom operation, or third-party package can be reconstructed across versions. GraphDef has separate compatibility rules, and a newer graph can contain operations that an older binary does not know.

TensorFlow 1 compatibility symbols remain available under tf.compat.v1 for many migrations, but running old graph-and-session code through that namespace does not turn it into idiomatic TensorFlow 2 code. Eager behavior, resource variables, control flow, equality, shapes, and object-based tracking differ.^[5][34] Long-lived systems should migrate and test intentionally instead of treating compatibility mode as a permanent proof of equivalence.

For release 2.21, official Python wheels covered Python 3.10-3.13 on listed platforms, with different CPU, GPU, operating-system, and architecture support.^[24] Platform support is narrower than the abstract TensorFlow API. An environment should pin the TensorFlow, Keras, Python, driver, compiler, accelerator-library, and custom-op versions needed to reproduce a build.

Security model

TensorFlow's security policy states that models are programs. Loading an untrusted GraphDef, SavedModel, or equivalent serialized computation should be treated as executing untrusted code. Such artifacts should run inside an appropriate sandbox, with filesystem, network, credential, device, and process privileges restricted.^[22]

Checkpoints are not executable graphs by themselves, but their values are still untrusted input. A program that uses a restored string or scalar to construct a file path, network target, allocation size, or command can turn a malicious checkpoint value into a security problem. Validation must occur at the application boundary as well as inside model code.^[22]

The built-in tf.train.Server is intended for internal distributed communication. The documented default server has no authorization protocol, sends messages without encryption, accepts network connections, and executes submitted graphs. It must not be exposed directly to an untrusted network.^[22] Authentication or transport security provided by a separate serving product should not be assumed to protect this lower-level server.

Input decoders and external libraries have different security histories. The set of formats that TensorFlow's policy considers suitable for untrusted input can change, so deployments should consult the versioned security document rather than copy an old allowlist. Keeping TensorFlow and parsing dependencies patched, limiting input size and complexity, and isolating risky decoders are separate controls.^[22]

Multi-tenant deployments require isolation for models, data, network access, accelerators, and resources. TensorFlow does not automatically create a security boundary between tenants that share one process or device. Resource exhaustion and accelerator side channels also require controls outside the model graph. The project directs vulnerability reports through Google Bug Hunters.^[22]

The security policy does not recommend eager execution for serving because of both performance and security-model considerations. More generally, converting eager code to a graph or SavedModel is not a sandbox. It changes the representation of the program, not the trustworthiness of its operations, custom kernels, assets, or inputs.^[22]

Reproducibility, performance, and operational limits

TensorFlow can request deterministic operation implementations with tf.config.experimental.enable_op_determinism, and its utility functions can set TensorFlow, Python, and NumPy random seeds. Determinism still requires the same hardware and software environment, deterministic input processing, controlled external concurrency, and the absence of nondeterministic custom operations. TensorFlow does not guarantee determinism across versions.^[21]

Deterministic kernels can be slower, sometimes substantially, because parallel algorithms often change reduction order. Seeds alone are insufficient: pseudorandom generator state, dataset order, worker count, asynchronous updates, compiler decisions, and hardware libraries all matter. A reproducibility record should include source revision, package lock, model configuration, data identity and order, preprocessing code, random seeds, device topology, driver and accelerator libraries, distribution strategy, precision policy, and checkpoint.^[21]

Floating-point arithmetic is not associative. Reordering a reduction across threads or replicas can change low-order bits, and those differences can compound during training. Mixed precision changes both range and rounding. Consequently, exact bitwise equality, numerical closeness, model-metric equivalence, and statistical reproducibility are different evaluation targets.^[20][21]

Performance is similarly conditional. Meaningful measurements should state:^{[12][13][14][15][16]}

• TensorFlow, Keras, compiler, driver, and device versions.
• Model and input shapes, data types, batch size, and precision policy.
• Eager, graph, and compilation settings.
• Warm-up and tracing treatment.
• Input-pipeline configuration and whether data is cached.
• Number of devices and workers, communication topology, and synchronization mode.
• Whether compilation, conversion, checkpointing, and data loading are included.

Common bottlenecks include Python dispatch in fine-grained eager code, repeated tracing, host-to-device copies, unsupported device kernels, small operations that do not saturate an accelerator, input stalls, collective communication, memory pressure, and serialization overhead. TensorFlow's graph and compiler facilities can address some of these costs, but no optimization is universal.^{[8][9][12][13][14][15][16]}

Operational correctness extends beyond successful execution. Production systems need shape and type validation, out-of-distribution handling, bounded resource use, artifact provenance, dependency patching, model rollout and rollback, observable errors, and application-level monitoring. TensorFlow supplies mechanisms used in those systems; it does not establish that a model is statistically valid, fair, private, robust, secure, or suitable for a particular decision.^[22][29]

Governance and licensing

TensorFlow's source is developed in public repositories. The contributor guide requires a Contributor License Agreement for code contributions and subjects features, fixes, and other changes to code review. It directs nontrivial design work through prior discussion and the project's documented Request for Comments process, with tests and API documentation expected for new features.^[25]

The core repository is distributed under the Apache License 2.0.^[26] That license applies to the repository content covered by it, not automatically to trained models, datasets, third-party dependencies, plugins, documentation, trademarks, or code in separate repositories. Users must inspect the license and notices attached to each artifact they redistribute or deploy. The repository license also provides software without warranties or conditions as specified in the license text.

Release tags, documentation pages, Keras, OpenXLA, LiteRT, TensorFlow.js, and TensorFlow Serving may move on different schedules. Governance and support should therefore be evaluated at the repository and release level. A statement about TensorFlow Core maintainers or compatibility does not automatically apply to every project carrying the TensorFlow name.^{[16][17][20][23][27][28][29]}

Related projects and boundaries

Scroll sideways for more →

Comparisons with JAX or PyTorch require a defined workload, version, backend, hardware, precision, compilation policy, and measurement method. Repository popularity, survey share, or a single benchmark does not establish general technical superiority. TensorFlow is best evaluated as a set of versioned interfaces and runtimes whose suitability depends on the program and deployment constraints.^{[16][17][20][21]}

References

1. ^Dean, Jeffrey, et al. "Large Scale Distributed Deep Networks." Advances in Neural Information Processing Systems 25, 2012. proceedings.neurips.cc/...823815f66102863-Abstract
2. ^Dean, Jeff, and Rajat Monga. "TensorFlow - Google's latest machine learning system, open sourced for everyone." Google Open Source Blog, November 10, 2015. opensource.googleblog.com/...oogles-latest-machine
3. ^Abadi, Martin, et al. "TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems." TensorFlow white paper, 2015. download.tensorflow.org/...whitepaper2015.pdf
4. ^Abadi, Martin, et al. "TensorFlow: A System for Large-Scale Machine Learning." 12th USENIX Symposium on Operating Systems Design and Implementation, 2016. usenix.org/...abadi
5. ^TensorFlow Team. "TensorFlow 2.0 is now available!" TensorFlow Blog, September 30, 2019. blog.tensorflow.org/...sorflow-20-is-now-available
6. ^TensorFlow. "Introduction to Tensors." TensorFlow Core Guide. tensorflow.org/...tensor
7. ^TensorFlow. "Introduction to Variables." TensorFlow Core Guide. tensorflow.org/...variable
8. ^Agrawal, Akshay, et al. "TensorFlow Eager: A Multi-Stage, Python-Embedded DSL for Machine Learning." Proceedings of Machine Learning and Systems 1, 2019. proceedings.mlsys.org/...f6f6e9ff8d14c87f-Abstract
9. ^TensorFlow. "Better performance with tf.function." TensorFlow Core Guide. tensorflow.org/...function
10. ^Moldovan, Dan, et al. "AutoGraph: Imperative-style Coding with Graph-based Performance." arXiv:1810.08061, 2018. arxiv.org/...1810.08061
11. ^TensorFlow. "Introduction to gradients and automatic differentiation." TensorFlow Core Guide. tensorflow.org/...autodiff
12. ^Murray, Derek G., Jiri Simsa, Ana Klimovic, and Ihor Indyk. "tf.data: A Machine Learning Data Processing Framework." Proceedings of the VLDB Endowment 14, no. 12, 2021. vldb.org/...p2945-klimovic.pdf
13. ^TensorFlow. "Better performance with the tf.data API." TensorFlow Core Guide. tensorflow.org/...data_performance
14. ^TensorFlow. "Use a GPU." TensorFlow Core Guide. tensorflow.org/...gpu
15. ^TensorFlow. "Distributed training with TensorFlow." TensorFlow Core Guide. tensorflow.org/...distributed_training
16. ^OpenXLA Project. "XLA architecture." OpenXLA documentation. openxla.org/...architecture
17. ^Keras Team. "Keras 3: Deep Learning for humans." Keras documentation. keras.io/keras_3
18. ^TensorFlow. "Training checkpoints." TensorFlow Core Guide. tensorflow.org/...checkpoint
19. ^TensorFlow. "Using the SavedModel format." TensorFlow Core Guide. tensorflow.org/...saved_model
20. ^TensorFlow. "TensorFlow version compatibility." TensorFlow Core Guide. tensorflow.org/...versions
21. ^TensorFlow. "tf.config.experimental.enable_op_determinism." TensorFlow Python API documentation. tensorflow.org/...enable_op_determinism
22. ^TensorFlow Project. "Using TensorFlow Securely." TensorFlow 2.21.0 security policy. raw.githubusercontent.com/...SECURITY.md
23. ^TensorFlow Project. "TensorFlow 2.21.0." GitHub Releases, March 6, 2026. github.com/...v2.21.0
24. ^TensorFlow. "Install TensorFlow with pip." TensorFlow installation guide. tensorflow.org/...pip
25. ^TensorFlow. "Contribute to the TensorFlow code." TensorFlow Contributor Guide. tensorflow.org/...code
26. ^TensorFlow Project. "Apache License 2.0." TensorFlow 2.21.0 repository license. github.com/...LICENSE
27. ^TensorFlow.js. "TensorFlow.js guide." TensorFlow documentation. tensorflow.org/...guide
28. ^Google AI Edge Team. "TensorFlow Lite is now LiteRT." Google Developers Blog, September 4, 2024. developers.googleblog.com/...ow-lite-is-now-litert
29. ^TensorFlow Serving. "Serving a TensorFlow Model." TensorFlow documentation. tensorflow.org/...serving_basic
30. ^TensorFlow Team. "What's new in TensorFlow 2.16." TensorFlow Blog, March 13, 2024. blog.tensorflow.org/...whats-new-in-tensorflow-216
31. ^TensorFlow. "TensorFlow Decision Forests." TensorFlow documentation. tensorflow.org/decision_forests
32. ^TensorFlow. "Get started with TensorBoard." TensorFlow documentation. tensorflow.org/...get_started
33. ^TensorFlow. "Advanced automatic differentiation." TensorFlow Core Guide. tensorflow.org/...advanced_autodiff
34. ^TensorFlow. "TensorFlow 1.x vs TensorFlow 2 - Behaviors and APIs." TensorFlow Core migration guide. tensorflow.org/...tf1_vs_tf2
35. ^Google AI Edge. "Convert TensorFlow models." LiteRT documentation. developers.google.com/...convert_tf