工程确实有自己的一套理论，否则为什么台积电能做出 3 纳米，而 intel 做不成。理论大家都知道，但工程上的问题就多了去了。算法能给你把模型跑出来，但要变成应用，还得保证性能，就完全依赖工程部分的能力。

@bskfz 现在制程确实到了瓶颈，性能提升需要更高的运行频率还有更多的晶体管，这些都受阻制程上的漏电。鳍型工艺已经快到尽头了，越来越不好控制漏电了。

@OneMan M3 用的是台积电第一代 3 纳米工艺，叫 N3B ，良品率低，成本过高，苹果用在 iphone 15 和 Macbook 上了，都遇到了发热的问题，iphone 15 是升级了系统来改进，应该就是降频处理。用在 macbook air 上，也遇到降频的问题，因为 air 不带风扇，只能通过降频来减少发热。据说台积电在下一代 3 纳米工艺 N3E 上会改进制程设计，发热会改善。

感觉 intel 被两家都抛弃了，是不是该反思一下。这么多年都过去了，毫无进步。

不需要考虑这么紧凑的数据格式吧，数据错了造成的损失比网络开销要大很多。如果网关丢掉了设备的信息，还是让网关把格式改一下，增加传感器的 id 数据到后端。一般都是设备直接对接 mqtt 的 server ，mqtt 的协议里面应该有设备的 session 数据结构，应该是能将数据合并在一起的。

等 M4 的，这代 M3 的工艺发热量高

学习和调试机应该是要配置一台的，N 卡就行。租卡适合模型都调试完毕了，要进行大规模训练。

主要是依赖 N 卡，显存是关键，一个 7B 的模型，大概能塞进 24G 的显存里，再大就装不进去了。

@cheng6563 线程池的作用还是为了减少创建线程的开销，在 linux 下是存在用户态和核心态的指令差别的，核心态运行在 cpu 0 的指令级别上，是一种高优先级的程序指令，通常叫系统调用，这些指令能干很危险的操作，例如对物理内存的访问。而用户态只能看到虚拟内存了，这就倒是创建线程时候，会在两个状态的代码之间来回切换。当你做高并发的应用时，例如 1000req/s 的操作时，你就不能忽视这种开销了。你可以做个实验，当你创建 100 万个 thread 对象，即便都在线程池中什么任务都不干，机器已经卡的不行了。

Java 的这个线程池设计问题可以追朔到 java 语言创立之初的作用，最早 java 是想提供给智能硬件编程用的，没有考虑服务器大并发的使用场景，后续的 golang 还有 erlang 的并发模型都和 java 不一样，只能说 java 用在服务器上编程大大超出了创建者的预期。每年都有新的技术出现，开发者可能疲于追求新的技术，而忘记了探讨一项技术的本源是什么，上面太多的回答是从使用的角度解释的，可能从业这么长时间，也没有去了解过这些技术是怎么演进的。我想，可能参与这个过程的老师傅们已经下岗了。

首先你的说法是没有问题的，这个问题是 java 的问题，如果你学习过其他语言，如 erlang ，它是可以马上创建新的线程去执行的。erlang 可以轻松并发几百万个线程。其实 erlang 这个不叫线程，叫协程。java 做不到是因为线程太昂贵了，这个资源创建时候，需要准备部分线程栈存放线程的元数据，大概要消耗一小部分内存，同时要映射到操作系统的线程上，如果经常这样做，开销是非常高的，可能会超过你执行线程的任务。所以，现在 java 的模式是做一个线程池，通过一个队列来接受任务，避免反复创建线程的开销。

可以不放，但是 mqtt 的服务你的做调整吧，如果 mqtt 是自己定制的，可以做。因为每个 client 有自己的 session ，如果你能用 payload 的 id 关联到 sessionid 上，那就可以让 mqtt 给特定 session 的设备推消息。

小学那点知识，家长都可以辅导，没啥好坏之分，小学就是培养学习习惯吧，主要是能完成作业。

煤炭基本是不会新增产能了，维持现有产能，基本国内煤炭要比外煤贵，但未来外贸减少，人民币贬值，外煤可能就不便宜，还得用内煤，看看几个煤炭上市公司回报都不错，未来应该也是这样。

3 以为是退路，其实 3 基本没戏了。经济下行，公务员已经无法供养那么多了。

存在风险的系统，供应商有风险的该替换的替换，反正这个阶段别想怎么搞造轮子，吹概念，就需要性能提高 10%，费用减少 50%。

这个阶段不是应该先想着怎么来减少 IT 支出吗？没有必要的系统该关的关闭，没法维护的该退出退出，服务器能压缩的压缩，能自动化的自动化，减少人为操作。

现在问题是 b 站免费的课程都刷不过来，另外就是如果大家平时工作和这项内容不搭边，多半听听后就没有然后了，而专们做这部分工作的人又没有必要去听。