وقتی کلود بتواند چیزی را اندازه گیری کند، می تواند آن را سریعتر کند

وقتی کلود بتواند چیزی را اندازه گیری کند، می تواند آن را سریعتر کند. بنابراین ما به یافتن چیزهای بیشتری برای اندازه گیری ادامه دادیم.

در آگوست امسال، تجربه کاربری اصلی claude.ai و برنامه دسکتاپ Claude را در مدت دو هفته سه برابر سریع‌تر کردیم. کاربران به ما می گفتند کند است و حق با آنها بود. ما همه چیز را از یک کانال Slack اجرا کردیم، با کلود در هر رشته.

ما روی چهار سفر متمرکز شدیم که 95٪ از فعالیت کاربر را تشکیل می دهند. در صدک 75، زمان رسیدن به یک صفحه قابل تایپ در بار جدید claude.ai از 3.1 ثانیه به 0.55، شروع جلسه جدید Claude Code از 0.8 ثانیه به 0.3 و بارگیری یک جلسه ابری Claude Cowork از 2.6 ثانیه به 0.73 رسید. در مجموع، تخمین می زنیم که هر روز ده ها هزار کاربر-ساعت انتظار را ذخیره می کند.

ما از Claude Tag (بتا) استفاده کردیم که یک مدل تحقیقاتی داخلی تقریبا قابل مقایسه با Opus 5.5 را اجرا کرد. کلود گلوگاه‌هایی پیدا کرد، معیارهایی ساخت، پیشرفت‌هایی را ارسال کرد و هر استقرار را تماشا کرد. ما با تعیین اهداف، ایجاد معاوضه و تأیید هر تغییری هدایت شدیم. با این رویکرد، ما بیش از سه هزار تغییر را بدون یک حادثه یا عقبگرد با مشتری ادغام کردیم. این پست شامل مواردی است که ما ارسال کردیم، نحوه اندازه‌گیری آن و حلقه‌ای که با کلود برای انجام ایمن این کار ایجاد کردیم.

قبل از اسپرینت، یک کانال Slack با دستورالعمل‌های ثابت زیر ایجاد کردیم:

@Claude وظیفه شما این است که همه موارد مربوط به عملکرد وب سایت و برنامه دسکتاپ claude.ai را تسهیل کنید. مسئولیت‌های شما شامل نظارت بر استقرار رگرسیون‌های عملکرد، ارزیابی دقت و جامعیت تله‌متری موجود، حفظ داشبوردهای مشاهده‌پذیری به‌خوبی، اجرای فعال راه‌حل‌ها برای مسائل مشاهده‌شده و میوه‌های کم‌آویز، پیشنهاد فرصت‌های پروژه عملکرد، و برقراری ارتباط با هم تیمی‌های انسانی است. […]

هدف نهایی این کانال این است که شما تا حد امکان خودمختار شوید، اما امروز می دانیم که هنوز امکان پذیر نیست.

ما از کلود خواستیم که داده های استفاده را از طریق سرور Datadog MCP تجزیه و تحلیل کند. چهار سفر کاربر با بیشترین تأثیر را شناسایی کرد: راه اندازی برنامه، شروع مکالمه، بارگیری مکالمه موجود و ارسال پیام. بین وب و دسکتاپ، و در محصولات ما، این سفرها به سیزده اندازه گیری مجزا رسید. برای ایجاد خطوط پایه، ابزار دقیق را اضافه کردیم تا زمانی که مستقیما قابل مقایسه باشند: هر کدام با یک تعامل کاربر شروع شد، پس از ارائه نتیجه به پایان رسید و کار مشتری و سرور را ابهام زد.

ما دوی سرعت را با لیستی از حدود بیست پروژه دست‌چین شده آغاز کردیم که هر کدام یک سفر خاص را هدف قرار می‌دهند. کلود تأثیر هر پروژه را در میلی ثانیه تخمین زد و ما آن تخمین ها را جمع آوری کردیم تا اهداف خود را برای سرعت دویدن تعیین کنیم. برخی از پروژه‌ها نسبتا بزرگ بودند، اما فکر می‌کردیم که احتمالا می‌توانیم در عرض دو هفته به اکثر آنها برسیم.

ما دوازده هدف از سیزده هدف را در روز سوم زدیم.

پروژه‌های برنامه‌ریزی‌شده زودتر به پایان رسیدند. برای راه‌اندازی سریع‌تر، ما یک آهنگساز استاتیک را در HTML ایجاد کردیم تا کاربران بتوانند در حین تنظیم اولیه React تایپ کنند، و یک حافظه پنهان کد V8 را از قبل کامپایل کردیم تا فرآیند اصلی پوسته دسک‌تاپ از ابتدا دوباره کامپایل نشود. برای پیمایش سریع‌تر، ما آهنگساز را بین مکالمه‌ها نصب کرده‌ایم، جلساتی را که کاربر روی آن‌ها قرار می‌دهد از قبل واکشی کرده، و رندرهای نوار کناری را تا 90 درصد کاهش می‌دهیم.

ما همچنین فضایی برای کلود گذاشته بودیم تا فرصت‌ها را شناسایی کند و جریان‌های کاری جدید را پیشنهاد کند. این جریان‌های کاری به سرعت به پروژه‌های کامل خود تبدیل شدند، که بسیار فراتر از اهداف اولیه ما بود. بنابراین ما اهداف جدیدی تعیین کردیم، سپس به دنبال چیزهای بیشتری برای اندازه گیری بودیم:

@Claude ما تقریبا تمام پروژه‌های موجود در فهرست پروژه‌های اصلی و موارد دیگر را تأمین مالی کرده‌ایم. بیایید تازه کنیم […] چه چیزی را کاوش نکرده ایم، از چه تپه ای می توانیم بالا برویم، در این نقطه بیشترین فرصت کجاست؟ […] من پذیرای ایده های حواس پرت هستم

از همان ابتدا می دانستیم که می خواهیم سریعتر از سرعت استقرار خود تکرار کنیم. کلود می‌توانست ساعت‌ها، حتی یک شبه، به‌صورت ناهمزمان کار کند، و ما می‌خواستیم به آن اجازه دهیم نمونه‌های اولیه‌اش را بدون انتظار برای خواندن میدانی تأیید کند. برای دستیابی به آن، ما به دنبال راه های دیگری برای اندازه گیری عملکرد در آزمایشگاه بودیم.

به جای زمان بندی ساعت دیواری چه کنیم؟ آیا می توانیم برای مثال تعداد دستورات JS را اندازه گیری کنیم؟

بله برای مسیرهای داغ JS خالص، دستورالعمل تحت اللفظی حساب می‌شود: معیار را تحت Valgrind با گره اجرا کنید - قابل پیش‌بینی و مقایسه با یک خط پایه بررسی شده - یک اجرا، بدون نیاز به آمار.

برای مسیرهای مرورگر، هیچ دستورالعملی در Chromium شمارش نمی‌شود، اما نردبانی از شمارش‌های قطعی دیگر وجود دارد: React commits در هر تعامل، شمارش فراخوانی تابع از پوشش دقیق V8، تعداد طرح‌بندی و محاسبه مجدد سبک، جهش‌های DOM. اول کدام را می خواهید؟

بیایید valgrind + Ir + --قابل پیش‌بینی در یک رشته و هر یک از بنچ‌های مرورگر/react را در رشته‌های جدید بررسی کنیم. من را در همه آنها پینگ کنید. شما می دانید ما چه می خواهیم. برویم

یازده دقیقه بعد، پنج رشته در حال اجرا بودند که هر کدام روی اندازه گیری متفاوتی متمرکز بودند: تعداد دستورالعمل، تعداد تماس V8، تعهدات React، محاسبات مجدد سبک و جهش های DOM.

ما با هر معیار جدیدی با شک و تردید برخورد کردیم. هر کدام دو شغل داشتند: اول اینکه کلود متریک می توانست در آزمایشگاه حرکت کند. دوم، یک نرده محافظ در CI با شماره ای که فقط می تواند با جغجغه پایین بیاید. اگر معیاری پوسته پوسته بود، یا اگر واقعا با تأخیر کاربر مرتبط نبود، به جای اینکه اجازه دهیم کلود از تپه اشتباهی بالا برود، آن را بیرون انداختیم.

@Claude لطفا ثابت کنید که بالا رفتن از تپه در برابر هر یک از اینها می‌تواند به برنده‌های قابل اندازه‌گیری ساعت دیواری منجر شود. ما برای هر نامزدی که نتواند این را ثابت کند، نیمکت‌ها را برمی‌داریم

زمان ساعت دیواری همان چیزی است که کاربران احساس می‌کنند، اما پر سر و صدا است و میلی‌ثانیه‌ها برای استفاده به‌عنوان یک گیت CI بسیار ضعیف هستند. تعداد دستورالعمل‌ها جذاب بودند زیرا قطعی بودند، اما ما همچنان به کلود نیاز داشتیم تا ثابت کنیم که زمان ساعت دیواری را دنبال می‌کنند.

بنابراین ما از کلود خواستیم که شمارش معکوس را روی دو مسیر داغ هدایت کند: روتینی که درخت پیام مکالمه را جمع‌آوری می‌کند و اسکنر برای خطوط وضعیت در خروجی کد کلود. کلود هر دو را با Valgrind نمایه کرد و متوجه شد که یک چهارم دستورالعمل‌های مسیر اول جستجوهای فرهنگ لغت مگامورفیک بوده و شناسه پیام یکسان را سه بار جداگانه حل کرده است.

یک ساعت بعد دستورات را در هر دو مسیر 48% و 31% کاهش داد و زمان ساعت دیواری 78% و 44% کاهش یافت. ما دو جغجغه جدید را بررسی کردیم. از آن زمان به بعد، هر روابط عمومی که تعداد دستورالعمل‌های آن مسیرها را افزایش می‌داد، CI را با شکست مواجه می‌کرد و یک کار روزانه هر سقف را کاهش می‌داد.

که ما را به درس اصلی دوی سرعت هدایت کرد. با کلود، اندازه گیری چیزی آن را قابل حمل می کند.

اندازه‌گیری قبلا مرحله صفر بود: شما یک متریک اضافه می‌کردید، منتظر می‌مانید تا داده‌ها وارد شوند و تنها پس از آن شروع به درک مشکل می‌کردید. با کلود، این مرحله یک صعود است. به محض اینکه کلود یک عدد برای شکست دادن داشت، می توانست شروع به بهینه سازی کند. این به این معنی بود که بالاترین اهرمی که می‌توانستیم انجام دهیم این بود که چیزهای بیشتری برای اندازه‌گیری پیدا کنیم.

همه اینها در یک کانال Slack اجرا شد، با چندین مهندس و کلود که در هر رشته ای پارازیت می کرد. از آنجا، اسپرینت در یک حلقه قرار گرفت:

یک مثال: شخصی یک صفحه ضبط شده را به اشتراک گذاشت که نشان می داد ردیف های نوار کناری پس از بارگیری صفحه ظاهر می شوند. ردیف‌های Chat و Cowork در زمان‌های مختلف حل می‌شوند، و باعث می‌شود صفحه احساس بدی داشته باشد. هیچ یک از مانیتورهای موجود ما آن را شناسایی نکردند. نزدیک‌ترین چیزی که داشتیم، جابجایی چیدمان تجمعی بود، اما هر شیفت فقط حدود 0.008 امتیاز کسب کرد - در آستانه خوب 0.1.

Issac این ایده را داشت که مستقیما به Layout Instability API اساسی ارجاع دهد. کلود یک رویداد تله‌متری ایجاد کرد که منابع هر ورودی تغییر طرح را به یک منطقه نام‌گذاری شده (مانند نوار کناری، رونوشت) و فاز (مثلا قبل از اولین نقاشی، بعد از تایپ کردن) نگاشت می‌کرد. این یک تست یکپارچه سازی اضافه کرد که صفحه را با یک نوار کناری پر شده باز می کرد، داده های نوار کناری را تا اولین نقاشی نگه می داشت و در هر تغییری در هر منطقه نامگذاری شده ناموفق بود. کلود از آن به عنوان معیاری برای اثبات راه حل استفاده کرد: تست 20 از 20 اجرا در اصلی قرمز و 20 از 20 در PR سبز شد.

پس از استقرار رویداد، کلود داده‌های میدانی را خواند و دریافت که 31 درصد از بارگذاری‌های صفحه وب، چیزی را پس از قابل استفاده بودن صفحه، بدون هیچ گونه تعامل کاربر، منتقل می‌کنند. از آنجا، کلود روی علل با نام کار کرد: یک ردیف سرصفحه که دیر رسید، یک حلقه که پس از بارگیری نام کاربر به طرفین لغزید، یک لیست که با ظاهر شدن نوار پیمایش حرکت کرد.

این یک رشته بود. در طول دوی سرعت، هر بار بیش از صد و پنجاه دویدیم.

هنگامی که حلقه روی یک رشته کار می کرد، اجرای آن بر روی تعداد بیشتری از موضوعات فقط باز کردن آنها بود. کلود به جای بستن یک تاپیک پس از برآورده شدن درخواست اولیه، به کار خود ادامه می دهد. یک رشته منفرد پنجاه و گاهی صدها PR بهینه سازی را قرار می دهد. به طور فزاینده ای، این کلود بود، نه یکی از ما، که موضوعات جدیدی را برای تعقیب فرصت هایی که خودش پیدا کرده بود، به عنوان بخشی از یک تحقیق جداگانه یا کار شبانه باز می کرد. شلی، یکی از مهندسان این کانال، مشاهده کرد، "[این مدل] یک شیطان اعداد است."

هر اندازه گیری چیزی برای بهبود یافت. کلود یک سرشماری هوک React انجام داد و 6900 هوک و 900 اشتراک فروشگاه را در مسیر تایپ آهنگساز پیدا کرد که با هر ضربه کلید دوباره رندر می‌شد. کلود محاسبات مجدد سبک را شمارش کرد و یک انتخابگر :root:has() پیدا کرد که 24 میلی ثانیه به هر تغییر DOM اضافه می کرد. کلود پس از اولین نقاشی، مسیرهای کد را ردیابی کرد و یک مکان باقیمانده ()reload پیدا کرد که باعث ایجاد نیم میلیون بارگذاری مجدد پنهان در روز می شد که هیچ یک از معیارهای بارگذاری ما نمی توانست آنها را ببیند.

کلود نمونه‌های نمایه‌ساز را از برگه‌های غیرفعال می‌خواند و تصاویر لحظه‌ای کش یکسان را دو بار در دقیقه در IndexedDB شبیه‌سازی می‌کند، همه در رشته اصلی.

ما به ندرت می دانستیم که یک نخ به کجا منتهی می شود. کلود در جستجوی مشکلات CPU متوجه شد که برجسته کردن یک بلوک کد تمام شده می تواند صفحه را برای حدود یک ثانیه ثابت کند. در آزمایشگاه حفاری کرد و مقصر را پیدا کرد: ام داش. اگر علامت‌گذاری پاسخ حاوی هر کاراکتر غیرلاتین-1 باشد، مانند خط تیره em یا نقل قول مجعد، V8 کل رشته را به‌عنوان UTF-16 ذخیره می‌کند، که هر regex برجسته‌سازی نحو را در مسیر کندتر دو بایتی خود قرار می‌دهد. کلود آن را با یک تغییر بیست خطی اصلاح کرد تا هر بلوک کد را قبل از برجسته کردن آن در یک رشته یک بایتی کپی کند.

در هفته دوم، ما به سختی توانستیم خروجی خود را در به روز رسانی های روزانه خلاصه کنیم. در شلوغ ترین روزها، بیش از دویست تغییر فرود آمد. کلود همچنان معیارهای جدیدی را پیشنهاد می کرد. حدود یک سوم PR ها شامل تله متری یا نرده های محافظ اضافی بودند و هر ابزار جدید رشته های بیشتری با فرصت های بیشتر تولید می کرد.

کار در یک کانال به این معنی بود که همه چیز در فضای باز اتفاق می افتاد. ما برای بحث درباره تصمیم‌ها و جشن گرفتن پیروزی‌ها، وارد و بیرون از رشته‌های یکدیگر شدیم. انتشار خبر: تیم های دیگر شروع به آوردن تغییرات خود در کانال کردند تا از نظر عملکرد بررسی شوند. پروژه‌های جدید به‌دلیل تمام حفاظ‌ها و مهارت‌های کلود که معرفی شده بود، به شیوه‌های ظریف‌تری با عملکرد بهتر نوشته شدند.

ما برای سرعت آماده شده بودیم. از آنجا که تقریبا هر چیزی را که لمس می کردیم یک مسیر داغ بود (نقاشی اول، آهنگساز، متن)، مکانیسم های ایمنی خود را از قبل ایجاد کرده بودیم. هر روابط عمومی با حداقل یک تأیید انسانی از طریق بررسی خودکار انجام می‌شود، آزمایش‌های واحد همیشه قبل از بهینه‌سازی انجام می‌شود، و هر چیزی که می‌تواند باعث ایجاد مشکل قابل مشاهده برای کاربر شود، پشت پرچم ویژگی کوتاه مدت ارسال می‌شود.

هنگامی که پرچم ها شروع به انباشتن کردند، ما یک موضوع را برای هماهنگ کردن عرضه و پاکسازی آنها باز کردیم. کلود هر پرچمی را به عنوان سوئیچ کشتن یا رمپ طبقه بندی کرد و هر کدام را به محض ایمن شدن بازنشسته کرد. در طول این دو هفته، ما نزدیک به دویست پرچم را معرفی کردیم که بیش از نیمی از آنها تا پایان پاکسازی شده بودند.

همچنین می‌دانستیم که عملکرد در یک پایگاه کد با حرکت سریع کاهش می‌یابد، و کد به سرعت در Anthropic ارسال می‌شود. هنگامی که یک پروژه برنده شد، ما در راه هایی برای محافظت از آن سرمایه گذاری کردیم. برای مثال آهنگساز استاتیک از نظر طراحی شکننده است. ما تقریبا بلافاصله یک کپی HTML از صفحه را به کاربران نشان می‌دهیم و به React اجازه می‌دهیم مستقیما بالای آن نقاشی کند.

اگر رندر React حتی یک پیکسل خاموش باشد، جادو از بین می رود. بنابراین کلود ده ها نرده محافظ ساخت:

همه چیز را نمی‌توان در آزمایشگاه گرفت، بنابراین ما از قدیمی‌ترین نرده محافظ کتاب نیز استفاده کردیم: روکش‌های افزایشی. تغییرات پرخطر ابتدا برای کارمندان، سپس یک درصد از کاربران و سپس همه منتشر شد. چهار ساعت پس از انتشار داخلی آهنگساز استاتیک، یکی از هم تیمی‌ها یک صفحه ضبط شده از تغییر چیدمان را به اشتراک گذاشت که هیچ یک از معیارهای ما نمی‌توانست آن را ببیند. وقتی claude.ai را در یک برگه جدید باز می کرد، آهنگساز رها می شد - اما این کد ما نبود.

گاهی اوقات، هنگام باز کردن claude.ai در یک برگه جدید، یک تغییر طرح عمودی کوچک (شاید 15 تا 20 پیکسل) را می بینم (با فشار دادن کادر آهنگساز به پایین) (نه در هنگام بارگیری مجدد صفحه). من نمی توانم دقیقا مشخص کنم که دقیقا چه چیزی باعث آن می شود، اما وجود دارد

آن را در ضبط خود پیدا کردید - این تغییر اندازه صفحه کروم است، نه انتقال از آهنگساز ثابت به واقعی (که 0 پیکسل در همه 49 بارگذاری امروز شما اندازه‌گیری شد).

به نحوی، کلود آن را در یک مورد لبه در بارگذاری گمانه زنی کروم ردیابی کرد. زمانی که کاربر URL را در نوار آدرس تایپ می‌کرد، Chrome صفحه را در پس‌زمینه، در اوج برگه فعلی، از قبل اجرا می‌کرد. در مرورگرهایی که توسط یک سازمان مدیریت می شوند، صفحه برگه جدید به دلیل پاورقی کمی کوتاهتر است. وقتی کاربر Enter را فشار داد، اولین فریم claude.ai طرح بندی کمی کوتاه تر را نشان داد و کروم آن را حدود یک دهم ثانیه بعد تغییر اندازه داد. کلود طرح‌بندی را روی تغییر اندازه سنجاق کرد، و ما یک آزمایش برای شبیه‌سازی جریان پیش‌اجرا اضافه کردیم.

حلقه سازنده بود، اما مستقل نبود. نگه داشتن آن سریع، ایمن و در مسیر کار ما بود و سه قسمت داشت.

جاه طلبی به طور پیش فرض، کلود مراقب دامنه است. یافته‌ها را بررسی می‌کند، امکان‌سنجی را پوشش می‌دهد و برآوردهای خود را تکمیل می‌کند. اما ما به گاردریل خود اطمینان داشتیم. بسیاری از کارهایی که ما انجام دادیم، مخصوصا در اوایل، تشویق کلود به جسورتر بودن بود.

بله - یک روابط عمومی کوچک برای دادن به کد همان علائم زمانی که Chat و Cowork قبلا دارند. من آن را این هفته قرار خواهم داد؛ در واقع، شماره کد چند روز برای ادغام، استقرار و یک پنجره پایه منتظر می ماند.

اگر همین الان آن را قرار دهید، من آن را ادغام و مستقر خواهم کرد. ما قدرت انجام هر کاری را داریم لطفا شجاع تر باش

وقتی شروع به زدن به اهدافی که تعیین کرده بودیم، متوجه شدیم که رشته ها کند می شوند. سام با همین پیغام تاپیک به نخ رفت: "بیایید به پایین آوردن این موضوع ادامه دهیم، اهداف نقطه توقف نیستند. بعدی چه چیزی است؟ جاه طلب باشید."

طعم. هر رشته دارای یک مالک انسانی به نام بود، و کلود هر گونه تغییر قابل درک توسط کاربر را با اسکرین شات ها یا ضبط های قبل و بعد برجسته می کرد تا آنها بر آن حکم کنند. آیا جدول باید سلول به سلول پر شود یا منتظر بمانیم تا هر ردیف کامل شود؟ آیا اسکلت بارگیری باید فورا ظاهر شود یا فقط بعد از نیم ثانیه؟ آیا محو شدن کلمه به کلمه در متن پخش شده ارزش یک پنجم بودجه فریمی را دارد که هزینه می کند؟ کلود به دنبال راه‌هایی برای اصلاح میلی‌ثانیه‌ها بود، و ما این معاوضه را سنجیدیم.

جهت. ما هر رشته را عمدا محدود نگه داشتیم، روی یک معیار یا سفر متمرکز شدیم و از کلود خواستیم که پیشرفت‌هایی را فقط در آن محدوده پیدا کند. ما نخ ها را صد و پنجاه چکش می پنداشتیم که به دنبال میخ هستند. بیشتر تماس‌های ما در مورد توالی و تأثیر کاربر بود: کدام سطوح باید اولویت‌بندی شود، چگونه رشته‌هایی را که روی یکدیگر قرار می‌گیرند ترکیب کنیم، و چه زمانی رشته‌ای را ببندیم که بازدهی کم‌تری داشته است. یک PR 900 خطی یک پاسخ یک خطی دریافت کرد: «رفتن به 2 میلی‌ثانیه در هر ارسال، ارزش پیچیدگی حفظ این افزونه ساختنی را ندارد.»

یکی از فرعی‌های ما نشان می‌دهد که همه چیز با هم کار می‌کند. برای نشان دادن بهینه سازی یک regex مورد استفاده در برجسته کردن نحو زنده، کلود یک ضبط صفحه نمایش از یک پاسخ طولانی در آزمایشگاه را پیوست کرد. در گوشه، یک بازخوانی نرخ فریم را اضافه کرده بود که در صفحه از مهرهای زمانی فریم انیمیشن محاسبه شده بود.

این در واقع نوعی نیمکت بیمار است. آیا ما در 60 فریم در ثانیه محدودیت داریم؟ آیا می توانید سعی کنید اسکرول و صافی استریم را به 120 برسانید؟ iiuc دکل شما ممکن است از این پشتیبانی نکند

درست است، ریگ امروزی 60 هرتز است، زیرا Chromium هدلس به طور پیش‌فرض این کار را انجام می‌دهد. من معتقدم که می توان آن را در 120 هدایت کرد (کنترل فریم vsync بدون پوشش یا DevTools) - ابتدا تأیید می کند، سپس eval را با بودجه 8.3 میلی ثانیه برای فریم دوباره اجرا می کنم.

به روز رسانی در ریگ 120 هرتز: کار می کند. فریم قطعی 120 هرتز در کروم بدون هد از طریق کنترل شروع فریم DevTools - دقیقا 240 فریم برای 240 فریم شروع در 8.33 میلی ثانیه، بنابراین "آیا این فریم با بودجه 120 هرتز تناسب داشت" به جای خواندن پر سر و صدا تبدیل به یک قاب دقیق می شود.

پس از ایجاد مکانیسم و ​​جاه طلبی، کلود دست به کار شد. هر فریم نقاشی شده بودجه ای 8.33 میلی ثانیه داشت، بنابراین کلود یک فریم به فریم پاسخ طولانی را طی کرد و هر یک را برای یافتن قسمت های کند زمان بندی کرد. با به خاطر سپردن بلوک‌های تمام‌شده، کار O (طول پیام) را در هر تکه حذف کرد، منطق توکن‌سازی را برای رشد حصارهای کد به یک کارگر منتقل کرد و جداول را سلول به سلول نشان داد.

در آن یک رشته، ما نزدیک به شصت PR را دریافت کردیم. پاسخ‌های طولانی، رشته اصلی را در مجموع حدود 200 میلی‌ثانیه مسدود می‌کرد، جایی که قبلا آن را برای حدود 750 مسدود می‌کردند، تقریبا روی یک سوم CPU اجرا می‌شد و 120 فریم در ثانیه را از ابتدا تا انتها در مک‌بوک 120 هرتزی نگه می‌داشتند. ریگ 120 هرتز خود به یک کار شبانه تبدیل شد و کلود مراقب رگرسیون بود.

پاسخ‌های طولانی در کلود در وب و دسک‌تاپ اکنون 4 برابر روان‌تر پخش می‌شوند.

ما رندر استریم را بازسازی کردیم تا فقط آنچه را که هنوز در حال تغییر است لمس کند، بنابراین یک پاسخ طولانی در لپ‌تاپ‌های کندتر 9 برابر کمتر متوقف می‌شود، بدترین حالت فریز آن 4.5 برابر کوتاه‌تر است، و در مک‌بوک 120 هرتزی، از شروع تا پایان 120 فریم در ثانیه نگه می‌دارد.

زمانی که ما دوی سرعت را شروع کردیم، برنامه‌ریزی نکرده بودیم که هنگام استریم بین فریم‌ها در فاصله چند میلی ثانیه از تپه صعود کنیم. اما معلوم شد که ما می‌توانیم آنها را بشماریم - و هر چیزی که بتوانیم بشماریم، کلود می‌تواند صعود کند.

امروزه، claude.ai و برنامه دسکتاپ حدود 3 برابر سریعتر از اوایل آگوست هستند، و جغجغه ها باید آنها را در آنجا نگه دارند. اما کار ما تمام نشده است: صدک 95، سفرهای دیگر و مکالمات بسیار طولانی هنوز جای پیشرفت دارند. در یک پست جداگانه، ما همچنین در مورد برخی از موارد جانبی که ما را در طول اسپرینت به سمت بالا بردند، با مشارکت در Electron، Chromium، Node.js و موارد دیگر خواهیم نوشت.

زمانی که نتایج را به صورت داخلی به اشتراک گذاشتیم، ایساک به بهترین شکل بیان کرد: "شما نمی توانستید من را متقاعد کنید که این امکان وجود دارد حتی شش ماه پیش." ما انتظار داریم که به این روش، یک رشته در هر زمان، در هر مقیاسی کار کنیم. کانال همچنان ادامه دارد

با مشارکت آلفرد زینگ، آنتونی موریس، بنجامین پاسرو، چیس مک کوی، جاشوا ان، لوک دین تیلور، ماریوس شولز، و شلی وهر. تشکر ویژه از بوریس چرنی برای تشویق ما به جاه طلبی بیشتر.