some nits
Browse files- content/article.md +6 -1
- dist/index.html +4 -1
content/article.md
CHANGED
|
@@ -50,6 +50,11 @@ We codify the "tenets" that guide our development, demonstrate how they are impl
|
|
| 50 |
|
| 51 |
For any OSS maintainer, power user, or contributor, this is the map to understanding, using, and building upon `transformers`, but not only: any project of comparable size will require you to make deep choices, not only on design and choice of abstraction, but on the very mindset of the software you are building.
|
| 52 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 53 |
|
| 54 |
## The core tenets of transformers
|
| 55 |
|
|
@@ -149,7 +154,7 @@ We amended the principle of [DRY*](#do-repeat-yourself) by removing progressivel
|
|
| 149 |
|
| 150 |
It works as follows. In order to contribute a model, say for instance define a `modular_` file that can inherit from _any function across all other modeling, configuration and processor files_.
|
| 151 |
|
| 152 |
-
<summary>Auto-generated modeling code</summary>
|
| 153 |
|
| 154 |
{{{fragment-glm-compare}}}
|
| 155 |
|
|
|
|
| 50 |
|
| 51 |
For any OSS maintainer, power user, or contributor, this is the map to understanding, using, and building upon `transformers`, but not only: any project of comparable size will require you to make deep choices, not only on design and choice of abstraction, but on the very mindset of the software you are building.
|
| 52 |
|
| 53 |
+
[Tenets exemplified](#source-of-truth) will have their summary available on hover.
|
| 54 |
+
|
| 55 |
+
[External links](https://huggingface.co/blog/welcome-openai-gpt-oss) to articles will help you solidify your knowledge.
|
| 56 |
+
|
| 57 |
+
[Several interactive visualisations](#generated-modeling) are available as you go - scroll, zoom, drag away.
|
| 58 |
|
| 59 |
## The core tenets of transformers
|
| 60 |
|
|
|
|
| 154 |
|
| 155 |
It works as follows. In order to contribute a model, say for instance define a `modular_` file that can inherit from _any function across all other modeling, configuration and processor files_.
|
| 156 |
|
| 157 |
+
<summary id="generated-modeling">Auto-generated modeling code</summary>
|
| 158 |
|
| 159 |
{{{fragment-glm-compare}}}
|
| 160 |
|
dist/index.html
CHANGED
|
@@ -56,6 +56,9 @@
|
|
| 56 |
<p>This post dissects the design philosophy that makes this possible. It’s a continuation of our older principles, detailed on our previous <a href="https://huggingface.co/docs/transformers/en/philosophy">philosophy</a> page, as well as its accompanying <a href="https://huggingface.co/blog/transformers-design-philosophy">blog post from 2022</a>. More recently, and I recommend the read if it’s not done yet, a blog post about <a href="https://huggingface.co/blog/faster-transformers">recent upgrades to transformers</a> was written, explaining in particular what makes the library faster today. Again, all of that development was only made possible thanks to these principles.</p>
|
| 57 |
<p>We codify the “tenets” that guide our development, demonstrate how they are implemented in code, and show the measurable impact they have on the library’s sustainability and growth.</p>
|
| 58 |
<p>For any OSS maintainer, power user, or contributor, this is the map to understanding, using, and building upon <code>transformers</code>, but not only: any project of comparable size will require you to make deep choices, not only on design and choice of abstraction, but on the very mindset of the software you are building.</p>
|
|
|
|
|
|
|
|
|
|
| 59 |
<h2>The core tenets of transformers</h2>
|
| 60 |
<p>We summarize the foundations on which we’ve built everything, and write the “tenets” of the library. They behave like <em>software interfaces</em>, hence it is crucial that they are explicitly written down. However opinionated they are, they have evolved over time.</p>
|
| 61 |
<p>Note that the library <em>evolved</em> towards these principles, and that they <em>emerged</em> from decisions taken, and once emerged they were recognized as critical.</p>
|
|
@@ -132,7 +135,7 @@
|
|
| 132 |
<p>Transformers is an opiniated library. The previous <a href="https://huggingface.co/docs/transformers/en/philosophy">philosophy</a> page, and the <a href="https://huggingface.co/blog/transformers-design-philosophy">blog post</a> were already pointing at the drawbacks mentioned just above, which have been iteratively addressed. <a href="https://huggingface.co/docs/transformers/en/modular_transformers"><code>modular</code> transformers were introduced</a>, allowing a form of inheritance without breaking <a href="#one-model-one-file">One model, One file</a>.</p>
|
| 133 |
<p>We amended the principle of <a href="#do-repeat-yourself">DRY*</a> by removing progressively all pieces of code that were “copied from” another file.</p>
|
| 134 |
<p>It works as follows. In order to contribute a model, say for instance define a <code>modular_</code> file that can inherit from <em>any function across all other modeling, configuration and processor files</em>.</p>
|
| 135 |
-
<summary>Auto-generated modeling code</summary>
|
| 136 |
<p><div class=code-compare style="display: grid; grid-template-columns: 1fr 1fr; gap: 1rem; margin: 1.5rem 0;">
|
| 137 |
<div class=code-column style="border: 1px solid #e2e8f0; border-radius: 8px; overflow: hidden;">
|
| 138 |
<div class=code-header style="background: #f8f9fa; padding: 0.75rem 1rem; font-weight: 600; color: #495057; border-bottom: 1px solid #e2e8f0;">
|
|
|
|
| 56 |
<p>This post dissects the design philosophy that makes this possible. It’s a continuation of our older principles, detailed on our previous <a href="https://huggingface.co/docs/transformers/en/philosophy">philosophy</a> page, as well as its accompanying <a href="https://huggingface.co/blog/transformers-design-philosophy">blog post from 2022</a>. More recently, and I recommend the read if it’s not done yet, a blog post about <a href="https://huggingface.co/blog/faster-transformers">recent upgrades to transformers</a> was written, explaining in particular what makes the library faster today. Again, all of that development was only made possible thanks to these principles.</p>
|
| 57 |
<p>We codify the “tenets” that guide our development, demonstrate how they are implemented in code, and show the measurable impact they have on the library’s sustainability and growth.</p>
|
| 58 |
<p>For any OSS maintainer, power user, or contributor, this is the map to understanding, using, and building upon <code>transformers</code>, but not only: any project of comparable size will require you to make deep choices, not only on design and choice of abstraction, but on the very mindset of the software you are building.</p>
|
| 59 |
+
<p><a href="#source-of-truth">Tenets exemplified</a> will have their summary available on hover.</p>
|
| 60 |
+
<p><a href="https://huggingface.co/blog/welcome-openai-gpt-oss">External links</a> to articles will help you solidify your knowledge.</p>
|
| 61 |
+
<p><a href="#generated-modeling">Several interactive visualisations</a> are available as you go - scroll, zoom, drag away.</p>
|
| 62 |
<h2>The core tenets of transformers</h2>
|
| 63 |
<p>We summarize the foundations on which we’ve built everything, and write the “tenets” of the library. They behave like <em>software interfaces</em>, hence it is crucial that they are explicitly written down. However opinionated they are, they have evolved over time.</p>
|
| 64 |
<p>Note that the library <em>evolved</em> towards these principles, and that they <em>emerged</em> from decisions taken, and once emerged they were recognized as critical.</p>
|
|
|
|
| 135 |
<p>Transformers is an opiniated library. The previous <a href="https://huggingface.co/docs/transformers/en/philosophy">philosophy</a> page, and the <a href="https://huggingface.co/blog/transformers-design-philosophy">blog post</a> were already pointing at the drawbacks mentioned just above, which have been iteratively addressed. <a href="https://huggingface.co/docs/transformers/en/modular_transformers"><code>modular</code> transformers were introduced</a>, allowing a form of inheritance without breaking <a href="#one-model-one-file">One model, One file</a>.</p>
|
| 136 |
<p>We amended the principle of <a href="#do-repeat-yourself">DRY*</a> by removing progressively all pieces of code that were “copied from” another file.</p>
|
| 137 |
<p>It works as follows. In order to contribute a model, say for instance define a <code>modular_</code> file that can inherit from <em>any function across all other modeling, configuration and processor files</em>.</p>
|
| 138 |
+
<summary id="generated-modeling">Auto-generated modeling code</summary>
|
| 139 |
<p><div class=code-compare style="display: grid; grid-template-columns: 1fr 1fr; gap: 1rem; margin: 1.5rem 0;">
|
| 140 |
<div class=code-column style="border: 1px solid #e2e8f0; border-radius: 8px; overflow: hidden;">
|
| 141 |
<div class=code-header style="background: #f8f9fa; padding: 0.75rem 1rem; font-weight: 600; color: #495057; border-bottom: 1px solid #e2e8f0;">
|