diff --git a/docs/help/amd_info.md b/docs/help/amd_info.md
index 348f9fc..058c16e 100644
--- a/docs/help/amd_info.md
+++ b/docs/help/amd_info.md
@@ -11,63 +11,66 @@ title: AMD
 
 ## ZLUDA 使用提醒
 
-如果系统中同时存在集成的 AMD GPU 和专用的 AMD GPU，则 ZLUDA 将使用集成的 GPU。
+如果系统中同时存在 AMD 的核心显卡和独立显卡，则 ZLUDA 将使用核心显卡。
 
-这是底层 ROCm/HIP 运行时中的一个错误。您可以通过禁用集成 GPU 来解决此问题。
+这是底层 ROCm / HIP 运行时中的一个错误。您可以通过禁用核心显卡来解决此问题。
 
-在 Windows 上，我们建议您使用环境变量`HIP_VISIBLE_DEVICES=1`或在设备管理器中禁用它，关于环境变量[此处有更多内容](https://rocmdocs.amd.com/en/latest/conceptual/gpu-isolation.html#hip-visible-devices)
+在 Windows 上，我们建议您使用环境变量 `HIP_VISIBLE_DEVICES=1` 或在设备管理器中禁用它，关于环境变量[此处有更多内容](https://rocmdocs.amd.com/en/latest/conceptual/gpu-isolation.html#hip-visible-devices)。
 
-集成 GPU（经 Radeon 680M 测试）的工作方式有限。一些很少使用的 GPU 操作（abort、printf 等）会挂起或使应用程序崩溃。此外，性能库支持（cuBLAS、cuDNN 等）可能会受到限制，从而导致更复杂的应用程序无法运行。
+核心显卡（经 Radeon 680M 测试）的工作方式有限。一些很少使用的 GPU 操作（abort、printf 等）会挂起或使应用程序崩溃。此外，性能库支持（cuBLAS、cuDNN 等）可能会受到限制，从而导致更复杂的应用程序无法运行。
 
-ZLUDA 可以使用 AMD 服务器 GPU（通过 Instinct MI200 进行测试），但需要注意。
+ZLUDA 可以使用 AMD 计算卡（通过 Instinct MI200 进行测试），但需要注意。
 
-在服务器 GPU 上，ZLUDA 可以编译 CUDA GPU 代码以以下两种模式之一运行：
+在 AMD 计算卡上，ZLUDA 可以编译 CUDA GPU 代码以以下两种模式之一运行：
 
 快速模式，速度更快，但可以使奇特（但正确）的 GPU 代码挂起。
 慢速模式，这应该会使 GPU 代码更稳定，但可能会阻止某些应用程序在 ZLUDA 上运行。
-默认情况下，ZLUDA使用快速模式。这是因为：
+默认情况下，ZLUDA 使用快速模式。这是因为：
 
 性能差异很大，快速模式可以快两倍。
 在多个项目(SPECFEM3D, QUDA, CHroma, MILC, Kokkos, LAMMPS, OpenFOAM, XGBoost, NAMD, LAMMPS)中没有遇到可以跳闸快速模式的代码模式。
-您可以使用环境变量`ZLUDA_WAVE64_SLOW_MODE=1`强制在慢速模式下编译。
+您可以使用环境变量 `ZLUDA_WAVE64_SLOW_MODE=1` 强制在慢速模式下编译。
 
-这些都不适用于台式机和集成 GPU（RDNA 系列）
+这些都不适用于家用级显卡（RDNA 系列）
 
 ***
 
 ## ZLUDA 首次启动
 
-使用ZLUDA的应用程序启动速度很慢。
+使用 ZLUDA 的应用程序启动速度很慢。
 
-在第一次启动时，ZLUDA需要为应用程序编译GPU代码。这是一次性成本，编译后的 GPU 代码缓存在 Windows的`%LOCALAPPDATA%` 中和 Linux的`$XDG_CACHE_HOME` 或` $HOME/.cache` 中。
+在第一次启动时，ZLUDA 需要为应用程序编译 GPU 代码。这是一次性成本，编译后的 GPU 代码缓存在 Windows 的 `%LOCALAPPDATA%` 中和 Linux 的 `$XDG_CACHE_HOME` 或 `$HOME/.cache` 中。
 某些应用程序会在使用 GPU 代码时逐渐加载它。如果不希望这样做，您可以尝试设置环境变量 `CUDA_MODULE_LOADING=EAGER`。这取决于应用程序的编程方式，但它可能会强制在启动时加载（和编译）所有内核，无论它们是否被使用。
 
 ***
 
 ## 运行 ZLUDA 的应用程序可能会产生略有不同的值
 
-首先，ZLUDA忽略了内核中存在的一些浮点非正态和舍入模式信息。其次，对于CUDA中的某些近似（非IEEE 754）NVIDIA浮点运算，ZLUDA盲目使用近似AMD浮点运算。两者可能具有不同的精度。
+首先，ZLUDA 忽略了内核中存在的一些浮点非正态和舍入模式信息。其次，对于 CUDA 中的某些近似（非IEEE 754）NVIDIA浮点运算，ZLUDA 盲目使用近似 AMD 浮点运算。两者可能具有不同的精度。
 
 ***
 
 ## CUDA 12+
-使用 CUDA 12 构建并使用 Thrust 的应用程序会崩溃`LLVM ERROR: unsupported libcall legalization`
 
-这是一个 ROCm/HIP 错误。目前，使用 CUDA 12 之前版本构建的 CUDA 应用程序效果最好。使用 CUDA 12 和 CUDA 12 之前的版本构建也可能有效。
+使用 CUDA 12 构建并使用 Thrust 的应用程序会崩溃 `LLVM ERROR: unsupported libcall legalization`
+
+这是一个 ROCm / HIP 错误。目前，使用 CUDA 12 之前版本构建的 CUDA 应用程序效果最好。使用 CUDA 12 和 CUDA 12 之前的版本构建也可能有效。
 
 ***
 
 ## OptiX 的
+
 ZLUDA 为 Arnold 提供了最低限度的 OptiX 实现。有关详细信息，请参阅 [Arnold](https://github.com/vosen/ZLUDA#arnold) 部分。
 
 ***
 
 ## Windows
+
 防病毒软件将 ZLUDA 标记为恶意软件。
 
-ZLUDA 启动器`zluda.exe`使用恶意软件使用的一些技术，但效果很好。`zluda.exe`劫持该进程，并将原始 NVIDIA CUDA 库的所有使用重定向为使用 ZLUDA 的 CUDA。
+ZLUDA 启动器 `zluda.exe` 使用恶意软件使用的一些技术，但效果很好。`zluda.exe` 劫持该进程，并将原始 NVIDIA CUDA 库的所有使用重定向为使用 ZLUDA 的 CUDA。
 
-不要在反作弊的游戏中使用`zluda.exe`。ZLUDA 不支持 CUDA 游戏工作负载（PhysX 或 DLSS），反作弊可能会误认为`zluda.exe`是恶意软件或作弊软件。
+不要在反作弊的游戏中使用 `zluda.exe`。ZLUDA 不支持 CUDA 游戏工作负载（PhysX 或 DLSS），反作弊可能会误认为 `zluda.exe` 是恶意软件或作弊软件。
 
 ***
 
@@ -77,4 +80,4 @@ ZLUDA 启动器`zluda.exe`使用恶意软件使用的一些技术，但效果很
 
 ZLUDA 对性能库（cuDNN, cuBLAS, cuSPARSE, cuFFT, OptiX, NCCL）提供的支持有限。目前，此支持仅适用于 Linux，在 Windows 上不可用。
 
-ZLUDA 启动器 `zluda.exe`不支持 32 位进程。如果应用程序启动 32 位子进程`a.exe`则 32 位进程`a.exe`及其 64 位子进程`a64.exe`都无法使用 ZLUDA。这会影响SiSoft Sandra。
+ZLUDA 启动器 `zluda.exe` 不支持 32 位进程。如果应用程序启动 32 位子进程 `a.exe` 则 32 位进程 `a.exe` 及其 64 位子进程 `a64.exe` 都无法使用 ZLUDA。这会影响 SiSoft Sandra。
diff --git a/docs/help/intel_info.md b/docs/help/intel_info.md
index 1b542b7..820b668 100644
--- a/docs/help/intel_info.md
+++ b/docs/help/intel_info.md
@@ -19,26 +19,26 @@ title: Intel
 
 # 运行报错 invalid device pointer if import horovod.torch as hvd before import intel_extension_for_pytorch
 
-原因：`Intel® Optimization for Horovod*`使用`Intel® Extension for PyTorch*`提供的实用程序。不正确的导入顺序导致`Intel® Extension for PyTorch*` 在`  Intel® Optimization` 之前卸载 在执行结束时对 Horovod* 进行优化，并触发此错误。
+原因：`Intel® Optimization for Horovod*` 使用 `Intel® Extension for PyTorch*` 提供的实用程序。不正确的导入顺序导致 `Intel® Extension for PyTorch*` 在 `Intel® Optimization` 之前卸载 在执行结束时对 Horovod* 进行优化，并触发此错误。
 
-解决方案：在`import intel_extension_for_pytorch`之前加上`import horovod.torch as hvd`
+解决方案：在 `import intel_extension_for_pytorch` 之前加上 `import horovod.torch as hvd`
 
 ***
 
 # dpcpp 设备数应大于零。
 
-原因：如果您在 conda 环境中使用`Intel® Extension for PyTorch*`，您可能会遇到此错误。因为Conda 还附带了 `libstdc++.so` 动态库文件，该文件可能与操作系统中附带的文件冲突。
+原因：如果您在 conda 环境中使用 `Intel® Extension for PyTorch*` ，您可能会遇到此错误。因为Conda 还附带了 `libstdc++.so` 动态库文件，该文件可能与操作系统中附带的文件冲突。
 
-解决方案：将操作系统中的`libstdc++.so`文件路径导出到环境变量`LD_PRELOAD`。
+解决方案：将操作系统中的 `libstdc++.so` 文件路径导出到环境变量 `LD_PRELOAD` 。
 
 ***
 
-## 由_GLIBCXX_USE_CXX11_ABI引起的符号未定义。
+## 由 _GLIBCXX_USE_CXX11_ABI 引起的符号未定义。
 
-`ImportError: undefined symbol: _ZNK5torch8autograd4Node4nameB5cxx11Ev`
-原因：DPC++ 不支持 `_GLIBCXX_USE_CXX11_ABI=0`，`Intel® Extension for PyTorch*`始终使用`_GLIBCXX_USE_CXX11_ABI=1`进行编译。当 PyTorch* 以 `_GLIBCXX_USE_CXX11_ABI=0`编译时，会出现此符号未定义问题。
+`ImportError: undefined symbol: _ZNK5torch8autograd4Node4nameB5cxx11Ev` 
+原因：DPC++ 不支持 `_GLIBCXX_USE_CXX11_ABI=0`，`Intel® Extension for PyTorch*` 始终使用 `_GLIBCXX_USE_CXX11_ABI=1` 进行编译。当 PyTorch* 以 `_GLIBCXX_USE_CXX11_ABI=0` 编译时，会出现此符号未定义问题。
 
-解决方案：传递导出  `GLIBCXX_USE_CXX11_ABI=1 ` 并使用支持 ` _GLIBCXX_USE_CXX11_ABI=1 ` 的特定编译器编译 PyTorch*。我们建议在[下载服务器](https://developer.intel.com/ipex-whl-stable-xpu)中以避免此问题。
+解决方案：传递导出 `GLIBCXX_USE_CXX11_ABI=1` 并使用支持 `_GLIBCXX_USE_CXX11_ABI=1` 的特定编译器编译 PyTorch*。我们建议在[下载服务器](https://developer.intel.com/ipex-whl-stable-xpu)中以避免此问题。
 
 ***
 
@@ -46,27 +46,27 @@ title: Intel
 
 原因：当 AI 模型（例如 RN50 训练）在英特尔 MPI 环境中执行完成时，这是一个随机问题。它不是用户友好的，因为模型执行不优雅地结束。此问题已在 PyTorch* 2.3 [#116312](https://github.com/pytorch/pytorch/commit/f657b2b1f8f35aa6ee199c4690d38a2b460387ae) 中修复。
 
-解决方案：在模型脚本的清理阶段添加 `dist.destroy_process_group() `，如分布式数据并行入门中所述，如[Getting Started with Distributed Data Parallel](https://pytorch.org/tutorials/intermediate/ddp_tutorial.html)中所述在 Intel Extension for PyTorch* 支持 PyTorch* 2.3 之前®。
+解决方案：在模型脚本的清理阶段添加 `dist.destroy_process_group()`，如分布式数据并行入门中所述，如[Getting Started with Distributed Data Parallel](https://pytorch.org/tutorials/intermediate/ddp_tutorial.html)中所述在 Intel Extension for PyTorch* 支持 PyTorch* 2.3 之前®。
 
 ***
 
-## 在 Intel® Arc™ A-Series GPUs 上运行某些 AI 模型时。  -997 runtime error  
+## 在 Intel® Arc™ A-Series GPUs 上运行某些 AI 模型时。 -997 runtime error  
 
-原因：一些 -997 运行时错误实际上是内存不足错误。由于 Intel® Arc™ A-Series GPUs 的设备内存少于Intel® Data Center GPU Flex Series 170和Intel® Data Center GPU Max Series，因此在其上运行某些 AI 模型可能会触发内存不足错误，并导致它们报告故障，例如最有可能的 -997 运行时错误。这是意料之中的。内存使用优化是一项正在进行的工作，以允许英特尔®锐炫™ A 系列 GPU 支持更多 AI 模型。
+原因：一些 -997 运行时错误实际上是内存不足错误。由于 Intel® Arc™ A-Series GPUs 的设备内存少于 Intel® Data Center GPU Flex Series 170 和 Intel® Data Center GPU Max Series，因此在其上运行某些 AI 模型可能会触发内存不足错误，并导致它们报告故障，例如最有可能的 -997 运行时错误。这是意料之中的。内存使用优化是一项正在进行的工作，以允许英特尔®锐炫™ A 系列 GPU 支持更多 AI 模型。
 
 ***
 
-## 在 WSL2 上，从Intel® Arc™ A-Series GPUs 的源代码构建失败，而不会引发任何错误。
+## 在 WSL2 上，从 Intel® Arc™ A-Series GPUs 的源代码构建失败，而不会引发任何错误。
 
 原因：您的系统可能没有足够的内存，因此调用了 Linux 内核的内存不足杀手。可以通过在 bash（WSL2 终端）上运行 dmesg 来验证这一点。
 
-解决方案：如果 OOM 杀手确实终止了生成过程，则可以尝试增加 WSL2 的交换大小和/或减少具有环境变量 `MAX_JOBS `的并行生成作业数（默认情况下，它等于逻辑 CPU 内核数）。因此，将 ` MAX_JOBS  `设置为  `1  `是一种非常保守的方法，会大大减慢速度）。
+解决方案：如果 OOM 杀手确实终止了生成过程，则可以尝试增加 WSL2 的交换大小和/或减少具有环境变量 `MAX_JOBS` 的并行生成作业数（默认情况下，它等于逻辑 CPU 内核数）。因此，将 `MAX_JOBS` 设置为 `1` 是一种非常保守的方法，会大大减慢速度）。
 
 ***
 
 ## 某些工作负载在 WSL2 上一段时间后终止并显示错误。CL_DEVICE_NOT_FOUND
 
-原因：此问题是由于 Windows 上的 [TDR feature](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/tdr-registry-keys#tdrdelay)造成的。
+原因：此问题是由于 Windows 上的 [TDR feature](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/tdr-registry-keys#tdrdelay) 造成的。
 
 解决方案：尝试将 Windows 注册表中的 TDRDelay 增加到一个大值，例如 20（默认为 2 秒），然后重新启动。
 
@@ -82,7 +82,7 @@ title: Intel
 
 ## 在英特尔®数据中心 GPU Max 系列显卡上执行 LLM 推理工作负载时，存在随机不稳定问题，例如页面错误或访问冲突。
 
-原因：LTS 驱动程序[803.29](https://dgpu-docs.intel.com/releases/LTS_803.29_20240131.html) 上报告了此问题。根本原因正在调查中。
+原因：LTS 驱动程序 [803.29](https://dgpu-docs.intel.com/releases/LTS_803.29_20240131.html) 上报告了此问题。根本原因正在调查中。
 
 解决方案：使用主动滚动稳定释放驱动程序 [775.20](https://dgpu-docs.intel.com/releases/stable_775_20_20231219.html) 或最新驱动程序版本来解决。
 
@@ -90,7 +90,7 @@ title: Intel
 
 ## Undefined symbol: mkl_lapack_dspevd. Intel MKL FATAL ERROR: cannot load libmkl_vml_avx512.so.2 or `libmkl_vml_def.so.2.
 
-原因：当英特尔扩展 PyTorch* 是使用 oneMKL 库构建的，而 PyTorch* 不是使用任何 MKL 库构建时®，可能会出现此问题。oneMKL内核可能错误地进入CPU后端 并触发此问题。
+原因：当英特尔扩展 PyTorch* 是使用 oneMKL 库构建的，而 PyTorch* 不是使用任何 MKL 库构建时，可能会出现此问题。oneMKL 内核可能错误地进入CPU后端 并触发此问题。
 
 解决方案：通过从 conda 安装 oneMKL 库来解决问题：
 
@@ -107,13 +107,13 @@ conda install mkl-include
 
 原因：当系统中存在多个 MKL 库时，使用了错误的 MKL 库。
 
-解决方案：通过以下方式预加载oneMKL：
+解决方案：通过以下方式预加载 oneMKL：
 
 ```
 export LD_PRELOAD=${MKL_DPCPP_ROOT}/lib/intel64/libmkl_intel_lp64.so.2:${MKL_DPCPP_ROOT}/lib/intel64/libmkl_intel_ilp64.so.2:${MKL_DPCPP_ROOT}/lib/intel64/libmkl_gnu_thread.so.2:${MKL_DPCPP_ROOT}/lib/intel64/libmkl_core.so.2:${MKL_DPCPP_ROOT}/lib/intel64/libmkl_sycl.so.2
 ```
 
-如果您继续看到其他共享对象文件的类似问题，请在  `${MKL_DPCPP_ROOT}/lib/intel64/ `下添加相应的文件，通过  `LD_PRELOAD `。请注意，如果系统上安装了多个 MKL 库，则库的后缀可能会更改（例如从 .1 更改为 .2）。
+如果您继续看到其他共享对象文件的类似问题，请在 `${MKL_DPCPP_ROOT}/lib/intel64/` 下添加相应的文件，通过 `LD_PRELOAD `。请注意，如果系统上安装了多个 MKL 库，则库的后缀可能会更改（例如从 .1 更改为 .2）。
 
 ***