AI | 边际效应 - 杨文博的个人博客 - 页码 2

估值最高的 AI 搜索独角兽 Perplexity 使用倒排索引做 RAG

3 月份我曾写了一篇博客《在 LLM 时代我们是否还需要倒排索引？》，探讨了在向量数据库崛起的情况下倒排索引仍然存在的价值。

也许仍然有人对传统搜索技术弃如敝履，但前几天我正好看到一个 Lex Fridman 对 Perplexity CEO Aravind Srinivas 的采访，他表示 Perplexity 仍然使用（可能不是仅使用）倒排索引和 BM25 传统算法进行全网搜索。作为估值 30 亿美元的 AI 搜索独角兽公司，在全网搜索上却也选择了倒排索引，而且访谈中非常强调倒排的重要性，这应该算是印证了我的观点吧。

他的这些思考对我也有一些启发，为了保持互联网的记忆，我将这些相关节选的原文和翻译记录如下：

Aravind Srinivas 2024年6月20日采访节选

这个 Podcast 有 3 个小时，可以从 2:03:52 开始看。

Lex Fridman (02:03:52)

这是一个通过（将内容）嵌入到某种向量空间实现的完全的机器学习系统吗？
Is that a fully machine learning system with embedding into some kind of vector space?

Aravind Srinivas (02:03:57)

它并不是纯粹的向量空间。并不是说内容一旦被获取，就会有某种 BERT 模型在所有内容上运行并将其放入一个巨大的向量数据库中进行检索。
It’s not purely vector space. It’s not like once the content is fetched, there is some BERT model that runs on all of it and puts it into a big, gigantic vector database which you retrieve from.

这并不是那样的，因为将网页的所有知识打包到一个向量空间表示中是非常困难的。首先，向量嵌入在处理文本时并没有想象中的那么神奇。理解一个文档是否与一个特定检索词相关非常困难。它应该是与检索词中的人物有关，还是与检索词中的特定事件有关，更或者它是基于对检索词更深层次的理解，使得检索词可以应用到另外一个人物，他也需要被检索到？什么才是（向量）表示应该捕捉的内容？大家可能会不断争论。而让这些向量嵌入具有不同维度，彼此解耦并捕捉不同语义是非常困难的。
It’s not like that, because packing all the knowledge about a webpage into one vector space representation is very, very difficult. First of all, vector embeddings are not magically working for text. It’s very hard to understand what’s a relevant document to a particular query. Should it be about the individual in the query or should it be about the specific event in the query or should it be at a deeper level about the meaning of that query, such that the same meaning applying to a different individual should also be retrieved? You can keep arguing. What should a representation really capture? And it’s very hard to make these vector embeddings have different dimensions, be disentangled from each other, and capturing different semantics.

顺便说一句，这只是排序部分的内容。还有索引部分——假设你有一些处理后的 URL，排序模块会基于你提问的检索词，从索引中召回相关的文档和一些打分。这就是为什么，当你的索引中有数十亿个页面，而你只需要前 K 个结果时，你必须依赖近似算法来获取这些前 K 个结果。
This is the ranking part, by the way. There’s the indexing part, assuming you have a post-process version for URL, and then there’s a ranking part that, depending on the query you ask, fetches the relevant documents from the index and some kind of score. And that’s where, when you have billions of pages in your index and you only want the top K, you have to rely on approximate algorithms to get you the top K.

Lex Fridman (02:05:25)

所以这就是排序，但是将页面转换为可以存储在向量数据库中的内容，这一步似乎非常困难。
So that’s the ranking, but that step of converting a page into something that could be stored in a vector database, it just seems really difficult.

Aravind Srinivas (02:05:38)

它并不必须全存在向量数据库中。你可以使用其他数据结构和其他形式的传统检索。有一种算法叫做 BM25，它正是为此设计的，是 TF-IDF 的一个更复杂的版本。TF-IDF 是词频乘以逆文档频率，是一种非常老派的信息检索系统，实际上即使在今天也仍然非常有效。BM25 是它的一个更复杂的版本，仍然在许多排名中击败大多数嵌入。当 OpenAI 发布他们的嵌入时，围绕它有一些争议，因为在许多检索基准测试中，它甚至没有击败 BM25，这并不是因为他们做得不好，而是因为 BM25 太好了。这就是为什么仅靠纯粹的嵌入和向量空间并不能解决搜索问题。你需要传统的基于词项的检索，你需要某种基于 NGram 的检索。
It doesn’t always have to be stored entirely in vector databases. There are other data structures you can use and other forms of traditional retrieval that you can use. There is an algorithm called BM25 precisely for this, which is a more sophisticated version of TF-IDF. TF-IDF is term frequency times inverse document frequency, a very old-school information retrieval system that just works actually really well even today. And BM25 is a more sophisticated version of that, that is still beating most embeddings on ranking. When OpenAI released their embeddings, there was some controversy around it because it wasn’t even beating BM25 on many retrieval benchmarks, not because they didn’t do a good job. BM25 is so good. So this is why just pure embeddings and vector spaces are not going to solve the search problem. You need the traditional term-based retrieval. You need some kind of NGram-based retrieval.

Aravind Srinivas 2023年12月14日采访节选

其实在去年 Unsupervised Learning 的 Jacob Ephron 采访 Aravind Srinivas 时，他也有过类似的表述，但是没有像最新一次采访那样强调倒排的重要性。这个 Podcast 也很长，可以从 28:08 开始看。

Aravind Srinivas (28:08)

很多人认为，既然我们在网页搜索的 RAG 方面如此擅长，那么 Perplexity 就能轻松搞定内部搜索。不，这是完全不同的两回事。
A lot of people think that because we are so good at RAG for web search, Perplexity will just nail internal search. No, it's two completely different entities.

Google Drive 的搜索之所以糟糕是有原因的。你可能会想，Google作为网页搜索的王者，怎么会这么差劲？他们之所以差劲，是因为索引机制完全不同，需要训练的嵌入模型也完全不同。这不仅仅是嵌入模型的问题，还包括你如何对页面进行摘要、如何进行文本召回——如何使用传统的基于TF-IDF的倒排索引来构建弹性索引，这些都大不相同。
There is a reason why search on Google Drive sucks. Like would you expect Google the king of web search to be so bad? They're bad because of a reason that the indexing is so different, the embeddings that you got to train are so different. Not just the embeddings, but even the way you snippet a page, your text retrieval——the elastic index that you're building with traditional TF-IDF based inverted indexes are so different.

所以需要某家公司专注于这种场景，就像我们专注于网页搜索场景一样。RAG 是一项非常艰巨的任务，在生成式 AI 之外还有很多工作需要完成。这不仅仅是训练一个大型的嵌入模型就能解决的问题。
That you need a company to just obsessively focus on that use case. Just like how we are obsessively focused on the web search use case. So RAG is going to be pretty hard and there's a lot of work that needs to be done outside of generative AI. It's not just training a large embedding model and you're done.

我记得当 OpenAI 发布嵌入 API 时，Sam Altman（OpenAI的CEO）在推特上说，下一个万亿公司可能只需要接入这个 API 就可以建立起来。这虽然是一种很好的营销方式，但事实并非如此。他当时说的是一万亿美元。所以，当听到有人声称他们已经解决了 RAG 问题时，我会非常谨慎。他们可能只是在某个场景下做得很好。
I remember like when OpenAI releases embedding API, Sam Altman tweeted the next 1 trillion company can just plug into this API and be built. That's not true. It's a good way to market it. But that's not true at all. Sorry, he said 1 trillion dollars. So I think that's why I would be very careful when somebody makes claims that they've solve RAG. They probably can do it really well for one use case.

此外，在排名中还有很多其他因素需要考虑，才能使答案真正出色。即使 LLM 最终决定了哪些链接用于答案，你也不能仅仅将一些垃圾信息放入 prompt 中，就指望它能神奇地只选择最相关的链接，并在答案中给出引用。
You know and also there are so many more things to handle in the ranking. That'll make the answer really good. Cuz even though the LLMs are finally the ones that are taking which links to use for the answer, it's not like you can just dump garbage into the prompt and it'll just be magically so good that it'll only take the top most relevant links in the answer and give you the citations with them.

事实上，你向这些长上下文模型提供的信息越多，最终出现幻觉的可能性就越大。因此，你实际上需要在检索模块上投入大量工作，不仅仅是嵌入向量，在索引、嵌入向量和排序上都要投入。排序也应该包含很多除了向量内积之外的其他信号，具体是哪些信号事实上取决于你的场景。
In fact the more information you throw at these really long context models, the more chances that you have a hallucination at the end. So you actually have to do a lot of work in the retrieval component, not just the embeddings, the indexing, the embeddings and the ranking. Ranking should also have a lot of signals outside of just the vector dot products. And then what is those signals are really depend on your use case.

分析（在2024年8月）

从以上不同时期 Aravind 的公开披露的信息分析，几乎可以说 Perplexity 在当前时间点，在召回阶段主要（如果不是全部的话）依赖倒排索引，在排序阶段会用到嵌入向量和其它信号，并且他们很重视除了嵌入向量之外的其它信号。

LLM 推理优化 Prefix Caching 及其实现

Prefix Caching

上文中提到，Prompt 计算（Prefill 阶段）和生成阶段的计算特性很不相同。为避免重复计算，所有框架的 prefill 阶段主要作用就是给迭代的生成阶段准备 KV Cache。但这些 KV Cache 仅仅是为单次生成式请求服务的，那很自然的一种想法就是，KV Cache 能不能跨请求复用？

在某些场景下，多次请求的 Prompt 可能会共享同一个前缀（Prefix），比如拟人 Agent 的人物设定，文档阅读理解时的文档内容等。这些情况下，很多请求的前缀的 KV Cache 计算的结果是相同的，像一般互联网服务的请求缓存一样，可以被缓存起来，给下一个请求复用。

限制

但 KV Cache 跟其它服务缓存不一样的地方是，它太大了，以至于（目前）很难通过 Redis/Memcache 这种分布式缓存服务存取。比如对 13B LLM 模型来说，在 FP16 精度下单 token 的 KV Cache 大约是 1MB，假设要缓存的前缀有 500 个 token（大约800多个汉字），那就是 500MB。一般来说，我们不会每次请求去从分布式系统里读取/传输 500MB 的缓存，甚至都不会每次请求从内存往显存中拷贝 500MB 的缓存，所以大部分情况下，prefix cache 都会放在显存里。

这也就意味着，如果你想命中 prefix cache，必须把相同 prefix 的请求发到同一张 GPU卡上才行。

实现

由于不是普遍需求，加上前面说的限制，prefix caching 作为一个加速特性，不是很受关注，一般也不是默认开启的。各框架的实现和配置略有差异，这里简单做下记录，便于回顾。

刚开始 vLLM 的实现是给 generate 接口增加一个 prefix_pos 参数，通过 prefix_pos 输入参数为每个请求指定 prefix 长度，为 prefix 建一个带淘汰的哈希缓存。后来觉得这样做使用上不够便利，升级成了自动前缀缓存，即将 prompt 的 kv cache 分成 block，然后为 block 建设 LRU 缓存机制，这样就不必在接口上使用 prefix_pos 指定哪部分是 prefix 了。自动前缀缓存功能默认是不开启的，开启的配置项为 --enable-prefix-caching 。

TensorRT-LLM 与 vLLM 后来的实现类似，也是实现了 block kv cache，配置项是 enableBlockReuse，默认也是不开启的。代码未开源，无法看到实现。

Lmdeploy 的 Python 和 TurboMind C++ 版本的 prefix caching 功能都已经有了 PR，但现在（20240425）看还没有合入主干。有意思的是它没有使用 hash block 对应 token_id 子串的所有 token_id 前缀然后组成哈希表的方式，而是用 hash 当前 block 对应的 token_id 子串然后组成 trie 树的缓存管理结构。默认的参数名与 vLLM 相同，也叫做 --enable-prefix-caching。

HuggingFace TGI 现在看起来还没实现 Prefix Caching 功能。

Prompt Caching

除了 Prefix Caching 这种比较直观的工程优化，现在也有一些研究在看 Prompt 的其它缓存机制。比如设计一种机制让 prompt 模块化，不仅可以复用 prefix，还能复用中间的部分；或者通过 query 的相似性复用其它 query 的 prompt。

但目前看实现上都过于复杂，比如第一种要求模型使用不连续的 poition_id，这样就可以插入 token，但这种方式对 attention 的计算机制有一定的影响，难以说明它对效果的影响。

LLM 推理优化 Continuous Batching 及其实现

原理

Continuous Batching 是 LLM 推理优化的一项技术，作为这篇文章的知识背景不再赘述，目前流传最广的参考资料是这篇：《How continuous batching enables 23x throughput in LLM inference while reducing p50 latency》。它也有中文翻译，感兴趣可以搜一下，先看看。

虽然这篇资料介绍了它的主要原理，尤其是这张简单易懂的图，但是实现与原理是存在差异的，因为工程实现要解决很多现实问题。

(Re)scheduling 开销

如原文所说，Continuous batching 还有个别名，叫做：batching with iteration-level scheduling，这里的 iteration 就是指一次 decode 计算。也就是说在每次 decode 的迭代过程中，做 batch 的调度调整。

但调度本身不是无代价的，它可能涉及到接收和处理新的输入请求，重新组织输入数据的形状，甚至各种状态的重新初始化，这些都需要消耗 CPU 时间。这也就意味着在这段时间里，GPU 是闲着的，GPU 没有得到充分利用。

所以在实现时，程序并不会真的每个 iteration 都做 scheduling，目前看到有两种做法：

合理间隔调度。比如每 16 次 decode 计算后，检查一下是否有新的输入，以及是否有空闲的槽位，然后对 batch 做一次调度调整。这能够显著降低调度的开销（TGI、lmdeploy、vLLM）。
排队比例调度。比如当前 batch 中有 10 个请求的 decode 正在进行，而排队中有 12 个请求，超过了排队比例 1.2，那么就启动一次调度调整（TGI）。

KV Cache 重读

如果真的像图中那样，每个生成 Token 的 decode iteration 与一个 prompt token 的计算对齐，那 KV Cache 的利用就会很糟糕。因为它们需要在 Global Memory 与 Shared Memory 之间反复搬运，而且每次搬进来以后只被使用一次。

这本质上是 prefill 阶段（prompt 计算）与生成阶段的计算特性不同导致的，prefill 阶段并不适合 one-by-one 的 token 计算。

所以在实现时，程序并不会真的做 prefill 和生成的 token 对齐调度。目前看到的调度方法有三种：

在重调度时，如果有新的请求进来，那么将新请求的 prefill 计算和要进行的 decode 计算做合并（Orca、vLLM-prev）。
在重调度时，如果有新的请求进来，那么先对新的请求做 prefill 计算，然后再合并所有进行中的请求做 decode 计算（TGI、vLLM、lmdeploy）。
先根据 decode 耗时估算出来每次 decode 同时能做 prefill 的 token 数量，在重调度时，如果有新的请求进来，对新请求的 prefill 按照上面的估算进行分块，然后将分块的 prefill 和其它请求的 decode 计算融合在一起，一定程度上减少了 KV Cache 重读的次数，又避免先做 prefill 计算带来的 Token 生成延时增加（Sarathi-Serve+vLLM）。

可调优能力

LLM 推理服务往往用于生产环境，而生产环境面临的情况是复杂多样的。

对于做阅读理解的应用来说，Prompt 可能会非常长，但生成的内容可能会非常短，开发人员可能会更追求吞吐；
对于聊天应用来说，Prompt 可能较短，生成的内容也不会太长，开发人员可能会更追求延迟；
对于创作类应用来说，Prompt 可能很短，生成的内容会更长，开发人员可能会更追求首 Token 延迟。

对 Continuous Batching 实现来说，就要求它调度策略尽量清晰，并且参数可调。所以更灵活的实现，未来可能会更受欢迎。

Logits of API-Protected LLMs Leak Proprietary Information

看到一篇挺有意思的论文，大开脑洞，没想到还能这么玩，做一下粗读的笔记。

论文

标题：《Logits of API-Protected LLMs Leak Proprietary Information》，链接： https://arxiv.org/pdf/2403.09539.pdf 。

假设条件

典型 LLM 需要将最后一个 Transformer 块输出的嵌入向量转成要输出的 Token，这一步往往通过一个线性变换加 softmax 获取那个最大概率的 tokenid。

线性变换的权重是一个 vocabulary size * hidden size 的矩阵，比如 llama2-7B 的词表大小是 32000，hidden size 是 4096，那么线性变换权重矩阵的尺寸就是 32000x4096。这个矩阵再与 4096x1 的嵌入向量相乘，得到的就是 32000x1 的 logits 向量，其中每一个元素对应着一个词表中的 token 作为最终输出的概率。

上面这只是假设，也许 GPT 使用的是一个非线性变换，那论文内容可能就不成立了。

数学原理

这个线性变换将一个 4096 维的向量映射到了一个 32000 维的向量，从线性代数的角度来看，这是一个低维向高维的映射，所以它肯定不是一个满射（onto mapping）。也就是说，这个映射的像空间（image）只是 32000 维实数空间的一个子空间（subspace），而且这个像空间的秩（rank）最多是 4096。

这意味着可以找到不多于 4096 个线性无关的基向量（basis），使得这个像空间的每一个元素都能表示为这些基向量的线性组合。假设能采集到 4096 个线性无关的输出 logits，那这些 logits 就构成了像空间的一组基向量。

反过来想，如果你不知道 LLM 的 hidden size，那么你可以通过采集足够多的输出 logits，以保证有足够多的线性无关的向量。然后对矩阵进行奇异值分解（singular value decomposition），可以通过非 0 的奇异值个数推导出矩阵的秩。这个秩应该接近于模型的 hidden size。

逆向恢复 logits

遗憾的是，很多模型的 API 并没有输出完整的 logits 矩阵，但幸运的是，OpenAI 的 API 支持输出最多 top 5 个 token 的 logprobs，并且支持 logit_bias 干预 token 的输出。那就给了反复通过 API 调用来逆向恢复 logits 向量的可能。

但是具体方法我没看，粗读嘛，知道能做到就行了，有用到的时候再看吧。还有另一篇文章《Stealing Part of a Production Language Model》分析了在没有 logit_bias 甚至没有 logprobs 时该如何恢复 logits，我也没看，记录下链接 https://arxiv.org/pdf/2403.06634.pdf 。

无法输出的 Token

这篇论文还介绍了很多其它应用，太长没有看。比较有意思的一个引用是，在将嵌入向量映射到 logits 的过程中，如果一个 token 的嵌入向量在其它 token 的嵌入向量组成的凸包的内部，它就永远不可能被输出。扫了一眼引用的论文，证明没看懂，大致意思是 softmax 权重矩阵的低秩特性导致了可能输出 token 的排列在线性变换后不会出现在子空间里？实话说我感觉不像是很严谨的数学证明。。。

在 LLM 时代我们是否还需要倒排索引？

近些年，EBR（基于文本嵌入向量的召回）的强大语义召回能力让基于属性索引的传统倒排索引技术黯然失色，即使对专业搜索引擎来说，EBR 的应用也是越来越广泛 [1,2,3] 。尤其在 LLM（大语言模型）激起的 RAG（检索增强生成）技术框架下，大部分人似乎已经忘记了倒排索引，向量数据库成为 RAG 的标配。

但在 LLM 时代倒排索引真的没有用武之地了吗？我尝试列一下自己的思考。

Embedding 向量缺少 ground truth，但是倒排有。你无法通过直接观察或者测量，来明确一个向量指代的一段文本是否一定包含某些信息。但是如果这段文本在某个 term 的倒排拉链里，你可以从一定程度上明确这段文本包含了一些相关信息。
term 命中也是一种 attention。在训练模型时，我们总是希望 LLM 能关注到 context 中应该关注的信息，而忽略其它无关内容。那跟用户问题或者指令中某些 term 相关的内容，应该需要更多的关注。其实也可以类比人类肉眼的信息查找，人们也总是会扫到某些关键词，然后再仔细阅读它的上下文篇章。
不基于倒排做召回，仍可以用倒排做粗筛。倒排作为一种可以查询 term 命中的高效结构，对 EBR 也许可以起到补充作用。例如对于某些 EBR 效果不够理想，误召回概率较高的场景下，对得分比较低的文档用命中信息作一次粗筛，能显著提升送给模型的 context 质量，也能减少对 LLM 计算资源的浪费。
term 命中的位置信息和权重不再重要。对于 LLM 来说，它会自行关注到 context 中需要关注的信息，不再需要位置信息或者权重来指示文本中哪些部分更重要。也就是说，倒排只需要解答 term 在文本中是否出现的问题，而不需要回答出现几次、在哪里出现的问题。
也许倒排不再用 term，而是 token。term 依赖于切词，有一定的语义含义，term 集合空间一般有百万甚至千万的量级。但现在 LLM 大部分使用 BPE（Byte-Pair Encoding）分词器，token 集合空间只有几万到十几万的量级。使用 token 将显著减少倒排链的数量而优化其性能，但 token 存在没有归一化、分词边界不对齐的问题，是否可用还有待验证。

参考

[1] Guo, Ruiqi, et al. "Accelerating large-scale inference with anisotropic vector quantization." International Conference on Machine Learning. PMLR, 2020

[2] Huang, Jui-Ting, et al. "Embedding-based retrieval in facebook search." Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2020.

[3] Liu, Yiding, et al. "Pre-trained language model for web-scale retrieval in baidu search." Proceedings of the 27th ACM SIGKDD Conference on Knowledge Discovery & Data Mining. 2021.

配置 dcgmi 遇到的问题

dcgmi 是 Nvidia datacenter-gpu-manager 的命令行程序，可以用来采集 GPU 各类子资源的利用率数据，揭示的数据比 nvidia-smi 更详细，也更便于对接监控系统（比如 Prometheus）。这次我主要想用它来看模型训练过程中的 NVLink 带宽使用情况。

在一个已经完成 Nvidia 训练环境配置的服务器上安装 dcgmi，主要有以下几步：

1. 如果服务器上有 NVSwitch，比如 A100/800，或者部分 V100，需要先安装 nvidia-fabric-manager，注意 nvidia-fabric-manager 的版本要和 GPU 驱动版本严格一致，包括小版本号（nvidia-smi 显示的驱动版本）。

2. 如果服务器上有 NVSwitch，还需要安装 libnvidia-nscq，版本也要和驱动严格一致。

3. 安装 datacenter-gpu-manager。

4. 启用并启动 nvidia-fabricmanager 服务，注意服务名(nvidia-fabricmanager)、包名(nvidia-fabric-manager)和进程名(nv-fabricmanager)的区别。根据启动成功与否，可检查 /var/log/fabricmanager.log 中的错误信息。

systemctl enable nvidia-fabricmanager
systemctl start nvidia-fabricmanager

5. 启用并启动 nvidia-dcgm服务，注意包名(datacenter-gpu-manager)、服务名(nvidia-dcgm)和实际命令/进程名(nv-hostengine)的区别。根据启动成功与否，可检查 /var/log/nv-hostengine.log 中的错误信息。

systemctl enable nvidia-dcgm
systemctl start nvidia-dcgm

但是整套配置下来，我还是遇到了不少问题，有些是配置问题，有些是文档未明确说明的问题。甚至我找到 Nvidia 的售后工程师咨询，他们都没法给我答案，后来还是我自己摸索出来了，做个记录。

1. nvidia-dcgm 服务启动成功，但又没完全成功

启动服务时候没有报错，但是执行监控命令时出错，其实启动的时候 /var/log/nv-hostengine.log 就已经出现无法加载 nscq 库的错误，只不过没影响服务的启动。因为 nscq 是对 nvswitch 的查询，用户如果不需要查询 nvswitch 的数据，可以接受这个错误。

ERROR [13862:13862] [[NvSwitch]] Could not load NSCQ. dlwrap_attach ret: Can not access a needed shared library (-79): If this system has NvSwitches, please ensure that the package libnvidia-nscq is installed on your system and that the service user has permissions to access it. [/workspaces/dcgm-rel_dcgm_3_3-postmerge/modules/nvswitch/DcgmNvSwitchManager.cpp:798] [DcgmNs::DcgmNvSwitchManager::AttachToNscq]
ERROR [13862:13862] [[NvSwitch]] AttachToNscq() returned -25 [/workspaces/dcgm-rel_dcgm_3_3-postmerge/modules/nvswitch/DcgmNvSwitchManager.cpp:632] [DcgmNs::DcgmNvSwitchManager::Init]
ERROR [13862:13862] [[NvSwitch]] Could not initialize switch manager. Ret: DCGM library could not be found [/workspaces/dcgm-rel_dcgm_3_3-postmerge/modules/nvswitch/DcgmModuleNvSwitch.cpp:34] [DcgmNs::DcgmModuleNvSwitch::DcgmModuleNvSwitch]

虽然我已经安装了 libnvidia-nscq 库，但 nv-hostengine 就是找不到 NSCQ 对应 so。我在这个问题上困扰了很久，Nvidia 的工程师也没法给我解释原因，只是一遍一遍地让我去看文档，甚至重装系统。

我觉得他的建议不靠谱，后来还是自己找到了原因，那就是 datacenter-gpu-manager 对 libnvidia-nscq 也有隐式的版本依赖。虽然在文档和包依赖中完全没有体现这种依赖关系，但我通过降级 datacenter-gpu-manager 到与 libnvidia-nscq 时间上更接近的版本解决了这个找不到 so 的问题。

之所以想到去尝试降级版本，还是因为 Nvidia 各种环境和驱动版本的强绑定，让我免不了去怀疑一下这个。

2. 查询部分指标 DCGM_FI_PROF_* 时出错

在执行 dcgmi dmon -e 449,1011,1012 时，命令行显示如下错误：

Error setting watches. Result: The third-party Profiling module returned an unrecoverable error

查看 /var/log/nv-hostengine.log，有如下错误日志：

ERROR [225876:233276] [[Profiling]] [ProfModule][PerfWorks] Got status 1 from NVPW_DCGM_PeriodicSampler_BeginSession() on deviceIndex 0 [/workspaces/dcgm-rel_dcgm_2_3-post
merge/dcgm_private/modules/profiling/DcgmLopGpu.cpp:351] [DcgmLopGpu::BeginSession]
ERROR [225876:233276] [[Profiling]] EnableMetrics returned -37 The third-party Profiling module returned an unrecoverable error [/workspaces/dcgm-rel_dcgm_2_3-postmerge/dc
gm_private/modules/profiling/DcgmModuleProfiling.cpp:2461] [DcgmNs::Modules::Profiling::DcgmModuleProfiling::ReconfigureLopGpu]
ERROR [225876:233276] [[Profiling]] Unable to reconfigure LOP metric watches for GpuId {0} [/workspaces/dcgm-rel_dcgm_2_3-postmerge/dcgm_private/modules/profiling/DcgmModu
leProfiling.cpp:2545] [DcgmNs::Modules::Profiling::DcgmModuleProfiling::ChangeWatchState]

导致这个错误的原因是对于这些 Profile 指标（1001-1014 ），NV 的 Profiler 对每个硬件使用了一个唯一锁。当你启动了超过 1 个的 nv-hostengine （包括内建的），比如使用 NCGM-Exporter 容器时，已经启动了一个内建的 nv-hostengine，然后又在主机上又启动了一个 nv-hostengine 服务，在访问这些指标时，就会出现这种访问失败。解决方案就是一台服务器仅启动一个 nv-hostengine 服务，然后所有的客户端都用本地或者远程的方式去访问它（5555 端口）。

这类问题在云场景下可能更常见，因为云服务商可能已经在租用的 GPU 服务器上部署了 DCGM 监控，你再去部署就可能遇到硬件锁的问题。

3. DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL 的单位

我最早看到这个指标是在 NCGM-Exporter 的输出指标中，但是无论是文档、配置文件还是输出接口中，都没有写明这个指标的单位和计算逻辑。我问 Nvidia 的售后工程师，他告诉我这个指标的单位是 B/s，LoL！

后来仔细查 NCGM 的文档，发现 NCGM-Exporter 的所有指标其实都源自 NCGM 的接口，但还是没看到这个指标的单位和计算逻辑。

最后使用 dcgmi dmon -e 449,1011,1012 做了一下对比，才发现其输出头中有个不起眼的 MB 字样：

#Entity   NBWLT                       NVLTX                       NVLRX
ID       MB/

我做了一下数字的校验，基本可以明确 DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL[449] 约等于 (DCGM_FI_PROF_NVLINK_TX_BYTES[1011] + DCGM_FI_PROF_NVLINK_RX_BYTES[1012]) / 1048576，所以单位应该是 MB/s 。

4. NCGM-Exporter 的采集延迟和精度

用 docker 跑 NCGM-Exporter 镜像时，发现指标的输出非常慢，输出的值看起来也很奇怪。后来自己构建了一下，研究了一下命令行参数，才发现默认采集的周期是 30s 一次。这种采样精度下，输出的指标值能准确才怪了。正常 dcgmi 采样的频率是 1s 一次，最低可以配置到 100ms 一次。NCGM-Exporter 有命令行参数可以调整这个采样频率，但需要你自己用修改 Dockerfile 去重建镜像。或者可以考虑启动的时候将启动脚本映射到外部文件？没尝试。

GPT-2 Tokenizer 效率观察

对基于 Transformer 结构的 LLM （大语言模型）来说，模型的输入输出都是 Token（词元）。一段输入文本，首先要经过 Tokenizer（分词器）切分成 Token 再输入给模型。

不同的 Tokenizer 会把文本按不同的边界切分，那一段文本到底会被切成几个 Token 就体现了 Tokenizer 本身的效率，这本身也是信息论的讨论范畴。不过今天不做理论分析，也不介绍 Tokenizer 的训练算法，就看下 GPT-2 和 GPT-3 Tokenizer 的实际分词效率（GPT-2 和 GPT-3 使用的是同样的 Tokenizer）。

用 GPT-2 Tokenizer 编码一段中文

from transformers import GPT2Tokenizer

tokenizer = GPT2Tokenizer.from_pretrained('gpt2')
input_str = '不同的 Tokenizer 会把文本按不同的边界切分，那一段文本到底会被切成几个 Token 就体现了 Tokenizer 本身的效率，这本身也是信息论的讨论范畴。'
tokenids = tokenizer(input_str)['input_ids']
raw_tokens = tokenizer.convert_ids_to_tokens(tokenids)
token_strs = [tokenizer.convert_tokens_to_string([token]) for token in raw_tokens]
print(len(input_str), len(tokenids), tokenids, token_strs)

82 121 [38834, 28938, 234, 21410, 29130, 7509, 220, 27670, 248, 162, 232, 232, 23877, 229, 17312, 105, 162, 234, 231, 38834, 28938, 234, 21410, 164, 122, 117, 45911, 234, 26344, 229, 26344, 228, 171, 120, 234, 165, 224, 96, 31660, 162, 106, 113, 23877, 229, 17312, 105, 26344, 108, 41753, 243, 27670, 248, 164, 95, 104, 26344, 229, 22755, 238, 49035, 254, 10310, 103, 29130, 10263, 108, 109, 19526, 241, 163, 236, 108, 12859, 228, 29130, 7509, 42164, 105, 164, 118, 104, 21410, 46763, 230, 163, 236, 229, 171, 120, 234, 32573, 247, 17312, 105, 164, 118, 104, 20046, 253, 42468, 46479, 94, 162, 223, 107, 164, 106, 118, 21410, 164, 106, 101, 164, 106, 118, 164, 234, 225, 45911, 112, 16764] ['不', '�', '�', '的', ' Token', 'izer', ' ', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '不', '�', '�', '的', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '一', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', ' Token', ' �', '�', '�', '�', '�', '�', '�', '�', '�', '�', ' Token', 'izer', ' �', '�', '�', '�', '�', '的', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '是', '�', '�', '�', '�', '�', '�', '�', '�', '的', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '�', '。']

输入的中英文夹杂的字符串长度为 82 个字符，其中有 6 个空格，23 个英文字符（3个单词），3个标点符号，50 个汉字字符。最终编码出来的 tokenids 长度是 121 个 Token，仔细检查可以看到，大部分汉字被编码成两个 Token，英文则是按照 subword 级别进行了编码。由此可见，GPT-2 Tokenizer 编码中文的效率是很低的。

GPT-2 Tokenizer 词典中包含中文的 Token 数量

import re
tokens = [tokenizer.convert_tokens_to_string([key]) for key in tokenizer.get_vocab()]
cn_tokens = [t for t in tokens if re.search(u'[\u4e00-\u9fff]', t)]
cn_tokens.sort(key=len, reverse=True)
print(len(tokens), len(cn_tokens), cn_tokens)

50257 51 [' 裏覚醒', ' 裏�', '��士', '龍喚士', ' 裏�', '龍契士', '��極', ' 裏', '龍�', '�醒', '覚醒', 'の魔', '�士', '龍�', ' 神', '龍', '神', '士', '魔', '的', '人', '天', '王', '一', '大', '装', '田', '子', '戦', '生', '者', '不', '姫', '中', '上', '闘', '是', '女', '方', '作', '黒', '之', '使', '光', '代', '版', '三', '五', '武', '将', '機']

对 GPT-2 Tokenizer 词典中的 Token 进行分析，可以看到：在数量为 50257 大小的词典中，只有 51 个 Token 包含常见的中文字符。上一节中出现的“是”、“的”、“不”也在其中，但是大家随便一想就能想到的，常见的“你”、“我”、“他”并不在内。这些数据印证了它对中文分词的效率低下。

GPT-2 Tokenizer 词典中包含英文的 Token 数量

en_tokens = [t for t in tokens if re.search(u'[A-Za-z]', t)]
en_tokens.sort(key=len, reverse=True)
print(len(en_tokens), en_tokens[:10])

46949 ['rawdownloadcloneembedreportprint', 'BuyableInstoreAndOnline', 'cloneembedreportprint', ' RandomRedditorWithNo', ' telecommunications', ' disproportionately', ' guiActiveUnfocused', 'channelAvailability', ' Telecommunications', ' externalToEVAOnly']

但是针对英文字符进行统计，可以看到在数量为 50257 大小的词典中，有 46949 个 Token 包含 26 个英文字母。由于数量太多，这里仅输出了长度排前 10 的英文 Token。

从 Tokenizer 词典中不同语言字符的分布，我们可以验证 GPT-3 论文 “Language Models are Few-Shot Learners” 中提到的这句话：

... This could be a weakness due to reusing the byte-level BPE tokenizer of GPT-2 which was developed for an almost entirely English training dataset.

GPT-2 Tokenizer 词典中最长的 Token 是什么

tokens.sort(key=len, reverse=True)
print(len(tokens), tokens[:10])

50257 [' =================================================================', ' ----------------------------------------------------------------', '----------------------------------------------------------------', '................................................................', '================================================================', '________________________________________________________________', 'ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ', '--------------------------------------------------------', '------------------------------------------------', ' =================================']

可以看到，最长的 Token 居然是一些连续的标记，看起来像是论坛上的分割线。在“Natural Language Processing with Transformers” 一书中说，这可能是由于 GPT-2 的词典是用以 Reddit 为核心的语料训练的。

Codex Tokenizer 提升代码处理效率的 Trick

上面讲到 Tokenizer 效率对最终生成 Token 序列大小的影响，如果只关注最终的模型效果，可能并不在意中间过程的效率问题。

但从一个小点可以看到 OpenAI 还是很重视 Tokenizer 效率的。在训练 Codex 时，它在 50257 的词典之外新增了 23 个 Token，分别编码了：[2个连续空格, 3个连续空格, ..., 23个连续空格]。

大家都知道，代码中有很多锁进和对齐，如果每个空格都编码成一个 Token，训练和推理的效率就会极低；如果像常规语言模型那样忽视更多连续的空格，又会导致生成的代码不可读，甚至对 Python 这样的语言来说代码完全不可理解。所以 OpenAI 专门修改了 Tokenizer 的词典，提升了对连续空格的编码效率。

在中文数据集上训练的 Tokenizer 表现如何？

同样使用第一节的代码，我们换一个在中文数据集上训练的 Tokenizer，效果会如何呢？我随便在 HuggingFace 上找了一个模型 HuiHuang/gpt3-base-zh，使用它的 Tokenizer 对那段话进行重新分词。

from transformers import BertTokenizerFast

tokenizer = BertTokenizerFast.from_pretrained("HuiHuang/gpt3-base-zh")
input_str = '不同的 Tokenizer 会把文本按不同的边界切分，那一段文本到底会被切成几个 Token 就体现了 Tokenizer 本身的效率，这本身也是信息论的讨论范畴。'
tokenids = tokenizer(input_str)['input_ids']
raw_tokens = tokenizer.convert_ids_to_tokens(tokenids)
token_strs = [tokenizer.convert_tokens_to_string([token]) for token in raw_tokens]
print(len(input_str), len(tokenids), tokenids, token_strs)

82 65 [2, 215, 1750, 10574, 22090, 24330, 23635, 21748, 484, 5460, 6225, 6646, 5587, 215, 1750, 10574, 17027, 10262, 1233, 1232, 21124, 17261, 202, 7807, 6225, 6646, 1274, 4447, 484, 15221, 1233, 5338, 1194, 244, 22090, 24330, 3835, 541, 9850, 336, 22090, 24330, 23635, 21748, 6646, 16757, 10574, 6162, 9809, 21124, 17059, 6646, 16757, 297, 6393, 683, 4921, 16004, 10574, 15986, 16004, 13773, 10302, 160, 3] ['[CLS]', '不', '同', '的', 'to', '##ken', '##ize', '##r', '会', '把', '文', '本', '按', '不', '同', '的', '边', '界', '切', '分', '，', '那', '一', '段', '文', '本', '到', '底', '会', '被', '切', '成', '几', '个', 'to', '##ken', '就', '体', '现', '了', 'to', '##ken', '##ize', '##r', '本', '身', '的', '效', '率', '，', '这', '本', '身', '也', '是', '信', '息', '论', '的', '讨', '论', '范', '畴', '。', '[SEP]']

可以看到，82 个字符的输入被分成了 63 个 Token（除去[CLS]和[SEP]），比 GPT-2 Tokenizer 的分词数量 121 几乎少了一半。这就是 Tokenizer 训练数据集对分词效率的影响。

Tokenizer 的效率意味着什么

在以前，Tokenizer 的效率只是算法工程师们关注的话题。但是现在，LLM 逐渐成为云服务，Token 成为 API 调用的基本收费单元。例如：OpenAI gpt-3.5-turbo 的收费标准是 $0.002/1K tokens。

在这种情况下，Tokenizer 的效率就意味着成本。这意味着使用中文调用 OpenAI 的 chatGPT API，假设单 Token 成本一样的话，每次调用的实际成本可能是调用国内类似 chatGPT 云服务的 2 倍以上。

GPT-4 的 Bits Per Word 指标是什么意思

最近人人都在聊 ChatGPT，这里聊点儿更底层的技术细节。上周 OpenAI 发布了 GPT-4，里面有一张图引起了我的兴趣。在 OpenAI 内部的 Codebase 上，他们准确预测了 next word prediction 误差随着计算规模增加的下降曲线。让我感兴趣的不是这个曲线，而是这个曲线纵轴使用的指标：Bits Per Word (BPW)。

乍一看我以为这是信息论里的概念，Bits Per Word 可能是指在某种语言里表达一个词所需要的最小位数，比如用于压缩时，这意味着压缩比的理论上限。但仔细看下指标接近 1.2 BPW，虽说英文字母的 Bits Per Character (BPC) 大约也在 1.2 左右，我不太相信单词的 BPW 能降到 1.2 这个规模。

后来才了解到，Bits Per Character (BPC) / Bits Per Word (BPW) 是 NLP 任务中对语言模型的评估指标之一。这些评估指标的详细解释可以先阅读这篇文章《Evaluation Metrics for Language Modeling》，但是我感觉这篇文章的说明在理论和应用之间跳过了一些环节，下面我以我的理解补全一下这些环节。推测的内容以黑字标出，如有谬误，欢迎指正。

原始 BPW 定义

The entropy is a statistical parameter which measures, in a certain sense, how much information is produced on the average for each letter of a text in the language. If the language is translated into binary digits (0 or 1) in the most efficient way, the entropy $H$ is the average number of binary digits required per letter of the original language.

以上，是香农在《Prediction and Entropy of Printed English》一文中对语言的熵的定义。可以看到，语言的熵 $H$ 其实就是 BPC (Bits Per Character) 的均值。但我们一般不会报告某个字符有几个 bits，因而通常所说的 BPC，就是整个语言(数据集)的平均 BPC，所以可以理解为语言的熵 $H$ 就是 BPC。

但是在原始论文中，香农是用字符来建模的语言的熵，当用单词来建模语言时，语言的熵 $H$ 就是 BPW (Bits Per Word)。

用 BPW 表示交叉熵

对于生成式语言模型来说，它的目标就是从样本中学习到一个分布 $Q$，使这个分布尽量接近语言的经验分布 $P$。交叉熵 $H(P, Q)$ 经常被用来衡量这种接近程度，

\[H(P, Q) = H(P) + D_{KL}(P \Vert Q) \]

根据《Evaluation》一文，交叉熵的两个因子用信息论的角度来理解：

$H(P)$: 就是 $P$ 的熵，即使用为分布 $P$ 优化的编码器编码 $P$ 中所有可能出现的字符的平均位数；

$D_{KL}(P \Vert Q)$: 使用为分布 $Q$ 优化的编码器编码 $P$ 中所有可能出现的字符，所需要的平均额外位数；

与原始 BPC/BPW 的定义相同，如果用 $BPC/BPW(P, Q)$ 表示交叉熵 $H(P, Q)$，那么它意思应该是使用为分布 $Q$ 优化的编码器编码 $P$ 中所有可能出现的字符/单词所需要的平均位数。

上面这点理解，与知乎上一篇文章《一文搞懂Language Modeling三大评估标准》存在 diff（飘红部分）：

也就是说BPC/BPW是cross-entropy对句子长度的平均，我们可以很容易地得出它的信息论含义：
基于预测的Q序列来编码P序列所需要的额外bit数在句子长度上的平均，也就是平均每一个字母/单词需要额外的bit数。

下面这一节，可能能解释 diff 的由来。

用 BPW 表示损失指标

但是在评估一个语言模型时，我们并不是评估模型输出的整个分布，而是评估模型的输出跟实际样本的不同。拿 GPT-2 模型来说，它是拿模型输出的预测下一个 Token 的 logits 与 label （样本中真实的下一个 Token）计算交叉熵：

The output from the decoder is passed to a language modeling head, which performs a linear transformation to convert the hidden states into logits. The label is the next token in the sequence, which are created by shifting the logits to the right by one. The cross-entropy loss is calculated between the shifted logits and the labels to output the next most likely token.

logits 是一个 $Q(x)$ 的向量，表示下一个 Token 是 $x$ 的概率；

label 表示样本中下一个 Token 是什么，它是一个 $P(x)$ 的向量，但只有 x = 下一个 Token 时为 1，其它位置为 0，那么：

\[H(P) = -\sum_{x}P(x)\log{P(x)} = 0\]

从信息论也好理解，在计算损失时样本 $P$ 是一个确定性分布，确定性分布的熵应该为 0。那么在计算交叉熵损失的场景下：

\[H(P, Q) = H(P) + D_{KL}(P \Vert Q) = 0 + D_{KL}(P \Vert Q)\]

可以看到，这时候交叉熵等于相关熵，那么 $BPC/BPW(P, Q)$ 也就是 $D_{KL}(P \Vert Q)$，或者更精确地说，是在数据集样本上平均的 $D_{KL}(P \Vert Q)$。那么在评估一个语言模型的场景下，把 BPC/BPW 损失指标的信息学含义解释成：“使用为分布 $Q$ 优化的编码器编码 $P$ 中所有可能出现的字符/单词所需要的平均额外位数”，也是合理的了。

GPT-4 的 BPW 指标

从 GPT-4 给出的指标来看，它的 BPW 指标只有 1.26 左右。除了信息论编码的概念，这代表什么意思呢？

这里我引入《Evaluation》一文中提到的另一个指标 Perplexity (PPL) 困惑度和一个有趣的比喻。考虑到：

\[PPL(P, Q) = 2^{H(P, Q)} = 2^{BPW(P, Q)} = 2^{1.26} \approx 2.4\]

那么 GPT-4 语言模型的效果相当于：在给定的数据集上，提供一个样本的前缀串后，GPT-4 会制作一个包含下一个 Token 的 2.4 面的新骰子，然后掷骰子来预测下一个 Token 是什么。

使 Netron 支持 PaddlePaddle 模型子图显示

先介绍一下什么是 PaddlePaddle 的模型子图。一般的神经网络都可以表示成一张由算子组成的计算图，但是对一些较为复杂的神经网络，可能会存在一些条件分支。PaddlePaddle 在构建这种条件分支的网络时，会把分支内的计算图单独保存成一张子图。

具体到 PaddlePaddle 的内部数据结构时，每个子图就是 Program 内的一个 Block。这个 Block 内包含该子图的所有中间变量，op 算子和参数等。

目前 PaddlePaddle 的模型可视化主要是依赖 Netron，包括 PadddlePaddle 提供的 VisualDL 工具里内嵌的也是 Netron。

我最近在研究 PaddlePaddle 模型优化的时候，发现 VisualDL 完全不支持子图的可视化。我稍微研究了一下 Netron 的代码，想把子图的可视化给加上。但没想到的是，其实 Netron 本身已经做了 PaddlePaddle 子图结构的解析，只是代码上存在一点儿 bug，导致子图无法被选择出来。

我就修复了一下这个 BUG，提交了一个 PR: https://github.com/lutzroeder/netron/pull/588 。希望对 PaddlePaddle 的用户能有所帮助。

只是 Netron 项目的 Owner lutzroeder 有些奇怪。他不是直接接受这个 PR，而是自己做一些修改后提交一个新的 commit 引用了这个 PR，不知道出于什么目的。这个习惯会让人很难分析出来对 PaddlePaddle 模型解析代码感兴趣的人都是谁，对于维护并不便利。

神经网络图像输入的 resize 问题

这个标题在我的博客后台躺了快一年了，但一直没想好该怎么写。主要是没有深入地去研究这里面的问题，就随便谈谈一点粗浅的认知吧。这些认知可能不对，仅供参考，并且欢迎批评。

一、不同的 resize 方式对最终的结果有一定的影响，尤其是用随机图片评估时会更加明显。

看似用的是同一个神经网络，同一个训练集，但在输入的处理上仍然会有各种不同。比如 Inception 要求 299x299，你可以直接用 ImageMagick 将原始图片处理成 299x299 再输入，也可以用 OpenCV 读入图片后再转成 299x299，还可以直接用深度学习框架（TensorFlow/Caffe）进行 resize。甚至同一种方法也可能有各种不同的参数控制，比如最邻近插值、双线性插值、双立方插值等。通过不同的 resize 方法训练出来的网络参数，或者同一张图片不同方法 resize 后预测的输出，数值是存在差异的。如果使用的是质量较低的大规模数据集，差异可能会非常明显。

二、不同的 resize 方式对最终结果的影响无法确定。

换种说法，这可能是个玄学。这算是一个经验总结，就不多讲了。也就是说，某种 resize 方式有时可能让结果变好，有时也可能让结果变差。

三、训练、评估和线上预测时统一图片处理方式有一些好处。

有的公司在训练神经网络时使用一种框架，上线时使用另一种框架；或者训练时采取一种输入，上线时采取另一种输入。都会导致线上服务的预测结果跟评估结果不一致，导致排查问题较为复杂。

有时候为了性能考虑，必须在客户端完成图片处理，resize 成较小图片后再传给服务端。而客户端往往使用的不同的库，比如 iOS 可以使用 Core Graphics 库或者 UIKit 库，Android 的 Bitmap 库，这些库在服务端是基本上无法使用的。这时候就需要知道这可能会导致线上效果与评估结果有不一致的可能，并且采取一定的措施来消减这样的不同。

Caffe 神经网络配置 - All in one network

很多人使用 Caffe 配置神经网络的时候，习惯于撰写两个配置文件，一个叫 train_val.prototxt，在训练的时候使用；一个叫 deploy.prototxt，在预测的时候使用。这两个文件的本质区别，往往在输入、输出层不同。train_val.prototxt 里包含 train/test 的输入数据和标签，但出于效率考虑，train/test 都是分 batch 进行的，而输出的往往是 acc/loss；deploy.prototxt 里只包含 test 的输入，而且一般是每次输入一个数据（没有标签），输出的也不是 acc/loss，而是预测值（Top N 类别或者预测概率）。可以把 deploy.prototxt 看成可以往线上部署的网络配置文件，来一个用户请求，执行 network 的 forward，预测返回给用户结果。

这样做没什么不可以，而且很多开源的例子都是这么做的。但实际操作中，有一个很麻烦的地方是，当你在频繁调整模型的时候，每次修改隐层都要同时修改两个 .prototxt 让人很烦恼。Caffe 的配置文件不像 Keras 那样，每层就是简单的一行代码，而是一个 Protobuf 的 txt message，有很多行，这样电脑的一屏显示不全，就需要花精力去仔细 diff 两个文件。

其实我们有更好的办法，使用 Caffe 的 proto 协议实现 All in one network。那就是充分利用 NetStateRule 这个结构，结合 phase 和 stage/not_stage，实现不同场合下 layer 的过滤。

message NetStateRule {
  // Set phase to require the NetState have a particular phase (TRAIN or TEST)
  // to meet this rule.
  optional Phase phase = 1;

  // Set the minimum and/or maximum levels in which the layer should be used.
  // Leave undefined to meet the rule regardless of level.
  optional int32 min_level = 2;
  optional int32 max_level = 3;

  // Customizable sets of stages to include or exclude.
  // The net must have ALL of the specified stages and NONE of the specified
  // "not_stage"s to meet the rule.
  // (Use multiple NetStateRules to specify conjunctions of stages.)
  repeated string stage = 4;
  repeated string not_stage = 5;
}

以 Caffe 里的 example/minist/lenet_train_test.prototxt 为例，那怎么把它改成 all in one 的 prototxt 呢？

name: "LeNet"
layer {
  name: "mnist"
  type: "Data"
  top: "data"
  top: "label"
  include {
    phase: TRAIN
  }
  transform_param {
    scale: 0.00390625
  }
  data_param {
    source: "examples/mnist/mnist_train_lmdb"
    batch_size: 64
    backend: LMDB
  }
}
layer {
  name: "mnist"
  type: "Data"
  top: "data"
  top: "label"
  include {
    phase: TEST
  }
  transform_param {
    scale: 0.00390625
  }
  data_param {
    source: "examples/mnist/mnist_test_lmdb"
    batch_size: 100
    backend: LMDB
  }
}

首先，我们要明确解决的是 TEST phase 的冲突（验证集和测试集的 input/output 不同），不用去管 TRAIN phase。而为了解决 TEST phase 的冲突，就需要通过为 NetStateRule 增加参数来实现。min_level/max_level 和 stage/not_stage 都可以做这个事情，但我习惯用 stage，因为文字看起来比数字更直观一些。所以我会在原来的 train_val.prototxt 里再增加一个 TEST 输入层，通过 stage 区分不同的应用场景，如下所示：

layer {
  name: "mnist"
  type: "Data"
  top: "data"
  top: "label"
  include {
    phase: TEST
    not_stage: "predict"    # 在 predict 时过滤掉这一层
  }
  transform_param {
    scale: 0.00390625
  }
  data_param {
    source: "examples/mnist/mnist_test_lmdb"
    batch_size: 100
    backend: LMDB
  }
}
# 增加 deploy 的输入层
layer {
  name: "data"
  type: "Input"
  top: "data"
  input_param { shape: { dim: 1 dim: 1 dim: 28 dim: 28 } }
  include {
    phase: TEST
    stage: "predict"    # 在 predict 时加上这一层
  }
}

在 caffe.bin train 时，由于 solver.prototxt 没有提供特殊的参数，所以只包含 batch_size 100 的 TEST 输入层；在预测的时候，设置 stage='predict' 参数（设置方式下文有介绍），网络的输入层就变成了 dim: 1 的 TEST 输入层了。

同理，对输出层也是一样，在 loss layer 加上 exclude stage: "predict" 的参数，预测时就无需提供 label 和计算 loss 了，如下所示：

layer {
  name: "accuracy"
  type: "Accuracy"
  bottom: "ip2"
  bottom: "label"
  top: "accuracy"
  include {               #
    phase: TEST           #
    not_stage: "predict"  # 在 predict 时过滤掉 accuracy 层
  }                       #
}
layer {
  name: "loss"
  type: "SoftmaxWithLoss"
  bottom: "ip2"
  bottom: "label"
  top: "loss"
  exclude {           # 注意是 exclude
    phase: TEST       #
    stage: "predict"  # 在 predict 时过滤掉 loss 层
  }                   #
}

这样，你就能得到一个 all in one 的网络配置 lenet_train_val_deploy.prototxt，可以统一用它进行训练和预测，修改隐层再也不用拷贝来拷贝去了。其实使用 NetStateRule 可以进行各种组合，其它的参数组合也能实现 all in one 的网络设置，但我上面介绍的这种配置方法有个好处是完全不用修改原来的 solver.prototxt。也就是 default 走 non-predict，显式走 predict。

那怎样显式提供 stage='predict' 参数呢？在 caffe.bin 命令行可以使用：

$ caffe.bin test --stage="predict" --model="train_val_deploy.prototxt" \
--weights="iter_N.caffemodel"

当然，这时候输入层可能要换成其它的类型，不能是 Input 类型，不然 caffe 没法读取数据。使用 Input 类型时，就得用 Python/C++ 来加载数据。使用 stage="predict" 初始化 Python 和 C++ 的方法如下：

Python:
net = caffe.Net("train_val_deploy.prototxt", caffe.TEST, stages=['predict'],
                weights="iter_N.caffemodel")
C++:
caffe::vector<caffe::string> stages;
stages.push_back("predict");
caffe::Net *net = new caffe::Net("train_val_deploy.prototxt", caffe::TEST, 0, &stages);

手机上的 AI - 在 Android/iOS 上运行 Caffe 深度学习框架

目前在云端基于各种深度学习框架的 AI 服务已经非常成熟，但最近的一些案例展示了在移动设备上直接运行深度神经网络模型能够带来很大的处理速度优势。比如 Facebook 在官方博客上发布的可在移动设备上进行实时视频风格转换的应用案例 “Delivering real-time AI in the palm of your hand”。其中提到 Caffe2go 框架加上优化后的网络模型，可以在 iPhone6S 上支持 20FPS 的视频风格转换。Google Tensorflow 也提供了 iOS 和 Android 的 example。

Caffe 是一个知名的开源深度学习框架，在图像处理上有着非常广泛的应用。Caffe 本身基于 C++ 实现，有着非常简洁的代码结构，所以也有着很好的可移植性。早年也已经有了几个 github 项目实现了 Caffe 到 iOS/Android 平台的移植。但从我的角度来看，这些项目的编译依赖和编译过程都过于复杂，代码也不再更新，而且最终产出的产品包过大。caffe-compact 最接近我的思路，但是在两年前未完工就已经不更新了。

从我个人在 APP 产品上的经验来看，移植深度学习框架到 APP 中，不仅仅是能不能跑，跑不跑得快，还有个很重要的因素是包大小问题。因为一般用深度学习模型只是实现一个产品功能，不是整个产品。一个产品功能如果对 APP 包大小影响太大，很多 APP 产品都无法集成进去。我希望依赖库能尽量地精简，这样打包进 APP 的内容能尽量地少。所以我在春节期间在 github 上启动了一个 Caffe-Mobile 项目，将 Caffe 移植到 Android/iOS 上，并实现了以下目标：

NO_BACKWARD：手机的电量和计算能力都不允许进行模型训练，所以不如干脆移除所有的后向传播依赖代码，这样生成的库会更小，编译也更快。

最小的依赖。原始的 Caffe 依赖很多第三方库：protobuf, cblas, cuda, cudnn, gflags, glog, lmdb, leveldb, boost, opencv 等。但事实上很多依赖都是没必要的：cuda/cudnn 仅支持 GPU, gflags 仅为了支持命令行工具，lmdb/leveldb 是为了在训练时更高效地读写数据，opencv 是为了处理输入图片，很多 boost 库都可以用 c++0x 库来替换。经过精简和修改部分代码，Caffe-Mobile 的第三方库依赖缩减到两个：protobuf 和 cblas。其中在 iOS 平台上，cblas 用 Accelerate Framework 中的 vecLib 实现；在 Android 平台上， cblas 用交叉编译的 OpenBLAS 实现。

相同的代码基，相同的编译方式。两个平台都采取先用 cmake 编译 Caffe 库（.a or .so），然后再用对应平台的 IDE 集成到 app 中。编译脚本使用同一个 CMakeList.txt，无需将库的编译也放到复杂的 IDE 环境中去完成。

可随 Caffe 代码更新。为了保证开发者能追随最新 Caffe 代码更新，我在修改代码时使用了预编译宏进行分支控制。这样进行 diff/patch 时，如果 Caffe 源码改动较大，merge 时开发者可以清楚地看到哪些地方被修改，是如何改的，更方便 merge 最新更新。

除了 Caffe 库外，在 Caffe-Mobile 项目中还提供了 Android/iOS 两个平台上的最简单的 APP 实现示例 CaffeSimple，展示了在手机上使用 Caffe example 里的 MNIST 示例（深度学习领域的 Hello World）训练出来的 LeNet 模型预测一个手写字符 “8” 图片的过程和结果。 Caffe-Mobile 项目的地址在：https://github.com/solrex/caffe-mobile 欢迎体验，感兴趣的同学们也可以帮忙 Star 下 :)

700行代码帮你迈出打造专属Jarvis的第一步

前几天，Mark Zuckerberg 写了一篇博客《Building Jarvis》，立即风靡科技圈。智能家庭，Bill Gates 弄了一个，Zuckerberg 也搞了一个，科技圈的大佬们纷纷动手，让小民们看着很眼馋。

在《Building Jarvis》这篇文章中，Zuckerberg 写到：

These challenges always lead me to learn more than I expected, and this one also gave me a better sense of all the internal technology Facebook engineers get to use, as well as a thorough overview of home automation.

注意到这些酷炫的技术，都是 internal technology Facebook engineers get to use。那么到底有没有可能，使用公开领域的服务，构建一个类似于 Jarvis 的系统呢？

正好这段时间，我也在做一个基于人工智能技术的简单 APP：WhatIsWhat。这个 APP 目前很简单，甚至可以称得上简陋，但可能对你构建自己的 Jarvis 会有所帮助或启发。

背景

某天闲聊的时候，有个妈妈同事说，她家宝宝问她很多东西不懂，只好去搜索，发现百度百科的不少词条有个“秒懂百科”，用视频讲解百科词条，宝宝很爱看。只是可惜宝宝不认字，不会自己搜索。然后我就想，要是有个工具，能用语音问问题，语音或者视频回答问题，那挺不错啊，就有了这个 APP。

随着近几年语音识别准确率的大幅度提升，语音交互技术已经步入到非常成熟的阶段了。公开领域也有讯飞、百度等好几家免费服务可用，只是关注和使用这些的一般都是企业，个人开发者并不多。其实从我工作上的背景出发，语音交互背后的技术都是非常熟悉的。下面我就以我使用的百度语音开放平台为例，解释下能有哪些免费的语音交互服务可用。

语音识别

要想宝宝能使用语音问问题，首先需要有一个语音转文字的技术，我们一般称之为“语音识别”。从 20 世纪 70 年代 IBM 把 HMM 应用到语音识别技术上来以后，语音识别准确率一直在稳步提升。但到了 2000 年以后，语音识别的效果改进停滞了，而且一停就是 10 年。直到 2010年，Geoffrey Hinton、邓力和俞栋在微软研究院将深度学习引入语音识别技术后，平地一声惊雷，语音识别的准确率才又开始一次大跃进。

可以这样说，20 年前的语音识别和六七年前的语音识别，没有太大区别。但现在的语音识别技术，和六七年前的语音识别技术，是有革命性改进的。如果你还根据几年前的经验，认为语音识别是个 Tech Toy，识别结果充满了错漏。不妨试试最新的语音识别产品，比如讯飞语音输入法、百度语音搜索，结果会让你很吃惊的。

值得高兴的是，讯飞和百度都将最新的语音识别技术免费开放给所有人使用。比如百度的语音识别服务，单个应用每天可以免费调用 5 万次，而且可以通过申请提升这个免费上限。只需要到它的平台上注册成为开发者（不需要任何费用），申请新建一个应用，下载最新版的 SDK，参考文档集成到 APP 里就行了。

语音合成

如果想让手机使用语音回答问题，还需要一个文字转语音的技术，我们一般称之为“语音合成”或者“TTS”。语音合成在准确率方面的问题上，没有语音识别那么显著，但更大的困难来自于“怎么让机器发出的声音更像人声？”有很多个方面的考量，比如情绪、重音、停顿、语速、清晰度等等。现代的语音合成产品，一般都支持选择发声人（男声、女声、童声）和调整语速的功能。很多小说阅读器都配备的“语音朗读”，就是语音合成技术的典型应用。

讯飞和百度也都免费开放了自家的语音合成技术，也是类似于语音识别的SDK集成即可。值得一说的是，Google 在今年 9 月发表了自家的 WaveNets 语音合成模型，号称将 TTS 发声和人声的差距缩短了 50%（可以到这个页面体验一下），所以我们可以期待公开的语音合成服务效果有更进一步的改进。

语音唤醒

就像两个人交谈时你必须得称呼对方名字，他才知道你是在对他说话，机器也是一样。对着手机屏幕的时候，可以通过点击麦克风按钮来实现唤醒语音输入，但在远处或者不方便点击时（比如开车），需要用特定的指令唤醒它接收并处理你的输入。就像我们熟悉的“Hey，Siri”和“OK，Google”，我们一般称之为“语音唤醒”。

一般情况下，唤醒指令不依赖语音识别，也就是说，它纯粹是使用声学模型匹配你的声音。这样做也有好处，就是不依赖网络，待机功耗也更低。

讯飞的语音唤醒功能是收费的，但是百度的语音唤醒功能是免费的，可以定制自己的唤醒词，然后下载对应唤醒词的声学模型包，集成到语音识别 SDK 中即可。

如果希望打造一个专属的 Jarvis 的话，这个唤醒词声学模型最好是使用自己的语音训练出来的，这样召准率才能更高。但很遗憾，百度的免费语音唤醒还不支持这点，只能用百度语料库训练出来的模型。

自然语言理解

关于自然语言理解，Zuckerberg 的《Building Jarvis》已经解释得非常充分了，这是一个非常复杂和困难的技术领域。讯飞和百度也都在自身语音识别能力基础上，开放了自然语言理解的能力。用户甚至可以在云端自定义自己的语义，这样识别后不仅能拿到一个纯文本识别结果，还可以获取结构化的分析后结果。

我对 WhatIsWhat 这个 APP 的要求很简单，只需要理解“什么是什么？”这个问题即可。我没有用到百度的语义理解能力，而是简单地写了一个正则表达式匹配，主要是希望后续能充分利用语音识别的 Partial Result 对性能进行优化。

问题回答

目前很多搜索引擎（比如谷歌、百度）对语音发起的搜索，在给出搜索结果的同时，往往附带着一句或者几句语音的回答。但搜索引擎针对的往往是开放领域的搜索词，所以语音回答的覆盖比例并不高。限定到“什么是什么”这个特定的领域，百度百科的满足比例就高了。尤其是秒懂百科，使用视频的方式讲解百科词条，样式非常新颖。

在这个最初的版本中，我只采取了秒懂百科的结果。也就是先抓取百科结果页，提取秒懂百科链接，然后打开秒懂百科结果页。为了让播放视频更方便，我用 WebView 执行了一个自动的点击事件，这样第一条视频结果在打开页面后会直接播放，不需要再点击。

演示视频

下面是“WhatIsWhat”这个 APP 的演示视频，请点击查看，因为录音设备的冲突，视频的后半部分没有声音，敬请谅解。

源代码地址

你可以到 https://github.com/solrex/WhatIsWhat 这个链接查看“WhatIsWhat”的全部源代码。代码总共 700 多行，不多，需要有一点儿 Android 和 Java 基础来理解。

总结

WhatIsWhat 是从一个朴素 idea 出发的非常简单的 APP，这个产品集成了“语音识别、语音合成、语音唤醒、自然语言理解”几类人工智能服务。想要实现 Jarvis，可能还需要人脸识别、智能对话、开放硬件 API 等几项能力，并且需要一定的工程能力将这些功能整合起来。

虽然 WhatIsWhat 与 Jarvis 的复杂度不可比，但它演示了如何使用公共领域已有的人工智能服务，构造一个落地可用的产品。更重要的是，它便宜到不需花一分钱，简单到只有 700 行代码。

就像 Zuckerberg 所说“In a way, AI is both closer and farther off than we imagine. ”虽然很多人并没有意识到语音交互这类 AI 技术能够那么地触手可及，但技术的开放对 AI 应用普及的影响是巨大的。在这一点上，国内的人工智能产业巨头们做得并不差。这篇文章，WhatIsWhat 这个 APP，只能帮你迈出第一步，希望不远的将来，我们能够有更多的开放 AI 服务，使得搭建自己的专属 Jarvis 变成一件轻而易举的事情。