(This article is authored by Tech Business; published on Titanium Media with authorization.)
Article | Tech Business
During the internet’s golden decade, ByteDance was hailed as a godlike organizational machine. Leveraging its “app factory” model, flat‑hierarchy agile development, and an intensely competitive “racehorse mechanism,” it managed to carve out a global‑scale behemoth like TikTok, even while caught between Tencent and Alibaba.
But when this company entered the era of large models, armed with the most dazzling funding, top-tier computing power, and an enormous talent pool, its once‑“powerful weapon” turned into its deepest vulnerability.
Recently, a discussion on X about ByteDance’s Seed team has torn away the most brutal organizational veil hiding behind the hype around large models. An insider bluntly pointed out: Seed boasts top talent and substantial computing power, yet progress in LLMs (large language models) has been disappointingly slow. The root cause isn’t technical limitations—it’s an organizational issue: ByteDance’s “horse-racing” incentive system simply doesn’t align with the R&D needs of large models.
In conjunction with the firsthand accounts from those involved in the “poisoning” incident during ByteDance’s Seed team training, as reported previously, and the discussions in the comment sections about a “heavy-industry assembly line for large models,” an extremely absurd reality has come to light: faced with large models—the most complex systems engineering project in human history—ByteDance’s much‑boasted “horse racing” approach has failed to deliver the rocket‑like progress toward AGI.
Image from Twitter
When “horse racing” collides with “heavy industry”
Executives at major companies often fall into a fatal path dependency: they assume that large models are just another, more complex app—so long as they allocate enough teams and pit them against each other in internal competitions, they’ll end up with the strongest model.
This is the ideological imprint left by the mobile internet era.
As one industry professional aptly summarized in the comments: “Large‑model pretraining is, at its core, a pipeline‑driven operation akin to precision heavy industry. From tokenization and filtering, to data balancing, and on to communication optimization across thousands or even tens of thousands of GPUs, every stage must fit together seamlessly and operate in full coordination.”
In this heavy‑industry‑scale system, there’s no room for isolated, siloed operations. You need a highly centralized command center to coordinate tens of thousands of GPUs, uniformly process hundreds of trillions of tokens, and consistently align the underlying infrastructure architecture. Even a minor data‑ratio error or a loose network cable in a thousand‑card cluster can cause an entire training run—lasting months and costing tens of millions—to collapse completely.
And what is the core of the “racehorse mechanism”? It’s iterative, rapid iteration; resource isolation; team-driven competition; and a winner-takes-all dynamic.
Forcing the race‑horse model of the mobile internet onto the development of ultra‑large, globally coordinated clusters has directly resulted in fragmenting what should be a “supercomputing pool” capable of pooling resources to tackle major challenges into isolated “resource silos,” each fighting its own battle.
The report notes that, within ByteDance, hoarding resources has become the norm. Teams that have already secured computing power prefer to let it sit idle rather than share it with others, even if it means letting it go to waste. Everyone is wary of neighboring teams outperforming them; information is opaque, communication is fraught with suspicion, and teams even conceal critical code and data from one another.
This is not a fatal flaw unique to ByteDance. The leaker also mentioned that Silicon Valley giants face similar issues: within Google, the team developing Gemini has been complaining about a shortage of GPUs, while the profit-generating advertising team holds a large number of GPUs—yet outsiders remain unaware of what exactly they are using this computing power for. It should be noted that this specific claim about internal GPU allocation at Google has so far only appeared in relayed reports and has not yet been independently verified by other sources; however, the departmental silos and organizational self-interest it highlights are indeed costly sunk costs in the era of large-scale models.
After six months of data cleansing, who’s going to take ownership of the OKR?
Developing large models requires not only “scale” but also “calm.” Unlike writing front-end code, where you can immediately see flashy UI feedback, building such models demands extensive, tedious data cleaning and painstaking communication tuning.
And under the highly competitive KPI/OKR system prevalent in major companies, such “quietness” is simply not tolerated.
The leak paints a very realistic picture of the developers’ pain points: building LLMs doesn’t require all those sudden “eureka moments.” The real work involves painstakingly getting the data and environment right, and relentlessly optimizing infrastructure efficiency. Yet these developers—composed of top-tier talents—deep down crave innovation and the chance to lead projects.
“With OKRs that are reviewed every few months, I’ve spent the entire past six months cleaning up dirty data—how am I supposed to write my year-end OKRs?” This is a deadlock.
Under the current evaluation system, tasks like data cleaning, anomaly detection, and communication optimization—those “dirty, tedious jobs” that truly set the lower bound for large models—cannot be translated into polished presentation slides or top-tier conference papers. If employees, in order to meet their OKRs, focus on the most eye-catching, easiest-to-publish architectural innovations, then who will handle the grunt work?
If no one is working on it, the model will ingest toxic data, ultimately leading to a disaster.
Previously, the “poisoning” incident in which ByteDance’s Seed team trained a model—once a shock within the industry—was precisely the result of such extreme internal competition and organizational fragmentation. As the most direct victim, former employee ShoufaChen painfully recounted those months-long investigations, confrontations, and accusations. Over several months, the team faced nothing but bizarre collapses in model performance and mutual recriminations over each other’s mistakes.
Public reports indicate that this was not a simple technical bug, but rather systematic sabotage carried out by a former intern in the training environment: tampering with underlying code, randomly terminating training processes, planting backdoors, and disguising these failures as random accidents. When teams grow wary of one another in the scramble for resources, and when researchers conceal genuine data issues to protect their own projects, the behemoth of large models can quietly spiral toward collapse. The OKR systems employed by major tech companies, originally designed to unlock human potential, ultimately end up bringing out the most shortsighted and selfish aspects of human nature.
The missing "Research Group"
Even more interesting is another comment: “ByteDance has the most resources, but it doesn’t have a single genuine research group.”
Over the past few years, this company has produced remarkably impressive content on its tech blog, publishing numerous high-quality infrastructure frameworks and underlying algorithms. However, a closer look reveals that there appears to be an extremely mismatched, nonlinear relationship between their technical output and the computational resources they’ve actually invested. Despite deploying tens of thousands of GPUs, what they deliver often amounts to localized, “engineering‑level” wins rather than fundamental, paradigm‑shifting breakthroughs.
Why? Because the “research institutes” of major companies often remain subordinate to business units. They are expected to “be both cutting-edge and practical”: they must publish papers at top-tier conferences to demonstrate their technical prowess, while also being able to integrate immediately into Douyin for ad‑based recommendations. This contradictory demand—“both this and that”—prevents researchers from maintaining long-term focus on a single direction.
But in the era of large models, true research requires “cost-agnostic trial and error” and “long-term, tolerant patience.”
Microsoft built a top-tier supercomputing center for OpenAI, yet it still took them several years to finally produce GPT-4. Meanwhile, DeepSeek, backed by Fantai, boasts virtually unlimited computational redundancy and an extremely flat, geek‑centric culture, allowing a small team of just a few dozen people to relentlessly pursue even the most ambitious MoE architecture. In contrast, at large corporations, unless they address the free allocation of computing resources and establish a performance‑evaluation system that doesn’t obsess over short‑term DAU metrics, talented engineers will end up reduced to high‑level data‑cleaning assembly‑line workers or office politicos locked in internecine battles over GPU access.
Notably, public reports indicate that ByteDance has since encouraged the Seed team to streamline its organizational structure and abolished the quarterly OKRs and semi-annual performance reviews for the Seed Edge project. This indirectly suggests that the previous “race‑horse model plus short‑cycle evaluations” approach has indeed become unsustainable.
Conclusion: Saying goodbye to the “App Factory” and reinventing the “Big Tech Company”
In fact, it’s not just ByteDance. Alibaba, Tencent, Google—every traditional tech giant that has tried to pour “large models” into the old bottle of an “app factory”—is experiencing painful growing pains.
Large models are not mini-programs that can be launched with just a few lines of front-end code; they represent the pinnacle of compressing human knowledge into an engineering feat—a truly massive, ruthless, and highly collaborative fusion process. They demand that enterprises possess bottom-level hardware‑level scheduling capabilities, be prepared to endure prolonged periods of “zero output,” and, above all, embrace an unwavering conviction that transcends short-term financial results.
If major tech companies still cling to the old internet mindset of “internal horse-racing,” “forcing output through OKRs,” and “focusing only on their own backyard,” then despite having tens of thousands of compute cards at their disposal, they will ultimately end up building a “resource island” that falls short of the mark above and struggles below.
The winners of the future may not be the companies with the most GPUs, but they will certainly be the organizations that dare to tear down the old departmental silos, consolidate all their computing power into a single, unified force, and create an environment where top talent is willing to spend an entire year labeling data. After all, computing power can be bought with money, but building a “research‑industrial system” that aligns with the evolutionary logic of silicon‑based intelligence requires a profound, transformative self‑revolution. Without overhauling their operating systems, even the biggest tech firms are destined to remain stuck outside the narrow gateway to AGI.
This article is from the WeChat official account “Tech Business,” authored by Tech Business, and published with permission.
For more exciting content, follow TMTPost on WeChat (ID: taimeiti), or download the TMTPost App.