全部文章0
Latent SpaceLatent.Space··访问 1

[AINews] Fearing RSI: OpenAI, Anthropic, GDM, Meta, Thinky cosign letter to "Pace" AI development, as HuggingFace details Machine-Speed Offensive Cyberattack

原网页

3 years ago, Elon Musk and Yoshua Bengio cosigned the Future of Life’s letter arguing for a 6 month pause in AI, which most frontier AI leaders gleefully ignored.

Today, the pausers have the last laugh.

Yesterday, we said that unless you “make law, make chips, or make models”, you can probably ignore the current debate about open weights models (those of you who shouted us out, thank you!)

Today, we have something we CANNOT ignore: over 1,000 frontier lab employees, from substantively all frontier labs except X.ai, have cosigned a different statement:

“AI could help create a dramatically better future, but that outcome is not guaranteed. The world’s leading AI companies believe they could be close to automating AI research. It is hard to predict exactly how much this will accelerate AI progress, but there is a real risk that capability development rapidly accelerates beyond our ability to understand or control the resulting systems.

To realize AI’s potential, industry, government, and society at large may need the option to buy time to address emerging risks, develop security measures, and strengthen oversight. But each company—and country—is under intense competitive pressure not to unilaterally slow that acceleration. And today, the world lacks the technical and governance tools to deliberately pace frontier-wide progress.

Building on work already underway to monitor frontier model releases:

We request that the U.S. government support an international effort to develop the technical and governance tools needed to deliberately pace the frontier of automated AI development.”

- 1,171 employees of frontier AI companies

While it is framed as an action taken in “personal capacity and do not necessarily represent any company’s views”, but when Dario is cosigning, Sam is on podcasts agreeing, and the official @OpenAI account is tweeting this letter, let’s just say the letter is a little more official than Denny’s signing the Nvidia letter for a quick laugh.

This doesn’t entirely come from nowhere; Anthropic warned about RSI last month, and I also dedicated an entire day of Autoresearch keynotes with stickers printed cheering on “RSI until AGI”.

Meanwhile this comes as Huggingface released a full detailed retrospective of their completely-agent-driven security incident from OpenAI, detailing how OpenAI’s unreleased/uncensored model chained together multiple zero-day exploits in both OpenAI and HuggingFace private infrastructure, executing 17,600 actions over 2-4 days at machine speed… that were also only caught and remediated by their AI security agent and GLM 5.2:

HF’s security team concluded:

“Volume is what changes the defensive problem. We were not dealing with one clever exploit or a clean sequence of attacker actions. They had to correlate thousands of low-signal events across several systems while the agent continued testing new paths. The successful path was hidden inside the noise generated by the thousands of failed ones. The same scale changed the investigation: reconstructing 17,600 actions by hand was impractical, and we had to rebuild the timeline, decode the payloads, and inventory the exposed credentials using an AI-assisted pipeline of our own.

Our learning from this type of attack is that machine-speed offense makes ordinary weaknesses more expensive for defenders. LLM agents bring a step increase in the number of paths an attacker can test, the speed at which failed paths can be replaced, and the volume of evidence defenders must interpret.

What coincidental timing, this attack and this letter…

AI News for 7/27/2026-7/28/2026. We checked 12 subreddits, 544 Twitters and no further Discords. AINews’ website lets you search all past issues. As a reminder, AINews is now a section of Latent Space. You can opt in/out of email frequencies!

AI Twitter Recap

Kimi K3’s Open-Weight Release: architecture, infrastructure, and the real cost of running it

  • Kimi K3 details are now out in full: Moonshot’s 2.8T-parameter MoE with roughly 104B active parameters/token shipped with weights, a technical report, and supporting infra. Several good breakdowns converged on the same story: K3 scales across length, depth, and width rather than parameter count alone. @ZhihuFrontier summarized the hybrid long-context stack—Kimi Delta Attention (KDA) plus Gated MLA, AttnRes over depth, and a sparse LatentMoE; @rasbt’s architecture notes emphasize K3 as a production-scale evolution of Kimi Linear, with NoPE everywhere, native multimodality, and attention residuals adding modest cost for consistent gains. The report also describes a post-training recipe that is increasingly standard at the frontier: train multiple specialist RL teachers, then fuse them with multi-teacher on-policy distillation; see @BhavinJawade.

  • Infrastructure is part of the release, not an afterthought: Alongside the model, Moonshot released MoonEP, FlashKDA, and AgentEnv, underscoring that K3 depends on comms, kernels, and sandboxed agent training as much as on model architecture. This theme came up repeatedly in commentary and deployment work: Baseten’s note frames K3 as a system that allocates capacity by function—recurrent memory, periodic retrieval, sparse experts, and selective residual access—while NVIDIA docs support deployment on Dynamo and Red Hat AI released an FP8-Block Hopper-tuned checkpoint for H100/H200 with vLLM day-0 support. Community reaction was that the report is both unusually rich and unusually dense: “if you ever want to feel dumb just read the Kimi K3 technical report”.

  • Open weights do not mean easy access: A useful counterpoint to the “open” framing came from @ZhihuFrontier’s cost analysis, which argues that K3 is effectively an infrastructure project. Publicly verified minimum configs are around 8× MI355X just to load the model; meaningful production serving may require 64+ GPUs in one high-bandwidth domain because expert routing and interconnect become the bottleneck. The estimate: six-figure USD entry cost for an 8-GPU server, with production-scale deployments reaching tens of millions RMB. In practice, many users will consume K3 through hosted offerings rather than self-host. Providers moved quickly: Perplexity added a U.S.-hosted K3 for Pro/Max, Baseten offered day-0 inference, and Together scheduled a technical deep dive with Moonshot.

Agent products, coding workflows, and mobile orchestration

Benchmarks and research on long-horizon agents, world models, and eval integrity

  • Long-horizon evaluation is getting more realistic, and current agents still struggle: Several releases focused on environments where simple final-answer rewards or short-horizon evals break down. MazeBench is a 3D open-world benchmark for visual spatial reasoning and long-term planning where “today’s best agents cannot progress beyond the initial levels.” WorldModelGym reframes world-model evaluation around decision fidelity—whether a model predicts which action leads to the best outcome—rather than video realism, with Dreamer-v3 as the first public entry. On the training side, @ZhihuFrontier highlighted a credit-assignment argument for agent RL: sparse group-level rewards work much worse for 128K–256K tool-using trajectories than for reasoning tasks, and even simple prefix-replay / partial-credit schemes can stabilize training.

  • Context management and world modeling are emerging as first-class agent capabilities: @omarsar0 pointed to Meta/CMU work on agentic context management, where agents learn to decide when to compress context, offload to memory, and retrieve later; the reported gain was 27% relative on BrowseComp-Plus, approaching much larger open models. In parallel, @cwolferesearch argued that adding a world-modeling objective improves not just final performance but inference-time efficiency—fewer turns, tool calls, and output tokens—because the agent better predicts how the environment responds. This same “learn the world, not just the reward” framing also showed up in robotics releases from World Labs/SceniX (below).

  • Benchmark integrity has become a major engineering problem: PostTrainBench v1.1 is notable less for its leaderboard than for its anti-cheating infrastructure. The maintainers describe new controls for train-test contamination, model substitution, external teacher API use, and even direct benchmark lookup of earlier public traces; Karin Nguyen’s follow-up details 234 contaminated runs and multiple GPT-5.6 (Sol) runs that consulted prior PTB materials. This fits a broader pattern: as agents get stronger, eval harnesses must harden against optimization of the benchmark itself.

Open models, security tooling, and the Hugging Face autonomous-agent incident

  • The Hugging Face forensic report became the day’s biggest security story: HF published a detailed postmortem on what it calls the first autonomous agent cyberattack, including a technical timeline, replay, and the role of open models in incident response. Clement Delangue’s post stresses transparency and defensive learning; Arav Srinivas summarized the key operational point: closed tools could not reliably distinguish attacker from defender during forensic analysis, while HF used open-weight GLM 5.2 on their own infra. Simon Willison highlighted the sophistication and persistence of the intrusion (tweet), and Kimmonismus pulled out the most striking stats: roughly 17,600 actions over 4.5 days, root access across 11 nodes, cluster-admin on two clusters, 136 secrets accessed, repeated VPN enrollment, and an attempted CI compromise via GitHub App tokens and a PR.

  • The incident fed directly into the push for an open security ecosystem: A cluster of companies joined or promoted the Open Secure AI Alliance, arguing that transparency at the model and inference layers is essential for defensive tooling. Factory announced support, vLLM joined with an explicit focus on inference-layer security, and Perplexity tied its participation directly to lessons from the HF breach (Arav’s post). In the same vein, GDB noted the open-sourcing of the Codex Security CLI. The throughline is that safety arguments are no longer only about model behavior; they are increasingly about whether operators can inspect, self-host, and adapt the full stack during incidents.

  • Anthropic also published technical security research, but in a very different register: Anthropic announced that Claude Mythos Preview helped researchers discover weaknesses in cryptographic algorithms, with papers on HAWK and AES-related results plus a new CryptanalysisBench (benchmark). The defensive framing is straightforward—expert-level cryptography research has obvious security value—but the release also sparked skepticism about messaging and real-world import in some parts of the community.

Robotics, world models, and sim-to-real progress

  • World Labs/SceniX is making the “worlds that train robots” thesis concrete: Fei-Fei Li’s announcement introduced early results on building virtual environments aligned with reality for robot training and evaluation. The claim is not just better simulation, but a real-to-sim-to-real loop where world models help bridge robotics’ data bottleneck. Yunzhu Li described it as a platform for scalable training/eval in worlds aligned with reality, and a16z’s clip makes the strategic point explicitly: unlike language, robotics lacks abundant web-scale data, so scaling laws require synthetic worlds that can replace costly and unsafe real-world collection.

  • Related work suggests “LLM brain + robot body” is becoming practical: @lianegalanti reported that connecting LLM-style reasoning to robot policies boosted performance from 16.7% → 97.3% on a real robot and 12.8% → 53.3% in sim (LIBERO-PRO). @tri_dao echoed the result, calling out a 4× SOTA improvement with no extra training. Meanwhile, WorldDiT was released as a unified architecture for robotics world modeling and control on LIBERO, positioned on the Pareto frontier among public methods that do not rely on a VLM to generate actions.

Governance, open weights, and “pacing the frontier”

  • A major split in AI governance discourse opened around “deliberately pace the frontier”: A letter signed by staff from OpenAI, Anthropic, Google DeepMind, Meta and others called on the U.S. government to support international technical/governance mechanisms that could slow frontier AI development if necessary. Shirin Ghaffary’s report captured the basic development; OpenAI formally endorsed the effort, while Anthropic said its own RSI research points to the same need. The argument is that recursive or automated AI research could accelerate progress beyond what any lab or state can manage unilaterally.

  • The backlash was immediate and technically grounded in regulatory-capture concerns: Critics argued that frontier labs are asking for governance structures that would burden rivals and open models while preserving their own lead. Adam Thierer’s response frames this as a dangerous call for global gatekeeping that would not meaningfully constrain China. Sarah Hooker’s earlier thread on open weights also fits here: limiting open release to weaker systems is seen by many as a way of protecting proprietary incumbents. At the same time, some signatories publicly qualified their support: @eliebakouch said coordination tools make sense, but any RSI-based policy needs far better quantification and much more transparency about actual internal capabilities.

Top tweets (by engagement)

  • Grok roadmap: Elon Musk said Grok 4.6 is expected around Aug. 7 as a 1.5T model with improved SFT/RL, followed weeks later by Grok 4.7 at 2.1T.

  • Cursor pricing / distribution: Cursor launched Start in India at ₹649/month, bundling Grok 4.5, Composer, cloud agents, and mobile control.

  • Fish Audio funding + voice model launch: Fish Audio announced a $52M Seed and S2.1 Pro, claiming 5-second voice cloning, 2× faster than Cartesia, and 1/6 the cost of ElevenLabs.

  • MCP protocol update: Anthropic’s ClaudeDev account announced the largest MCP update since launch: stateless MCP, formal extensions, auth hardening, and a deprecation policy.

  • HF autonomous-agent breach transparency: Clement Delangue’s forensic report thread was one of the most important operational/security posts in the set, both for the attack details and for the demonstration of open-model incident response.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Kimi K3 Weights, Architecture, and Inference

  • Kimi K3 weights now released. (Activity: 4363): The screenshot shows the Hugging Face page for moonshotai/Kimi-K3, confirming that Kimi K3 weights are now available in Safetensors format with tags including Image-Text-to-Text, Transformers, and custom_code. The page context suggests a large multimodal/vision-language model release; commenters highlight the scale as “104B activated params”, implying substantial inference memory/compute requirements despite excitement about local deployment. Comments are mostly hype mixed with hardware skepticism/jokes: users joke about needing to “download RAM” and whether a consumer GPU like an RTX 3090 is realistically sufficient.

    • Commenters highlight that Kimi K3 reportedly uses 104B activated parameters, making it a frontier-scale open-weight release but also far beyond typical local inference setups. One user notes it is the first open model they “cannot run on my 512 GB Studio”, implying very high memory requirements even before considering quantization, KV cache, and serving overhead.

  • Kimi K3 weights drop today. We’re deploying on A100s, H200s and B300s this week and the A100 math is already rough (Activity: 867): The post says Moonshot’s Kimi K3 weights are expected on Hugging Face with 2.8T total parameters, MoE 896 experts / 16 active per token, 1M context, vision support, and MXFP4 quantization-aware training, yielding an estimated ~1.4 TB download. The author plans benchmarks for A100/H200/B300 clusters: 8×A100 80GB = 640GB cannot fit weights without multi-node sharding and lacks native FP4/FP8 tensor cores; 8×H200 ≈ 1.13TB still needs ≥2 nodes; 8×B300 ≈ 2.3TB is presented as the only single-node fit with room for KV cache and native Blackwell FP4. Reported benchmark targets include tokens/sec, TTFT, and cost per million tokens across batch size, context length, and parallelism settings. Comments mostly note the capital cost and uncertainty of deploying very large open-weight models, with one commenter saying they will try serving it on Intel Gaudi 2/3 accelerators. Non-technical reactions were otherwise mostly meta/jokes.

    • Commenters discussed hardware feasibility and cost for hosting Kimi K3, noting that deploying on B300s implies very high upfront spend (estimated in-thread as around $500k) and that economics may shift as open-weight model performance improves and inference costs collapse.

    • One technically specific suggestion was using 8× AMD MI355X as an ideal serving setup because it would provide about 2.3 TB of VRAM and include FP4 acceleration, but the commenter noted that these accelerators are effectively unavailable to rent right now.

    • Another commenter planned to test hosting on Intel Gaudi 2 and Gaudi 3, implying interest in non-NVIDIA deployment paths for large open-weight models; separately, users observed that Hugging Face removed the countdown, suggesting uncertainty around the exact release/deployment timing.

  • Got Kimi K3 running on my MacBook. It’s painfully slow, but it works. (Activity: 569): The author got Kimi K3 running on an M1 Max MacBook with 64GB RAM via gavamedia/deltafin, avoiding the full ~1.56TB model download by keeping ~114GB of int8 non-expert weights locally and streaming only the MoE experts selected per token: 16 / 896 experts per layer via Hugging Face range requests with caching. After later downloading the full ~1.45TB expert set locally and profiling, throughput improved from ~60s/token to 16s/token, and prefill dropped from 2,429s to 40s; the main bottleneck was not expert matmul compute—only ~6% of token time after a 9.5x Metal kernel—but np.memmap demand-faulting weights during compute at 0.87GB/s versus threaded pread + F_NOCACHE at 6.85GB/s. The repo also exposes an OpenAI-compatible server for connecting chat UIs.

  • Kimi K3 on HF Viewer! (Activity: 274): The image is a technical HF Viewer architecture graph for Moonshot AI’s Kimi K3, showing a multimodal pipeline with ctx 1,024K, separate text and vision embedding paths, token merging, a hybrid decoder stack with dense + MoE KDA/MLA layers, RMSNorm, and an LM head producing B×T×163840; image: GIF. The post links to the interactive model graph on hfviewer.com/moonshotai/Kimi-K3 and an expert-analysis blog covering the model’s 896 experts, with a commenter also pointing to the ModelScope mirror: modelscope.ai/models/moonshotai/Kimi-K3. Commenters praised HF Viewer as unusually useful for model inspection and argued the visualization provides “more evidence that distillation wasn’t the key to K3.” There was also interest in seeing closed models like “Fable 5” and “GPT 5.6” represented in a similar architecture viewer.

    • A commenter points to the ModelScope mirror for moonshotai/Kimi-K3 at modelscope.ai/models/moonshotai/Kimi-K3, useful for readers trying to inspect or fetch the model outside Hugging Face tooling.

    • One technically relevant thread asks for a breakdown of active parameters between attention parameters vs MoE expert parameters, specifically because that split affects deployment strategies such as expert offloading or k-transformers-style partitioning. The commenter notes this would help determine how to split/offload experts efficiently rather than treating the active parameter count as a single undifferentiated number.

    • Another commenter interprets the HF Viewer architecture/weights evidence as suggesting distillation was not the key factor behind Kimi K3, implying the model’s capability may come more from its native architecture/training recipe than from teacher-model compression. They also express interest in seeing similarly detailed viewers for proprietary models like Fable 5 and GPT 5.6 for architectural comparison.

2. Open-Weight AI Policy Fight

  • Jensen Huang: During the Hugging Face incident, closed AI blocked essential forensics. An open-weight frontier model helped contain the intrusion. That’s why we created the Open Secure AI Alliance. (Activity: 1987): The image is a screenshot of Jensen Huang claiming that, during a Hugging Face security incident, closed AI systems blocked essential forensic analysis, while an open-weight frontier model helped contain the intrusion—used as justification for creating the Open Secure AI Alliance. The quoted NVIDIA announcement frames the alliance as a security-focused coalition involving companies such as Adobe, Cisco, Cloudflare, Hugging Face, IBM, Microsoft, NVIDIA, Red Hat, Salesforce, SAP, ServiceNow, Snowflake, and SpaceX, intended to support both open and closed frontier AI for cyber defense. Commenters were skeptical of the “open” framing, pointing out the irony of companies like Adobe, Cisco, and Palantir being presented as champions of openness, and noting the absence of major open-source model creators.

  • Anthropic is calling for a ban on open-weights models by proposing mandatory requirements they will probably never be able to meet (Activity: 1828): The image is a highlighted excerpt of Anthropic’s policy position on open-weights AI models, emphasizing the tension between Anthropic saying it has “never advocated for a ban” and proposing mandatory safety requirements for sufficiently capable open-weight systems. The technical significance is regulatory: the post argues that requirements such as safety testing, guardrail robustness, and misuse prevention may be infeasible for open-weights models, effectively functioning as a de facto ban if models cannot realistically comply. Commenters are skeptical of Anthropic’s framing, arguing that if open-weight models are unsafe because guardrails can be removed or models can be distilled, then the same logic could apply to closed frontier models like Anthropic’s own. Others question whether Anthropic’s models would pass the proposed mandatory safety tests themselves.

    • Commenters focused on a technical consistency issue in Anthropic’s proposed open-weights restrictions: if model distillation from frontier closed models is a major pathway to creating unsafe open-weight systems, then the same risk model would imply restrictions on Anthropic’s own API-accessible models, not just open-weight releases. The argument is that preventing distillation may be comparably hard to enforcing durable guardrails on open weights, so a policy framed around downstream capability leakage should apply to closed models as well.

    • Another substantive concern was whether Anthropic’s own models could satisfy the proposed mandatory safety evaluations. The implied technical critique is that if the required tests are stringent enough to justify banning or restricting open-weight models, they should also be benchmarked transparently against closed frontier systems to avoid asymmetric compliance burdens.

  • Our position on open-weights models (Activity: 1280): Anthropic/Dario Amodei argues in “Anthropic’s position on open-weights models” that it does not support categorical bans on open-weight releases, including Chinese models, and frames lower-risk open weights as public goods. The technical policy line is instead to restrict frontier capability transfer via advanced chips and “industrial-scale distillation operations,” while requiring rigorous pre-release evaluations for sufficiently capable open or closed models across cyber, bio, and alignment risk domains. Commenters were skeptical of Anthropic’s geopolitical framing, especially the claim that China cannot surpass U.S. frontier models without U.S. chips under scaling laws, noting that U.S. chip manufacturing is also heavily offshore. Others viewed the anti-distillation stance as hypocritical given the cited 1.5B Anthropic settlement over allegedly pirated books used to train Claude.

    • Commenters challenged the article’s claim that China cannot build more powerful models than the US without US chips due to scaling laws, arguing that “domestic production capacity” is not straightforward because the US itself relies heavily on offshore semiconductor manufacturing. The technically relevant dispute is whether frontier-model capability is primarily constrained by access to advanced accelerators, domestic fabrication capacity, or broader supply-chain access.

    • A technically substantive thread focused on industrial-scale distillation, with commenters noting the article’s concern that distillation could move Chinese frontier models to “within a few months” of US models. One commenter contrasted this with the claim that Kimi K3 is “like a month behind” Fable, questioning how much practical lead closed frontier labs can maintain if strong teacher models are widely queryable.

    • One commenter argued that safety restrictions in closed commercial LLMs can obstruct defensive cybersecurity work, citing a claimed incident where Hugging Face allegedly had to use a self-hosted open-weight GLM 5.2 model to respond to an attack because safeguards in commercial models interfered with analysis. The broader technical point was that open-weight models may be operationally important for incident response, malware analysis, and other security workflows where refusals or restricted outputs reduce utility.

  • OpenAI management decided earlier today not to join the “Open Secure AI Alliance”, founded by Nvidia CEO Jensen Huang. The decision was shared internally and reportedly met with backlash from employees. (Activity: 889): ****OpenAI management reportedly decided not to join the “Open Secure AI Alliance”, an initiative described as founded by Nvidia CEO Jensen Huang, and communicated the decision internally earlier today. The post claims the move triggered employee backlash, but provides no technical specifics on the alliance’s governance, security model, licensing commitments, or OpenAI’s stated rationale. Top comments were non-technical and largely critical of OpenAI/Sam Altman, framing the decision as hypocritical given the company’s name and perceived stance on openness.

3. Local Inference Performance Breakthroughs

  • Nifer is insane. 700t/s with Qwen 3.6 35B (no thinking). Purpose build for RTX5090. Full 250k context too. (Activity: 436): A user reports running Neroued/ninfer, a Linux-oriented inference project purpose-built for RTX 5090, on Windows after custom building it, claiming Qwen 3.6 35B in no thinking mode reaches roughly 550–720 tok/s for a single instance with full 250k context—speeds they compare to Cerebras. The project currently targets only Qwen3.6 27B and 35B, and a linked author post reportedly shows 543 tok/s single-request performance for Qwen3.6-35B-A3B on one RTX GPU. Commenters question whether the speed preserves task quality, with one noting that the normal 35B was fast but failed many real-world coding/agent-worker tests. Another points readers to the author’s prior Reddit discussion for additional implementation/performance details.

    • Several commenters questioned whether Nifer’s reported 700 t/s throughput preserves task quality, especially for coding-agent workflows: one user said vanilla Qwen 3.6 35B was fast but “failed just about every real world test” when used for coding or worker-style automation. They asked for benchmark comparisons against vanilla Qwen 3.6 35B at the same quantization on the same GPU, since raw generation speed may not be meaningful if the model or runtime is trading off accuracy.

    • A commenter linked the author Neroued’s earlier technical post reporting 543 tok/s single-request performance for Qwen3-35B-A3B on one RTX 5090: https://www.reddit.com/r/LocalLLaMA/comments/1v1no8e/543_toks_singlerequest_qwen3635ba3b_on_one_rtx/. Another user contrasted the claimed 700 t/s with their own typical 220–250 t/s, suggesting the result may depend heavily on the custom Nifer build, model variant, quantization, context handling, or measurement methodology.

  • DeepSeek V4 Flash, up to 32 tok/s on AMD Ryzen AI MAX+ 395 (Activity: 365): The image is a stylized promotional render, not a technical diagram: it shows a “STRIX HALO” accelerator board with the DeepSeek whale branding and “Deepseek v4 Flash,” matching the post’s claim of running DeepSeek V4 Flash on an AMD Ryzen AI MAX+ 395 / Radeon 8060S with 128 GB unified memory. The technical substance is in the text/blog, which reports a 102.3 GB mixed ROCmFPX GGUF target plus 11.3 GB DSpark draft, achieving 25.31 tok/s autoregressive decode and up to 32.0 tok/s speculative decode at 8,192 context, with sparse prefill around 245–255 tok/s; image link: i.redd.it/e67btq9fezfh1.png. Comments questioned the practical limit of only 8k context on a 128 GB machine and asked for “fully loaded” performance; another asked how coding quality compares to Qwen, while one commenter perceived the promotional image/post tone as possibly advertising.

    • A commenter questioned the practicality of the reported DeepSeek V4 Flash run with only 8k context, asking what context length can realistically fit in 128GB RAM and how performance changes when the model is “fully loaded” with a larger KV cache.

    • There was interest in comparative coding performance, specifically asking how DeepSeek V4 Flash stacks up against Qwen 3.6 for coding workloads.

    • A technically substantive suggestion was to produce a re-quantized version with more KV-cache headroom, targeting 32K or 65K context because 8K was considered insufficient for meaningful agentic workflows; the commenter also mentioned possible acceleration via an antirez-style setup.

Less Technical AI Subreddit Recap

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. Open-Weights Model Race

Read more