Daniel Chernenkov

Looking very well! Single-prompt training pipelines are excellent for rapid prototyping, but deterministic execution remains the core bottleneck. If the training set is small, a decoupled inference setup with a structured context vector store is almost always more cost-effective and controllable than running customized local weights. What did the VRAM footprint and training loss curve look like on your local setup?

You can now vibe code a language model. From a single prompt, GPT‑5.6 built the entire training pipeline and trained a model from scratch on my iMessage history. Locally on my Mac. It now generates replies in my writing style.

3️⃣ Alignment Padding: We align and pad your prompt boundaries to exact 1024-token limits to force upstream KV prompt cache hits every single time.

Still paying full price to serve the exact same LLM queries? Swap one line of code to deploy Multi-Tier Semantic Caching and DataFission Intelligent Routing. Save 90%+ on your API bill or keep funding Sam's fusion reactor. betterproxy.ai

2️⃣ Seamless Rehydration: If the LLM doesn't explicitly fetch the crushed context, we automatically rehydrate the placeholders with your raw code back on the client stream.

1️⃣ Context Crusher: We instantly swap heavy code blocks and MCP payloads (>500 chars) with lightweight cryptographic placeholder tokens, hiding the original data behind an on-demand "fetch" tool definition.

Building AgentJourney by Ora. Release a swarm of real world top agents on your site and watch their live journeys - where they succeed, where they fail, and get insights on making your site agent-ready. Sneak peek: journey.ora.ai. Powered by @oradotai .

@alono88 זה גם סייבר אבל.... יש בעיה גדולה יותר שכבר עולה עכשיו משתי החברות - משאבים (+אנרגיה), וזה מה שמעניין בהחלט כי כולנו ניזונים מזה.

רוצים להתמודד עם הבעיות הגדולות ביותר שמטרידות את OpenAI, אנתרופיק, גוגל, מטא ואת כל יתר החברות שמאמנות מודלי שפה גדולים? אז קודם כל כדאי שתבואו להגיד שלום בכנס CyberML של אורי ודבר שני אנחנו עדיין מגייסים. קישור בתגובה הראשונה.

@Dmitriy_Grey_AI nice! share your site

The architecture mismatch creates real challenges. Token economics fundamentally shift data pipeline priorities, requiring optimization for retrieval speed over storage. At RAI AI, we designed our infrastructure around this reality because customized analysis at scale demands rethinking data relevance per query.

1/10 The LLM serving market is broken. Most teams are burning capital because they're treating Generative AI like a standard 2015 REST API. If you want to survive the shift to token-native infra, your mental model has to completely evolve. Let’s talk architecture. 🧵

10/10 The economic building blocks of viable AI business models. Stop deploying models. Start engineering platforms.

9/10 Thanks to Split-Prefill/Decode and prompt caching, the gateway seamlessly reroutes the context over to an active, on-demand node. The new node skips the heavy pre-fill penalty by leveraging the cached prompt matrix, picking up the decode phase right where it left off.

אחלה פוסט. מניסיון פיתוח שלי לאחרונה והמכירה לנבידיה - אני יכול לומר שבמצב הנוכחי מי שחושב על דרך של לשלוט על כמות אדירה של שרתים זוכה בטווח זמן המיידי אבל יפול בעוד שנתיים לאחר שיבין שאפשר לעשות עיבוד שונה בתכליתו. הרוב בעיקר חושבים על שרת אחד אבל פרסמתי פוסט לא מזמן על מחשבה של Token as a Service

אז כמה עולה להריץ מודלי שפה? עם היציאה של מודלים בקוד פתוח, אפשר לקבל הערכה גסה לכמה משאבי חישוב נדרשים על מנת להריץ "מקומית" מודלי שפה גדולים שמסוגלים להתחרות בביצועים של החברות הגדולות. ניקח לדוגמה את DeepSeek 4 Pro, מודל בגודל 1.6 טריליון פרמטרים שמתקרב בגודל שלו, לפי פרסומים של אילון מאסק, ל-5 טריליון פרמטרים של מודלים כמו Opus. ראשית, על מנת לאכלס את דיפסיק 4 פרו בזיכרון, אנחנו צריכים כ-900GB של ראם. הדרך הכי יעילה להשיג את הכמות הזו היא באמצעות שמונה כרטיסי מסך מסוג H200. כל כרטיס כזה עולה כ-30,000 דולר ועל מנת לחבר אותם אחד לשני נצטרך שרת שיעלה, יחד עם הכרטיסים עצמם, בערך 400 אלף דולר (לא כולל חשמל, קירור ותחזוקה). לא נעים. מה בנוגע לענן? שרת זהה יעלה לנו כ-100 דולר לשעת ריצה או 72,000 דולר לחודש, בהנחה והשרת רץ ללא הפסקה. אני מתעלם לרגע מהעובדה שלא ניתן לקבל את השרתים הללו מספקיות הענן באותה קלות בה אפשר לקבל שרתים פשוטים יותר. בכמה מתכנתים מסוגל לתמוך שרת כזה? לא הרבה. שרת כזה מסוגל לספק כמה אלפי טוקנים בשניה בשיא, כאשר אנחנו משתמשים בסוכני קידוד כמו Claude Code והאורך של הסשן גדל, פרומפט יחיד יכול להכיל עשרות ומאות אלפי טוקנים. כמובן שלא כל המפתחים עובדים במקביל בכל רגע נתון (אני מקווה שאתם קוראים את הקוד לפני שאתם לוחצים אנטר) אז אפשר להעריך שהחסם העליון לקידוד אפקטיבי הוא כ-20 מפתחים על שרת אחד. לונג שבבים (יש עניין, לא המלצה).

Andrew, your perspective is intriguing. However, I believe coding speed is a superficial metric. The true bottleneck lies not in syntax generation but in managing state, data lineage, and system-wide integrity. Agents that prioritize code generation without a deep understanding of architecture are merely accelerating technical debt.

Coding agents are accelerating different types of software work to different degrees. When we architect teams, understanding these distinctions helps us to have realistic expectations. Listing functions from most accelerated to least, my order is: frontend development, backend, infrastructure, and research. Frontend development — say, building a web page to serve descriptions of products for an ecommerce site — is dramatically sped up because coding agents are fluent in popular frontend languages like TypeScript and JavaScript and frameworks like React and Angular. Additionally, by examining what they have built by operating a web browser, coding agents are now very good at closing the loop and iterating on their own implementations. Granted, LLMs today are still weak at visual design, but given a design (or if a polished design isn’t important), the implementation is fast! Backend development — say, building APIs to respond to queries requesting product data — is harder. It takes more work by human developers to steer modern models to think through corner cases that might lead to subtle bugs or security flaws. Further, a backend bug can lead to non-intuitive downstream effects like a corrupted database that occasionally returns incorrect results, which can be harder to debug than a typical frontend bug. Finally, although database migrations can be easier with coding agents, they’re still hard and need to be handled carefully to prevent data loss. While backend development is much faster with coding agents, they accelerate it less, and skilled developers still design and implement far better backends than inexperienced ones who use coding agents. Infrastructure. Agents are even less effective in tasks like scaling an ecommerce site to 10K active uses while maintaining 99.99% reliability. LLMs' knowledge is still relatively limited with respect to infrastructure and the complex tradeoffs good engineers must make, so I rarely trust them for critical infra decisions. Building good infrastructure often requires a period of testing and experimentation, and coding agents can help with that, but ultimately that’s a significant bottleneck where fast AI coding does not help much. Lastly, finding infrastructure bugs — say, a subtle network misconfiguration — can be incredibly difficult and requires deep engineering expertise. Thus, I’ve found that coding agents accelerate critical infrastructure even less than backend development. Research. Coding agents accelerate research work even less. Research involves thinking through new ideas, formulating hypotheses, running experiments, interpreting them to potentially modify the hypotheses, and iterating until we reach conclusions. Coding agents can speed up the pace at which we can write research code. (I also use coding agents to help me orchestrate and keep track of experiments, which makes it easier for a single researcher to manage more experiments.) But there is a lot of work in research other than coding, and today’s agents help with research only marginally. Categorizing software work into frontend, backend, infra, and research is an extreme simplification, but having a simple mental model for how much different tasks have sped up has been useful for how I organize software teams. For example, I now ask front-end teams to implement products dramatically faster than a year ago, but my expectations for research teams have not shifted nearly as much. I am fascinated by how to organize software teams to use coding agents to achieve speed, and will keep sharing my findings in future posts. [Original text: deeplearning.ai/the-batch/issu… ]