LLM on 个人技术随想

MoE模型的高效微调

Wed, 21 Jan 2026 11:00:00 +0800

2026年了，MoE大模型微调竟然还没有彻底极其方便的通解。这合理吗？

为什么MoE大模型多卡分布式LoRA微调是困难的？

📌 重要

一句话总结

MoE模型在LoRA微调中产生巨量低秩矩阵，叠加低效的MoE实现，导致多卡梯度计算困难，最终容易卡死。

一开始我也很惊奇，都2026年了，Qwen3模型问世已半年有余，**难道业界就没有MoE做LoRA微调的需求么？**怎么会一直存在这个问题呢？

后来多方查阅资料，这个问题还真没那么好解决：

MoE架构的模型中存在数量极其庞大的小专家FFN，每个专家（Gated MLP）内有三个Linear模块；
在LoRA微调时，LoRA会为每个Linear模块添加两个低秩矩阵(A/B)；
这导致模型中参与计算的模块数量极其庞大，CUDA计算图相较Dense模型极其复杂；
在 HF transformers 4.* 版本中，MoE的专家路由与FFN选择甚至使用Python for循环实现；
低效的专家选择和计算加剧了多卡分布式计算的困难，也容易导致多卡不同rank数据不对齐，reduce失败；
最终导致训练完全卡死，表现为显卡占用率100%却没有计算量，NCCL通信超时；
所有基于transformers库搭建的框架（LLaMA-Factory等）都面临相同问题。

包括我在内，很多人惯性认为，现在的计算能力足以满足更大规模的模型训练，小小MoE引入的计算开销应当不足为惧才对？

让我们看看例子，以Qwen3-30B-A3B为例：

模型中每一层有128个专家
模型总共48层，因此整个模型就有6000多个专家FFN模块
而每个FFN模块都是一个Gated MLP模块，内含3个Linear矩阵
此时，单论专家部分，模型中就总共有18000+ Linear矩阵了，还没考虑Attention等部件
使用LoRA微调时，需要对每个Linear增加两个矩阵(A/B)，再次翻倍变成36000+矩阵参与反向传播

作为对比，Qwen3-32B共64层，每层包括Attention和Norm在内也不过11个Linear矩阵，整个模型应用LoRA后的可更新Linear数控制在2000以内，还不到MoE模型的零头。

解决方案

分析了问题原因，解决方案呼之欲出，无非两种：

Sensei，我不做LoRA微调啦！泷泽LoRA哒！
你去把 Huggingface 师徒干掉。我？

第一种方案是研究论文的主要手段，研究一些小模型尚且可以接受。

但眼下是大模型时代！Qwen3发布的MoE最小也有30B参数量，全参数微调需要的VRAM奔着360G以上去了，只有财大气粗的团队才能轻松实现吧。

第二种方案说得好，既然transformers库的MoE实现有问题，那我们不用不就行了？

很好，现在请开始手搓一个Fused MoE Kernel吧。这就是传说中的从入门到入土吗？

等一下，为什么要自己手搓呢？还好，有人帮我们实现过了！

Megatron + Swift

现在，有请NVIDIA开发的Megatron库，以及Modelscope开发的ms-swift库。

上面两个库是什么，还请自行搜索。总而言之，借助这两个库，我们可以在transformers v5真正解决MoE计算效率问题前，高效地训练MoE模型LoRA。

现在让我们直接开始准备吧！

环境配置

这一套方案需要使用Python 3.11，原始配环境教程在这里。

相较于原始教程，我做了一点点修改，总结了一些踩坑的改进，可以和原文档一起阅读。

假设此时系统已配置好CUDA Toolkit，也就是nvcc那一套东西。

另外，我现在更偏好使用uv作为pip的替代，使用pip时请自行调整。

基础环境

准备以下requirements.txt：

ms-swift==3.12
torch==2.8.0
transformers<4.58
trl<0.25
peft<0.19
deepspeed<0.18
pybind11

需要注意，这一套环境中，PyTorch 2.9.0或更高版本似乎存在一些问题，所以建议使用2.8.0。

接下来，根据机器上NVIDIA驱动的CUDA版本，选择好希望使用的CUDA版本号，然后开装！这里我们使用CUDA 12.6版本的PyTorch。

1
2

uv venv -p 3.11
uv pip install -r requirements.txt --torch-backend cu126

外部依赖项

接下来，我们需要获取一些外部依赖项，这些依赖需要手动从Github上拉取后本地编译安装。

# Create a folder, or NOT as you wish.
mkdir deps

# NVIDIA APEX
git clone https://github.com/NVIDIA/apex deps/apex

# NVIDIA Megatron
git clone --branch core_r0.15.0 https://github.com/NVIDIA/Megatron-LM.git deps/Megatron-LM

本地编译依赖

现在，我们需要开始一项项编译依赖。首先是transformer_engine：

1
2
3

source .venv/bin/activate

SITE_PACKAGES=$(uv run python -c "import site; print(site.getsitepackages()[0])") && echo $SITE_PACKAGES && CUDNN_PATH=$SITE_PACKAGES/nvidia/cudnn CPLUS_INCLUDE_PATH="$SITE_PACKAGES/nvidia/cudnn/include:$SITE_PACKAGES/nvidia/nccl/include" uv pip install --no-build-isolation transformer_engine[pytorch]

上面这一串看起来怪吓人的，其实就是把Python虚拟环境中的include文件夹暴露给编译器，避免重复下载CUDNN或者NCCL等库的麻烦。参考这个Issue。

接下来是APEX：

`1`	`uv pip install -v --disable-pip-version-check --no-cache-dir --no-build-isolation --config-settings="--build-option=--cpp_ext" --config-settings="--build-option=--cuda_ext" ./deps/apex/`

MS-Swift教程中的命令不完全兼容uv指令，需要像上面的例子一样，--config-settings后用等于号=连接参数字符串。

然后是Megatron：

`1`	`uv pip install ./deps/Megatron-LM/`

最后是Flash Attention：

`1`	`uv pip install "flash-attn==2.8.3" --no-build-isolation`

如果没有出错，那么环境就配好啦。

参数调优

请参考Megatron Core MoE

坑

数据加载有问题

上述依赖会在环境中使用datasets==3.6.0，如果你生成的数据集文件使用了不同版本的datasets库，会容易出错。

解决方法很简单：在生成数据集文件时，就使用datasets==3.6.0。

在电脑上使用AVX512加速LLaMA.cpp本地推理

Mon, 10 Jun 2024 11:00:00 +0800

想在本地玩大模型但服务器光有CPU没有高端显卡？

No No No，为什么不试试最新最潮（也不算）的LLaMA.cpp，只要有一定内存，和支持AVX512指令集的英特尔服务器CPU，尽管推理速度慢了一些，但只需要64G以上普通内存，依然可以试玩大模型。

打开教程一看，又得自己编译，又要配环境，还要量化模型……

觉得复杂？一切没有想象中困难！

(2026年更新) Vulkan支持

也不知道什么时候起，llama.cpp的Github页面就提供了支持Vulkan的预编译包。

所以理论上，只要系统安装了支持Vulkan的显卡驱动，配置好Vulkan环境，不管是哪家的显卡，都可以用同一个二进制文件，利用GPU进行LLM推理。

对于一些容器镜像，系统中的Vulkan包可能不齐全。对于Ubuntu，可以使用以下命令补全系统依赖：

`1`	`apt-get update && apt-get install -y --no-install-recommends libglvnd0 libgl1 libglx0 libegl1 libgles2 && rm -rf /var/lib/apt/lists/*`

安装Intel oneAPI编译工具

首先需要前往英特尔官网Download the Intel® oneAPI Base Toolkit下载支持AVX512指令集的编译器套件。

下载完成后安装，安装命令是：

`1`	`sh ./l_BaseKit_p_2024.1.0.596_offline.sh -a --silent --cli --eula accept`

官网示例命令中使用了sudo，但实际上也支持用户模式安装。-a选项有点莫名其妙，实际作用是把后面的参数传递给安装器。如果希望交互式安装，则需要去掉--silent选项。

引入cmake和oneAPI套件（可选）

如果没有root权限，cmake和oneAPI都只能安装在用户目录下，则需要先引入上述环境。

1
2

source /path/to/intel/oneapi/setvars.sh
source /path/to/cmake/activate_cmake.sh

这里的activate_cmake.sh文件是自己创建的，只是简单地在PATH中添加了cmake的bin文件路径，方便后续使用而已，内容如下：

1
2

#!/bin/bash
export PATH="$PATH:/path/to/cmake/bin"

编译安装LLaMA.cpp

克隆LLaMA.cpp仓库（不要直接下载Release中的打包源代码，编译时会检测git仓库是否存在，请直接克隆）

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

按照仓库里的指引，找到Intel oneMKL部分的编译指令，直接执行：

1
2

cmake -B build -DLLAMA_BLAS=ON -DLLAMA_BLAS_VENDOR=Intel10_64lp -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DLLAMA_NATIVE=ON
cmake --build build --config Release

等待编译完成，可执行文件就位于build/bin下面。如果希望将这些文件安装到特定文件夹，可以继续执行：

`1`	`cmake --install build/ --config Release --prefix /path/you/like/`

量化和加载模型文件

得到可用的LLaMA.cpp后，就可以对训练好的模型量化然后使用了。当然，如果不想自己炼丹/量化，也可以下载已经量化好的模型。

以千问模型为例，参考llama.cpp - Qwen的指引。

首先可以前往Huggingface下载模型的GGUF文件，例如Qwen/Qwen2-7B-Instruct-GGUF。

和HF上其他格式的检查点不同，这里只需要下载一个合适的GGUF文件就行。

下载完成后加载模型文件和初始提示词：

`1`	`./main -m ../models/qwen2-7b-instruct-q5_k_m.gguf -n 512 --color -i -cml -f ../prompts/chat-with-qwen.txt`

接着就可以对话了：

> Hello, tell me more about yourself.
I am an artificial intelligence designed to assist with a wide range of tasks, including answering questions, providing information, and performing various tasks. I am constantly learning and improving, and I am constantly updated with the latest technology and information. I am designed to assist with a wide range of tasks, and I am always ready to help you with whatever you need.

> What is 1+2?
1 + 2 equals 3.

踩坑

量化模型有很多，选哪个？

请参见Difference in different quantization methods.

quantize --help outputs a helpful table:

Allowed quantization types:
   2  or  Q4_0   :  3.50G, +0.2499 ppl @ 7B - small, very high quality loss - legacy, prefer using Q3_K_M
   3  or  Q4_1   :  3.90G, +0.1846 ppl @ 7B - small, substantial quality loss - legacy, prefer using Q3_K_L
   8  or  Q5_0   :  4.30G, +0.0796 ppl @ 7B - medium, balanced quality - legacy, prefer using Q4_K_M
   9  or  Q5_1   :  4.70G, +0.0415 ppl @ 7B - medium, low quality loss - legacy, prefer using Q5_K_M
  10  or  Q2_K   :  2.67G, +0.8698 ppl @ 7B - smallest, extreme quality loss - not recommended
  12  or  Q3_K   : alias for Q3_K_M
  11  or  Q3_K_S :  2.75G, +0.5505 ppl @ 7B - very small, very high quality loss
  12  or  Q3_K_M :  3.06G, +0.2437 ppl @ 7B - very small, very high quality loss
  13  or  Q3_K_L :  3.35G, +0.1803 ppl @ 7B - small, substantial quality loss
  15  or  Q4_K   : alias for Q4_K_M
  14  or  Q4_K_S :  3.56G, +0.1149 ppl @ 7B - small, significant quality loss
  15  or  Q4_K_M :  3.80G, +0.0535 ppl @ 7B - medium, balanced quality - *recommended*
  17  or  Q5_K   : alias for Q5_K_M
  16  or  Q5_K_S :  4.33G, +0.0353 ppl @ 7B - large, low quality loss - *recommended*
  17  or  Q5_K_M :  4.45G, +0.0142 ppl @ 7B - large, very low quality loss - *recommended*
  18  or  Q6_K   :  5.15G, +0.0044 ppl @ 7B - very large, extremely low quality loss
   7  or  Q8_0   :  6.70G, +0.0004 ppl @ 7B - very large, extremely low quality loss - not recommended
   1  or  F16    : 13.00G              @ 7B - extremely large, virtually no quality loss - not recommended
   0  or  F32    : 26.00G              @ 7B - absolutely huge, lossless - not recommended

The ppl column is perplexity increase relative to unquantized. Q4_K_M, Q5_K_S and Q5_K_M are considered “recommended”.

出现unknown argument: -cml

自从Releases/b3087开始，LLaMA.cpp对main程序进行了重构，删去了-cml参数。但千问文档中需要使用这一参数。

直接解决这一问题的方法比较麻烦，当然也有不需要动脑的方法：回退到之前的版本Releases/b3086。

在LLaMA.cpp主目录执行以下命令：

`1`	`git revert --no-commit b3086..HEAD`

重新编译一次即可。

更多请见Discussions/7837。

libmkl_intel_ilp64.so.2: No such file or directory

如果出现以下报错：

`1`	`./main: error while loading shared libraries: libmkl_intel_ilp64.so.2: cannot open shared object file: No such file or directory`

这是因为英特尔的MKL库文件libmkl_intel_ilp64.so.2没有在LD_LIBRARY_PATH中可以被搜索到，该文件实际位于/path/to/intel/oneapi/mkl/<year>.<ver>/lib里。

解决方法也相当简单，直接再次source /path/to/intel/oneapi/setvars.sh，脚本会自动帮我们把库文件添加到环境变量中。

oneAPI Compiler与GCC的性能

然而，实际测试中，较新版本的GCC也能利用AVX512指令集为程序加速。于是恭喜你和我一样，踩坑了！

使用DeBERTa V3进行基于方面的情感分析(ABSA)

Sun, 10 Dec 2023 15:00:00 +0800

基于方面的情感分析(Aspect Based Sentiment Analysis, ABSA)是一种细粒度的情感分析任务，即，对于给定的一段文本，识别出该文本针对文中指定的某一方面的情感极性。

📝 备注

2025年11月：更新了基于CausalLM的方法

本文将介绍如何在本机上部署并使用预训练的DeBERTa V3模型对文本中的某一特定方面进行情感分析，从而实现观点挖掘相关的工作。当然，由于本人没有涉足过NLP的具体研究，可能很多表述并不严谨，敬请批评指正。

前言

这两天接触了一下情感分析相关的工作，大致是需要确定一些文本对某些个体的情感倾向。经过搜索，这属于情感分析(Sentiment Analysis)的任务范畴，而更具体地，实际上是基于方面的情感分析(Aspect Based Sentiment Analysis, ABSA)。

所谓基于方面的情感分析，我们用一个例子来说明就可以。

The food here is delicious, but the serivce is terrible.

如果上面这句话是某个顾客对某家餐馆的评价，那么我们应该如何精确地描述这名顾客对餐馆的观点呢？

一个很显然的结论是，恐怕我们不能简单地将 delicious 或 terrible 作为顾客的态度代表，也不能简单地因为文本中出现了一个积极的词语和一个消极的词语，分别赋分1和-1，然后加起来得分为0，结论为情感中性。

但如果现在有一位饥肠辘辘的游人来到了这座城市，他更在乎食物的口味，但却对餐馆的服务态度毫不在意。现在，他正在手机上搜寻附近口味出众的餐馆，根据上述顾客的评论，我们能否将这家餐馆推荐给他呢？

通过上述这个案例，我们会发现，在现实中，我们面对的大量文本可能会同时描述多个实体(Entity)，例如上面出现在同一句话中的 food 和 serivce ，并表示出出截然相反的态度。然而，传统的方法无法准确地判别出隐藏在文本中的上述情感差异。

而通过对文本中不同的实体进行情感分析，就有可能发现人们在观点/意见(Opinion)上的差异。在上述例子中，顾客的评价是对餐馆不同方面/实体的观点存在差异，现实中包括新闻、媒体、文章等，可能都会对不同的事物存在不同的态度。通过发掘，可能发现上述差异，从而辅助决策。

(2025年11月更新) 基于CausalLM的实现方法

在CausalLM时代

两年前写下这篇文章时，GPT还是个新鲜事物，宛若天顶星科技一般，或许有人想过用GPT的API完成本文介绍的情感分析任务，但看在API价格的份上也还得慎重考虑。

两年后的今天，各种Decoder-Only架构的CausalLM获得了极其亮眼的进步，大模型也不再是少数公司的专利，开放权重的模型可以轻松获取，而LLM API的价格已经足够便宜。

在各种模型一路高歌猛进，卷着Agentic能力、Coding能力、Novelty的路上，本文所介绍的ABSA任务，被 “轻松地” 解决了，以更便宜更好的效果，像马儿扬鞭飞驰而去，徒留下一阵尘土。

回头来看，只是不由得感慨，这样的进步不可谓不日新月异哇。

实现案例

时至今日，这样的任务简单到只要是一个训练正常的CausalLM，哪怕参数量只有0.5B都能轻松解决，不仅分类效果好，支持多语言，对输出分类也可以极其轻松地自定义。

写了一个使用Qwen2.5-0.5B的示例，直接上代码和提示词：

# %%
from transformers import AutoTokenizer, AutoModelForCausalLM

# %%
model_id = "./Qwen2.5-0.5B-Instruct"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, dtype="auto", device_map="auto")

# %%
sentence = "The food here is delicious but the service is awful."
entity = "service"

prompt = f"""
Analyze the sentiment expressed toward the specified entity in the sentence. Classify it as exactly ONE of these categories: Happy, Sad, Angry, Surprise. Output only the category name.

Sentence: {sentence}
Entity: {entity}
"""

messages = [
    {
        "role": "system",
        "content": "You are Qwen, created by Alibaba Cloud. You are a helpful assistant.",
    },
    {
        "role": "user",
        "content": prompt
    },
]

text = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)

generated_ids = model.generate(**model_inputs, max_new_tokens=512)
generated_ids = [
    output_ids[len(input_ids) :]
    for input_ids, output_ids in zip(model_inputs.input_ids, generated_ids)
]

response = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0]
print(response)

事已至此，微调什么的都不需要了（笑）。

实现方法

搜索ABSA相关的应用方法，首先发现的是Azure提供的Sentiment analysis and opinion mining服务，刚好免费申请的Azure for Students权益包里似乎也能用这个API，只要把需要分析的文本上传，就可以得到分析的结果。

但思来想去，觉得光是调用API就没意思了。

继续搜索，发现HuggingFace上有很多训练好的模型，仔细一看，推理使用到的计算硬件资源也不大，在可以接受的范围内，于是决定试试在自己电脑上部署模型进行推理。

只是奈何自己也不会什么模型，最后还是得用其他人做好的模型来完成这项工作。不过倒也可以之后再改进吧。

这里我们使用的是DeBERTa V3模型，HuggingFace上已经有人使用ABSADatasets训练好了可用于ABSA任务的模型，请见yangheng/deberta-v3-large-absa-v1.1.

可以参考的其他模型

在情感分析方面，当然也有一些其他预训练好的模型可以使用，例如：

bhadresh-savani/distilbert-base-uncased-emotion: 尽管这并不是一个ABSA任务的模型，但其可以输出6种类别的情感。

部署细节

下面大致介绍一下本地部署模型的相关步骤和可能踩坑的地方。

获取模型

确保Git已经启用LFS扩展，然后执行如下命令：

1
2
3

GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/yangheng/deberta-v3-large-absa-v1.1
git lfs pull -I "model.safetensors"
git lfs pull -I "spm.model"

在我们使用的这一模型仓库里，我们需要拉取的是model.safetensors和spm.model两个文件，其中model.safetensors包含了模型主要的权重，因此不需要重复下载pytorch_model.bin权重文件。

本机环境

为了在本机上进行推理，需要创建一个Python环境，依赖如下：

这两个就是最简单的，使用CPU进行推理的配置了。稍后我们介绍不同模式时会再介绍其他模式下依赖的Python包。

运行推理

回到上面克隆的模型仓库目录的同一级目录下，创建一个.py文件（或者.ipynb，如果你喜欢），这里取名run.py。大致文件结构如下：

1
2
3

- MyABSA
  - deberta-v3-large-absa-v1.1/
  - run.py

编辑run.py文件，填入以下代码：

from transformers import AutoTokenizer, AutoModelForSequenceClassification, pipeline

model_path = "deberta-v3-large-absa-v1.1"

model = AutoModelForSequenceClassification.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
recognizer = pipeline("text-classification", tokenizer=tokenizer, model=model)

sentence = "[CLS] The food here is delicious but the service is awful. [SEP] service [SEP]"
recognizer(sentence)

这里我们传入模型的输入分为两个部分，前半段即为本文开头的餐馆评价示例，而后面，用[SEP]标志和主要文段内容分割开的，就是我们希望探知的情感的实体。

在上面的输入中，我们希望模型给出，前面语句对于service这个实体的态度。

运行上述代码，或许你会得到类似这样的输出：

1
2
3

[[{'label': 'Negative', 'score': 0.9997419714927673},
  {'label': 'Neutral', 'score': 0.00018644658848643303},
  {'label': 'Positive', 'score': 7.166137220337987e-05}]]

结果不难解读，模型给出的推理认为，前面的文本对service一词表现出的消极态度占据最主导的地位。

WebAPI化

为了便于对外设计接口，还可以将推理任务设计成WebAPI，对外暴露服务。

测试了一下使用ONNX Runtime进行的部署，甚至还测试了使用DirectML加速的ONNX Runtime，但似乎没啥用，测试下来尽管GPU占用是有了，但速度甚至比用numpy在CPU上的推理还要慢了。很大可能是我代码写的不好，数据在CPU和GPU之间反复倒腾了，导致速度上不去。

总之这一部分的代码，首先需要导出模型为ONNX格式，然后再放到这里进行加载。其实这部分内容主要是我想亲自动手看看，在pipeline中间到底发生了什么。实际使用其实并不用这样做的。

使用CPU进行推理的具体代码看下面吧，依赖项在引入部分已经写清楚了：

from fastapi import FastAPI, Depends, Request
from pydantic import BaseModel
from transformers import AutoTokenizer
from scipy.special import softmax
import json
import numpy as np
import onnxruntime

MODEL_DIR = "deberta-v3-large-absa-v1.1_onnx"

app = FastAPI()

def create_onnxruntime_infersess(model_file: str):
    print(f"Infering using {onnxruntime.get_available_providers()}")
    return onnxruntime.InferenceSession(model_file)

def create_tokenizer(model_dir: str):
    return AutoTokenizer.from_pretrained(model_dir)

def create_id2label_dict(model_config: str):
    with open(model_config, "r") as f:
        return {int(k): v for k, v in json.load(f)["id2label"].items()}

ort_infersess = create_onnxruntime_infersess(f"{MODEL_DIR}/model.onnx")
bert_tokenizer = create_tokenizer(MODEL_DIR)
id2label_dict = create_id2label_dict(f"{MODEL_DIR}/config.json")

def get_inference_session():
    return ort_infersess

def get_tokenizer():
    return bert_tokenizer

def get_id2label_dict():
    return id2label_dict

def predict(sentence: str, aspect: str):
    infsess = get_inference_session()
    tokenizer = get_tokenizer()
    id2label = get_id2label_dict()

    inputs = tokenizer(sentence, aspect, return_tensors="np")
    outputs = infsess.run(
        None,
        {
            "input_ids": inputs["input_ids"].astype(dtype=np.int64),
            "attention_mask": inputs["attention_mask"].astype(dtype=np.int64),
        },
    )
    pred_probs = softmax(outputs).flatten()
    return [(id2label[arg], pred_probs[arg]) for arg in np.flip(pred_probs.argsort())]

def get_predict_handler(request: Request):
    return predict

class SentimentAnalysisRequest(BaseModel):
    sentence: str
    aspect: str

@app.post("/analysis")
async def post_analysis(
    request: SentimentAnalysisRequest, predictor=Depends(get_predict_handler)
):
    sentence = request.sentence
    aspect = request.aspect

    result_list = predictor(sentence, aspect)
    return {
        "aspect": aspect,
        "mostlike_label": result_list[0][0],
        "mostlike_probability": f"{result_list[0][1]:.6f}",
        "full_result": [{"label": label, "prob": f"{prob:.6f}"} for label, prob in result_list],
    }

这将创建一个WebAPI，监听POST请求，请求主体是一个JSON格式的输入，包含sentence和aspect两个字段，前者是文本内容，后者就是希望获取态度的Aspect/Entity。

TODO

[]试着在预训练模型上进行fine-tune.
[]试着将推理过程运行在GPU上进行加速