fix report format

README.md

@@ -10,7 +10,7 @@
 ## 摘要
 
 * **项目目标**：将llama.cpp移植至龙芯处理器3A6000，并进行软硬件协同优化，加速模型的CPU推理速度，使得以Meta LLaMA为代表的流行的大语言模型能够以可接受的速度运行于龙芯平台；
-* **完成情况**：本项目的规划和进展情况可见[dev.md](dev.md)。截至本阶段，较于未经优化的代码，在矩阵乘法benchmark上达到6x~35x的FLOPS加速比，在模型推理上达到3x~6x的token吞吐量加速比，并能以流畅的用户体验进行13B参数量的大语言模型推理；
+* **完成情况**：本项目的规划和进展情况可见[dev.md](dev.md)。截至本阶段，较于未经优化的代码，在矩阵乘法benchmark上达到6x-35x的FLOPS加速比，在模型推理上达到3x-6x的token吞吐量加速比，并能以流畅的用户体验进行13B参数量的大语言模型推理；
 * **主要创新**：定位和分析了大语言模型推理的主要性能瓶颈；针对龙芯平台进行了**SIMD**和**Cache**两个方向的计算优化；同时支持**浮点**参数和**量化**参数的运算加速；在3A6000处理器上进行了正确性和性能的标准测试。
 
 本技术报告是对本项目的阶段性总结，也希望为后续工作及相关其他工作提供一些启发，具体包含以下章节：
@@ -455,7 +455,7 @@ LA_INLINE void gemm_block_kernel(const float *a, const float *b, float *c, int64
 1. 对于`Q4_1`量化类型的两个相乘矩阵$A,B$，llama.cpp（严格来说是GGML）在计算图的预处理阶段阶段会将矩阵$B$转化成`Q8_1`量化类型；
 2. 对于任何量化计算，算子的输出结果仍是F32类型。
 
-因此，本质上我们是在做 `Q4_1\times Q8_1\rightarrowF32`的计算优化，核心优化代码如下：
+因此，本质上我们是在做 $Q4\_1\times Q8\_1\rightarrow F32$的计算优化，核心优化代码如下：
 
 ```C++
 template <int B0, int B1>
@@ -694,7 +694,7 @@ make clean && make main LAMM_OPT_LEVEL=[0|1|2|3]
 | SIMD优化(LAMM_OPT_LEVEL=2)         | 12.89      | 24.71      | 44.11      | 25.98       | 51.39       | 88.84       |
 | SIMD+Cache优化(LAMM_OPT_LEVEL=3)   | **59.34**  | **85.66**  | **128.46** | **39.45**   | **77.00**   | **123.32**  |
 
-实验结果表明，本团队所作优化，在llama.cpp中矩阵乘法计算上可实现6x~35x的加速。
+实验结果表明，本团队所作优化，在llama.cpp中矩阵乘法计算上可实现6x-35x的加速。
 
 
 #### 4.4.2 模型推理测试结果
@@ -712,7 +712,7 @@ make clean && make main LAMM_OPT_LEVEL=[0|1|2|3]
 | SIMD优化(LAMM_OPT_LEVEL=2)                   | 0.77                  | 0.69                | 2.99                   | 2.02                 |
 | SIMD+Cache优化(LAMM_OPT_LEVEL=3)             |  **1.23**             | **0.82**            | **4.79**               | **2.30**             |
 
-实验结果表明，本团队所作优化，在模型推理的吞吐量上可实现3x~6x的加速，其中prompt evaluation阶段的加速效果比text generation阶段更为明显。这是因为，相对来说，前者比后者更计算密集，后者更受制于内存访问。因此，对于直接移植未经优化的代码，prompt evaluation和text generation的推理性能是差不多的，而优化过的代码在text generation在达到瓶颈。访存优化也是下一阶段我们的重点优化目标。
+实验结果表明，本团队所作优化，在模型推理的吞吐量上可实现3x-6x的加速，其中prompt evaluation阶段的加速效果比text generation阶段更为明显。这是因为，相对来说，前者比后者更计算密集，后者更受制于内存访问。因此，对于直接移植未经优化的代码，prompt evaluation和text generation的推理性能是差不多的，而优化过的代码在text generation在达到瓶颈。访存优化也是下一阶段我们的重点优化目标。
 
 
 ## 5. 相关工作