https://github.com/jeffreyforkfolder/tensorflow-learning/blob/master/other/tensorflow%E4%BC%98%E5%8C%96%E5%99%A8%E5%8F%82%E6%95%B0%E8%AF%A6%E8%A7%A3.md

• SGD：随机梯度下降
• Adagrad：
• Adadelta
• RMSprop
• Adam
• Adamax
• Nadam

都是非常流行的深度学习框架。比较大的点在于：

• 计算图的构建方式：TensorFlow 使用静态计算图，这意味着你需要先定义整个计算图，然后再运行你的模型。这种方式的优点是可以进行全局优化，如操作融合等，从而提高运行效率。而 PyTorch 使用动态计算图，你可以在运行模型的同时构建计算图。这种方式的优点是更加灵活，可以方便地进行控制流操作（如循环和条件语句）。
• 易用性：PyTorch 通常被认为更易于理解和使用。它的 API 设计更加直观，而且错误信息通常更加清晰。而 TensorFlow 的学习曲线可能会更陡峭一些，但是它提供了更多的高级功能和优化，这对于大规模的生产环境来说可能更有用。
• 部署：TensorFlow 提供了一整套的生产级部署工具，包括 TensorFlow Serving、TensorFlow Lite（用于移动和嵌入式设备）和 TensorFlow.js（用于在浏览器中运行模型）。而 PyTorch 的部署工具相对较少，但是它提供了与 C++ 的接口，可以用于在没有 Python 环境的设备上运行模型。
• 社区和支持：TensorFlow 由 Google 开发并支持，拥有大量的教程、例子和预训练模型。而 PyTorch 由 Facebook 开发并支持，近年来社区也在快速增长，提供了大量的学习资源。
• 性能：在大多数情况下，两者的性能都非常接近。但是在某些特定的任务和硬件配置下，可能会有一些差异。例如，TensorFlow 通常在 GPU 集群上表现得更好，而 PyTorch 在单个 GPU 上可能会有更好的性能。
• 研究和生产：PyTorch 通常被认为更适合研究和原型设计，因为它的动态计算图使得实验和调试更加容易。而 TensorFlow 则被认为更适合生产环境，因为它提供了一整套的工具来帮助你将模型部署到各种平台。

如何理解 TensorFlow 使用静态计算图，而 PyTorch 使用动态计算图呢？

首先先明确一下什么是计算图。计算图是用来描述运算的有向无环图。计算图由基本数据结构张量和基本运算单元算子构成。在计算图中通过使用节点来表示算子，节点间的有向边来表示张量状态。

TensorFlow 中的 estimator

是一个高级 API，

什么是超参数

参数和超参数的区别是什么？

Over the past five years, I've had the opportunity to work in both large corporations and startups, tackling middleware, infrastructure, and specific business projects. I've experienced the dynamics of B2B and B2C projects, and along the way, I've picked up some valuable lessons about development processes and team collaboration. Here's a summary of my experiences and what I've learned. I hope it helps anyone who reads this, and serves as a reminder to myself. I firmly believe there is always room for improvement, so I also hope this record will serve as a constant reminder to keep striving for better.

注意： 本文内容截止到 2024 年 2 月 26 日发布的 Kafka 3.7.0 版本。

MirrorMaker2（后文简称 MM2）在 2019 年 12 月随 Kafka 2.4.0 一起推出。顾名思义，是为了解决 Kafka 集群之间数据复制和数据同步的问题而诞生的 Kafka 官方的数据复制工具。在实际生产中，经常被用来实现 Kafka 数据的备份，迁移和灾备等目的。

在此也预告一下，AutoMQ 基于 MM2 的迁移产品化功能也即将和大家见面，可以帮助用户更好更快从自建 Kafka 迁移到 AutoMQ，欢迎大家届时使用。

本文翻译自：http://antirez.com/news/140
作者： Antirez（本名为 Salvatore Sanfilippo，Redis 作者）
发布时间：2024 年 1 月 1 日。

我想先明确一点，这篇文章并不旨在回顾大语言模型(LLMs)。毫无疑问，2023年对人工智能领域而言是具有里程碑意义的一年，但重复这一点似乎没有太多意义。这篇文章更多是一名程序员个人的体验分享。自从 ChatGPT 面世，以及后来我开始使用能在本地运行的大语言模型(LLMs)，我就深入地应用了这一新技术。我的目标是提高编程效率，但这不是唯一的理由。另一个重要的目的是避免在编程中那些不值得投入精力的部分浪费心智。无数个小时被花在搜索那些乏味、缺乏智力挑战的细节文档上；努力去理解一个复杂得无谓的 API；编写一些几小时后就被弃用的即用型程序。这些都是我特别想避免的，特别是在如今这个时代，谷歌搜索结果中充斥着大量无用信息，要在其中找到真正有价值的内容变得越来越困难。

本文翻译自：https://karpathy.medium.com/software-2-0-a64152b37c35
作者： Andrej Karpathy（OpenAI 创始团队成员，原特斯拉 AI 负责人）
发布时间：2017 年 11 月 12 日。

我发现，有时候人们把神经网络简单归类为机器学习工具箱里的一种工具。神经网络确实有其优势和局限，在某些情况下效果显著，有时候还能帮助人们在 Kaggle 竞赛中获胜。但遗憾的是，这种看法忽略了神经网络的真正意义。神经网络并不仅仅是一种分类工具，它们标志着软件开发方式的一次根本性变革，代表着软件 2.0 的时代。

我们所熟悉的软件 1.0 是用 Python、C++ 等语言编写的。这类软件包含了程序员为计算机撰写的明确指令。程序员通过编写代码的每一行，标定了程序空间中某一特定点，这一点展现了某种我们期望的行为。

Recently, my work requires me to familiarize myself with concepts such as AWS Availability Zones, subnets, network connectivity, NAT Gateways, and Internet Gateways. I would like to summarize my understanding of these topics briefly.

在分布式系统中，多个服务之间的交互涉及到复杂的网络通信和数据传输，其中每个服务可能由不同的团队或组织负责维护和开发。因此，在这样的环境下，当一个请求被发出并经过多个服务的处理后，如果出现了问题或错误，很难快速定位到问题的根源。全链路追踪技术可以帮助我们解决这个问题，它能够跟踪和记录请求在系统中的传输过程，并提供详细的性能和日志信息，使得开发人员能够快速诊断和定位问题。这种技术对于分布式系统的可靠性、性能和可维护性都非常重要。

RocketMQ 5.0 与分布式全链路追踪

Apache RocketMQ 5.0 版本作为近几年来最大的一次迭代，在整个可观测性上也进行了诸多改进。其中，支持标准化的分布式全链路追踪就是一个重要的特性。

分布式链路追踪系统的起源可以追溯到 2007 年 Google 发布的《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》论文。这篇论文详细介绍了 Google 内部使用的链路追踪系统 Dapper，其中使用的 span 概念被广泛采用，并成为后来开源链路追踪系统中的基础概念之一。

gRPC 提供了非常复杂的自动重试策略。其中按照重试时机可以分为简单 retry 和 hedging 两种。按照业务上划分可以分为透明重试和非透明重试。

长久以来，RocketMQ 易于部署、高性能、高可用的架构，支撑了数十年来集团内外海量的业务场景。时至今日，为了迎接如今云原生时代的新挑战，我们重磅推出了 RocketMQ 5.0 新架构。

在 5.0 新架构中，我们更新了整个 RocketMQ 的网络拓扑模型，着眼于将更上层的业务逻辑从 broker 中剥离到无状态的 proxy ，这样独立的计算节点可以无损地承担日后的升级发布任务，与此同时将 broker 解放出来承担纯粹的存储任务，为未来打造更强的消息存储引擎做好铺垫。通信层方面，出于标准化，多语言的考虑我们摒弃了 RocketMQ 使用多年的 RemotingCommand 协议，采用了 gRPC 来实现客户端与服务端之间的通信逻辑。

针对于用户侧，我们希望尽可能少的叨扰客户进行升级，维持逻辑轻量，易于维护，可观测性良好，能够可以达到“一次性把事情做对”。