2026-04-08 17:18:05
上篇文章中我分享了一些常用的沟通方式：尊重、倾听和情绪控制，并给出了几个我认为很不错的沟通技巧，比如：引起对方的兴趣；过滤信息，简明扼要地表达；用数据和实例说话。这篇文章中，我来分享几个关键的沟通技术，相信掌握了这几大沟通法宝，你的沟通水平会大幅提升。
你的逻辑能力一定要强。因为中国人从小就不学逻辑学，所以讲话不注重逻辑，而我们理科生尤其是学过数学的程序员是懂逻辑的，所以，对于我们程序员来说，我们是可以用缜密逻辑疯狂地碾压别人的。
逻辑是一门科学，也是一门数学。谁是谁的充分条件、必要条件或充要条件，以及有没有关联关系，有没有因果关系等，这些东西你要做到心中有数，当对方的表达中出现逻辑错误时，你可以随时指出来。比如，这两个事儿没有因果关系，我们不要把它们放在一起谈。
有一次，我就跟一家公司的产品团队 PK 了一下。这家公司的产品有一个视频下载功能，但他们统计数据发现，有大约 40% 的用户下载到一半就取消下载操作了。于是他们就想提高用户的下载体验，解决办法是模仿微信的绿色进度条的做法：让进度条的 90% 嗖地过去，然后最后的 10% 则对应实际剩下的下载进度。
我们通过逻辑分析，不难发现这样做是不能赢得用户的。他们的逻辑是：“用户看到已经下载 90% 了，然后会想那 10% 很快就能下载好，所以会愿意多等一会儿。而不是下载 10% 就让用户等了半天，那他就不想等了。”这里的前置条件是用进度条欺骗用户，后置条件是用户愿意等待下载。
但是不是进度条这样设计了以后，用户就真的愿意等到下载完成呢？不是的。不需要试验，我们脑补一下，当我们的微信打不开网页，或者打开速度超过我们的心理忍受限度时，无论那个进度条是多少，我们都不会等的。有这么一个逻辑在这里卡着。
基于这种逻辑，我跟他们说，这种进度条设计会导致更低的下载率。因为视频通常比较大，下载的总时间是很长的，绝大多数用户对这个速度是没有概念的。打开网页的时间是很短的，90% 的网页在 3、4 秒内就打开了，只有少数偶尔需要 5 秒到 10 秒才能打开（因为移动网络的问题）。
这时，我可以通过这种“就快完”的手段把用户多留下来一会儿。但是，视频下载无论怎样优化，至少需要半分钟，才能下载下来。此时，如果进度条不能反映真实进度的话，用户对总的打开时间是没有合理预期的，90% 的进度提前到了，剩下的 10% 花那么久，很容易让人认为是下载卡死了，从而放弃，乃至在多次重试无果后对应用和平台都失去兴趣。
所以，这样的进度条设计只是用户愿意等一小下（15 秒以内）的充分条件（还不一定是必要条件），并不是用户愿意等待直到视频下载完成的充分条件或必要条件。
在这样的逻辑面前，产品经理立马取消了这个功能的排期，说还需要想一想。你看，你可以用你的一些逻辑推理去分析问题的前因后果和条件，然后用这个条件来说服他。
在逻辑层面说服对方，是一种非常高级的手段，就像懂微积分的人来解数学题一样，那些不懂微积分的只有被碾压的份儿了。
信息要全面、准确。这里重点提一下 X/Y 问题。X/Y 问题是一件非常讨厌的事情。有时候我们拿着 Y 问题去找别人，问到一半才知道，我们原来要问的是 X 问题。
Stack Overflow 上有个问题，问的是“怎么截取一个字符串的最后三位？”大家给了一堆答案。突然有个人问：“你为什么要截取字符串的后三位？”他说：“我要找文件的扩展名”。实际上，文件的扩展名不一定是 3 个字符，而且有专门的函数干这个事儿，不需要自己写。这里，取文件的扩展名，这叫 X，取文件名的最后 3 个字符，这叫 Y。他想知道 X，但不知道该怎么说，于是就说成了 Y，导致别人都去解决一个不存在的问题。这叫 X/Y Problem。
我可以告诉你，这个世界上到处都是 X/Y 问题。有些公司找我说，我们要做分布式架构，我们要做大中台，我们要做线下线上融合……这些问题都是 Y 问题。我都要反问，你为什么要做分布式架构？为了大规模营销，为了稳定性，还是为了加快开发速度？做大中台，你是为了什么？ 是为了打通各个业务线，为了快速开发，还是为了技术输出？等等。要解的真实问题才是 X 问题，手段都是 Y 问题。只有你真正了解了 X 问题，你才能真正明白整个事。
当你了解了 X 问题后，你就要到源头，来质疑或是改良他的 Y 问题，甚至提出 Z 方案，而对方会陷入被动，被你牵着鼻子转。
我们想一下，人与人不同都是细节上的不同，比如：身高、体重、手机号等，人与人的相同点都是在宏观上相同，比如：国籍，性别……这告诉我们，如果你要找不同就要到细节上去，如果你要找共同，就要到大局上去。
所以，在和人争论时，如果要反驳，那一定是低维度反驳，越细节越好。而在说服对方时，则要在高维度说服对方，越宏观越好，比如从公司的大目标出发。高维度讲究的是求同存异。你跟别人相同的东西一定是高维度的，这就是大同，而你跟别人不同的一定是非常细节的东西。大同的东西，更容易让人产生共鸣，从而容易达成默契和共识。
因此，能够站在更高的维度来沟通是我们需要努力的目标。我们经常会听到类似的话：“哎呀，大家都没有恶意。我们虽然争论成这样，但是大家都是为公司好，只不过我们的路径不对。”或者“我们的目标是一样的，但是我们的方式不一样。”能感觉到吧？气氛一下子就缓和了好多。
站在更高的维度上讨论问题，可以让你有大局观，对方就会显得很小气，导致对方也会不好意思，于是就会出现“六尺巷”的故事中所描述的那种场景。
这里讲的是共情，共享，共利，共识以及换位思考。如果你能站在对方的角度思考问题，那么你所想的问题以及所想沟通的内容，一定会跟只想自己有很大不同。同时，你会神奇地发现，换位思考能帮助你更为全面地理解并解决问题。
寻找“共同”的过程，其实也可以理解成为化“敌”为“友”的过程。我们不妨想象一下，沟通双方剑拔弩张，随时一触即发的情况，和沟通双方有共同的目标一起思考和解决问题的状态，哪种更能获得更好的结果。而共同该怎样找，跟我们在维度中提及的很相似，就是从高维度，寻找共同之处。
首先是共情，跟对方相互分享各自的情感，这是一种拉近距离最有效的手段，然后是相互共享自己的观点，在观点中寻求双方共同的利益点，然后不断地循环，一点一点地达成共识。
此外，我还想强调一点，无论干什么，你一定要有一个非常犀利的观点，也就是金句。如何得到这些金句呢？一定要多看书。你到那些公众号或者知乎里面看一些抖机灵的内容是没有用的。抖机灵的金句没有用。一定要是有思想深度的金句，才有力量。推荐你看三本书《清醒思考的艺术》、《简单逻辑学》和《重来》。
我是先被《重来》洗脑了，这本书帮我开拓了眼界，打破了我既有的思维模式，让我反思过去习以为常的每一件事。同时书中给出了实用、可操作的建议，让我头一次从心底感受到，原来世界还可以如此不同。
然后，我看了《清醒思考的艺术》，这本书作者以显微镜般的观察发现人们常犯的 52 个思维错误，并一一列出。帮人们认识到错误的思维是如何发生，从而避免掉入思维陷阱中。看这本书的过程中，我能明显感觉到自己的思维方式在被重新构造。
随后是《简单逻辑学》。逻辑学是很枯燥的，但这本书的作者以其简练而又充满趣味的笔触，将逻辑学活化为一种艺术，从它的基本原理，到论证，到非逻辑思维的根源，再到 28 种就发生在人们身边的非逻辑思维形式，带领我们进入这个精彩无比的逻辑世界，体会妙趣横生的思维交锋，跨过无处不在的逻辑陷阱，让人沉醉其中，欲罢不能。
这三本书对我影响很大，也建议你好好读读，能改善你的思维，炼就你的火眼金睛。你会发现自己跟和别人不在一个频道上，你能看到事物更多的侧面，在阐述观点时，会比别人更加深刻、犀利和有见地。一些金句也会在你跟人互动交流时，随机地冒出来。你自己都能明显感觉到自己的气场要比其他人足。
总结一下今天的内容。我们讲了沟通的四大关键技术：逻辑、信息、维度和共同。
有逻辑的表达，更容易说服对方。信息全面准确，更有利于让沟通的双方清楚定位问题，从而更高效地解决问题。
维度是个很有趣的事儿，有的时候要站在高维度去碾压对方；有的时候要站在低维度去碾压对方。如何把握这个度很重要。如果站在客户的角度，最好用高维度。但如果站在技术细节的角度，这是低维度。高维度容易拉拢对方，而在低维度更容易说服对方。只不过低维度容易爆发冲突，要恰当地控制好度。
最后一点是共同，其实寻找共同的过程就是化“敌”为“友”的过程，帮助大家在共赢的大思路和环境下，共同思考问题的解，从而实现高效沟通。此外，我强调了金句的重要性，以及如何获得这些金句。答案是没有捷径可走，唯有多读书，多思考，才能慢慢获得。
来源：《左耳听风专栏：高效沟通》
2026-04-02 03:02:37
Chrome开启同步功能时忘了先备份本地书签，导致保存的书签全部被覆盖，赶紧呼叫AI
，Mark一下。
在Mac上，若Chrome同步功能覆盖了本地书签，最快恢复方法是利用Bookmarks.bak备份文件。切勿在此期间关闭Chrome。在访达中进入 ~/Library/Application Support/Google/Chrome/Default，将 Bookmarks.bak 重命名为 Bookmarks 覆盖原文件。
保持Chrome打开状态： 不要关闭浏览器，以免备份文件被更新。
查找书签文件：
在Mac中打开“访达”（Finder）。
按下 Cmd + Shift + G，输入：~/Library/Application Support/Google/Chrome/Default。
找到 Bookmarks（当前覆盖后的书签）和 Bookmarks.bak（原来的书签备份）两个文件。
恢复备份：
如果 Bookmarks.bak 文件较小且没有更新，说明它还存有旧数据。
退出Chrome。
删除 Bookmarks 文件。
将 Bookmarks.bak 重命名为 Bookmarks。
重新打开Chrome： 此时书签应已恢复。
开启同步注意： 如果书签再次被同步覆盖，建议在书签管理器中利用“时钟”图标恢复30分钟前的版本。
参考：
2026-03-26 20:59:28
在 Linux 系统上，df 和 du 命令统计结果不一致是经常遇到的情况，其背后的原理涉及到文件系统如何管理磁盘空间和文件这两个不同的视角。
简单来说，核心差异在于：
df 报告的是文件系统级别的磁盘块使用情况，它查看的是磁盘块的分配情况。
du 报告的是文件级别的磁盘块使用情况，它通过累加每个文件的大小来计算。
df (Disk Free)工作原理：df 命令直接读取文件系统的超级块（Superblock） 中的信息。超级块中存储了整个文件系统的元数据，包括总空间、已用空间、空闲空间、inode 数量等。因此，df 的执行速度非常快，因为它不需要遍历所有目录和文件。
它统计什么：文件系统上所有已分配的磁盘块（包括被文件占用的和部分被保留的）。
du (Disk Usage)工作原理：du 命令会递归地遍历指定目录下的每一个文件和子目录，然后累加每个文件占用的磁盘空间大小。它的结果基于当前用户权限下能看到的文件。
它统计什么：所有文件实际占用的磁盘块的总和。
正是因为上述不同的工作原理，导致了以下几种常见的不一致情况：
这是导致 df 显示空间已用而 du 找不到对应文件的最主要原因。
原理：当一个文件正在被某个进程使用时，如果它被删除（rm），Linux 并不会立即释放其占用的磁盘空间。该进程仍然持有该文件的句柄，可以继续读写它。此时，该文件在目录中的条目（entry）消失了，所以 du 无法统计到它。但该文件占用的磁盘块在文件系统中仍然被标记为“已使用”，直到所有打开它的进程都关闭该文件后，空间才会被释放。
表现：df 显示磁盘使用率很高，但 du -sh / 统计根目录占用的总空间却小很多。
解决方法：
使用 lsof | grep deleted 命令查找已被删除但仍被进程打开的文件及其进程ID（PID）。
确认无误后，重启或终止相关进程（kill -9 <PID>），空间便会释放。
原理：默认情况下，Ext3/Ext4 等文件系统会保留约 5% 的磁盘空间（可由 tune2fs 调整）给 root 用户。这样做的目的是在磁盘空间写满时，为 root 用户保留一定的操作空间（例如执行必要的恢复命令），防止系统完全崩溃。
表现：df 会把这 5% 的保留空间计入“已用”空间，因为它对普通用户不可用。而 du 不会统计这部分空间，因为它不是被任何文件占用的。
计算：对于一个 100G 的分区，df 可能会显示 95G 可用，5G 已用（其中一部分就是保留空间），即使一个文件都没存。
原理：如果在 /data 目录下挂载了另一个磁盘（例如 /dev/sdb1），那么：
du -sh /data 会统计挂载在 /data 上的文件系统（/dev/sdb1）中所有文件的大小。
df /data 显示的是 /dev/sdb1 这个独立文件系统的使用情况。
通常这里是一致的，但如果 /data 目录本身在根分区（/）中有一些文件（在挂载前存在的），这些文件会被挂载操作“隐藏”。du 看不到它们（因为访问路径被挂载点覆盖了），而 df 统计的是两个不同的文件系统，所以不会产生混淆。
原理：稀疏文件是一种特殊文件，它允许在文件中存在“空洞”（大量连续的0字节）。应用程序（如虚拟机磁盘镜像）创建它时，文件系统不会为这些空洞分配实际的磁盘块。
表现：
ls -l 或 du --apparent-size 显示的是文件的逻辑大小，会非常大。
du（默认行为）显示的是文件实际占用的磁盘块大小，会小很多。
df 反映的是文件系统实际消耗的磁盘块，与 du 的默认行为一致。
示例：一个 100GB 的虚拟机磁盘文件，可能只实际占用 10GB 空间。du -h file 显示 10G，而 ls -lh file 显示 100G。
原理：文件系统自身需要消耗磁盘空间来存储元数据，如 inode 表、磁盘位图、日志文件（对于日志文件系统如 ext3/4, xfs）等。
表现：这部分空间被文件系统占用，但不对应任何用户文件。因此 df 会将其统计为“已用空间”，而 du 根本无法统计这些元数据，从而导致 df 的结果略大于 du。
| 特性 | df |
du |
|---|---|---|
| 数据源 | 文件系统超级块（元数据） | 递归遍历统计文件 |
| 统计视角 | 磁盘块分配情况 | 文件数据占用情况 |
| 速度 | 非常快（直接读元数据） | 相对慢（需要遍历文件树） |
| 包含保留空间 | 是 | 否 |
| 包含被删除但未释放的文件 | 是 | 否 |
| 包含稀疏文件“空洞” | 否（只算实际块） |
否（只算实际块，但 --apparent-size 算） |
| 包含元数据 | 是（元数据也占用块） | 否 |
当遇到磁盘空间不足报警，但 du 找不到大文件时，排查思路如下：
首先执行 df -h，确认哪个分区使用率高。
然后执行 du -sh /path/to/mountpoint，查看该分区下文件总大小是否与 df 结果近似。
如果差异很大，首要怀疑有文件被删除未释放：使用 lsof +L1 或 lsof | grep deleted 命令检查。
其次考虑是否有隐藏挂载点、稀疏文件等原因。
云盘扩容后扩展分区操作
云主机的云盘从控制台100G扩容到300G后，根目录 /dev/vda1 显示还是100G，这通常是因为云盘扩容后只增加了底层存储空间，操作系统内部的分区和文件系统还未扩展。云平台的控制台扩容只是扩大了"物理磁盘"的容量，后续还需要在系统内部进行分区和文件系统的扩展。
1.确认底层磁盘容量
在操作系统内执行 lsblk 命令-4-5，它可以查看磁盘本身和分区的真实容量。
如果 lsblk 显示 /dev/vda 本身已经是300G，而其下的分区 /dev/vda1 还是100G，这就证实了是分区没有扩展-1-8。
2.扩展分区
确认是分区问题后，需要扩展分区以填满磁盘的可用空间。推荐使用 growpart 工具-5，它能够自动调整分区大小。
growpart /dev/vda 1
注意：命令中 vda 和 1 之间的逗号后有一个空格-5。完成后，再次运行 lsblk 检查，此时 /dev/vda1 的大小应该显示为300G左右。
3.扩展文件系统
分区扩展后，最后一步是扩展文件系统，这样才能让操作系统真正使用新增的空间。需要根据文件系统类型选择相应的命令。
如果文件系统是 ext4（常见于CentOS、Ubuntu等）：
resize2fs /dev/vda1
如果文件系统是 XFS（常见于较新版本的CentOS、RHEL）：
xfs_growfs /
注意：对于XFS文件系统，需要指定挂载点（此处根目录为 /），而不是设备名。
在进行任何磁盘操作前，请务必注意以下几点：
命令匹配：务必确保扩展文件系统的命令与系统上的文件系统类型匹配，否则可能报错或无效-5。
参考：
2026-03-24 09:10:35
李宏毅老师是台湾大学电机工程学系的教授，在机器学习和生成式AI领域的教学全球知名，尤其在华语社区拥有极高声誉。YouTube上的课程累计超过30万订阅，影响力横跨学界与业界。李老师的的教学风格以生动、幽默著称，擅长用“宝可梦 vs 数码宝贝”等通俗易懂的例子，将复杂的深度学习、Transformer等前沿技术讲得清晰透彻，被许多学习者誉为“AI领域最好的启蒙老师之一“。
个人网站: https://speech.ee.ntu.edu.tw/~hylee/index.php
YouTube 频道: https://www.youtube.com/@HungyiLeeNTU
课程观看列表: https://www.youtube.com/@HungyiLeeNTU/playlists
李宏毅老师近两年的课程紧跟技术前沿，主要可以分为两大核心：
1. 《生成式人工智能导论》 (Introduction to Generative AI)
学期：2024 春季
课程内容详细介绍：这是一门面向初学者的大规模课程，旨在帮助学习者掌握生成式AI（如ChatGPT、AI绘图）的基础原理、技术演变和应用场景。课程不仅讲解理论，更侧重于探讨如何有效利用现有的大型语言模型（LLM），内容涵盖提示工程、任务拆解、让AI使用工具等实用技巧。这门课在台大吸引了超过1000名学生选修，其中包括近200名文学院学生，足以证明其入门友好性和跨学科影响力。
适合人群：对AI感兴趣，希望系统了解生成式AI原理和应用，或想提升与AI协作效率的学习者。
2. 《机器学习》 (Machine Learning)
学期：2025 春季
课程内容详细介绍：这是李宏毅老师的经典招牌课程，2025年版本进行了重大改革。内容从传统的深度学习基础，全面转向大语言模型（LLM）时代最前沿的技术，重点包括：
AI Agent（人工智能智能体）：讲解AI如何感知、规划、行动和使用工具。
RAG（检索增强生成）：介绍如何让大模型结合外部知识库以生成更准确的答案。
模型内部机制与可解释性：深入探讨语言模型的“黑盒子”，分析神经元如何运作。
模型训练与优化：涵盖预训练、后训练、模型合并（Model Merging）以及像DeepSeek-R1这样的模型如何进行“深度思考”。
适合人群：已具备一定机器学习基础，希望深入掌握LLM、AI Agent等当代核心技术的学习者。
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2026-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Introduction to GenAI and ML | https://speech.ee.ntu.edu.tw/~hylee/GenAI-ML/2025-fall.php |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2025-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Spring | Introduction to Generative AI | https://speech.ee.ntu.edu.tw/~hylee/genai/2024-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Linear Algebra | https://voidful.github.io/LA_2023_fall/2023-fall.html |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2023-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Linear Algebra | https://googly-mingto.github.io/LA_2022_fall/2022-fall.html |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2022-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Linear Algebra | https://speech.ee.ntu.edu.tw/~hylee/la/2021-fall.php |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2021-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Linear Algebra | http://speech.ee.ntu.edu.tw/~tlkagk/courses/LA_2020/policy.pdf |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2020-spring.php |
| Spring | DLHLP (Deep Learning for Human Language Processing) | https://speech.ee.ntu.edu.tw/~hylee/dlhlp/2020-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Linear Algebra | https://speech.ee.ntu.edu.tw/~hylee/la/2019-fall.php |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2019-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Linear Algebra | https://speech.ee.ntu.edu.tw/~hylee/la/2018-fall.php |
| Spring | MLDS (Machine Learning and Deep Structured) | https://speech.ee.ntu.edu.tw/~hylee/mlds/2018-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2017-fall.php |
| Spring | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2017-spring.php |
| Spring | MLDS (Machine Learning and Deep Structured) | https://speech.ee.ntu.edu.tw/~hylee/mlds/2017-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | ML (Machine Learning) | https://speech.ee.ntu.edu.tw/~hylee/ml/2016-fall.php |
| Spring | Linear Algebra | https://speech.ee.ntu.edu.tw/~hylee/la/2016-spring.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | MLDS (Machine Learning and Having It Deep and Structured) | https://speech.ee.ntu.edu.tw/~hylee/mlds/2015-fall.php |
| 学期 | 课程名称 | 链接 |
|---|---|---|
| Fall | Circuit | https://speech.ee.ntu.edu.tw/~hylee/circuit/2014-fall.php |
2026-03-20 10:30:06
前面两篇文章主要介绍了大模型GPU资源需求计算及使用场景：大模型GPU显存算力需求计算 | 大模型推理资源需求计算及使用场景示例。
在常见并发推理场景中，显存需求会随着并发数的增加而显著增长，因为KV Cache是显存占用的主要变量。下面我们来系统性地介绍并发推理的显存计算方法，并通过7B、32B、70B三个模型的示例进行全面评估。
总显存 = 模型参数 + KV Cache + 中间激活值 + 系统开销
KV Cache是并发场景下显存增长的主要来源，其精确计算公式如下-7：
KV Cache显存(GB) = 2 × 最大并发请求数 × 序列长度 × 层数 × 隐层维度 × 精度字节数 ÷ (1024³)
其中：
2：Key和Value两份缓存
最大并发请求数：服务能同时处理的请求数量
序列长度：输入+输出的总token数
层数：Transformer层数
隐层维度：每个token的表示维度
精度字节数：FP16为2，INT8为1
KV Cache 大小和 并发数有关，和 batch size 无关；batch 只影响一次计算的规模，不改变 KV 总量。
vLLM通过gpu_memory_utilization参数控制显存分配-7：
可用显存 = 总GPU显存 × gpu_memory_utilization 模型权重显存 + KV Cache显存 ≤ 可用显存
通常设置gpu_memory_utilization = 0.8-0.9，预留部分显存用于系统开销和中间激活值-7-8。
CPU核心：建议≥并发数/2，用于数据预处理和调度
系统内存：需存储模型权重副本（用于CPU卸载场景）和数据缓存
以Llama 2-7B或DeepSeek-7B为例，假设模型配置：
层数：32
隐层维度：4096
精度：FP16（2字节/参数）
| 并发数 | KV Cache显存公式 | KV Cache显存 | 参数显存 | 总显存需求 | 说明 |
|---|---|---|---|---|---|
| 1 | 2×1×2048×32×4096×2÷(1024³) | 1.0GB | 14GB | ~16GB | 单用户场景 |
| 4 | 2×4×2048×32×4096×2÷(1024³) | 4.0GB | 14GB | ~19GB | 小团队使用 |
| 8 | 2×8×2048×32×4096×2÷(1024³) | 8.0GB | 14GB | ~23GB | 中等负载 |
| 16 | 2×16×2048×32×4096×2÷(1024³) | 16.0GB | 14GB | ~31GB | 高并发场景 |
| 并发数 | GPU显存需求 | 推荐GPU配置 | CPU核心 | 系统内存 | 适用场景 |
|---|---|---|---|---|---|
| 4 | 19GB | 1×RTX 4090 24GB | 4-8核 | 32GB | 个人API服务 |
| 8 | 23GB | 1×RTX 4090 24GB | 8核 | 64GB | 中小团队 |
| 16 | 31GB | 1×A100 40GB 或 2×RTX 4090 | 8-16核 | 64-128GB | 企业级服务 |
优化提示：当并发数超过8时，单张RTX 4090 24GB已接近极限，建议使用张量并行（TP）分散到多卡-1。
以Qwen-32B或DeepSeek-32B为例，假设模型配置：
层数：64
隐层维度：5120
精度：FP16（2字节/参数）
| 并发数 | KV Cache显存公式 | KV Cache显存 | 参数显存 | 总显存需求 | 说明 |
|---|---|---|---|---|---|
| 1 | 2×1×2048×64×5120×2÷(1024³) | 2.5GB | 64GB | ~67GB | 单用户场景 |
| 4 | 2×4×2048×64×5120×2÷(1024³) | 10.0GB | 64GB | ~75GB | 小团队使用 |
| 8 | 2×8×2048×64×5120×2÷(1024³) | 20.0GB | 64GB | ~85GB | 中等负载 |
| 16 | 2×16×2048×64×5120×2÷(1024³) | 40.0GB | 64GB | ~105GB | 高并发场景 |
| 并发数 | GPU显存需求 | 推荐GPU配置 | CPU核心 | 系统内存 | 适用场景 |
|---|---|---|---|---|---|
| 4 | 75GB | 1×A100 80GB | 8-16核 | 128GB | 企业API服务 |
| 8 | 85GB | 2×A100 40GB（TP=2） | 16核 | 256GB | 中型负载 |
| 16 | 105GB | 2×A100 80GB（TP=2） | 16-32核 | 256-512GB | 高并发场景 |
vLLM配置示例（2×A100 80GB）-1：
vllm serve Qwen-32B \ --tensor-parallel-size 2 \ --max-num-seqs 16 \ --gpu-memory-utilization 0.9
以Llama 2-70B或DeepSeek-70B为例，假设模型配置：
层数：80
隐层维度：8192
精度：FP16（2字节/参数）
| 并发数 | KV Cache显存公式 | KV Cache显存 | 参数显存 | 总显存需求 | 说明 |
|---|---|---|---|---|---|
| 1 | 2×1×2048×80×8192×2÷(1024³) | 5.0GB | 140GB | ~146GB | 单用户场景 |
| 4 | 2×4×2048×80×8192×2÷(1024³) | 20.0GB | 140GB | ~161GB | 小团队使用 |
| 8 | 2×8×2048×80×8192×2÷(1024³) | 40.0GB | 140GB | ~181GB | 中等负载 |
| 16 | 2×16×2048×80×8192×2÷(1024³) | 80.0GB | 140GB | ~221GB | 高并发场景 |
| 并发数 | GPU显存需求 | 推荐GPU配置 | CPU核心 | 系统内存 | 适用场景 |
|---|---|---|---|---|---|
| 4 | 161GB | 2×A100 80GB（TP=2） | 16-32核 | 256GB | 企业API服务 |
| 8 | 181GB | 4×A100 40GB（TP=4） | 32核 | 512GB | 中型负载 |
| 16 | 221GB | 4×A100 80GB（TP=4） | 32-64核 | 1TB | 高并发场景 |
混合专家模型（MoE）的并发推理显存计算与稠密模型有所不同-6-9：
总显存 = 共享参数 + 专家参数 + KV Cache + 路由开销
其中：
假设模型配置-9：
专家数量E=256，每个专家参数量约2.6B
共享参数量约300B
精度：FP8（1字节/参数）
激活专家数K=8（Top-8路由）
| 并发数 | 显存需求 | 推荐GPU配置（EP并行） | CPU核心 | 系统内存 |
|---|---|---|---|---|
| 4 | ~350GB | 8×A100 80GB（EP=8） | 32核 | 512GB |
| 8 | ~380GB | 8×A100 80GB（EP=8） | 32-64核 | 1TB |
| 16 | ~450GB | 16×A100 80GB（EP=16） | 64核+ | 2TB+ |
关键提示：MoE模型通过专家并行（EP）可将专家参数分散到多卡，大幅降低单卡显存压力-6-9。
| 参数 | 作用 | 推荐值 | 说明 |
|---|---|---|---|
gpu_memory_utilization |
显存利用率 | 0.8-0.9 | 预留10-20%用于系统开销-7 |
max_num_seqs |
最大并发数 | 根据显存计算 | 控制KV Cache上限-8 |
max_num_batched_tokens |
批处理token上限 | 4096-8192 | 平衡吞吐与延迟-8 |
tensor_parallel_size |
张量并行度 | 2/4/8 | 模型放不下时启用-1 |
enable_expert_parallel |
专家并行开关 | True（MoE模型） | 对DeepSeek等MoE模型有效 |
| 量化精度 | 参数显存减少 | KV Cache显存减少 | 适用场景 |
|---|---|---|---|
| INT8 | 50% | 50% | 高并发、追求吞吐 |
| INT4 | 75% | 75% | 超大模型、资源受限 |
当KV Cache空间不足时，vLLM会触发抢占（Preemption）机制-8。为避免性能下降：
适当提高gpu_memory_utilization
启用分块预填充（Chunked Prefill）平衡预填充和解码请求-8
| 模型规模 | 参数显存 | 并发1 | 并发4 | 并发8 | 并发16 |
|---|---|---|---|---|---|
| 7B | 14GB | 16GB | 19GB | 23GB | 31GB |
| 32B | 64GB | 67GB | 75GB | 85GB | 105GB |
| 70B | 140GB | 146GB | 161GB | 181GB | 221GB |
| 模型规模 | 目标并发 | GPU配置 | CPU核心 | 系统内存 |
|---|---|---|---|---|
| 7B | 8 | 1×RTX 4090 24GB | 8核 | 64GB |
| 7B | 16 | 2×RTX 4090 24GB（TP=2） | 16核 | 128GB |
| 32B | 8 | 2×A100 40GB（TP=2） | 16核 | 256GB |
| 32B | 16 | 2×A100 80GB（TP=2） | 32核 | 512GB |
| 70B | 8 | 4×A100 40GB（TP=4） | 32核 | 512GB |
| 70B | 16 | 4×A100 80GB（TP=4） | 64核 | 1TB |
并发推理显存核心公式：总显存 ≈ 参数显存 + 2×并发数×序列长度×层数×隐层维度×精度
KV Cache是并发场景下的主要变量，与并发数成正比增长
MoE模型需结合专家并行（EP）优化-6，显存计算需考虑共享参数和专家参数的分布
CPU和内存需求：CPU核心数建议≥并发数/2，系统内存需能容纳完整模型权重
参考：
