Buckets:
| import"../chunks/DsnmJJEf.js";import{i as g,h as u,C as k,H as a,E as _,s as b}from"../chunks/CKEMnrQO.js";import{p as v,o as T,s as e,f as z,a as p,b as x,d as m,n as H}from"../chunks/Bb-LL0eD.js";const E='{"title":"FAQ","local":"faq","sections":[{"title":"Kernel layers","local":"kernel-layers","sections":[{"title":"Why is the kernelization step needed as a separate step?","local":"why-is-the-kernelization-step-needed-as-a-separate-step","sections":[],"depth":3},{"title":"Why does kernelization only replace forward methods?","local":"why-does-kernelization-only-replace-forward-methods","sections":[],"depth":3}],"depth":2},{"title":"Misc","local":"misc","sections":[{"title":"How can I disable kernel reporting in the user-agent?","local":"how-can-i-disable-kernel-reporting-in-the-user-agent","sections":[],"depth":3}],"depth":2}],"depth":1}';var M=m('<meta name="hf:doc:metadata"/>'),q=m(`<p></p> <!> <!> <!> <!> <p>In earlier versions of <code>kernels</code>, a layer’s <code>forward</code> method was replaced | |
| by <a href="/docs/kernels/pr_781/en/api/layers#kernels.use_kernel_forward_from_hub">use_kernel_forward_from_hub()</a> and <a href="/docs/kernels/pr_781/en/api/layers#kernels.replace_kernel_forward_from_hub">replace_kernel_forward_from_hub()</a>. | |
| The new <code>forward</code> would dispatch to a kernel based on the device type, | |
| whether a model was training, etc. However, this approach was | |
| fundamentally incompatible with <code>torch.compile</code> since it relied | |
| on data-dependent branching.</p> <p>To avoid branching, we have to make dispatch decisions ahead of time, | |
| which is what the <a href="/docs/kernels/pr_781/en/api/layers#kernels.kernelize">kernelize()</a> function does.</p> <!> <p>There are some other possible approaches. The first is to completely | |
| replace existing layers by kernel layers. However, since this would | |
| permit free-form layer classes, it would be much harder to validate | |
| that layers are fully compatible with the layers that they are | |
| replacing. For instance, they could have completely different member | |
| variables. Besides that, we would also need to hold on to the original | |
| layers, in case we need to revert to the base layers when the model | |
| is <a href="/docs/kernels/pr_781/en/api/layers#kernels.kernelize">kernelize()</a>d again with different options.</p> <p>A second approach would be to make an auxiliary layer that wraps the | |
| original layer and the kernel layer and dispatches to the kernel layer. | |
| This wouldn’t have the issues of the first approach, because kernel layers | |
| could be similarly strict as they are now, and we would still have access | |
| to the original layers when <a href="/docs/kernels/pr_781/en/api/layers#kernels.kernelize">kernelize()</a>-ing the model again. However, | |
| this would change the graph structure of the model and would break use | |
| cases where programs access the model internals (e.g. <code>model.layers[0].attention.query_weight</code>) or rely on the graph structure | |
| in other ways.</p> <p>The approach of <code>forward</code>-replacement is the least invasive, because | |
| it preserves the original model graph. It is also reversible, since | |
| even though the <code>forward</code> of a layer <em>instance</em> might be replaced, | |
| the corresponding class still has the original <code>forward</code>.</p> <!> <!> <p>By default, we collect telemetry when a call to <a href="/docs/kernels/pr_781/en/api/kernels#kernels.get_kernel">get_kernel()</a> is made. | |
| This only includes the <code>kernels</code> version, <code>torch</code> version, and the build | |
| information for the kernel being requested.</p> <p>You can disable this by setting <code>export HF_HUB_DISABLE_TELEMETRY=yes</code>.</p> <!> <p></p>`,1);function B(f,w){v(w,!1),T(()=>{new URLSearchParams(window.location.search).get("fw")}),g();var r=q();u("1bex8oj",h=>{var c=M();b(c,"content",E),p(h,c)});var t=e(z(r),2);k(t,{containerStyle:"float: right; margin-left: 10px; display: inline-flex; position: relative; z-index: 10;"});var o=e(t,2);a(o,{title:"FAQ",local:"faq",headingTag:"h1"});var n=e(o,2);a(n,{title:"Kernel layers",local:"kernel-layers",headingTag:"h2"});var s=e(n,2);a(s,{title:"Why is the kernelization step needed as a separate step?",local:"why-is-the-kernelization-step-needed-as-a-separate-step",headingTag:"h3"});var l=e(s,6);a(l,{title:"Why does kernelization only replace forward methods?",local:"why-does-kernelization-only-replace-forward-methods",headingTag:"h3"});var i=e(l,8);a(i,{title:"Misc",local:"misc",headingTag:"h2"});var d=e(i,2);a(d,{title:"How can I disable kernel reporting in the user-agent?",local:"how-can-i-disable-kernel-reporting-in-the-user-agent",headingTag:"h3"});var y=e(d,6);_(y,{source:"https://github.com/huggingface/kernels/blob/main/docs/source/faq.md"}),H(2),p(f,r),x()}export{B as component}; | |
Xet Storage Details
- Size:
- 4.78 kB
- Xet hash:
- 8de642543d937eca0c71cacaa75a80a7d4cf2f0754b0d57595e0bf0b0ab96320
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.