diff --git a/zh/_blog.yml b/zh/_blog.yml
index 1bafdc4497..b4de7ccb70 100644
--- a/zh/_blog.yml
+++ b/zh/_blog.yml
@@ -2096,6 +2096,17 @@
     - guide
     - sd3-5
 
+- local: s2s_endpoint
+  title: "在 Hugging Face 上部署语音转语音模型"
+  author: andito
+  thumbnail: /blog/assets/s2s_endpoint/thumbnail.png
+  date: October 22, 2024
+  tags:
+    - audio
+    - speech-to-speech
+    - inference
+    - inference-endpoints
+
 - local: synthid-text
   title: SynthID Text：在 AI 生成文本中应用不可见水印的新技术
   author: sumedhghaisas
@@ -2142,6 +2153,16 @@
     - datasets
     - guide
 
+- local: from-files-to-chunks
+  title: "从文件到块: 提高 Hugging Face 存储效率"
+  author: jsulz
+  thumbnail: /blog/assets/from-files-to-chunks/thumbnail.png
+  date: November 20, 2024
+  tags:
+    - dedupe
+    - storage
+    - content defined chunking
+
 - local: designing-positional-encoding
   title: 设计位置编码
   author: FL33TW00D-HF
@@ -2162,6 +2183,18 @@
     - guide
     - ethics
 
+
+- local: layerskip
+  title: 自推测解码实现更快文本生成
+  author: ariG23498
+  thumbnail: /blog/assets/layerskip/thumbnail.png
+  date: November 20, 2024
+  tags:
+    - research
+    - nlp
+    - open-source
+    - collaboration
+
 - local: paligemma2
   title: 欢迎 PaliGemma 2 – 来自 Google 的新视觉语言模型
   author: merve
@@ -2175,6 +2208,15 @@
     - VLM
     - research
 
+- local: ethics-soc-7
+  title: "人工智能代理已经到来，接下来呢？"
+  author: meg
+  thumbnail: /blog/assets/190_ethics-soc-7/thumbnail.png
+  date: January 13, 2025
+  tags:
+    - ethics
+    - agents
+
 - local: smolervlm
   title: SmolVLM 越变越小 —— 全新 250 M 和 500 M 模型正式发布！
   author: andito
diff --git a/zh/ai-art-newsletter-jan-25.md b/zh/ai-art-newsletter-jan-25.md
index d49b88d8c0..ab809b7497 100644
--- a/zh/ai-art-newsletter-jan-25.md
+++ b/zh/ai-art-newsletter-jan-25.md
@@ -77,7 +77,7 @@ _Zero-shot 技术风暴来袭_ ——2024 年见证了仅需 **单张参考图**
 
 <figure class="image flex flex-col items-center text-center m-0 w-full">
     <video
-       alt=" 混元视频演示 "
+       alt="混元视频演示"
        autoplay loop autobuffer muted playsinline
      >
      <source src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/video_gen/hunyuan-output.mp4" type="video/mp4">
@@ -135,7 +135,7 @@ _Zero-shot 技术风暴来袭_ ——2024 年见证了仅需 **单张参考图**
 
 <figure class="image flex flex-col items-center text-center m-0 w-full">
     <video
-       alt=" 面部动画演示 "
+       alt="面部动画演示"
        autoplay loop autobuffer muted playsinline
      >
      <source src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/ai_art_newsletter_1/isaac_1.mp4" type="video/mp4">
@@ -148,7 +148,7 @@ _Zero-shot 技术风暴来袭_ ——2024 年见证了仅需 **单张参考图**
 
 <figure class="image flex flex-col items-center text-center m-0 w-full">
     <video
-       alt="TRELLIS 演示 "
+       alt="TRELLIS 演示"
        autoplay loop autobuffer muted playsinline
      >
      <source src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/ai_art_newsletter_1/trellis.mp4" type="video/mp4">
@@ -171,7 +171,7 @@ Apache 2.0 协议开源的 [YuE](https://huggingface.co/m-a-p/YuE-s1-7B-anneal-e
 
 <figure class="image flex flex-col items-center text-center m-0 w-full">
     <video
-       alt="YuE 歌曲演示 "
+       alt="YuE 歌曲演示"
        autobuffer playsinline
      >
      <source src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/ai_art_newsletter_1/My first YuE (open source Suno) AI generated full song.mp4" type="video/mp4">
@@ -194,4 +194,4 @@ Apache 2.0 协议开源的 [YuE](https://huggingface.co/m-a-p/YuE-s1-7B-anneal-e
 
 从本期开始，我们 ([Poli](https://huggingface.co/multimodalart) 与 [Linoy](https://huggingface.co/linoyts)) 将每月为您精选创意 AI 领域最新动态。在这个快速迭代的领域，我们愿做您的信息顾问，让创意工具触手可及。
 
-<iframe src="https://multimodalaiart.substack.com/embed" width="480" height="320" style="border:1px solid #EEE; background:white;" frameborder="0" scrolling="no"></iframe>
\ No newline at end of file
+<iframe src="https://multimodalaiart.substack.com/embed" width="480" height="320" style="border:1px solid #EEE; background:white;" frameborder="0" scrolling="no"></iframe>
diff --git a/zh/ethics-soc-7.md b/zh/ethics-soc-7.md
new file mode 100644
index 0000000000..2720f7250f
--- /dev/null
+++ b/zh/ethics-soc-7.md
@@ -0,0 +1,201 @@
+---
+title: "人工智能代理已经到来，接下来呢？"
+thumbnail: /blog/assets/190_ethics-soc-7/thumbnail.png
+authors:
+  - user: meg
+  - user: evijit
+  - user: sasha
+  - user: giadap
+translators:
+  - user: smartisan
+  - user: zhongdongy
+    proofreader: true
+---
+
+# 人工智能代理已经到来，接下来呢？
+
+![Huggy the Pooh](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/190_ethics-soc-7/huggy_the_pooh.png)
+
+## 引言
+
+大语言模型 (Large Language Models，LLM) 能力的突然快速进步——例如生成流畅的句子和在基准测试中获得越来越高的分数——使得人工智能开发者和企业都在关注下一步的发展: 下一个突破性技术会是什么？最近迅速崛起的一项技术是 “人工智能代理”，这是一种能够在数字世界中按照部署者的目标采取行动的系统。如今大多数人工智能代理都是通过将大语言模型整合到可以执行多种功能的更大系统中构建的。这波新技术的一个基本理念是，计算机程序不再需要作为受人类控制的工具而局限于专门的任务: 它们现在可以在没有人类输入的情况下组合多个任务。
+
+这一转变标志着系统能力的根本性转变，使其能够在非确定性环境中创建特定于上下文的计划。许多现代人工智能代理不仅仅执行预定义的操作，而是被设计用来分析新情况、制定相关目标，并采取之前未定义的行动来实现目标。
+
+在本文中，我们将简要概述人工智能代理的概念，并详细说明其中涉及的伦理价值，记录人工智能代理在收益和风险方面的权衡。然后我们将建议前进的道路，以实现人工智能代理为社会带来尽可能多的益处的未来。关于代理技术方面的介绍，[请参阅我们最近的开发者博文](https://huggingface.co/blog/smolagents)。关于在现代生成式人工智能之前编写的代理介绍 (在今天仍然适用)，请参阅 [Wooldridge and Jennings, 1995](https://core.ac.uk/download/pdf/1498750.pdf)。
+
+我们的分析表明，系统的自主程度越高，对人的风险就越大: 用户让渡的控制权越多，系统带来的风险就越大。特别令人担忧的是个人 **安全** 风险，这些风险恰恰源于推动人工智能代理开发的同样好处，比如让开发者不必预测系统可能采取的所有行动。更加复杂的是，某些安全危害会为其他类型的危害打开大门——例如 [隐私](#价值观-隐私) 和 [安全](#价值观-安全性) 危害——而对不安全系统的不当 [安全性](#价值观-信任) 会引发更多危害的滚雪球效应。因此，我们建议不要开发完全自主的人工智能代理。例如，能够编写和执行自己代码的人工智能代理 (超出开发者控制的受限代码选项) 将被赋予凌驾于所有人类控制之上的能力。相比之下，半自主人工智能代理可能带来的好处超过风险，这取决于自主程度、系统可用的任务以及个人对其的控制性质。我们现在深入探讨这些主题。
+
+## 什么是人工智能代理？
+
+### 概述
+
+对于什么是 “人工智能代理” 尚无明确共识，但最近推出的人工智能代理的共同点是它们具有 “主动性”，也就是说，它们具有一定程度的 **自主性**: 在给定目标规范的情况下，它们可以将其分解为子任务并在没有直接人类干预的情况下执行每个任务。例如，一个理想的人工智能代理可以响应诸如 “帮助我写出更好的博文” 这样的高级请求，通过独立地将这个任务分解为: 检索与你以前的博文主题相似的网络写作; 为新博文创建带有大纲的文档; 并在每个文档中提供初步写作。最近关于人工智能代理的工作使软件具有比过去更广泛的功能范围和更灵活的使用方式，最近的系统被部署用于从组织会议 ([示例 1](https://www.lindy.ai/template-categories/meetings), [示例 2](https://zapier.com/agents/templates/meeting-prep-assistant), [示例 3](https://www.ninjatech.ai/product/ai-scheduling-agent), [示例 4](https://attri.ai/ai-agents/scheduling-agent)) 到创建个性化社交媒体帖子 ([示例](https://www.hubspot.com/products/marketing/social-media-ai-agent)) 的各种用途，而无需明确说明如何做到这一点。
+
+我们为本期通讯调查的所有最近推出的人工智能代理都建立在机器学习模型的基础上，大多数特别使用 **大语言模型** (LLM) 来驱动其行动，这是计算机软件的一种新颖方法。除了建立在机器学习之上，今天的人工智能代理与过去的代理有相似之处，在某些情况下实现了 [以前关于代理可能是什么样子的理论设想](https://core.ac.uk/download/pdf/1498750.pdf): 具有自主性，展示 (感知到的) 社交能力，并适当平衡反应性和主动性行为。
+
+这些特征有程度之分: 不同的人工智能代理具有不同程度的能力，可以单独工作或与其他代理协同工作以实现目标。因此，人工智能代理可以说具有或多或少的自主性 (或主动性)，代理的程度可以被视为一个连续的光谱。这种流动的人工智能代理概念导致了最近对什么是人工智能代理的困惑和误解，我们希望在这里提供一些明确的解释。下表详细说明了人工智能代理的各个层次。
+
+| 主动性程度 | 描述 | 控制者 | 功能称呼 | 示例代码 |
+|---------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------|-----------------------------|--------------------------------------------|
+| ☆☆☆☆ | 模型对程序流程没有影响 | 👤 开发者 | 简单处理器 | `print_llm_output(llm_response)` |
+| ★☆☆☆ | 模型决定基本控制流程 | 👤 开发者 | 路由器 | `if llm_decision(): path_a() else: path_b()` |
+| ★★☆☆ | 模型决定如何执行功能 | 👤 💻 开发者+系统 | 工具调用 | `run_function(llm_chosen_tool, llm_chosen_args)` |
+| ★★★☆ | 模型控制迭代和程序继续 | 💻 👤 系统+开发者 | 多步骤代理 | `while llm_should_continue(): execute_next_step()` |
+| ★★★★ | 模型编写和执行新代码 | 💻 系统 | 完全自主代理 | `create_and_run_code(user_request)` |
+
+_表 1. 使用机器学习模型 (如 LLM) 的系统可以具有不同程度的主动性。系统也可以在 “多代理系统” 中组合，其中一个代理工作流触发另一个代理，或多个代理共同工作以实现目标。改编自 [smolagent 博文](https://huggingface.co/blog/smolagents)，针对本博文进行了调整。_
+
+从伦理角度来看，从人类让渡控制权并将其交给机器的角度理解自主性的连续性也很有用。系统越自主，我们让渡的人类控制就越多。
+
+在本文中，我们使用了一些拟人化的语言来描述人工智能代理，这与当前行业惯例一致。[正如历史学术研究指出的](https://core.ac.uk/download/pdf/1498750.pdf)，使用通常描述人类的心理语言 (如知识、信念和意图) 来描述人工智能代理，可能会影响用户对系统能力的理解。这种语言作为一种抽象工具，虽然掩盖了技术细节，但有助于简化描述。需要强调的是: 使用拟人化语言并不意味着这些系统真正具有思维。
+
+### 人工智能代理的不同维度
+
+人工智能代理在多个相互关联的维度上有所不同:
+
+- **自主性:** 最新的 “代理” 可以在没有用户输入的情况下至少采取一个步骤。目前 “代理” 一词用于描述从单步提示和响应系统 ([引用](https://blogs.microsoft.com/blog/2024/10/21/new-autonomous-agents-scale-your-team-like-never-before/)) 到多步客户支持系统 ([示例](https://www.lindy.ai/solutions/customer-support)) 的各种系统。
+- **主动性:** 与自主性相关的是主动性，指的是系统在用户没有直接指定目标的情况下可以采取多少目标导向行为 ([引用](https://core.ac.uk/download/pdf/1498750.pdf))。一个特别 “主动” 的人工智能代理的例子是一个系统，它监控你的冰箱以确定你正在用完什么食物，然后在你不知情的情况下为你购买所需物品。[智能恒温器](https://en.wikipedia.org/wiki/Smart_thermostat) 是一种正在人们家中越来越多采用的主动式人工智能代理，根据环境变化和它们学习到的用户行为模式自动调节温度 ([示例](https://www.ecobee.com/en-us/smart-thermostats/))。
+- **拟人化:** 人工智能代理可以被设计得或多或少像特定的人或群体。这一领域的最新研究 ([示例 1](https://arxiv.org/abs/2411.10109)，[示例 2](https://www.researchgate.net/publication/387362519_Multi-Agent_System_for_Emulating_Personality_Traits_Using_Deep_Reinforcement_Learning)，[示例 3](https://medium.com/@damsa.andrei/ai-with-personality-prompting-chatgpt-using-big-five-values-def7f050462a)) 专注于根据五大人格特质——开放性、尽责性、外向性、宜人性和神经质来设计系统，作为人工智能的 “心理框架” ([引用](https://smythos.com/artificial-intelligence/conversational-agents/conversational-agent-frameworks/#:~:text=The%20OCEAN%20Model%3A%20A%20Framework%20for%20Digital%20Personality&text=OCEAN%20stands%20for%20Openness%2C%20Conscientiousness,feel%20more%20authentic%20and%20relatable.))。这一光谱的终点是 “数字孪生” ([示例非主动性数字孪生](https://www.tavus.io))。我们目前还不知道有主动性的数字孪生。为什么创建主动性数字孪生特别有问题最近已经被 [Salesforce 的伦理小组](https://www.salesforce.com/blog/ai-agent-design/) 等机构讨论过 ([示例](https://www.technologyreview.com/2024/11/26/1107309/we-need-to-start-wrestling-with-the-ethics-of-ai-agents/))。
+- **个性化:** 人工智能代理可能使用与用户个人需求相一致的语言或执行相应的操作，例如，根据当前市场模式和用户过去的投资来做出 [投资建议](https://www.zendesk.com/blog/ai-agents/)。
+- **工具使用:** 人工智能代理还可以使用不同数量的额外资源和工具。例如，第一波人工智能代理使用搜索引擎来回答查询，此后又添加了更多工具，使它们能够操作其他技术产品，如文档和电子表格 ([示例 1](gemini.google.com)，[示例 2](https://copilot.microsoft.com))。
+- **多样性:** 与上述相关的是代理可以采取的行动有多么多样。这取决于:
+
+  - **领域特异性:** 代理可以在多少不同领域运作。例如，仅限电子邮件，还是电子邮件与在线日历和文档并用。
+  - **任务特异性:** 代理可以执行多少种不同类型的任务。例如，通过在参与者的日历中创建日历邀请来安排会议 ([示例](https://attri.ai/ai-agents/scheduling-agent))，还是另外发送会议提醒邮件并在会议结束后向所有参与者提供会议内容摘要 ([示例](https://www.nyota.ai))。
+  - **模态特异性:** 代理可以操作多少种不同的模态——文本、语音、视频、图像、表单、代码。最近的一些人工智能代理被设计成高度多模态的 ([示例](https://deepmind.google/technologies/project-mariner/))，我们预测人工智能代理的开发将继续增加多模态功能。
+  - **软件特异性:** 代理可以与多少种不同类型的软件交互，以及交互的深度如何。
+
+- **适应性:** 与多样性类似的是系统根据新信息或情境变化更新其行动序列的程度。这也被描述为 “动态的” 和 “情境感知的”。
+- **行动界面:** 代理可以执行操作的场所。传统聊天机器人仅限于聊天界面; 基于聊天的代理可能还能浏览网络并访问电子表格和文档 ([示例](copilot.microsoft.com/))，甚至可能通过控制计算机图形界面上的项目来执行此类任务，例如移动鼠标 ([示例 1](DigiRL)，[示例 2](https://github.com/MinorJerry/WebVoyager)，[示例 3](https://www.anthropic.com/news/3-5-models-and-computer-use))。还有一些物理应用，比如使用模型来驱动机器人 ([示例](https://deepmind.google/discover/blog/shaping-the-future-of-advanced-robotics/))。
+- **请求格式:** 人工智能代理的一个共同主题是用户应该能够输入任务请求，而无需指定完成任务的具体细节。这可以通过低代码解决方案 ([示例](https://huggingface.co/blog/smolagents)) 、文本形式的人类语言或语音形式的人类语言 ([示例](https://play.ai)) 来实现。可以用人类语言提供请求的人工智能代理是基于 LLM 的聊天机器人最近成功的自然发展: 基于聊天的 “人工智能代理” 比聊天机器人更进一步，因为它可以在聊天应用程序之外运作。
+- **反应性:** 这个特征指的是人工智能代理完成其行动序列所需的时间: 仅仅几秒钟，还是更长的时间跨度。这种效果的先驱可以在现代聊天机器人中看到。例如，ChatGPT 在几毫秒内响应，而 Qwen QwQ 则需要几分钟，迭代通过标记为 “推理” 的不同步骤。
+- **数量:** 系统可以是单代理或多代理的，通过协同工作、按顺序或并行方式满足用户需求。
+
+## 风险、收益和使用: 基于价值的分析
+
+为了从伦理角度审视人工智能代理，我们根据最近人工智能代理研究和营销中倡导的不同价值观来分析其风险和收益。这些并非详尽无遗，而是对人工智能代理所基于的技术 (如 LLM) 已记录的风险、危害和收益的补充。我们希望本节能够有助于理解如何开发人工智能代理，提供有关不同开发优先事项中的收益和风险的信息。这些价值观也可能为评估协议 (如红队测试) 提供参考。
+
+### 价值观: 准确性
+
+- 🙂 **潜在收益:** 通过基于可信数据，代理可以比仅依靠纯模型输出更准确。这可以通过基于规则的方法或机器学习方法 (如 RAG) 来实现，现在正是为确保准确性做出新贡献的好时机。
+- 😟 **风险:** 现代人工智能代理的基础是生成式人工智能，它无法区分真实和虚幻、事实和虚构。例如，大语言模型被设计用来构建看起来像流畅语言的文本——这意味着它们经常产生听起来对但实际上很错的内容。在人工智能代理中应用时，LLM 输出可能导致错误的社交媒体帖子、投资决策、会议摘要等。
+
+### 价值观: 辅助性
+
+- 🙂 **潜在收益:** 代理理想情况下应该对用户需求有帮助，补充 (而不是取代) 人。理想情况下，它们可以帮助提高用户完成任务的 [速度](#价值观-速度) 和同时完成多个任务的 [效率](#价值观-效率)。辅助性代理也可能增强能力以最小化负面结果，例如帮助盲人用户导航繁忙楼梯的人工智能代理。经过良好开发以具有辅助性的人工智能代理可以为其用户提供更多的自由和机会，帮助提高用户在组织内的积极影响，或帮助用户增加在公共平台上的影响力。
+- 😟 **风险:** 当代理取代人时——例如在工作中使用人工智能代理代替人——这可能造成就业损失和经济影响，进一步加大技术创造者和为技术提供数据的人 (通常是在未经同意的情况下) 之间的分歧。此外，设计不当的辅助性可能导致过度依赖或不当 [安全性](#价值观-信任) 带来的危害。
+
+### 价值观: 一致性
+
+关于人工智能代理的一个观点是，它们可以帮助保持一致性，因为它们受周围环境的影响较小。这可能是好事也可能是坏事。我们尚未看到关于人工智能代理一致性本质的严谨研究，尽管相关研究表明，许多人工智能代理所基于的 LLM 具有高度的不一致性 ([引用 1](https://www.medrxiv.org/content/10.1101/2023.08.03.23293401v2)，[引用 2](https://arxiv.org/abs/2405.01724))。在敏感领域测量人工智能代理的一致性将需要开发新的评估协议。
+
+- 🙂 **潜在收益:** 人工智能代理不会像人类那样受到世界的 “影响”，不会因情绪、饥饿、睡眠水平或对人的感知偏见而产生不一致 (尽管人工智能代理会延续基于其训练数据中人类内容的偏见)。多家公司都强调一致性是人工智能代理的关键优势 ([示例 1](https://www.salesforce.com/agentforce/what-are-ai-agents)，[示例 2](https://www.oracle.com/artificial-intelligence/ai-agents/))。
+- 😟 **风险:** 许多人工智能代理的生成组件在结果中引入固有的可变性，即使在类似情况下也是如此。这可能影响 [速度](#价值观-速度) 和 [效率](#价值观-效率)，因为人们必须发现和解决人工智能代理的不当不一致性。未被发现的不一致可能造成 [安全](#价值观-安全性) 问题。一致性也可能并不总是可取的，因为它可能与 [公平](#价值观-公平) 产生冲突。在不同部署和行动链中保持一致性可能需要人工智能代理记录和比较其不同的交互——这带来了监控和 [安全性](#价值观-隐私) 风险。
+
+### 价值观: 效率
+
+- 🙂 **潜在收益:** 人工智能代理的一个卖点是它们可以帮助人们提高效率——例如，它们会为你整理文档，这样你就可以把更多时间花在家人身上或追求你觉得有意义的工作上。
+- 😟 **风险:** 一个潜在的缺点是它们可能降低人们的效率，因为试图识别和修复代理引入的错误 (由于代理能够采取多个连续步骤，可能是复杂的问题级联) 可能耗时、困难且令人压力重重。
+
+### 价值观: 公平
+
+人工智能代理可能影响情况的公平性、公正性和包容性。
+
+- 🙂 **潜在收益:** 人工智能代理可能有助于 “创造公平竞争环境”。例如，会议助手可能显示每个人发言的时间。这可以用来促进更平等的参与或突出性别或地点之间的不平衡 ([示例](https://equaltime.io))。
+- 😟 **风险:** 现代人工智能代理所基于的机器学习模型是通过人类数据训练的; 人类数据可能是不公平、不公正、排他性的，甚至更糟。系统结果的不公平也可能由于数据收集中的样本偏差 (例如，某些国家的过度代表) 而产生。
+
+### 价值观: 类人性
+
+- 🙂 **潜在收益:** 能够生成类人行为的系统提供了机会来模拟不同子群体如何对不同刺激做出反应。这在直接人类实验可能造成伤害的情况下，或当大量模拟有助于更好地解决实验问题时特别有用。例如，合成人类行为可以用来预测约会兼容性，或预测经济变化和政治转变。目前正在研究的另一个潜在好处是类人性对于易于沟通甚至陪伴都很有用 ([示例](https://dl.acm.org/doi/abs/10.1145/3213050))。
+- 😟 **风险:** 这种好处可能是一把双刃剑: 类人性可能导致用户** 拟人化**系统，这可能产生负面心理影响，如过度依赖 ([引用](https://www.vox.com/future-perfect/367188/love-addicted-ai-voice-human-gpt4-emotion)) 、[不当信任](#价值观-信任)、依赖性和情感纠缠，导致反社会行为或自我伤害 ([示例](https://www.npr.org/2024/12/10/nx-s1-5222574/kids-character-ai-lawsuit))。有人担心人工智能代理的社交互动可能会加剧孤独感，但请参见 [引用 1](https://www.sciencedirect.com/science/article/abs/pii/S0747563203000402)，[引用 2](https://www.sciencedirect.com/science/article/pii/S245195882100018X) 了解从社交媒体使用中可能获得的细微差别。恐怖谷现象增加了另一层复杂性——当代理变得更像人类但又未能完全模拟人类时，它们可能在用户中引发不适、厌恶或认知失调的感觉。
+
+### 价值观: 互操作性
+
+- 🙂 **潜在收益:** 能够与其他系统协同工作的系统可以为人工智能代理提供更多的灵活性和选择。
+- 😟 **风险:** 然而，这可能会损害 [安全性](#价值观-安全性) 和 [安全防护](#价值观-安全防护)，因为代理能够影响并受到其有限测试环境之外系统的影响会增加恶意代码和意外问题行为的风险。例如，连接到银行账户以便轻松代表某人购买物品的代理可能会掏空银行账户。由于这种担忧，科技公司一直避免发布可以自主进行购买的人工智能代理 ([引用](https://www.wired.com/story/amazon-ai-agents-shopping-guides-rufus/))。
+
+### 价值观: 隐私
+
+- 🙂 **潜在收益:** 人工智能代理可能在保持交易和任务完全保密方面提供一些隐私保护，除了人工智能代理提供商可以监控的内容之外。
+- 😟 **风险:** 为了使代理按照用户的期望工作，用户可能必须提供详细的个人信息，如他们要去哪里、与谁会面以及在做什么。为了使代理能够以个性化方式代表用户行动，它可能还需要访问可用于提取更多私人信息的应用程序和信息来源 (例如，从联系人列表、日历等)。用户可以为了 [效率](#价值观-效率) 轻易放弃对其数据的控制 (如果对代理有 [安全性](#价值观-信任)，甚至更多) ; 如果发生隐私泄露，人工智能代理带来的不同内容的互连性可能使情况更糟。例如，有权访问电话对话和社交媒体发帖的人工智能代理可能会向全世界分享高度私密的信息。
+
+### 价值观: 相关性
+
+- 🙂 **潜在收益:** 创建针对个别用户个性化的系统的一个动机是帮助确保其输出对用户特别相关和连贯。
+- 😟 **风险:** 然而，这种个性化可能会放大现有偏见并创造新的偏见: 当系统适应个别用户时，它们可能会通过选择性信息检索强化和加深现有偏见，创建确认偏见，并建立强化有问题观点的回音室。使代理对用户更相关的机制——它们从用户偏好中学习和适应的能力——可能会无意中延续和加强社会偏见，使平衡个性化与负责任的人工智能开发的挑战变得特别困难。
+
+### 价值观: 安全性
+
+- 🙂 **潜在收益:** 机器人人工智能代理可能有助于保护人们免受身体伤害，例如能够拆除炸弹、清除毒物或在对人类有危险的制造或工业环境中操作的代理。
+- 😟 **风险:** 代理行动的不可预测性意味着看似安全的单个操作可能会以潜在有害的方式组合，创造出难以预防的新风险。(这类似于 [工具趋同性和回形针最大化问题](https://en.wikipedia.org/w/index.php?title=Instrumental_convergence&section=3#Paperclip_maximizer)。) 也可能不清楚人工智能代理是否会设计一个绕过给定防护措施的过程，或者防护措施的指定方式是否会无意中造成进一步的问题。因此，使代理更有能力和效率的驱动力——通过更广泛的系统访问、更复杂的行动链和减少人类监督——与安全性考虑相冲突。此外，访问广泛界面 (例如，如上文 [“行动界面”](#人工智能代理的不同维度) 中所讨论的 GUI) 和 [类人](#价值观-类人性) 行为使代理能够执行与具有相同控制级别的人类用户相似的操作，而不会触发任何警告系统——例如操作或删除文件、在社交媒体上冒充用户，或使用存储的信用卡信息购买任何弹出的广告。来自人工智能代理与多个系统交互的能力以及设计上缺乏对它们可能采取的每个行动的人类监督，还会出现更多安全风险。人工智能代理可能共同创造不安全的结果。
+
+### 价值观: 科学进步
+
+目前关于人工智能代理是否真的是人工智能发展的根本性进步，还是我们多年来已有技术的 “重新包装”——深度学习、启发式方法和流水线系统——存在争议。重新引入 “代理” 这个术语作为现代人工智能系统的总称，这些系统共同具有以最少用户输入产生操作的特征，是一种有用的简洁引用最近人工智能应用的方式。然而，这个术语带有自由和主体性的含义，暗示人工智能技术发生了更根本的变化。
+
+本节列出的所有价值观都与科学进步相关; 其中大多数都提供了潜在收益和风险的详细信息。
+
+### 价值观: 安全防护
+
+- 🙂 **潜在收益:** 潜在收益与 [安全性](#价值观-隐私) 类似。
+- 😟 **风险:** 人工智能代理由于经常处理敏感数据 (客户和用户信息) 以及它们的 [安全性](#价值观-安全性) 风险，如与多个系统交互的能力和设计上缺乏对它们可能采取的每个行动的人类监督，因此带来严重的安全挑战。即使在用户善意设定目标的情况下，它们也可能共享机密信息。恶意行为者还可能劫持或操纵代理以未经授权访问连接的系统、窃取敏感信息或进行大规模自动攻击。例如，有权访问电子邮件系统的代理可能被利用来共享机密数据，或集成到家庭自动化的代理可能被破坏以突破物理安全。
+
+### 价值观: 速度
+
+- 对用户的速度而言:
+  - 🙂 **潜在收益:** 人工智能代理可能帮助用户更快地完成更多任务，作为必须完成的任务的额外帮手。
+  - 😟 **风险:** 然而，由于它们的行动中存在问题，也可能造成更多工作 (参见 [效率](#价值观-效率))。
+
+- 对系统的速度而言:
+
+  - 与大多数系统一样，快速获得结果可能以牺牲其他理想属性为代价 (如 [准确性](#价值观-准确性)、质量、低成本等)。如果历史能给我们启示的话，未来较慢的系统可能会提供总体更好的结果。
+
+### 价值观: 可持续性
+
+- 🙂 **潜在收益:** 人工智能代理理论上可能有助于解决与气候变化相关的问题，如预测野火或城市地区洪水的增长，同时分析交通模式，然后实时建议最佳路线和运输方法。未来的自动驾驶人工智能代理可能直接做出这样的路线决策，并可以与其他系统协调获取相关更新。
+- 😟 **风险:** 目前，人工智能代理所基于的机器学习模型带来负面环境影响，如碳排放 ([引用](https://dl.acm.org/doi/pdf/10.1145/3630106.3658542)) 和饮用水的使用 ([引用](https://www.theatlantic.com/technology/archive/2024/03/ai-water-climate-microsoft/677602/))。更大并不总是更好 ([示例](https://huggingface.co/blog/smollm))，高效的硬件和低碳数据中心可以帮助减少这种影响。
+
+### 价值观: 信任
+
+- 🙂 **潜在收益:** 我们尚未发现人工智能代理在信任方面有任何收益。系统应该被构建成值得我们信任的，这意味着它们被证明是 [安全的](#价值观-安全性)、[安全可靠的](#价值观-安全性)、[一致的](#价值观-一致性) 等。
+- 😟 **风险:** 不当信任导致人们被操纵，以及 [效率](#价值观-效率)、[类人性](#价值观-类人性) 和 [真实性](#价值观-真实性) 详述的其他风险。另一个风险源于 LLM 产生虚假信息的倾向 (称为 “幻觉” 或 “虚构”): 大多数情况下正确的系统在错误时更可能被不当信任。
+
+### 价值观: 真实性
+
+- 🙂 **潜在收益:** 我们尚未发现人工智能代理在真实性方面有任何收益。
+- 😟 **风险:** 人工智能代理所基于的深度学习技术是众所周知的虚假信息来源 ([引用](https://www.sciencedirect.com/science/article/abs/pii/S1364661324002213))，这可能以深度伪造或错误信息等形式出现。人工智能代理可能被用来进一步巩固这种虚假信息，例如收集最新信息并在多个平台上发布。这意味着人工智能代理可能被用来提供关于什么是真实和虚假的错误认识，操纵人们的信念，并扩大非自愿亲密内容的影响。人工智能代理传播的虚假信息，针对特定人群个性化，也可能被用来欺骗他们。
+
+## Hugging Face 的人工智能代理
+
+在 Hugging Face，我们已经开始以多种方式引入人们构建和使用人工智能代理的能力，基于上述讨论的价值观。这包括:
+
+- 我们最近发布的 [smolagents](https://huggingface.co/docs/smolagents/index)，提供工具、教程、指导性教程和概念指南;
+- [AI Cookbook](https://huggingface.co/learn/cookbook/index)，包含多种代理的 “配方”:
+
+  - [使用 Transformers Agents 构建具有工具调用超能力的代理🦸](https://huggingface.co/learn/cookbook/agents)
+  - [主动式 RAG: 通过查询重构和自查询为您的 RAG 提速！🚀](https://huggingface.co/learn/cookbook/agent_rag)
+  - [从任何 LLM 推理提供者创建 Transformers Agent](https://huggingface.co/learn/cookbook/agent_change_llm)
+  - [具有自动错误纠正功能的文本到 SQL 代理](https://huggingface.co/learn/cookbook/agent_text_to_sql)
+  - [数据分析师代理: 瞬间获取数据洞察✨](https://huggingface.co/learn/cookbook/agent_data_analyst)
+  - [让多个代理在多代理层次结构中协作🤖🤝🤖](https://huggingface.co/learn/cookbook/multiagent_web_assistant)
+  - [多代理 RAG 系统🤖🤝🤖](https://huggingface.co/spaces/data-agents/jupyter-agent)
+
+- 我们的 [gradio 代理用户界面](https://www.gradio.app/main/guides/agents-and-tool-usage)，为您构建的代理提供前端;
+- 我们的 [gradio 代码编写代理](https://www.gradio.app/playground)，允许您在编码游乐场中实时尝试代码想法。
+- Jupyter Agent，[一个在 Jupyter 笔记本内编写和执行代码的代理](https://huggingface.co/spaces/data-agents/jupyter-agent)。
+
+## 建议与未来展望
+
+当前人工智能 “代理” 的最新技术指向几个明确的方向:
+
+1. 必须设计严格的代理评估协议。自动基准可能受到上述 [人工智能代理不同维度](#人工智能代理的不同维度) 的启发。社会技术评估可能受到 [价值观](#风险-收益和使用-基于价值的分析) 的启发。
+2. 必须更好地理解人工智能代理的影响。应该追踪和分析人工智能代理对个人、组织、经济和环境的影响，以便为它们应该如何进一步发展 (或不发展) 提供信息。这应该包括分析人工智能代理对福祉、社会凝聚力、就业机会、资源获取和对气候变化的贡献的影响。
+3. 必须更好地理解连锁反应。当一个用户部署的代理与其他用户的其他代理互动，并且它们基于彼此的输出执行操作时，目前尚不清楚它们满足用户目标的能力将如何受到影响。
+4. 必须改进透明度和披露。为了实现上述价值观的积极影响，并最小化其负面影响，人们需要清楚地知道何时在与代理交谈以及它有多自主。清晰的人工智能代理互动披露需要的不仅仅是简单的通知——它需要一种结合技术、设计和心理考虑的方法。即使用户明确知道他们正在与人工智能代理互动，他们可能仍然会经历拟人化或产生不当信任。这个挑战需要在多个层面上运作的透明机制: 在整个互动过程中保持清晰的视觉和界面提示，精心设计的对话模式定期强调代理的人工性质，以及在上下文中诚实披露代理的能力和局限性。
+5. 开源可以产生积极的影响。开源运动可以作为对人工智能代理开发集中在少数强大组织手中的一种平衡。与关于开放性价值的更广泛讨论一致，通过民主化对代理架构和评估协议的访问，开放倡议可以使更广泛的参与者参与塑造这些系统如何开发和部署。这种协作方法不仅通过集体改进加速科学进步，还有助于建立社区驱动的 [安全性](#价值观-安全性) 和 [安全性](#价值观-信任) 标准。当代理开发在公开环境中进行时，任何单一实体为了商业利益而在相关和重要的价值观如 [安全性](#价值观-隐私) 和 [真实性](#价值观-真实性) 方面做出妥协就变得更加困难。开放开发固有的透明性也创造了自然的问责制，因为社区可以验证代理行为并确保开发继续与公共利益而不是狭隘的企业目标保持一致。随着代理变得更加复杂且其社会影响增长，这种开放性特别重要。
+6. 开发者可能会创建更具主动性的 “基础模型”。这基于当前趋势和研究模式清晰可见，而不是我们提供的与伦理相关的建议。当前的代理技术利用计算机科学中最近和较早的技术集合——近期未来的研究可能会尝试将代理模型训练为一个整体通用模型，一种增强型多模态模型: 与学习建模文本、图像等一起训练执行操作。
+
+## 致谢
+
+感谢 Bruna Trevelin、Orion Penner 和 Aymeric Roucher 对本文的贡献。
\ No newline at end of file
diff --git a/zh/from-files-to-chunks.md b/zh/from-files-to-chunks.md
new file mode 100644
index 0000000000..8b058db53d
--- /dev/null
+++ b/zh/from-files-to-chunks.md
@@ -0,0 +1,101 @@
+---
+title: "从文件到块：提高 Hugging Face 存储效率"
+thumbnail: /blog/assets/from-files-to-chunks/thumbnail.png
+authors:
+  - user: jsulz
+  - user: erinys
+translators:
+  - user: smartisan
+  - user: zhongdongy
+    proofreader: true
+---
+
+# 从文件到块: 提高 Hugging Face 存储效率
+
+Hugging Face 在 [Git LFS 仓库](https://huggingface.co/docs/hub/en/repositories-getting-started#requirements) 中存储了超过 [30 PB 的模型、数据集和 Spaces](https://huggingface.co/spaces/xet-team/lfs-analysis)。由于 Git 在文件级别进行存储和版本控制，任何文件的修改都需要重新上传整个文件。这在 Hub 上会产生高昂的成本，因为平均每个 Parquet 和 CSV 文件大小在 200-300 MB 之间，Safetensor 文件约 1 GB，而 GGUF 文件甚至可能超过 8 GB。设想一下，仅仅修改 GGUF 文件中的一行元数据，就需要等待数 GB 大小的文件重新上传。除了耗费用户时间和传输成本外，Git LFS 还需要保存文件的两个完整版本，这进一步增加了存储开销。
+
+下图展示了 Hub 上各类仓库 (模型、数据集和 Spaces) 中 LFS 存储容量在 2022 年 3 月至 2024 年 9 月期间的增长趋势:
+
+<p align="center">
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/from-files-to-chunks/lfs-analysis-min.png" alt="LFS Storage Growth" width=90%>
+</p>
+
+Hugging Face 的 Xet 团队正在采用一种创新的存储方案: 将文件分块存储。通过只传输发生变化的数据块，我们可以显著提升存储效率和迭代速度，同时确保用户能可靠地访问不断演进的数据集和模型。下面让我们详细了解其工作原理。
+
+## 基于内容的分块原理
+
+我们采用的分块方法称为基于内容的分块 (Content-Defined Chunking，CDC)。与将文件视为不可分割的整体不同，CDC 根据文件内容本身来确定边界，将文件划分为大小可变的数据块。为了计算这些块的边界，我们使用 [滚动哈希算法](https://en.wikipedia.org/wiki/Rolling_hash) 来扫描文件的字节序列。
+
+让我们通过一个简单的例子来说明:
+
+```bash
+transformerstransformerstransformers
+```
+
+这里我们用文本来演示，但实际上这个过程适用于任何字节序列。
+
+滚动哈希算法通过在数据上滑动固定大小的窗口来计算哈希值。比如，当窗口长度为 4 时，算法会依次计算 `tran` 、 `rans` 、 `ansf` 等字符序列的哈希值，直到处理完整个文件。
+
+当某个位置的哈希值满足预设条件时，就会在该处设置块的边界。例如，可以设置如下条件:
+
+```python
+hash(data) % 2^12 == 0
+```
+
+如果序列 `mers` 的哈希值满足这个条件，那么文件就会被分成三个块:
+
+```bash
+transformers | transformers | transformers
+```
+
+系统会计算这些块的哈希值，建立块哈希值到实际内容的映射，并最终将它们存储在基于内容寻址的存储系统 (Content-Addressed Storage，CAS) 中。由于这三个块完全相同，CAS 只需要存储一个块的实际内容，从而自动实现了数据去重。🪄
+
+## 处理插入和删除操作
+
+当文件内容发生变化时，CDC 的优势就体现出来了: 它能够精确定位变化的部分，高效处理插入和删除操作。让我们看一个具体示例，在原文件中插入 `super` 后:
+
+```bash
+transformerstransformerssupertransformers
+```
+
+使用相同的边界条件重新应用滚动哈希算法，新的分块结果如下:
+
+```bash
+transformers | transformers | supertransformers
+```
+
+前两个块的内容系统中已经存在，无需重新存储。只有 `supertransformers` 是新的数据块，因此保存这个更新版本只需要上传和存储这一个新块即可。
+
+为了验证这种优化方案在实际应用中的效果，我们将 XetHub 上基于 CDC 的存储实现与 Git LFS 进行了对比测试。在三个迭代开发场景中，我们发现存储和传输性能始终提升了 50%。其中一个典型案例是 [CORD-19 数据集](https://ai2-semanticscholar-cord-19.s3-us-west-2.amazonaws.com/historical_releases.html)——这是一个在 2020 年至 2022 年间持续更新的 COVID-19 研究论文集合，共有 50 次增量更新。下表对比了两种存储方案的性能指标:
+
+| 指标 | 基于 Git LFS 的仓库 | 基于 Xet 的仓库 |
+| --------------------- | ------------------------- | --------------------- |
+| 平均下载时间 | 51 分钟 | 19 分钟 |
+| 平均上传时间 | 47 分钟 | 24 分钟 |
+| 存储占用 | 8.9 GB | 3.52 GB |
+
+通过只传输和保存变化的数据块，再结合改进的压缩算法和优化的网络请求，基于 Xet 的 CDC 方案显著缩短了上传和下载时间，同时大幅降低了存储多个版本所需的空间。想深入了解测试细节？请查看我们的 [完整基准测试报告](https://xethub.com/blog/benchmarking-the-modern-development-experience)。
+
+## CDC 技术对 Hub 的影响
+
+那么，CDC 如何应用于 Hugging Face Hub 上的各类文件呢？为了直观展示 CDC 在文件集合上的存储节省潜力，我们开发了一个简单的 [重复数据删除估算工具](https://github.com/huggingface/dedupe_estimator)。我们用这个工具分析了 [openai-community/gpt2](https://huggingface.co/openai-community/gpt2) 仓库中 `model.safetensors` 文件的两个版本，得到了以下结果:
+
+<p align="center">
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/from-files-to-chunks/safetensors_dedupe_image.png" alt="Safetensors Deduplication" width=40%>
+</p>
+
+图中的绿色区域表示两个版本之间内容的重叠部分，这意味着我们可以在单个文件内部以及不同版本之间进行有效的数据去重。
+
+|           | Git LFS 存储占用 | Xet 存储占用 |
+| --------- | ------------------------ | --------------------------- |
+| 版本 1 | 664 MB                   | 509 MB                      |
+| 版本 2 | 548 MB                   | 136 MB                      |
+| 总计     | 1.2 GB                   | 645 MB                      |
+
+在这个案例中，采用基于 Xet 的存储方案不仅大大缩短了第二个版本的上传和下载时间，还将总存储空间减少了 53%。通过进一步的压缩优化，我们预计还能额外节省 10% 的空间。
+
+我们对 Hub 上的仓库进行的初步研究显示，CDC 技术对某些类型的数据特别有效。例如，微调模型通常只修改部分参数，大部分模型权重在不同版本间保持不变，这使它们非常适合使用数据去重技术。同样，模型检查点文件也是理想的应用场景，因为相邻检查点之间的变化往往很小。这两类文件都展现出 30-85% 的去重比率。考虑到 PyTorch 模型检查点在 Hub 上占用了约 200 TB 的存储空间，如果能达到 50% 的去重率，我们可以立即节省 100 TB 的存储空间，并在未来每月减少 7-8 TB 的增长。
+
+除了降低存储成本，块级数据去重还能显著提升数据传输效率，因为只需要传输实际发生变化的数据块。这对于需要频繁处理多个模型版本或数据集版本的团队来说尤其重要，可以大大减少等待时间，提高工作效率。
+
+目前，我们团队正在开发 Hub 的基于 Xet 存储的概念验证系统，计划在 2025 年初推出首批基于 Xet 的仓库。欢迎 [关注我们的团队](https://huggingface.co/xet-team)，了解更多技术进展。我们将持续分享在全球分布式仓库扩展 CDC、优化网络性能、保护数据隐私以及并行化分块算法等方面的研究成果。
\ No newline at end of file
diff --git a/zh/layerskip.md b/zh/layerskip.md
new file mode 100644
index 0000000000..91e7d2ef06
--- /dev/null
+++ b/zh/layerskip.md
@@ -0,0 +1,220 @@
+---
+title: "LayerSkip：使用自推测解码加速大模型推理"
+thumbnail: /blog/assets/layerskip/thumbnail.png
+authors:
+- user: ariG23498
+- user: melhoushi
+  guest: true
+  org: facebook
+- user: pcuenq
+- user: reach-vb
+translators:
+- user: smartisan
+- user: zhongdongy
+  proofreader: true
+---
+
+# LayerSkip: 使用自推测解码加速大模型推理
+
+自推测解码是一种新颖的文本生成方法，它结合了推测解码 (Speculative Decoding) 的优势和大语言模型 (LLM) 的提前退出 (Early Exit) 机制。该方法出自论文 [LayerSkip: Enabling Early-Exit Inference and Self-Speculative Decoding](https://arxiv.org/abs/2404.16710)。它通过使用 _同一个模型_ 的早期层来生成候选词元 (token)，并使用后期层进行验证，从而实现高效生成。
+
+这项技术不仅加快了文本生成速度，还显著节省了内存并降低了计算延迟。为了实现端到端的加速，早期层的输出需要与最终层的输出足够接近。正如论文中所述，这可以通过一种训练方法来实现，该方法可以在预训练期间应用，也可以在特定领域进行微调时应用。自推测解码对于实际应用特别高效，它可以在较小的 GPU 上部署，并降低 **大规模推理** 所需的整体硬件资源。
+
+在本博客中，我们将探讨自推测解码的概念、其实现方式以及在 🤗 transformers 库中的实际应用。您将了解到其技术原理，包括 **提前退出层 (Early-Exit Layers)** 、 **反嵌入 (Unembedding)** 和 **训练修改 (Training Modifications)**。为了将这些概念付诸实践，我们提供了代码示例、与传统推测解码的基准比较，以及对性能权衡的见解。
+
+您还可以直接查看以下 Hugging Face 资源，了解更多关于该方法的信息并亲自尝试:
+
+1. [Hugging Face 论文讨论论坛](https://huggingface.co/papers/2404.16710)
+2. [LayerSkip 模型集合](https://huggingface.co/collections/facebook/layerskip-666b25c50c8ae90e1965727a)
+3. [展示自推测解码深入工作原理的 Colab 笔记本](https://huggingface.co/datasets/ariG23498/layer-skip-assets/blob/main/early_exit_self_speculative_decoding.ipynb)
+
+## 推测解码与自推测解码
+
+![LayerSkip 演示 GIF](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LayerSkip-Demo.gif)
+
+_在 [`facebook/layerskip-llama2-7B`](https://huggingface.co/facebook/layerskip-llama2-7B) 上的 LayerSkip 推理演示 (使用 LayerSkip 方法持续预训练的 Llama2 7B)。_
+
+[传统的推测解码](https://huggingface.co/blog/assisted-generation) 使用 **两个** 模型: 一个较小的模型 (草稿模型) 用于生成一系列候选词元，一个较大的模型 (验证模型) 用于验证草稿的准确性。较小的模型执行大部分生成工作，而较大的模型则负责改进结果。这提高了文本生成速度，因为较大的模型一次性验证完整序列，而不是逐个生成词元。
+
+在自推测解码中，作者在此概念的基础上，使用大模型的早期层来生成草稿词元，然后由模型的更深层进行验证。这种推测解码的“自洽”特性需要特定的训练，使模型能够同时执行草稿生成和验证。这反过来又比传统的推测解码提高了速度并降低了计算成本。
+
+## 在 `transformers` 中的使用
+
+为了在 🤗 transformers 库中启用提前退出自推测解码，我们只需在 `generate()` 函数中添加 `assistant_early_exit` 参数。
+
+以下是一个简单的代码片段，展示了该功能:
+
+```python
+pip install transformers
+
+from transformers import AutoTokenizer, AutoModelForCausalLM
+
+early_exit_layer = 4
+prompt = "Alice and Bob"
+checkpoint = "facebook/layerskip-llama2-7B"
+
+tokenizer = AutoTokenizer.from_pretrained(checkpoint)
+inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
+
+model = AutoModelForCausalLM.from_pretrained(checkpoint).to("cuda")
+outputs = model.generate(**inputs, assistant_early_exit=early_exit_layer)
+```
+
+注意: 虽然 `assistant_early_exit` 参数可以为任何仅解码器的 transformer 启用提前退出自推测解码，但除非模型经过专门训练，否则无法反嵌入 (通过 LM 头进行解码的过程，在博客文章后面有描述) 中间层的 logits。只有对检查点进行这样的训练，以提高早期层的准确性，您才能获得加速。LayerSkip 论文提出了一种训练方法来实现这一点 (即应用提前退出损失，并逐步增加层丢弃率)。[这里](https://huggingface.co/collections/facebook/layerskip-666b25c50c8ae90e1965727a) 提供了使用 LayerSkip 训练方法持续预训练的 Llama2、Llama3 和 Code Llama 检查点的集合。
+
+## 基准测试
+
+我们进行了一系列广泛的基准测试，以衡量 LayerSkip 的自推测解码相对于自回归解码在各种模型上的加速情况。我们还将自推测解码 (基于提前退出) 与标准推测解码技术进行了比较。要复现这些结果，您可以在 [这里](https://github.com/aritra24rg/LayerSkip-Benchmarking) 找到代码，并在 [此电子表格](https://docs.google.com/spreadsheets/d/15poLaR_7tG_5xZo-LzLMFd4dzz-dHl_h/edit#gid=1155443081) 中找到运行每个实验的命令。所有实验均在单个 80GB A100 GPU 上运行，除了 Llama2 70B 实验在 8 个 A100 GPU 的节点上运行。
+
+#### Llama3.2 1B
+
+| Model Variant (模型变体)       | Layers (层数) | Assistant Model (辅助模型) | Assistant Layers (辅助层数) | Task (任务)   | Total Layers (总层数) | FLOPs/Input (G) (输入 FLOPs) | Time/Input (s) (输入时间) | FLOPs/Output (G) (输出 FLOPs) | Time/Output (s) (输出时间) | Efficiency (效率) |
+| :----------------------------- | :------------ | :------------------------- | :-------------------------- | :------------ | :-------------------- | :--------------------------- | :------------------------ | :---------------------------- | :------------------------- | :---------------- |
+| facebook/layerskip-llama3.2-1B | 1             | Early Exit @ Layer 4       |                             | summarization | 1                     | 1195.28                      | 9.96                      | 2147.7                        | 17.9                       | 1.80              |
+
+#### Llama3 8B
+
+| Model Variant (模型变体)     | Layers (层数) | Assistant Model (辅助模型) | Assistant Layers (辅助层数) | Task (任务)   | Total Layers (总层数) | FLOPs/Input (G) (输入 FLOPs) | Time/Input (s) (输入时间) | FLOPs/Output (G) (输出 FLOPs) | Time/Output (s) (输出时间) | Efficiency (效率) |
+| :--------------------------- | :------------ | :------------------------- | :-------------------------- | :------------ | :-------------------- | :--------------------------- | :------------------------ | :---------------------------- | :------------------------- | :---------------- |
+| meta-llama/Meta-Llama-3-8B   | 8             | meta-llama/Llama-3.2-1B    | 1                           | summarization | 9                     | 1872.46                      | 19.04                     | 2859.35                       | 29.08                      | 1.53              |
+| meta-llama/Meta-Llama-3-8B   | 8             | meta-llama/Llama-3.2-3B    | 3                           | summarization | 11                    | 2814.82                      | 28.63                     | 2825.36                       | 28.73                      | 1.00              |
+| facebook/layerskip-llama3-8B | 8             | Early Exit @ Layer 4       |                             | summarization | 8                     | 1949.02                      | 15.75                     | 3571.81                       | 28.87                      | 1.83              |
+
+#### Llama2 70B
+
+| Model Variant (模型变体)          | Layers (层数) | Assistant Model (辅助模型) | Assistant Layers (辅助层数) | Task (任务)   | Total Layers (总层数) | FLOPs/Input (G) (输入 FLOPs) | Time/Input (s) (输入时间) | FLOPs/Output (G) (输出 FLOPs) | Time/Output (s) (输出时间) | Efficiency (效率) |
+| :-------------------------------- | :------------ | :------------------------- | :-------------------------- | :------------ | :-------------------- | :--------------------------- | :------------------------ | :---------------------------- | :------------------------- | :---------------- |
+| meta-llama/Llama-2-70b-hf         | 70            | meta-llama/Llama-2-13b-hf  | 13                          | summarization | 83                    | 5036.54                      | 46.3                      | 12289.01                      | 112.97                     | 2.44              |
+| meta-llama/Llama-2-70b-hf         | 70            | meta-llama/Llama-2-7b-hf   | 7                           | summarization | 77                    | 4357.55                      | 40.06                     | 12324.19                      | 113.3                      | 2.83              |
+| meta-llama/Llama-2-70b-hf         | 70            | TinyLlama/TinyLlama_v1.1   | 1                           | summarization | 71                    | 4356.21                      | 40.05                     | 12363.22                      | 113.66                     | 2.84              |
+| **facebook/layerskip-llama2-70B** | 70            | Early Exit @ Layer 10      |                             | summarization | 70                    | 6012.04                      | 54.96                     | 1283.34                       | 113.2                      | 2.06              |
+
+#### Llama2 13B
+
+| Model Variant (模型变体)          | Layers (层数) | Assistant Model (辅助模型) | Assistant Layers (辅助层数) | Task (任务)       | Total Layers (总层数) | FLOPs/Input (G) (输入 FLOPs) | Time/Input (s) (输入时间) | FLOPs/Output (G) (输出 FLOPs) | Time/Output (s) (输出时间) | Efficiency (效率) |
+| :-------------------------------- | :------------ | :------------------------- | :-------------------------- | :---------------- | :-------------------- | :--------------------------- | :------------------------ | :---------------------------- | :------------------------- | :---------------- |
+| meta-llama/Llama-2-13b-hf         | 13            | meta-llama/Llama-2-7b-hf   | 7                           | summarization     | 20                    | 3557.07                      | 27.79                     | 4088.48                       | 31.94                      | 1.15              |
+| meta-llama/Llama-2-13b-hf         | 13            | TinyLlama/TinyLlama_v1.1   | 1                           | summarization     | 14                    | 2901.92                      | 22.67                     | 4190.42                       | 32.74                      | 1.44              |
+| meta-llama/Llama-2-13b-hf         | 13            | apple/OpenELM-270M         | 0.27                        | summarization     | 13.27                 | 2883.33                      | 22.53                     | 4521.12                       | 35.32                      | 1.57              |
+| meta-llama/Llama-2-13b-hf         | 13            | apple/OpenELM-450M         | 0.45                        | summarization     | 13.45                 | 3267.69                      | 25.53                     | 4321.75                       | 33.76                      | 1.32              |
+| **facebook/layerskip-llama2-13B** | **13**        | **Early Exit @ Layer 4**   |                             | **summarization** | **13**                | **4238.45**                  | **33.11**                 | **4217.78**                   | **32.95**                  | **0.995**         |
+| **facebook/layerskip-llama2-13B** | 13            | Early Exit @ Layer 8       |                             | summarization     | 13                    | 2459.61                      | 19.22                     | 4294.98                       | 33.55                      | 1.746             |
+
+#### Llama2 7B
+
+| Model Variant (模型变体)         | Layers (层数) | Assistant Model (辅助模型) | Assistant Layers (辅助层数) | Task (任务)   | Total Layers (总层数) | FLOPs/Input (G) (输入 FLOPs) | Time/Input (s) (输入时间) | FLOPs/Output (G) (输出 FLOPs) | Time/Output (s) (输出时间) | Efficiency (效率) |
+| :------------------------------- | :------------ | :------------------------- | :-------------------------- | :------------ | :-------------------- | :--------------------------- | :------------------------ | :---------------------------- | :------------------------- | :---------------- |
+| meta-llama/Llama-2-7b-hf         | 7             | TinyLlama/TinyLlama_v1.1   | 1                           | summarization | 8                     | 2771.54                      | 21.65                     | 3368.48                       | 26.32                      | 1.22              |
+| meta-llama/Llama-2-7b-hf         | 7             | apple/OpenELM-270M         | 0.27                        | summarization | 7.27                  | 2607.82                      | 20.37                     | 4221.14                       | 32.98                      | 1.62              |
+| meta-llama/Llama-2-7b-hf         | 7             | apple/OpenELM-450M         | 0.45                        | summarization | 7.45                  | 3324.68                      | 25.97                     | 4178.66                       | 32.65                      | 1.26              |
+| **facebook/layerskip-llama2-7B** | 7             | Early Exit @ Layer 4       |                             | summarization | 7                     | 2548.4                       | 19.91                     | 3306.73                       | 25.83                      | 1.297             |
+
+我们可以观察到以下几点:
+
+- 从“ **总参数数量**”列可以看出，自推测解码消耗的内存更少，因为它不需要单独的草稿模型，并且草稿阶段层的权重被重用。
+- 对于除 Llama2 70B 之外的所有模型大小和生成，提前退出自推测解码比常规的两模型推测解码更快。
+- 与其它模型相比，Llama2 70B 的自推测解码速度提升相对有限，可能有不同的原因，例如，Llama2 70B 的 LayerSkip 检查点持续预训练的 token 较少 (Llama2 70B 为 328M token，而 Llama2 7B 为 52B token)。但这是未来研究需要改进的一个方面。尽管如此，70B 的自推测解码明显快于自回归解码。
+
+## **自生成和自验证**
+
+自推测解码过程从自生成开始，其中词元是通过从某个中间层提前退出来生成的。推测词元的数量定义了在此阶段生成多少草稿词元，而我们退出的层定义了草稿阶段的规模和准确性。这两个参数都可以在推理时根据草稿阶段的速度和准确性之间的权衡来指定。
+
+下一步是自验证，其中使用完整模型来验证草稿词元。验证模型重用草稿模型中的缓存部分。如果草稿词元与验证的词元一致，则将它们添加到最终输出中，从而更好地利用我们系统中的内存带宽，因为使用完整模型生成一系列词元比验证草稿要昂贵得多，只要有几个词元匹配即可。
+
+在自验证阶段，只有剩余的层才会被计算以进行验证，因为早期层的结果在草稿阶段已被缓存。
+
+## **提前退出和反嵌入**
+
+自推测解码中的一项关键技术是提前退出，即生成过程可以在预先指定的层停止。为了实现这一点，我们通过将这些层的 logits 投影到语言模型 (LM) 头上来反嵌入它们，以预测下一个词元。这允许模型跳过后续层并提高推理时间。
+
+可以在任何 transformer 层执行反嵌入，将提前退出转变为一种高效的词元预测机制。一个自然而然的问题出现了: 当 LM 头最初被训练为仅与最终层一起工作时，如何使其适应反嵌入较早层的 logits？这就是训练修改发挥作用的地方。
+
+## **训练修改**
+
+在训练阶段，我们引入了层丢弃，它允许模型在训练期间跳过某些层。丢弃率在较深的层中逐渐增加，使模型不太依赖其后面的层，并增强模型的泛化能力并加快训练速度。
+
+除了层丢弃之外，还应用了提前退出损失，以确保 LM 头学习反嵌入不同的层。使用每个出口 (中间层) 的归一化损失的总和来给出使用提前出口训练模型的总损失函数。这种技术通过在所有层之间分配学习任务来实现高效训练。
+
+## 优化: 共享权重、共享 KV 缓存和共享计算
+
+自推测解码显著受益于缓存重用，特别是 KV 缓存，它存储在草稿阶段计算的键值对。此缓存允许模型跳过冗余计算，因为草稿和验证阶段都使用相同的早期层。此外，退出查询缓存存储来自退出层的查询向量，允许验证从草稿阶段无缝继续。
+
+与传统的双模型推测解码相比，提前退出自推测解码可以从以下节省中受益:
+
+- **共享权重**: 为草稿和验证重用前 E 层 的权重。
+- **共享 KV 缓存**:  为草稿和验证重用前 E 层的键值对
+- **共享计算**:  通过使用仅保存退出层 E-1 的查询向量的退出查询缓存来重用前 E 层的计算，以便验证过程无需计算层 0 到 E-1。
+
+KV 和退出查询缓存的组合称为 KVQ 缓存，可减少内存开销并提高推理延迟。
+
+到目前为止，🤗 transformers 库已在此 [pull request](https://github.com/huggingface/transformers/pull/30890) 中实现了第一个优化 (共享权重)。随着使用此方法的模型数量增加，我们将考虑其他优化。如果您有兴趣，请随时提出 PR！
+
+## 提前退出层的选择策略
+
+草稿阶段的提前退出层是一个超参数，我们可以在推理期间调整或修改:
+
+- 我们越早退出，生成草稿词元的速度就越快，但它们的准确性就越低。
+- 我们越晚退出，生成的草稿词元就越准确，但它们的速度就越慢。
+
+我们编写了一个脚本来遍历不同的提前退出层并测量 A100 GPU 上的每秒词元数。在下面的表格中，我们绘制了针对不同 Llama 模型的 LayerSkip 和基线检查点的每秒词元数与提前退出层的关系图 (您可以在 [此处](https://docs.google.com/spreadsheets/d/15poLaR_7tG_5xZo-LzLMFd4dzz-dHl_h/edit#gid=1155443081) 查看完整日志)。
+
+#### Llama3.2 1B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![llama 3.2 1b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/Llama-3.2-1B.png) | ![layer skip llama 3.2 1b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-Llama3.2-1B.png) |
+
+#### Llama3 8B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![llama 3 8b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/Llama-3-8B.png) | ![layer skip llama 3 8b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-Llama3-8B.png) |
+
+#### Code Llama3 34B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![code llama 3 34b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/CodeLlama-34B.png) | ![code layer skip llama 3 34b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-CodeLlama-34B.png) |
+
+#### Code Llama3 7B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![code llama 3 7b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/CodeLlama-7B.png) | ![code layer skip llama 3 7b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-CodeLlama-7B.png) |
+
+#### Llama2 70B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![llama 2 70b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/Llama-2-70B.png) | ![layer skip llama 2 70b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-Llama2-70B.png) |
+
+#### Llama2 13B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![llama 2 13b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/Llama-2-13B.png) | ![layer skip llama 2 13b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-Llama2-13B.png) |
+
+#### Llama2 7B
+
+|                      Normal (常规模型)                       |                  LayerSkip (LayerSkip 模型)                  |
+| :----------------------------------------------------------: | :----------------------------------------------------------: |
+| ![llama 2 7b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/Llama-2-7B.png) | ![layer skip llama 2 7b](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/layerskip-assets/LS-Llama2-7B.png) |
+
+我们可以观察到以下几点:
+
+- 对于没有使用 LayerSkip 训练方法进行预训练或持续预训练的基线检查点，提前退出自推测解码比自回归解码更慢。这是因为在大多数 LLM 的训练过程中，早期层并没有被激励去学习预测输出，因此使用早期层生成词元的接受率会非常低。
+- 另一方面，对于使用 LayerSkip 训练方法持续预训练的 Llama 检查点，提前退出自推测解码在至少一部分层中比自回归解码具有更高的加速比。
+  - 对于大多数模型 (除了 Llama3.2 1B)，当我们遍历各层时，我们注意到一个规律模式: 加速比在前几层较低，逐渐增加到一个最佳点，然后再次下降。
+  - 提前退出层的最佳点是在预测的高准确性和生成词元的低开销之间达到最佳权衡时。这个最佳点取决于每个模型，也可能取决于提示或提示的领域。
+
+这些观察为进一步的实验和探索提供了有趣的机会。我们鼓励读者在这些想法的基础上进行构建，测试变体，并进行自己的研究。这些努力可以带来有价值的见解，并为该领域做出有意义的贡献。
+
+## 结论
+
+LayerSkip 利用提前退出、层丢弃和缓存重用之间的协同作用，创建了一个快速高效的文本生成流程。通过训练模型从不同层反嵌入输出，并使用缓存优化验证过程，这种方法在速度和准确性之间取得了平衡。因此，它显著改善了大语言模型的推理时间，同时保持了高质量的输出。由于使用单个模型作为草稿和验证模型，它还比传统的推测解码技术减少了内存使用。
+
+自推测是一个令人兴奋的领域，同一个 LLM 可以创建草稿词元并自我修正。其他自推测方法包括:
+
+- [Draft & Verify](https://aclanthology.org/2024.acl-long.607/): 其中草稿阶段涉及跳过预定的注意力和前馈层。
+- [MagicDec](https://arxiv.org/abs/2408.11049): 其中草稿阶段使用 KV 缓存的子集，这对长上下文输入很有用。
+- [Jacobi Decoding](https://arxiv.org/abs/2305.10427) 和 [Lookahead Decoding](https://arxiv.org/abs/2402.02057): 其中草稿阶段是一系列“猜测词元”，可以是随机的或从 n-gram 查找表中获得的。
\ No newline at end of file
diff --git a/zh/s2s_endpoint.md b/zh/s2s_endpoint.md
new file mode 100644
index 0000000000..6b912c066b
--- /dev/null
+++ b/zh/s2s_endpoint.md
@@ -0,0 +1,283 @@
+---
+title: "在 Hugging Face 上部署语音转语音模型"
+thumbnail: /blog/assets/s2s_endpoint/thumbnail.png
+authors:
+- user: andito
+- user: derek-thomas
+- user: dmaniloff
+- user: eustlb
+translators:
+- user: smartisan
+- user: zhongdongy
+  proofreader: true
+---
+
+# 在 Hugging Face 上部署语音转语音模型
+
+## 介绍
+
+[S2S (语音到语音)](https://github.com/huggingface/speech-to-speech) 是 Hugging Face 社区内存在的一个令人兴奋的新项目，它结合了多种先进的模型，创造出几乎天衣无缝的体验: 你输入语音，系统会用合成的声音进行回复。
+
+该项目利用 Hugging Face 社区中的 Transformers 库提供的模型实现了流水话处理。该流程处理由以下组件组成:
+
+1. 声音活动检测 (VAD)
+2. 语音识别 (STT)
+3. 语言模型 (LLM)
+4. 文本转语音 (TTS)
+
+除此之外，S2S 项目支持多语言！目前支持英语、法语、西班牙语、中文、日语和韩语。您可以使用单语言模式运行此流程或通过 `auto` 标志进行语言自动检测。请查看 [这里](https://github.com/huggingface/speech-to-speech) 的仓库获取更多详情。
+
+```
+> 👩🏽‍这些都是很棒的功能，但我该如何运行 S2S 呢？
+> 🤗: 很好的问题！
+```
+
+运行语音转语音项目需要大量的计算资源。即使在高端笔记本电脑上，你也可能会遇到延迟问题，特别是在使用最先进的模型时。虽然强大的 GPU 可以缓解这些问题，但并不是每个人都有条件 (或意愿) 去搭建他们的硬件设备。
+
+这正是 Hugging Face 的 [推理端点 (IE)](https://huggingface.co/inference-endpoints) 发挥作用的地方。推理端点允许您租用带有 GPU (或其他可能需要的硬件) 的虚拟机，并仅需按系统运行时间付费，为部署如语音转语音这类大型应用提供了理想的解决方案。
+
+在本文中，我们将逐步指导您将 Speech-to-Speech 部署到 Hugging Face 推理端点上。以下是主要内容:
+
+- 理解推理端点，并快速了解设置 IE 的不同方式，包括自定义容器镜像 (这正是我们需要用于 S2S 的)
+- 构建适用于 S2S 的自定义 Docker 镜像
+- 将自定义镜像部署到 IE 并尽情体验 S2S！
+
+## 推理断点
+
+推理端点提供了一种可扩展且高效的方式部署机器学习模型。这些端点允许您在最少设置的情况下利用各种强大的硬件用模型提供服务。推理端点非常适合需要高性能和高可靠性的应用程序部署，而无需管理底层基础设施。
+
+以下是几个关键功能，请查阅文档获取更多信息:
+
+- **简洁性** - 由于 IE 直接支持 Hugging Face 库中的模型，您可以在几分钟内快速上手。
+- **可扩展性** - 您无需担心规模问题，因为 IE 可以自动扩展 (包括缩小规模到零)，以应对不同的负载并节省成本。
+- **自定义** - 您可以根据需要自定义 IE 的设置来处理新任务。更多详情请参见下方内容。
+
+推理端点支持所有 Transformers 和 Sentence-Transformers 任务，也可以支持自定义任务。这些是 IE 设置选项:
+
+1. **预构建模型**: 直接从 Hugging Face 枢纽快速部署模型。
+2. **自定义处理器**: 为更复杂的流程任务自定义推理逻辑。
+3. **自定义 Docker 映像**: 使用您自己的 Docker 映像封装所有依赖项和自定义代码。
+
+对于简单的模型，选项 1 和 2 是理想的选择，并且可以使用推理端点部署变得极其简单。然而，对于像 S2S 这样的复杂流程任务来说，您将需要选项 3 提供的灵活性: 通过自定义 Docker 镜像部署我们的 IE。
+
+这种方法不仅提供了更多的灵活性，还通过优化构建过程并收集必要的数据提高了性能。如果您正在处理复杂的模型流程任务或希望优化应用程序的部署，请参考本指南以获得有价值的见解。
+
+## 在推理端点上部署语音转语音模型
+
+让我们开始吧！
+
+### 构建自定义 Docker 镜像
+
+为了开始创建一个自定义的 Docker 镜像，我们首先克隆了 Hugging Face 的标准 Docker 镜像仓库。这为在推理任务中部署机器学习模型提供了一个很好的起点。
+
+```bash
+git clone https://github.com/huggingface/huggingface-inference-toolkit
+```
+
+### 为什么克隆默认镜像仓库？
+
+- **坚实的基础**: 仓库提供了专门为推理工作负载优化的基础镜像，这为可靠地开始推理任务提供了一个牢固的基础。
+- **兼容性**: 由于该镜像是按照与 Hugging Face 部署环境对齐的方式构建的，因此在部署您自己的自定义镜像时可以确保无缝集成。
+- **易于定制化**: 仓库提供了干净且结构化的环境，使得为应用程序的具体要求定制镜像变得容易。
+
+您可以查看所有更改内容 [在这里](https://github.com/andimarafioti/speech-to-speech-inference-toolkit/pull/1/files)
+
+### 为语音识别应用自定义 Docker 镜像
+
+克隆了仓库后，下一步是根据我们的语音识别流程需求来调整镜像。
+
+1. 添加语音到语音项目
+
+为了无缝集成该项目，我们添加了语音转语音识别的代码库以及所需的任何数据集作为子模块。这种方法提供了更好的版本控制能力，在构建 Docker 镜像时可以确保始终使用正确的代码和数据版本。
+
+通过将数据直接包含在 Docker 容器中，我们避免了每次实例化端点时都需要下载数据，这显著减少了启动时间并确保系统可重复。这些数据被存储在一个 Hugging Face 仓库中，提供了易于跟踪和版本控制的功能。
+
+```bash
+git submodule add https://github.com/huggingface/speech-to-speech.git
+git submodule add https://huggingface.co/andito/fast-unidic
+```
+
+1. 优化 Docker 镜像
+
+接下来，我们修改了 Dockerfile 文件来满足我们的需求:
+
+- **精简镜像**: 移除了与用例无关的软件包和依赖项。这减少了镜像大小，并在推理过程中降低了不必要的消耗。
+- **安装依赖项**: 我们将`requirements.txt` 的安装从入口点移动到了 Dockerfile 本身。这样，当构建 Docker 镜像时会安装这些依赖项，从而加快部署速度，因为运行时将不需要再次安装这些包。
+1. 部署自定义镜像
+
+完成修改后，我们构建并推送了自定义镜像到 Docker Hub:
+
+```bash
+DOCKER_DEFAULT_PLATFORM="linux/amd64" docker build -t speech-to-speech -f dockerfiles/pytorch/Dockerfile .
+docker tag speech-to-speech andito/speech-to-speech:latest
+docker push andito/speech-to-speech:latest
+```
+
+Docker 镜像构建并推送后，就可以在 Hugging Face 推理端点中使用了。通过使用这个预构建的镜像，端点可以更快地启动并且运行得更高效，因为所有依赖项和数据都已预先打包在镜像中。
+
+## 设置推理端点
+
+使用自定义 Docker 镜像只需稍微不同的配置，您可以点击并查看 [文档](https://huggingface.co/docs/inference-endpoints/en/guides/custom_container)。我们将通过图形界面和 API 调用两种方式来介绍如何做到这一点。
+
+前置步骤
+
+1. 登录: [https://huggingface.co/login](https://huggingface.co/login)
+2. 请求访问 [meta-llama/Meta-Llama-3.1-8B-Instruct](https://huggingface.co/meta-llama/Meta-Llama-3.1-8B-Instruct)
+3. 创建细粒度令牌: [https://huggingface.co/settings/tokens/new?tokenType=fineGrained](https://huggingface.co/settings/tokens/new?tokenType=fineGrained)
+
+​	
+
+![Fine-Grained Token](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/fine-grained-token.png)
+
+- 选择访问受限制的仓库权限
+- 如果您正在使用 API，请确保选择管理推理端点的权限
+
+### 推断端点 GUI
+
+1. 访问 https://ui.endpoints.huggingface.co/new
+2. 填写相关信息:
+  - 模型仓库 - `andito/s2s`
+  - 模型名称 - 如果不喜欢生成的名称，可以自由重命名
+    - 例如: `speech-to-speech-demo`
+    - 保持小写字母且简短
+  - 选择您偏好的云和硬件配置 - 我们使用了 `AWS GPU L4`
+    - 只需每小时 $0.80，足够用来处理模型
+  - 高级配置 (点击展开箭头 ➤)
+    - 容器类型 - `Custom`
+    - 容器端口 - `80`
+    - 容器 URL - `andito/speech-to-speech:latest`
+    - 密钥 – `HF_TOKEN` |`<您的令牌在这里>`
+
+<details>
+  <summary> 点击展示图片步骤 </summary>
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/new-inference-endpoint.png" alt="New Inference Endpoint" width="500px">
+  </p>
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/advanced-configuration.png" alt="Advanced Configuration" width="500px">
+  </p>
+</details>
+
+1. 点击 `创建终端节点`
+
+> [!NOTE] 实际上模型仓库并不重要，因为模型会在容器创建时指定和下载。但是推理终端节点需要一个模型，所以你可以选择你喜欢的一个较轻量级的。
+
+> [!NOTE] 你需要指定 `HF_TOKEN` 因为我们需要在容器创建阶段下载受限制访问的模型。如果你使用的是未受限或私有的模型，则不需要这样做。
+
+> [!WARNING] 当前 `[huggingface-inference-toolkit 入口点](https://github.com/huggingface/huggingface-inference-toolkit/blob/028b8250427f2ab8458ed12c0d8edb50ff914a08/scripts/entrypoint.sh#L4)` 默认使用的是端口 5000，但推理终端节点期望的端口号是 80。你应该在 **容器端口** 中匹配这一点。我们已经在 Dockerfile 中设置了这个值，但如果从零开始构建，请务必注意！
+
+### 推理端点 API
+
+在这里，我们将逐步介绍创建带有 API 的端点步骤。只需在您选择的 Python 环境中使用以下代码。
+
+确保使用版本 `0.25.1` 或更高版本
+
+```bash
+pip install huggingface_hub>=0.25.1
+```
+
+使用一个可以写入端点 (Write 或  细粒度权限) 的 [Hugging Face 令牌](https://huggingface.co/docs/hub/en/security-tokens)
+
+```python
+from huggingface_hub import login
+login()
+```
+
+```python
+from huggingface_hub import create_inference_endpoint, get_token
+endpoint = create_inference_endpoint(
+    # Model Configuration
+    "speech-to-speech-demo",
+    repository="andito/s2s",
+    framework="custom",
+    task="custom",
+    # Security
+    type="protected",
+    # Hardware
+    vendor="aws",
+    accelerator="gpu",
+    region="us-east-1",
+    instance_size="x1",
+    instance_type="nvidia-l4",
+    # Image Configuration
+    custom_image={
+        "health_route": "/health",
+        "url": "andito/speech-to-speech:latest", # Pulls from DockerHub
+        "port": 80
+    },
+    secrets={'HF_TOKEN': get_token()}
+)
+
+# Optional
+endpoint.wait()
+```
+
+## 预览
+
+![Overview](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/overview.png)
+
+主要组件
+
+- [语音转语音](https://github.com/huggingface/speech-to-speech/tree/inference-endpoint)
+  - 这是一个 Hugging Face 库，我们在 `inference-endpoint` 分支中加入了一些特定于推理端点的文件，该分支很快将合并到主分支。
+- andito/s2s 或其他任何仓库。这对我们来说不是必需的，因为我们已经在容器创建阶段包含了模型，但推理端点需要一个模型，所以我们传递了一个瘦身后的仓库。
+- [andimarafioti/语音转语音工具包](https://github.com/andimarafioti/speech-to-speech-inference-toolkit)
+  - 这是 [huggingface/huggingface-inference-toolkit](https://github.com/huggingface/huggingface-inference-toolkit) 的分支，帮助我们构建符合我们需求的自定义容器。
+
+### 构建 web 服务器
+
+为了使用端点，我们需要构建一个小的 WebService 服务。这部分代码位于 [speech_to_speech 库](https://github.com/huggingface/speech-to-speech) 中的 `s2s_handler.py` 以及我们用于客户端的 [speech_to_speech_inference_toolkit 工具包](https://github.com/huggingface/speech-to-speech-inference-toolkit) 中的 `webservice_starlette.py` ，后者被用来构建 Docker 镜像。通常情况下，你只需要为端点编写一个自定义处理程序即可，但由于我们希望实现极低的延迟，因此还特别构建了支持 WebSocket 连接的 WebService 而不是普通的请求方式。乍一听起来可能有些令人望而生畏，但这个 WebService 服务代码只有 32 行！
+  
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/webservice.png" alt="Webservice code" width="800px">
+  </p>
+
+这段代码将在启动时运行 `prepare_handler` ，这将初始化所有模型并预热它们。然后，每个消息将会由 `inference_handler.process_streaming_data` 处理。
+
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/process_streaming.png" alt="Process streaming code" width="800px">
+  </p>
+
+这种方法简单地从客户端接收音频数据，将其分割成小块供 VAD 处理，并提交到队列进行处理。然后检查输出处理队列 (模型的语音响应！)，如果有内容则返回。所有的内部处理均由 [Hugging Face 的 speech_to_speech 库](https://github.com/huggingface/speech-to-speech) 负责。
+
+### 自定义处理程序和客户端
+
+WebService 接收并返回音频，但仍然缺少一个重要的部分: 我们如何录制和回放音频？为此，我们创建了一个 [客户端](https://github.com/huggingface/speech-to-speech/blob/inference-endpoint/audio_streaming_client.py)，用于连接到服务。最简单的方法是将分析分为与 WebService 的连接以及录音/播放音频两部分。
+
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/client.png" alt="Audio client code" width="800px">
+  </p>
+
+初始化 WebService 客户端需要为所有消息设置一个包含我们 Hugging Face Token 的头部。在初始化客户端时，我们需要设定对常见消息的操作 (打开、关闭、错误、信息)。这将决定当服务器向我们的客户端发送消息时，客户端会执行什么操作。
+
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/messages.png" alt="Audio client messages code" width="800px">
+  </p>
+
+我们可以看到，对接收到的消息的反应非常直接，只有 `on_message` 方法较为复杂。该方法能够理解服务器完成响应后开始“监听”用户的回复。否则，它会将从服务器接收到的数据放入播放队列中。
+
+  <p>
+    <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/s2s_endpoint/client-audio.png" alt="Client's audio record and playback" width="800px">
+  </p>
+
+客户的音频部分有 4 个任务:
+
+1. 录制音频
+2. 提交音频录制文件
+3. 接收服务器的音频响应
+4. 播放音频响应
+
+录音是在 `audio_input_callback` 方法中完成的，它只是将所有片段提交到一个队列。然后使用 `send_audio` 方法将其发送给服务器。在此过程中，如果没有要发送的音频，则仍然提交空数组以从服务器接收响应。我们之前在博客中看到的 `on_message` 方法处理来自服务器的响应。随后，音频响应的播放由 `audio_output_callback` 方法处理。在这里，我们需要确保音频处于我们预期的范围内 (不希望因为错误的数据包而损上某人的耳膜！)，并确保输出数组的大小符合播放库的要求。
+
+## 结论
+
+在本文中，我们介绍了如何使用自定义 Docker 镜像，在 Hugging Face 推断端点上部署语音到语音 (S2S) 流程的步骤。我们构建了一个定制容器来处理 S2S 流程的复杂性，并展示了如何对其进行配置以实现可扩展且高效的部署。Hugging Face 推断端点使得将如语音到语音这类性能密集型应用程序变为现实变得更加容易，无需担心硬件或基础设施管理的问题。
+
+如果您想尝试一下或者有任何问题，请探索以下资源:
+
+- [Speech-to-Speech GitHub 仓库](https://github.com/huggingface/speech-to-speech)
+- [Speech-to-Speech 推断工具包](https://github.com/andimarafioti/speech-to-speech-inference-toolkit)
+- [基础推断工具包](https://github.com/huggingface/huggingface-inference-toolkit)
+- [Hugging Face 推断端点文档](https://huggingface.co/docs/inference-endpoints/en/guides/custom_container)
+
+遇到问题或有任何疑问？请在相关 GitHub 仓库中开启讨论，我们将非常乐意帮助您！
\ No newline at end of file
diff --git a/zh/sql-console.md b/zh/sql-console.md
index 81a0e6b42f..0f27026904 100644
--- a/zh/sql-console.md
+++ b/zh/sql-console.md
@@ -1,5 +1,6 @@
 ---
 title: "为数据集而生的 SQL 控制台"
+
 thumbnail: /blog/assets/sql_console/thumbnail.png
 authors:
 - user: cfahlgren1
@@ -21,6 +22,7 @@ _每个月在 Hugging Face Hub 创建的数据集_
 
 在每个公共数据集中，您应该会看到一个新的 SQL 控制台标签。只需单击即可打开 SQL 控制台以查询该数据集。
 
+
 <figure class="image flex flex-col items-center text-center m-0 w-full">
    <video
       alt="SQL Console Demo"
@@ -28,6 +30,7 @@ _每个月在 Hugging Face Hub 创建的数据集_
     >
     <source src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/sql_console/Magpie-Ultra-Demo-SQL-Console.mp4" type="video/mp4">
   </video>
+
   <figcaption class="text-center text-sm italic">查询 Magpie-Ultra 数据集来获取优秀的高质量推理指令。</figcaption>
 </figure>
 
@@ -44,6 +47,7 @@ _每个月在 Hugging Face Hub 创建的数据集_
 
 大多数在 Hugging Face 上的数据集都存储为 Parquet 格式，这是一种优化了性能和存储效率的列式数据格式。Hugging Face 的  数据集视图 和 SQL 控制台会直接从数据集的 Parquet 文件中加载数据。如果数据集是以其他格式存储的，则前 5GB 自动转换为 Parquet 格式。您可以在 [Dataset Viewer Parquet API 文档](https://huggingface.co/docs/dataset-viewer/en/parquet) 中找到更多关于 Parquet 转换过程的信息。
 
+
 使用这些 Parquet 文件，SQL 控制台会为您创建视图，基于数据集的划分和配置供您进行查询。
 
 ### DuckDB WASM 🦆引擎
@@ -86,6 +90,7 @@ _每个月在 Hugging Face Hub 创建的数据集_
 
 ```sql
 -- Convert Alpaca format to Conversation format
+
 WITH
 source_view AS (
   SELECT * FROM train -- Change 'train' to your desired view name here
@@ -106,7 +111,9 @@ SELECT
     )
   ] AS conversation
 FROM source_view
+
 WHERE instruction IS NOT NULL
+
 AND output IS NOT NULL;
 ```
 
diff --git a/zh/trufflesecurity-partnership.md b/zh/trufflesecurity-partnership.md
index c208775b54..8b17d36385 100644
--- a/zh/trufflesecurity-partnership.md
+++ b/zh/trufflesecurity-partnership.md
@@ -1,5 +1,7 @@
 ---
+
 title: "Hugging Face 与 TruffleHog 成为合作伙伴，实现风险信息预警"
+
 thumbnail: /blog/assets/trufflesecurity-partnership/thumbnail.png
 authors:
 - user: mcpotato
@@ -39,14 +41,17 @@ We will eventually migrate to the `trufflehog huggingface` command, the native H
 
 ## TruffleHog 原生 Hugging Face 扫描器
 
+
 创建原生 Hugging Face 扫描器的目标是积极的帮助我们的用户 (以及保护他们的安全团队) 扫描他们自己的账户数据，以发现泄露的风险。
 
 TruffleHog 的新的开源 Hugging Face 集成可以扫描模型、数据集和 Spaces，以及任何相关的 PRs 或 Discussions。
 
 唯一的限制是 TruffleHog 目前不会扫描任何存储在 LFS 格式中的文件。他们的团队正在努力解决这个问题，以便尽快支持所有的 `git` 源。
 
+
 要使用 TruffleHog 扫描你或你组织的 Hugging Face 模型、数据集和 Spaces 中的秘密，请运行以下命令:
 
+
 ```sh
 # For your user
 trufflehog huggingface --user <username>
@@ -58,8 +63,10 @@ trufflehog huggingface --org <orgname>
 trufflehog huggingface --user <username> --org <orgname>
 ```
 
+
 你可以使用 ( `--include-discussions` ) 和 PRs ( `--include-prs` ) 的可选命令来扫描 Hugging Face 讨论和 PR 评论。
 
+
 如果你想要仅扫描一个模型、数据集或 Space，TruffleHog 有针对每一个的特定命令。
 
 ```sh
@@ -73,6 +80,7 @@ trufflehog huggingface --dataset <dataset_id>
 trufflehog huggingface --space <space_id>
 ```
 
+
 如果你需要传入认证令牌，你可以使用 –token 命令，或者设置 HUGGINGFACE_TOKEN 环境变量。
 
 这里是 TruffleHog 在 [mcpotato/42-eicar-street](https://huggingface.co/mcpotato/42-eicar-street) 上运行时的输出示例:
@@ -81,6 +89,7 @@ trufflehog huggingface --space <space_id>
 trufflehog huggingface --model mcpotato/42-eicar-street
 🐷🔑🐷 TruffleHog. Unearth your secrets. 🐷🔑🐷
 
+
 2024-09-02T16:39:30+02:00	info-0	trufflehog	running source	{"source_manager_worker_id": "3KRwu", "with_units": false, "target_count": 0, "source_manager_units_configurable": true}
 2024-09-02T16:39:30+02:00	info-0	trufflehog	Completed enumeration	{"num_models": 1, "num_spaces": 0, "num_datasets": 0}
 2024-09-02T16:39:32+02:00	info-0	trufflehog	scanning repo	{"source_manager_worker_id": "3KRwu", "model": "https://huggingface.co/mcpotato/42-eicar-street.git", "repo": "https://huggingface.co/mcpotato/42-eicar-street.git"}
@@ -99,4 +108,6 @@ Timestamp: 2024-06-17 13:11:50 +0000
 2024-09-02T16:39:32+02:00	info-0	trufflehog	finished scanning	{"chunks": 19, "bytes": 2933, "verified_secrets": 0, "unverified_secrets": 1, "scan_duration": "2.176551292s", "trufflehog_version": "3.81.10"}
 ```
 
-致敬 TruffleHog 团队，感谢他们提供了这样一个优秀的工具，使我们的社区更安全！随着我们继续合作，敬请期待更多功能，通过 Hugging Face Hub 平台为所有人提供更加安全的服务。
\ No newline at end of file
+
+致敬 TruffleHog 团队，感谢他们提供了这样一个优秀的工具，使我们的社区更安全！随着我们继续合作，敬请期待更多功能，通过 Hugging Face Hub 平台为所有人提供更加安全的服务。
+