From 1e5f986f1fedc1d718fc53d2458a036daea2dd40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Adam=20Wysoki=C5=84ski?=
 <42808557+AdamWysokinski@users.noreply.github.com>
Date: Thu, 5 Dec 2024 00:24:52 +0100
Subject: [PATCH] Update gpu.md

typos fixed
---
 docs/src/guide/gpu.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/src/guide/gpu.md b/docs/src/guide/gpu.md
index 7adaa7ebe0..e702bd4444 100644
--- a/docs/src/guide/gpu.md
+++ b/docs/src/guide/gpu.md
@@ -221,7 +221,7 @@ BSON.@save "./path/to/trained_model.bson" model = cpu(model)
 ```
 The reason behind this is that models trained in the GPU but not transferred to the CPU memory scope will expect `CuArray`s as input. In other words, Flux models expect input data coming from the same kind device in which they were trained on.
 
-In controlled scenarios in which the data fed to the loaded models is garanteed to be in the GPU there's no need to transfer them back to CPU memory scope, however in production environments, where artifacts are shared among different processes, equipments or configurations, there is no garantee that the CUDA.jl package will be available for the process performing inference on the model loaded from the disk.
+In controlled scenarios in which the data fed to the loaded models is guaranteed to be in the GPU there's no need to transfer them back to CPU memory scope, however in production environments, where artifacts are shared among different processes, equipments or configurations, there is no guarantee that the CUDA.jl package will be available for the process performing inference on the model loaded from the disk.
 
 
 ## Disabling CUDA or choosing which GPUs are visible to Flux