diff --git a/docs/source/concept_guides/training_tpu.mdx b/docs/source/concept_guides/training_tpu.mdx
index 32736ce31..7fe54b14a 100644
--- a/docs/source/concept_guides/training_tpu.mdx
+++ b/docs/source/concept_guides/training_tpu.mdx
@@ -89,7 +89,7 @@ like:
 ProcessExitedException: process 0 terminated with signal SIGSEGV
 ```
 
-This error is *extremely* cryptic but the basic explaination is you ran out of system RAM. You can avoid this entirely by reconfiguring the training function to 
+This error is *extremely* cryptic but the basic explanation is you ran out of system RAM. You can avoid this entirely by reconfiguring the training function to 
 accept a single `model` argument, and declare it in an outside cell:
 
 ```python
@@ -137,7 +137,7 @@ accelerator = Accelerator(mixed_precision="bf16")
 By default this will cast `torch.float` and `torch.double` to `bfloat16` on TPUs. 
 The specific configuration being set is an environmental variable of `XLA_USE_BF16` is set to `1`.
 
-There is a futher configuration you can perform which is setting the `XLA_DOWNCAST_BF16` environmental variable. If set to `1`, then 
+There is a further configuration you can perform which is setting the `XLA_DOWNCAST_BF16` environmental variable. If set to `1`, then 
 `torch.float` is `bfloat16` and `torch.double` is `float32`.
 
 This is performed in the `Accelerator` object when passing `downcast_bf16=True`:
diff --git a/docs/source/quicktour.mdx b/docs/source/quicktour.mdx
index 812b20226..6d92e7958 100644
--- a/docs/source/quicktour.mdx
+++ b/docs/source/quicktour.mdx
@@ -391,7 +391,7 @@ and [`~Accelerator.clip_grad_value_`] respectively.
 
 If you are running your training in Mixed Precision with 🤗 Accelerate, you will get the best result with your loss being
 computed inside your model (like in Transformer models for instance). Every computation outside of the model will be
-executed in full precision (which is generally what you want for loss computation, expecially if it involves a
+executed in full precision (which is generally what you want for loss computation, especially if it involves a
 softmax). However you might want to put your loss computation inside the *accelerator.autocast* context manager:
 
 ```
diff --git a/docs/source/usage_guides/big_modeling.mdx b/docs/source/usage_guides/big_modeling.mdx
index 243b354d0..9b3252809 100644
--- a/docs/source/usage_guides/big_modeling.mdx
+++ b/docs/source/usage_guides/big_modeling.mdx
@@ -213,7 +213,7 @@ You can let 🤗 Accelerate handle the device map computation by setting `device
 
 </Tip>
 
-All the options will produce the same result when you don't have enough GPU memory to accomodate the whole model (which is to fit everything that can on the GPU, then offload weights on the CPU or even on the disk if there is not enough RAM). 
+All the options will produce the same result when you don't have enough GPU memory to accommodate the whole model (which is to fit everything that can on the GPU, then offload weights on the CPU or even on the disk if there is not enough RAM). 
 
 When you have more GPU memory available than the model size, here the difference between each option:
 - `"auto"` and `"balanced"` evenly split the model on all available GPUs, making it possible for you to use a batch size greater than 1.
diff --git a/docs/source/usage_guides/checkpoint.mdx b/docs/source/usage_guides/checkpoint.mdx
index c818c9847..7d6bbbf99 100644
--- a/docs/source/usage_guides/checkpoint.mdx
+++ b/docs/source/usage_guides/checkpoint.mdx
@@ -13,7 +13,7 @@ specific language governing permissions and limitations under the License.
 # Checkpointing
 
 When training a PyTorch model with 🤗 Accelerate, you may often want to save and continue a state of training. Doing so requires
-saving and loading the model, optimizer, RNG generators, and the GradScaler. Inside 🤗 Accelerate are two convience functions to achieve this quickly:
+saving and loading the model, optimizer, RNG generators, and the GradScaler. Inside 🤗 Accelerate are two convenience functions to achieve this quickly:
 - Use [`~Accelerator.save_state`] for saving everything mentioned above to a folder location
 - Use [`~Accelerator.load_state`] for loading everything stored from an earlier `save_state`
 
diff --git a/docs/source/usage_guides/deepspeed.mdx b/docs/source/usage_guides/deepspeed.mdx
index 8a4238732..29561c77b 100644
--- a/docs/source/usage_guides/deepspeed.mdx
+++ b/docs/source/usage_guides/deepspeed.mdx
@@ -68,7 +68,7 @@ Inference:
 
 ## How it works?
 
-**Pre-Requisites**: Install DeepSpeed version >=0.6.5. Please refer to the [DeepSpeed Insallation details](https://github.com/microsoft/DeepSpeed#installation)
+**Pre-Requisites**: Install DeepSpeed version >=0.6.5. Please refer to the [DeepSpeed Installation details](https://github.com/microsoft/DeepSpeed#installation)
 for more information.
 
 We will first look at easy to use integration via `accelerate config`. 
@@ -383,13 +383,13 @@ We will look at the changes needed in the code when using these.
    ```
    b. Custom Optim + Custom Scheduler: The case when both `optimizer` and `scheduler` keys are absent in the DeepSpeed config file.
    In this situation, no code changes are needed from the user and this is the case when using integration via DeepSpeed Plugin.
-   In the above example we can see that the code reamins unchanged if the `optimizer` and `scheduler` keys are absent in the DeepSpeed config file.
+   In the above example we can see that the code remains unchanged if the `optimizer` and `scheduler` keys are absent in the DeepSpeed config file.
 
    c. Custom Optim + DS Scheduler: The case when only `scheduler` key is present in the DeepSpeed config file. 
    In this situation, user has to use `accelerate.utils.DummyScheduler` to replace the PyTorch/Custom scheduler in their code. 
 
    d. DS Optim + Custom Scheduler: The case when only `optimizer` key is present in the DeepSpeed config file. 
-   This will result in an error because one can only use DS Scheduler when using DS Optim.
+   This will result in an error because you can only use DS Scheduler when using DS Optim.
 
 2. Notice the `auto` values in the above example DeepSpeed config files. These are automatically handled by `prepare` method 
 based on model, dataloaders, dummy optimizer and dummy schedulers provided to `prepare` method. 
@@ -435,7 +435,7 @@ ZeRO Stage-3 has 2 options:
        logging.warning(f"Failure {status_msg}")
    ``` 
    This will create ZeRO model and optimizer partitions along with `zero_to_fp32.py` script in checkpoint directory.
-   One can use this script to do offline consolidation.  
+   You can use this script to do offline consolidation.  
    It requires no configuration files or GPUs. Here is an example of its usage:  
    ```bash
    $ cd /path/to/checkpoint_dir
@@ -444,14 +444,14 @@ ZeRO Stage-3 has 2 options:
    Detected checkpoint of type zero stage 3, world_size: 2
    Saving fp32 state dict to pytorch_model.bin (total_numel=60506624)
    ```
-   To get 32bit model for saving/inference, one can do the following:
+   To get 32bit model for saving/inference, you can perform:
    ```python
    from deepspeed.utils.zero_to_fp32 import load_state_dict_from_zero_checkpoint
 
    unwrapped_model = accelerator.unwrap_model(model)
    fp32_model = load_state_dict_from_zero_checkpoint(unwrapped_model, checkpoint_dir)
    ```
-   If only interested in state_dict, one can do the following:
+   If you are only interested in the `state_dict`, you can do the following:
    ```python
    from deepspeed.utils.zero_to_fp32 import get_fp32_state_dict_from_zero_checkpoint
 
@@ -462,7 +462,7 @@ ZeRO Stage-3 has 2 options:
 ## ZeRO Inference
 DeepSpeed ZeRO Inference supports ZeRO stage 3 with ZeRO-Infinity. 
 It uses the same ZeRO protocol as training, but it doesn't use an optimizer and a lr scheduler and only stage 3 is relevant.
-With accelerate integration, one has to just prepare model and dataloader as shown below:
+With accelerate integration, you just need to prepare the model and dataloader as shown below:
 
 ```python
 model, eval_dataloader = accelerator.prepare(model, eval_dataloader)
diff --git a/docs/source/usage_guides/tracking.mdx b/docs/source/usage_guides/tracking.mdx
index 7c61b21e9..cc5c17418 100644
--- a/docs/source/usage_guides/tracking.mdx
+++ b/docs/source/usage_guides/tracking.mdx
@@ -104,7 +104,7 @@ Every tracker must implement three functions and have three properties:
     - This should be implemented as a `@property` function 
     - Should return the internal tracking mechanism the library uses, such as the `run` object for `wandb`.
 
-A brief example can be seen below with an integration with Weights and Biases, containing only the relevent information:
+A brief example can be seen below with an integration with Weights and Biases, containing only the relevant information:
 ```python
 from accelerate.tracking import GeneralTracker
 from typing import Optional


Review comments: body: ```suggestion
To introduce special behavior in your script for TPUs you can check the `distributed_type` of your
```
diff_hunk: @@ -261,7 +261,7 @@ lot of time. In practice, that means you must take special care to have all your
 shape (so no dynamic padding for instance if you are in an NLP problem) and should not use layers with for loops that
 have different lengths depending on the inputs (such as an LSTM) or the training will be excruciatingly slow.
 
-To introduce special behavior in your script for TPUs you can check the `distributed_type` of your
+To introduce special behaviour in your script for TPUs you can check the `distributed_type` of your
body: ```suggestion
Internally, the library works by first analyzing the environment in which the script is launched to determine which
```
diff_hunk: @@ -447,7 +447,7 @@ will be added in a next version.
 
 ## Internal mechanism
 
-Internally, the library works by first analyzing the environment in which the script is launched to determine which
+Internally, the library works by first analysing the environment in which the script is launched to determine which

Discussion: body: _The documentation is not available anymore as the PR was closed or merged._