面试记录：请谈谈一下你对大模型的看法

发表于 更新于 分类于 阅读次数： 本文字数： 1k 阅读时长 ≈ 4 分钟

前言

也许你一开始就在期待我开始讲什么self-attention。我承认，这已经算是必背科目，甚至算客观题了。

但是，从这个地方开始总归是有点追逐太阳的感觉，越追越累，还追不上。

所以，我们直接从太阳开始出发。

工作中遇到的大模型

目前因为各种各样的原因，接触到了昇腾平台，这个平台号称对大模型有着比较不错的支持。所以，我也尝试了一下在上面部署DeepSeek、Qwen以及各种闭源自研的央企大模型。

部署过程中，需要配置的包括tokenizer.json、tokenizer_config.json以及mindie_config.json，然后再去魔搭找到一个适配的模型，用mindieservice_daemon启动，就好了。默认配好的是localhost:8090端口，对外只需要控制docker映射即可。

这也算是运维角度的一个看法。

我们再深挖一下。

各种配置文件

mindie_config.json

比如说，mindie_config.json，这个能够配置MindIE中的一些配置，包括有模型名称（DeepSeek-R1-Dstill-Llama-70B）、显卡数量（$4$）、显卡设备编号（[0, 1, 2, 3]）等等。有了这些，MindIE就会创建HTTP服务，共发布$4$个接口，包括/generate、generate_stream、/v1/models、/v1/chat/completions。

其中，/generate和generate_stream使用较少，也不会检查model_name是否在mindie_config.json中存在；而/v1/models则会列出所有mindie_config.json中配置的模型名称。最后呢，也就是我们的常客，/v1/chat/completions。他会检查model_name是否在mindie_config.json中存在，而且会提供兼容OpenAI的接口。

tokenizer.json

tokenizer.json提供了完整序列化的Fast分词器，里面包含分词算法、词表、合并表、normalization、preprocessor、postprocessor等所有细节。

我们也经常能够在Huggingface、modelscope等网站中找到大模型参数的说明文件，其中说明文件也经常能够看到首先使用AutoTokenizer加载模型文件。就像这样：

1
2
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("/path/to/model")

首先呢，对于这个/path/to/model，我们首先检查是否存在config.json文件。依照这个文件，可以选出具体的分词器，这也是为什么模型文件中一旦缺少config.json文件就会报错的原因。

其次，在获取到分词器之后，还有一步，就是找到tokenizer.json文件进行反序列化，利用PreTrainedTokenizerFast构成tokenizer.Tokenizer对象。就像这样：

1
2
from transformers import PreTrainedTokenizerFast
tok = PreTrainedTokenizerFast(tokenizer_file="tokenizer.json")

这个对象最终就可以开始进行大模型的下一步了，也就是输出文段编号。就像这样：

1
out = tok(["some text", "more text"], return_tensors="pt", padding=True, truncation=True)

整个流程就是Normalizer->PreTokenizer->Model->Post-Processor->Output，从左到右功能依次是：

  • Normalizer：大小写、Unicode归一化等；
  • PreTokenizer：空白、字节级拆分等；
  • Model：此表、合并表、概率等；
  • Post-Processor：BOS、EOS、PAD、UNK等其他特殊分割、偏移对齐等；

后面可能还有一个decoder。

注：这里的Model指的是分词器的model，比如BERT的WordPiece模型。

tokenizer_config.json

除了tokenizer.Tokenizer对象，我们还需要一个tokenizer_config.json文件。它相当于是tokenizer.json的一个补充，里面记载了一些特殊分词器的配置，包括换行、结束等等。如果没有的话，大模型生成这些也就无法识别，更没办法进行所需要的特殊处理。

到这里，就是高级一点的运维了。

MindIE特性

当然，运维不光是运行部署，还有维护。显存爆了怎么办，并发不够怎么办之类的。我们也就可以从MindIE开始。

比如说，我们可以开启CPU的KV Cache缓存，帮助GPU减少KV Cache负担。

又比如说，我们可以修改npuMemSize，限制模型和KV Cache的显存占用，这样就会多一点点给到运行的并发。

如果显存不够的话，最大的影响就是大模型服务每秒的吞吐量，如果说极限吞吐量也只能达到16 tokens/s的话，这也就意味着最多最多也只有10字/秒的吞吐量，不优化将大幅降低用户体验。