写点什么
创作场景
- 记录自己日常工作的实践、心得
- 发表对生活和职场的感悟
- 针对感兴趣的事件发表随笔或者杂谈
- 从 0 到 1 详细介绍你掌握的一门语言、一个技术，或者一个兴趣、爱好
- 或者，就直接把你的个人博客、公众号直接搬到这里
登录/注册
dean
收录了 dean 频道下的 50 篇内容
Jeff Dean 再执笔：一文看尽 2019 谷歌 AI 重大突破
对于谷歌的研究团队来说，2019 年是令人兴奋的一年。
Jeff Dean 三执笔：一文看尽 2020 年谷歌 AI 重大突破
在二十年前刚刚加入谷歌时，我们关注的问题只有一个——如何面向这么多不同种类的联网计算机提供一整套质量出色且涵盖范围全面的网络信息搜索服务。
谷歌最好的程序员 Jeff Dean：我用过 18 种编程语言
“不是由编译器向 Dean 报警，而是Dean 向编译器报警。”
Gemini 灵魂人物、传奇工程师 Jeff Dean 最新访谈：未来人均 50 个虚拟实习生，用不上专家了！
“大一统模型的时代真的来了。关键在于，模型正在变得越来越强，不再需要领域专家。”
Jeff Dean：一年内 AI 将取代初级工程师，网友：“Altman 只会画饼，Jeff 说的话才致命”
大神Jeff Dean划定职业生命线：2026年，AI初级工程师将24/7全天候工作
百度入局后“形势不对劲”，拍卖当场叫停！Hinton 与 Jeff Dean 首曝：64 岁实习生，为“开心”与 200 万美元算力押定谷歌
现代AI的成就，是在哪个时刻开始丝滑迭代，频频爆发？Transformer之后，未来何种架构能再度支撑起下一代AI的阶跃式进步？
Jeff Dean 离职前最后一次对话：我低估了 AI，也看清了创业者的唯一生路
“模型其实只是整个系统里的一块拼图。你要做的，是构建一个能解决真正有趣问题的完整系统。”
Jeff Dean 在 SystemML 会议上的论文解读：学习索引结构的一些案例
本文是Google的Fellow，Jeff Dean，把机器学习应用到系统设计的论文，原文发布在SystemML会议上，作者进行了翻译。
Jeff Dean 执笔：一文看尽 2018 谷歌 AI 重大突破
2018 年是令人兴奋的一年。Google Research 通过多种方式推动技术研究工作，包括基础计算机科学研究成果和出版物，以及多项研究被应用在谷歌的新兴领域（如医疗保健和机器人）、开源软件贡献，以及与谷歌产品团队的密切合作，所有这些都旨在提供有用的工具和服务。
Jeff Dean 的传奇人生：超级工程师们拯救谷歌
计算机界最好的结对编程榜样
采访高性能 ASP.NET 网站一书的作者 Dean Hume 及书评
本文作者Anand将对Dean Hume所编写的《高性能ASP.NET网站》一书进行一番点评，这本书将帮助开发者们学习与ASP.NET网站优化相关的各种技术。
刚刚，哈萨比斯卸任谷歌 DeepMind CEO，27 年老将 Jeff Dean 离职创业
谷歌正在对其AI权力中心进行一次罕见的系统性重排。
Yann LeCun、Jeff Dean 等 AI 大神推特激辩 AGI 和深度学习
最近，推特上掀起了一场AI领域的大论战，AI大神们连打几个回合，讨论AGI（通用人工智能）和深度学习之间的关系。一时间，Yann LeCun、Jeff Dean、Gary Marcus等大神都卷入这场讨论中，宛如神仙打架。
Jeff Dean 谈如何在大型在线服务中做到快速响应
6月于硅谷举行的Velocity 2014大会上，Google首席科学家Jeff Dean做了一场题为《Achieving Rapid Response Times In Large Online Services》的主题演讲，分享了让大型系统运行更加流程以便改善用户体验的种种方法。
谷歌 AI 老大 Jeff Dean 惹争议，只因开除黑人高管研究员？
谷歌这次似乎摊上大事儿了。
Jeff Dean 点赞共识论文：一种通用的分布式一致性方案
Heidi Howard最近通过推特与全世界分享了一篇论文草稿。这篇文章引起了我的注意，因为它承诺为一致性问题提供一个通用的解决方案，而且还利用了对不可变状态的推理来实现这一点。每个服务器维护的状态都是单调的。
图书摘录:《伸缩的软件敏捷：大型企业最佳实践》
“但是敏捷怎么伸缩？”越来越多的案例表明敏捷可以伸缩。请浏览《可伸缩的软件敏捷：大型企业最佳实践》一书的节选文章。在第一章中，Leffingwell回顾了敏捷开发方法增长背后的驱动力，在第二章中，他回顾了“为什么瀑布模型无效。”
谷歌 AlphaChip 论文再被质疑，DeepMind 驳斥都没做预训练，顺带还揪出了“内鬼”？
Markov 的“元分析”也让 DeepMind 产生了新的担忧，即谷歌内部存在一位“告密者”。
拖尾请求不是故障：自适应 Hedged Request 如何降低 74% 的 p99 延迟
拖尾请求指的是完成时间异常缓慢但最终成功完成的请求。在扇出（fan-out）架构中，它们才是 p99 延迟的主要来源。重试机制则会向已经备受压力的后端增加额外负载，从而使问题进一步恶化。 在一个包含 100 个下游服务的扇出架构中，如果每个服务的拖尾请求率为 1%，那么 63% 的顶层请求都会因为至少一个拖尾请求而被拖慢。因此，仅依赖单个服务的健康指标来诊断系统级尾部延迟往往具有误导性。 固定的请求对冲触发条件在测试环境中看起来效果显著，但在生产环境中往往难以长期奏效。因为负载变化、服务发布以及业务流量波动都会改变系统的延迟特征，这意味着触发条件需要持续人工调整，而现实中很少有团队能够长期维护这项工作。 DDSketch 提供了 O(1) 的分位数估计能力，并且内存占用恒定。它能够提供相对误差保证（±1%），非常适合实时追踪每台主机的延迟分布，每个请求仅增加约 35 纳秒的额外开销。 通过 Token Bucket（令牌桶）预算机制，将 Hedge 请求速率限制在总流量的一定比例以内，可
Copyright © 2026, Geekbang Technology Ltd. All rights reserved. 极客邦控股（北京）有限公司 | 京 ICP 备 16027448 号 - 5
京公网安备 11010502039052号 | 产品资质
京公网安备 11010502039052号 | 产品资质
