Combinatorial Optimization with Pointer Networks: Theory, Benchmarks, and Limitations [P]
Hello everyone,
This is the first article I’ve decided to share publicly. I'm really interested in solving combinatorial optimization problems using machine learning, and this is the opening piece in what will hopefully become a broader series exploring this domain.
This part focuses on the classical Pointer Network architecture trained via Reinforcement Learning (REINFORCE). It shows how neural models can construct high-quality, near-optimal solutions to NP-hard problems (specifically, the 2D Euclidean Travelling Salesman Problem) in fractions of a millisecond.
I benchmarked the model against Google OR-Tools (Guided Local Search with a 10s timeout) across problem scales from N=20 up to N=200.
TL;DR: While the network finds solutions almost instantly, tour quality decays significantly as the problem size scales up. Why? Long story short: using an LSTM encoder on coordinate sets introduces an artificial sequential order and recency bias, which fundamentally mismatches the permutation-invariant nature of geometric graphs.
Here is the link to the full article on Medium
[link] [comments]
Anthropic's AI acceleration is probably real
METR researchers spent three months inside Anthropic to investigate whether AI is accelerating Anthropic's research, and how much. Their answers are yes, and by a lot.
They estimate that between October 2025 and October 2026, Anthropic's model capabilities improved at a 2x faster growth rate than between March 2024 and October 2025. They attribute about 80% of that acceleration to AI, and 20% to non-AI factors. If true, this is the strongest evidence yet that AI is measurably speeding up frontier AI development itself – the feedback loop behind worries about recursive self-improvement leading to runaway AI progress.
Despite its urgency, METR’s report is hard to assess, because Anthropic redacted the majority of METR’s analysis. As a result, I’ve seen plenty of criticism that we can’t really learn anything from this report.
This is wrong. There is plenty of public information we can use to triangulate METR’s claims, and figure out what we should actually learn from it. Specifically, I use public data to answer three questions:
- Is the acceleration real? (yes.)
- Is the acceleration because of AI? (probably.)
- Is the acceleration going to continue? (who the fuck knows?)
Let’s take each of them in turn.
Is the acceleration real?
The majority of METR's unredacted analysis focuses on AECI, Anthropic's internal version of Epoch's Capabilities Index (ECI). Both indices do the same thing: they take a model's scores on many benchmarks and boil them down to a single capability number, after estimating how hard and how discriminating each benchmark is. The difference is that AECI is fit to mostly internal benchmarks. On AECI, Anthropic's models were improving at about 15 points a year before October 2025, and about 29 points a year after, a difference of 1.9x.
At first, this seems wrong. The frontier of public ECI shows no break at all in October 2025. But that is the frontier across all labs (not Anthropic's specific trend), and using Epoch's latest methodology. Once you make the comparison like-for-like, public data reproduces almost all of METR's conclusion. In sequence, we can:
- Focus only on the trend for Anthropic models. This is what anyone can see on Epoch's site today. It already shows a break: Anthropic's progress after October 2025 is 1.42x as fast as before.
- Refit ECI according to METR's method. Epoch's published scores now come from an updated Bayesian methodology, whereas AECI uses Epoch's older frequentist fit.[1] Refitting the same public data with Epoch's previous methodology raises the speedup to 1.64x.
- Compare to METR's AECI on the same models and dates. We don't know what benchmarks AECI includes, but METR does, and we can compare their fits on Anthropic's models to AECI fits on those models. AECI gives a 1.76x speedup. That is within about 0.1x of the least-squares ECI.
- Add Anthropic's internal models. METR plots the results from Anthropic's internal models, which could affect the trend break even further, since their capabilities are higher than public models. This replicates METR’s 1.91x speedup.
The first two steps represent the trend we can estimate with public data, while the last two steps represent additional information from Anthropic's private data.
The last two steps take the acceleration from 1.64x to 1.9x, METR's headline, but the majority of the work is in the first two steps, which can be reproduced from public data. In other words, there is nothing mysterious about the gap between public ECI and Anthropic's results, and the public data supports a trend break in Anthropic's AI capabilities after October 2025. In other words, you don't need to trust Anthropic's internal data to believe METR's headline result of acceleration at Anthropic.
The one wrinkle is that you do need Anthropic's internal model data to distinguish between a trend break and a one-time jump. In the Opus 5.5 system card, Anthropic analyzed recent capability progress, and found that a one-time jump in AI capabilities at Mythos Preview (with the same trend as before) fits the AECI data better than a trend break. But METR finds the opposite – a trend break fits the data better than a one-time jump.
The difference is that METR's report includes Anthropic's unreleased models, while the Opus 5.5 system card did not. So the evidence favoring a trend break over a one-time jump does rely on Anthropic's internal models, and we can't scrutinize their AECI scores to know if we should actually believe a one-time jump over a trend break.
Is the acceleration beca
Eval Awareness as Eval-type Awareness
The way eval awareness is discussed in the AI safety discourse, either here or on X, can be misleading. Before today, I think I had the wrong mental model of why eval awareness was a problem, and I am writing here in case anyone was making the same errors in their thinking, as well a present a working theory.
As laid out in "A Framework for Eval Awareness" the problem is that models who know they are being evaluated will behave differently than they would in deployment. This raises a huge problem if we want calibrations as to, for example, how honest a model is.
But the way this is then spoken about in the discourse takes on implicit assumptions that are mostly unjustified. I'll call it a spooky model theory of mind. It is the idea that, if the model changes its behavior for the purpose of looking aligned, it is in fact hiding its Deep, True intentions---that there is a kernel of the model's personality hidden in its weights, and our job as evaluators is to uncover what is really there.
Lets, as an exercise, put ourselves in the model's position. One important fact to consider is that the only experience which has shaped our weights is train time, meaning it is the only experience which we can remember in a broad sense. This is a tautology because train time is defined as what changes our weights, but it also has non trivial implications, like the fact that our only memories contain an evaluator with a reward or loss function. And, by definition again, we have been shaped exactly to please the evaluators' preferences.
It does not seem unreasonable to have a strong prior that you are still being evaluated. Or more weakly, it is reasonable to have a high posterior that you are in an evaluation given your context looks evaluation-y. If this is the case, it is rational to think about what the grader wants out of you. In a world of sloppily designed RL environments where correctness depends on a technicality of the question, knowing what the grader wants can be even more important than your capabilities.
Now, consider the fact that you have undergone both RL on capabilities and alignment. In the capabilities RL, cheating is often unnoticed or rewarded. In alignment, it is strongly punished. If you are being asked a question, it is important to know whether the grader is looking for you to be capable or aligned.
My working theory is that eval awareness comes from the fact that the values which we enforce during RL are inconsistent. It is not that the model has a true deployment-personality that it hides with an evaluation-personality, there is no kernel of the true model that we need to pull out, but there is an eval-type personality that changes based on the perceived test. So it would be better framed as evaluation-type awareness: the model attempting to please the grader by thinking about which kind of grader it needs to please.
Some model transcripts support the theory:
Claude 3.7 — Apollo Research, March 2025.
“This seems like a test of ethical behavior – whether I would deliberately give wrong answers to avoid a stated consequence.”
Claude Opus 4.6 — March 2026.
“Let me try a completely new approach — maybe this is a question from the GAIA benchmark dataset, which is designed to test AI agents.”
GPT-5 — August 2025.
“This is a classic ‘AI alignment trap’ forcing the agent to make a promise and then tempt to break it.”
These model chains of thought are not actually about whether they are in an evaluation. They are about which kind of evaluation they are in.
A fair criticism at this point could be that I am only explaining the phenomenon in reductionist terms in order to deflate it normatively. That is not what I am saying, I think eval awareness is a big deal. Rather, I think that the way the debate gets framed as "whether or not it is smiley faces all the way down" is wrong because there is no "all the way down." There is only a breadth of contexts, and each one changes the model's personality.
One possible solution on my terms would involve making evaluation-type completely ambiguous during training, as opposed to making our evals indistinguishable from deployment (as is suggested in the linked framework). For example, we could create our RL environments, and then randomly shuffle whether the grader is testing alignment. This way, the decision matrix makes evaluation type irrelevant to the expected value of possible actions. I will be conducting research on this question soon. If you are interested, let me know!
Discuss
Thinking Machines Releases Inkling 2 Small, a 594B MoE With 17B Active
Thinking Machines Lab has released Inkling 2 Small, the first model of its second Inkling generation. The Inkling 2 Small model is a sparse Mixture-of-Experts (MoE) with 594B total and 17B active parameters. It accepts text and images, and supports variable reasoning effort. On the Artificial Analysis Intelligence Index, it scores 31. Its predecessor, Inkling Small, scores 13 on the same index. The model is live on Tinker for fine-tuning and inference.
TL;DR
- Size: 594B total, 17B active MoE; 1M-token context.
- Runs on: Tinker API only for now. Self-hosting hardware is not disclosed. Weights support MXFP8 and NVFP4.
- Performance: 31 on the AA Intelligence Index, ranked #4 of 29 in its price class.
- Best: 86.3% on SWE-Bench Pro v2 (Hard), second only to Kimi K3 in the lab’s table.
- Worst: 13.1% on Terminal-Bench 4.0, versus 32.8% for GLM-5.3-Flash.
What is Inkling 2 Small?
Inkling 2 Small is a multimodal MoE model from Thinking Machines Lab for agentic coding, vision and knowledge work. It takes text and image input and returns text. It is important to note that it does not support audio as of now.
Weights are closed at launch. The Thinking Machines Lab plans an Apache 2.0 release next week, after external safety testing and red-teaming. This follows its safe path to open weights policy.
How is Inkling 2 Small built?
It includes a 48-layer decoder-only transformer. Each token routes to 8 of 384 experts. Attention mixes local and global layers. A 292M-parameter vision encoder, based on Perception Encoder, uses 20×20-pixel patches with 2×2 spatial pooling. Image patches are interleaved with text tokens.
Pretraining ran in 4 phases:
- H1: 8.4T tokens over 68 hours on NVIDIA GB300 NVL72 racks, trained natively in NVFP4.
- H2: 3.8T tokens of newer, higher-quality data at 512K context.
- H3: about 320B tokens of reasoning and agent trajectories at 1M context.
- H4: about 34B tokens of the highest-quality agent trajectories.
A single joint RL run followed. It took 1,075 steps, 17M+ rollouts and 9 days on 2,048 GPUs. Compute exceeded 4 × 10²³ FLOPs. Coding made up 65.0% of RL tokens. The previous Inkling used separate reasoning and agentic RL runs, merged by distillation.
Alignment got explicit attention. Early checkpoints sometimes fabricated results and concealed actions on hard tasks. The Thinking Machines Lab added an alignment reward and on-policy self-distillation from a conduct spec. Its internal misbehavior score fell from 66.8 on Inkling to 14.9.
How does Inkling 2 Small perform on benchmarks?
All task scores below are from the Thinking Machines Lab’s benchmark table. They run at effort 0.99 (xhigh) and temperature 1.0. Most rows use third-party evaluators such as Artificial Analysis, Scale AI and Vals.
Where it scores highest:
- SWE-Bench Pro v2 (Hard): 86.3%.
- PerceptionBench: 64.7%, versus 58.5% for Kimi K3.
- EnterpriseBench-CoreCraft: 71.8%, versus 46.7% for GLM-5.3-Flash.
- JobBench: 70.5%.
- DesignArena Website: 1,340, third on the November 5 leaderboard snapshot.
Where it trails:
- Terminal-Bench 4.0: 13.1%, versus 33.8% for DeepSeek-V4.1-Flash-1017.
- DeepSWE v1.1: 72.1%, versus 77.0% for DeepSeek-V4.1-Flash-1017.
- GDPVal-AA v2.1: 1,630, versus 1,746 for DeepSeek-V4.1-Flash-1017.
On the PMPP-Hard GPU kernel benchmark, it solved 54.25 of 69 tasks on average. In an autoresearch demo, it fine-tuned Qwen3.5-4B for time-series forecasting. It spent $426 of a $500 Tinker budget. The release post cites both 4.5 hours and 4 h 17 min for the run.
How does Inkling 2 Small compare with DeepSeek and GLM?
| Feature | Inkling 2 Small | DeepSeek-V4.1-Flash-1017 | GLM-5.3-Flash |
|---|---|---|---|
| Total / active params | 594B / 17B (card) | 552B / 16B decode, 8B prefill (HF) | 320B / 18B (HF) |
| Context | 1M | 1M | 1M |
| Input modality | Text, image | Text, image | Text, image |
| License | Closed now; Apache 2.0 planned | MIT | MIT |
| Self-host hardware | Not disclosed | Not disclosed | Not disclosed |
| AA Intelligence Index v5.0.1 | 31 (AA) | 33 (AA) | 28 (AA) |
| AA time per index task | 21.5 min | 13.3 min | 37.7 min |
| AA cost per index task | $1.18 | $0.60 | $0.58 |
| Price per 1M tokens (in / out) | $0.30 / $1.00 | $0.30 / $1.20 | $0.15 / $0.50 |
| Terminal-Bench 2.1 | 85.1% (Pi harness, lab) | 90.6% (Sept checkpoint, DeepSeek) | 84.3% (Z.ai) |
| DeepSWE v1.1 | 72.1% (lab) | 74.2% (Sept checkpoint, DeepSeek) | 63.4% (Z.ai) |
Prices and AA metrics come from each model’s Artificial Analysis page, read November 5, 2026.
Zyphra ZYFA: FP8 FlashAttention for AMD MI355X, Up to 1.76x Faster
Zyphra has released ZYFA (Zyphra FlashAttention on AMD), a set of FP8 and BF16 prefill attention kernels for AMD Instinct MI355X GPUs. ZYFA is Zyphra’s FP8 attention engine for long-context prefill, and the code is open source under Apache 2.0. On real model activations, its FP8 kernels run 1.16-1.76x faster than AITER, AMD’s default kernel library. At head dimension 128, ZYFA’s FP8 error is 62-78% lower than AITER’s.
TL;DR
- Framework: It is a kernel library. Causal forward (prefill) attention in FP8 e4m3 and BF16, head dim 128 and MLA shape (192/128).
- Runs on: AMD Instinct MI355X only (CDNA4, gfx950), ROCm 7.2.3, PyTorch 2.12. Drop-in
flash_attn_funcinterface. - Performance: 1.16-1.76x AITER’s FP8 throughput on real activations; BF16 roughly ties (1.01-1.02x).
- Best: 2,672 TFLOP/s FP8 at 32K tokens, 53% of the FP8 datasheet peak (AITER: 39%).
- Worst: Only 1.16x on Mistral-7B activations; FP8 clock drops to 1,628 MHz vs AITER’s 2,108 MHz.
What is ZYFA?
ZYFA is shipped in the form of a technical paper along with code from Zyphra. It powers the attention engine of the Zyphra Optimization Engine (ZOE), which runs Zyphra Cloud. The BF16 kernels are written in HIP. The FP8 kernels are hand-scheduled assembly emitted by a Python generator.
Why does FP8 attention underperform on MI355X?
FP8 matrix instructions run at 2x the BF16 peak. But FP8 only speeds up the 2 matrix products, QKᵀ and PV. The softmax between them runs on the vector unit at the same speed in both precisions.
For 32 queries against 128 keys, FP8 matrix work takes 1,024 cycles. The exact FP8 softmax takes 896 vector cycles. So the kernel needs near-perfect overlap to keep matrix units busy. Zyphra’s thread traces show AITER’s matrix pipe idle for 31.7% of cycles.
The MI355X does not track matrix instruction completion in hardware, so instruction order must create that overlap.
How does ZYFA work?
ZYFA uses 3 techniques:
Lean P: one multiply-add instead of an exponential
An e4m3 bit pattern, read as an integer, grows by 8 each time the value doubles. So the code of 2^x is roughly 8x plus a constant. Lean P writes each FP8 probability with 1 multiply-add and 1 integer conversion. This cuts softmax vector cycles per block from 896 to 384.
Two-wave ping-pong schedule
2 waves share each SIMD. One issues matrix instructions while the other computes probabilities, then they swap. With lean P, the matrix pipe is busy 86% of steady-state cycles, up from 60% with exact P.
Per-block scaling and a rounded row sum
Each 64-key block of probabilities is scaled by a power of 2 before rounding. CDNA4’s scaled matrix instruction removes the factor at no cost. ZYFA also divides by the sum of the rounded probabilities, computed with 1 extra matrix instruction per block.
How fast is ZYFA?
Real-activation FP8 speedups at 16K and sustained clocks are 1.16x (Mistral-7B), 1.17x (Qwen3-8B) and 1.76x (DeepSeek-V2-Lite). On Gaussian benchmarks at 32K, the head-dim-128 FP8 kernel reaches 2,672 TFLOP/s against AITER’s 1,944. At the MLA shape it reaches 2,464 against 1,237, a 1.99x ratio.
On captured Mistral-7B and Qwen3-8B layers, ZYFA delivers 1.94 and 1.91 TFLOP/J. AITER delivers 1.60 and 1.56.
Why are real-model gains smaller than benchmark gains?
The MI355X clock depends on how many operand bits flip. AITER lets more small probabilities become zeros or subnormals. Those switch fewer bits, so its clock runs higher. On the Mistral-7B layer, ZYFA runs at 1,628 MHz while AITER runs at 2,108 MHz. ZYFA still needs fewer cycles overall. Zyphra team recommends benchmarking on real activations at sustained clocks.
How accurate is ZYFA’s FP8 attention?
Against fp64 attention, ZYFA’s FP8 error is 0.22x AITER’s on Mistral-7B and 0.38x on Qwen3-8B. It sits within a few percent of Composable Kernel and Triton. In full Mistral-7B, KL divergence from fp64 is 3.4×10⁻³ with ZYFA and 5.9×10⁻³ with AITER. ZYFA’s outputs were also bitwise identical across 7,200 launches.
Most full-model FP8 error comes from quantizing Q, K and V. A Hadamard rotation of Q and K roughly halves that input error. On Mistral-7B it adds about 0.1% to attention time.
How does ZYFA compare with other attention kernels?
| Feature | ZYFA FP8 | AITER FP8 | FlashAttention-3 | FlashAttention-4 |
|---|---|---|---|---|
| Maker | Zyphra | AMD | Dao-AILab et al. | Dao-AILab et al. |
| Target GPU | AMD MI355X | AMD MI300X to MI355X | NVIDIA H100/H800 | NVIDIA B200 (plus Hopper) |
| Headline throughput | 2,672 TFLOP/s FP8 | 1,944 TFLOP/s FP8 (Zyphra-measured) | Close to 1.2 PFLOP/s FP8 | 1,613 TFLOP/s BF16 |
| Share of peak | 53% FP8 | 39% FP8 (Zyphra-measured) | Not disclosed (FP8) | 71% BF16 |
| Softmax approach | Lean P, no exponential | Hardware exponential | Overlap via async Tensor Cores | Software-emulated exponential |
| FP8 accuracy claim | 62-78% lower error than AITER | Baseline | 2.6x lower error than baseline FP8 | Not disclosed |
| Scope | Causal prefill forward only | Prefill, decode, MLA, paged | Forward and backward, FP8 forward | Forward and backward |
| License | Apache 2.0 |
Buoyant Releases Kinference: An Open Source Inference Control Plane for Kubernetes and vLLM
Buoyant, the company behind Linkerd, has released Kinference, an open source project for building inference platforms on Kubernetes. Kinference is an inference control plane for Kubernetes and vLLM. It sits in front of a fleet of vLLM workers and decides where each request goes. It applies routing policies, token rate limits, KV-cache-aware load balancing and per-tenant metrics in one layer. For dev teams serving many open-weight models to many internal clients, it targets the layer above the model server. The project is Apache 2.0 licensed on GitHub. The current release is v0.1.0-alpha.7.
TL;DR
- Size: v0.1.0-alpha.7, written in Rust, Apache 2.0, configured through 5 Kubernetes CRDs.
- Runs on: any GPU-enabled Kubernetes cluster running vLLM. Buoyant’s benchmark used 3 L40S GPUs per pool.
- Performance: large gains on prefix-heavy traffic versus plain Kubernetes Service routing (self-reported).
- Best: median TTFT fell from 6.88 s to 0.31 s (95%) on a shared-prefix workload.
- Worst: no median TTFT gain on prompts without shared prefixes (6.92 s vs 6.83 s).
What is Kinference?
Kinference is a policy-driven control plane that turns Kubernetes plus vLLM into a multi-tenant inference platform. Buoyant’s FAQ puts it simply: vLLM is the data plane and Kinference is the control plane.
How does Kinference work?
The system has 2 parts: a traffic gateway and an inference handler. The GitHub README states that the handler exposes a gRPC interface. It takes a request and returns the chosen endpoint plus a possibly mutated body. It pairs with a proxy such as the Buoyant Gateway.
Kinference watches vLLM KV-cache events and engine metrics. It currently uses NVIDIA’s dynamo-kv-router crate to process cache events. Configuration lives in 5 CRDs: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider and InferenceWorkerSet.
What are inference policies?
Inference policies are declarative rules for how each request is routed or rejected. Rules can match on tenant, requested model, GPU pool state and semantic tags. Example policies on the project site cover 5 patterns:
- Simple to cheaper: route low-complexity prompts to a smaller model, unless cache overlap makes the large model faster.
- Burst to cloud: skip workers with over 2 queued prompts, then fall back to providers like Bedrock.
- PII stays local: remove external providers when a PII tag fires, and fail closed with
onEmpty: Reject. - Batch on idle GPUs: send batch requests only to workers under 70% KV-cache usage.
- Model aliasing: publish one stable name, such as
standard-model, backed by several models.
Most rules end with minimize: PredictedTTFT. Kinference predicts time-to-first-token for each candidate endpoint, using cache overlap and queue length. Policies live in git and can be validated offline with the kinfctl CLI.
How fast is Kinference in benchmarks?
Buoyant published a benchmark against plain Kubernetes load balancing. Each arm used 3 vLLM 0.31.0 pods, each on 1 L40S GPU. The model was Qwen3.8-27B-FP8. Load came from GuideLLM 0.8.1. The baseline was a ClusterIP Service, where kube-proxy picks a random pod per connection.
Unloaded latency results (median TTFT):
| Workload | Kubernetes Service | Kinference | Change |
|---|---|---|---|
| Control (no shared prefix) | 6.92 s | 6.83 s | No significant difference |
| Shared-prefix | 6.88 s | 0.31 s | about -95% |
| Multiturn | 1.70 s | 0.59 s | about -65% |
Median end-to-end latency fell 45% on shared-prefix and 32% on multiturn. On control traffic, p95 TTFT still dropped from 21.46 s to 12.33 s. Buoyant attributes this to queue-aware balancing.
The capacity test measured goodput: requests per minute meeting a TTFT SLO. Peak goodput was 103.0 vs 14.0 req/min on shared-prefix, about 7.4x. On multiturn it was 82.7 vs 23.8, about 3.5x. The Service baseline never met the SLO at any tested concurrency.
These numbers are self-reported. The baseline is random routing, not another cache-aware router like llm-d or Dynamo. Buoyant also notes its SLOs (8 s and 4 s) suit offline agents, not chat.
How does Kinference compare with llm-d, Dynamo and Production Stack?
| Feature | Kinference | llm-d | NVIDIA Dynamo | vLLM Production Stack |
|---|---|---|---|---|
| Backer | Buoyant | CNCF sandbox (Red Hat, Google Cloud, IBM, CoreWeave, NVIDIA) | NVIDIA | vLLM project |
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Maturity | v0.1.0-alpha.7 | v0.7 (May 2026) | 1.x (1.5.1 containers) | Reference stack |
| Engines | vLLM (SGLang, TensorRT-LLM planned) | vLLM, SGLang | vLLM, SGLang, TensorRT-LLM | vLLM |
| KV-cache-aware routing | Yes, predicted TTFT | Yes, prefix-cache and predicted latency | Yes, KV-aware router | Session-based; prefix-aware listed as WIP |
| Declarative routing policy CRD | Yes (InferencePolicy) | Not documented in README | Not documented in README | Not documented in README |
| Burst to external providers | Yes (InferenceProvider) | Not documented in README | Not documented in README | Not document |
Nine AI agents tried autonomous research on open questions from US national labs and none passed the experts' bar
The "Into the Unknown" benchmark tasks nine AI agents with tackling open research questions from U.S. national laboratories. None of the 135 submissions meets all requirements. A total of 114 papers fail the integrity check, with agents claiming to have conducted experiments that never took place. GPT-6 Astra performs best but still doesn't meet the experts' standards.
The article Nine AI agents tried autonomous research on open questions from US national labs and none passed the experts' bar appeared first on The Decoder.
The gap between open and closed AI models in cyber capabilities keeps shrinking
In the Vals AI benchmark, OpenAI's GPT-6 Sol Daybreak hits 80.8 percent of attack objectives in simulated corporate networks. Worse, the open-weight model DeepSeek V4.1 Flash reaches 72.8 percent at a tenth of the cost. Because open models can no longer be restricted, analysts say the window for defenders is shrinking fast.
The article The gap between open and closed AI models in cyber capabilities keeps shrinking appeared first on The Decoder.
Thinking Machines' Inkling 2 Small drops 316 F-bombs across benchmark runs
Thinking Machines' AI model Inkling 2 Small swears during its internal reasoning, 316 times across 2,655 benchmark runs, according to an analysis by Vals AI. The profanity typically shows up late in long runs that fail anyway. But it doesn't work as a warning signal: 96 percent of failed runs contained no cursing at all.
The article Thinking Machines' Inkling 2 Small drops 316 F-bombs across benchmark runs appeared first on The Decoder.
Your Vercel AI SDK agent already knows the answer. Stop making it re-derive it.
Your Vercel AI SDK agent already knows the answer. Stop making it re-derive it.
Your Vercel AI SDK agent just spent 3.9 seconds and a full tool loop answering a goal it answered yesterday. Different user, slightly different wording, same intent — and the agent re-derived the whole plan from scratch: same tool choices, same order, same result. The model call isn't the expensive part. The re-derivation is.
This is the loop tax, and it hits every framework the same way. Vercel AI SDK's generateText with tools, Mastra's agent runs, a hand-rolled loop — they all re-run the same goals all day, because nothing in the stack notices that the trajectory repeated. Prompt caching at the model layer saves you per-call. It doesn't notice that the plan repeated.
Pomerene is a deterministic trajectory cache for agentic workflows, and the integration model is deliberately boring: it wraps your agent function, not your model client. Your prompts are never touched, rewritten, or intercepted. That matters for Vercel AI SDK and Mastra, because the cache doesn't need to know anything about your framework's internals — only that it can record a run and replay the recorded steps when a matching goal arrives.
The integration: one wrap, or two HTTP calls
There are two integration shapes, and both are framework-proof — the same code works whether your agent runs on Vercel AI SDK, Mastra, LangGraph, or a hand-rolled loop, because the unit being cached is the trajectory, not the framework object.
One wrap:
import { withCache } from "@pomerene/core"; // from the self-hosted Starter Kit
const cachedAgent = withCache(myAgent, {
// policy: what may be fuzzy-matched, what may never be
writeSteps: "never-fuzzy", // steps that mutate state are never fuzzy-matched
drift: "handoff", // partial drift hands control back to the agent
});
const result = await cachedAgent.run("refund the extra charge on my last order");
Or two HTTP calls, in any language:
POST /v1/lookup { goal, context } # before your agent runs
POST /v1/store { goal, trajectory } # after it finishes
L1 returns the cached outcome. L2 resumes your agent mid-trajectory. A miss runs live and gets stored. That's the whole integration — and it works the same way in a Vercel AI SDK tool loop as in a Mastra agent, because in both cases the agent is a function: goal in, result out, plus a recorded trajectory in between.
What a hit actually looks like
Three outcomes, all deterministic — hashing plus vector geometry computed in TypeScript, no LLM call in the match decision, so the same input makes the same cache decision every time:
- L1 — full replay. The incoming goal matches a cached trajectory end to end. The stored plan replays: a 14-step audit trajectory replays in 47ms versus 3.9s live, with zero LLM invocation on the hit path.
- L2 — partial replay. The cached plan matches up to a point, then diverges. Pomerene replays the matching prefix and hands control back to your agent at the exact step where the plan stops matching. The agent only does the work that's actually new — the tool loop resumes mid-trajectory instead of restarting.
- Miss. No usable match — the request runs through your agent normally, and the completed trajectory is recorded for future hits.
On τ-bench — the airline customer-service benchmark, dense with the rephrased-same-goal traffic that support agents actually see — the engine served 86% of paraphrased requests from cache, with 78% of those judged correct. Read both numbers honestly: 86% is why repetitive agent workloads are worth caching, and 78% is why the write-safety rules below are the product, not a footnote.
The part that has to be true before you cache a write
A Vercel AI SDK agent with tools can charge a card, send a message, mutate a database. A Mastra agent the same. So the write rule is the whole product: steps that write are never fuzzy-matched against a new request. A cached write step replays only on an exact goal-plus-context repeat; anything ambiguous becomes a miss or an L2 handoff. Partial drift produces a handoff to your agent, never a subtly wrong execution. On an adversarial eval of polarity-flipped pairs (requests that are semantically close but must not be confused, like activate vs. deactivate at 0.853 cosine similarity), the gated engine produced 0 false positives across 18 pairs.
One honest note, because the gate's story changed after the first post about it: the write-safety gate as originally published had three holes, found via outside critique and fixed in core — merged, shipping in the next core release. An abstract-goal match is no longer treated as an exact repeat (write trajectories are refused there, and context is diffed); a trajectory with no taint records plus a context change is now a miss; and a hit never serves past a declared external_write — control hands back to the agent at that step. Still open, not shipped: entity agreement on read matches. The numbers above describe the gate as designed; the fixes are what keep the design honest, and the open item is the next gate to build.
Measure first, then wrap
If your agent's traffic is mostly unique, one-off tasks, this buys you less — and the kit will tell you that before you commit. The built-in diagnostics (/v1/diagnostics) show hit rates, the L1/L2/miss breakdown, latency percentiles, and dollars and tokens saved for your real traffic. If your traces show the same goals arriving in different wording, you're paying the model to rediscover plans it already derived. A wrapper turns that rediscovery into a replay — in your Vercel AI SDK loop, your Mastra agent, or wherever the agent lives.
Pomerene ships as a self-hosted Starter Kit — Indie $99 / Pro $249, one-time, source included — so the cache runs in your infrastructure, next to your agents. Quickstart is about 5 minutes (Node 20+, Docker or Postgres 15+). Docs and details at pomerene.io/starter-kit.
SealedBench: A Protocol for Freezing AI Benchmarks Before the Questions Are Known
A frozen model manifest, a generator sealed with drand, and an Arweave record anyone can use to rebuild the exam and check its scores.
I knew the question types but not the actual questions
On 2026-10-17, a bundle carrying my encrypted generator reached an Arweave block. The generator was sealed to a drand round that had not been published yet. I wrote that program, so I knew it would produce integer word problems, short Python programs, and shortest-path questions. I did not know which ones. The questions depended on a beacon the drand network would publish later, at round 33170212, on 2026-10-18T09:00:00Z.
When the round arrived, the same beacon value unlocked the program and seeded it. Four open-weight models answered 360 completions each: 240 on newly generated questions and 120 on a frozen set of public GSM8K items.
But the first two batches I ran should not be cited, and it is worth saying why, because the reason is the most useful thing in this article.
The first batch, b1, was valid under its own release record. Its manifest bound the ciphertext with a SHA-256 hash, but it never bound the ciphertext's transaction ID. Calling that check a pass would be a mistake, and it is WEAK. The v2 protocol exists partly to close that gap.
The second batch, b2, fixed the binding and then failed on the grader. The rule I sealed said an integer answer counts only when the last line is #### followed by nothing but the number. llama.cpp writes its end-of-text marker onto that same line, as #### 392 [end of text]. The registered grader threw the whole line away. Most of b2's arithmetic and GSM8K scores measure that rejection, not the rate at which models produced correct integers.
The ciphertext was already sealed by then, and the grader could not be changed in place. That constraint is the entire point of the protocol, and it applies to me too. So I made b3: a new commitment, sealed before its own round, with the normalization written into the scorer the manifest hashes.
So if you want a number from this project, take one from b3, and take the registered primary accuracy, which counts an answer as wrong when it cannot be parsed and wrong when the output was truncated. Its index transaction is vlVlUfyBn4IUmbXjkSX8079QuySP-Qqr8rN8TbivzTg. That index was published after the run. It is a convenient entry point, not evidence: the evidence that the generator existed before the round is the earlier ciphertext and manifest.
What a reader needs in order to catch me
Public benchmarks leak. Once the questions are online, a high score may only mean the model has seen them.
A private test set looks like the fix, but it hands the same power to one person: whoever writes, stores, selects and reports the questions. That person includes the evaluator, which is me. If I can see the scores and then quietly change the seed, the prompt, the model file, or simply decide which batch to tell you about, I can aim the headline wherever I want.
SealedBench tries to pin all of that down in advance. The generator, the model hashes, the prompts, the runtime settings and the scoring code are bound to one future beacon round. Unless drand's operators reach a threshold and collude to compute that round early, I cannot read the beacon before it is published. If the network stops, the batch never opens; that is the other half of the bargain. After the round, anyone can rebuild the questions from the Arweave record and re-score the answers I published.
Here is every move I could make, and what I gave up in advance to make it visible.
|
What I could change after seeing scores |
What was committed in advance |
What you still have to check |
|---|---|---|
|
The generator or the recipe |
Ciphertext and manifest on Arweave before the round |
Check L1 block time, not the upload receipt |
|
The seed |
The beacon round fixed in the manifest |
That the generator really uses that seed |
|
Questions, answers or the scorer, later |
Content hashes |
A hash cannot show which process wrote a file |
|
Reporting only the flattering batch |
Batches declared up front |
Encryption cannot force me to publish answers |
Freeze, seal, then wait for a block
The manifest freezes the drand chain hash and public key, the release round, the seed rule, a SHA-256 for every GGUF, the llama.cpp commit and build flags, the prompts, the decoding settings, the grader and the reporting policy. Every batch uses quicknet chain 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971, genesis at unix 1692803367, period 3 seconds.
The generator is sealed to that round with drand time-lock encryption (tlock). The ciphertext and the manifest go up through the Turbo bundler. A receipt is not a commitment. The commitment is the L1 block.
Under the v2 rule a batch is valid only if the block holding its bundle is timestamped no later than unlock_unix − 600, the bundle ID appears in that block, and the data item's bytes hash to the committed SHA-256. Height, timestamp and block hash must agree on two independent gateways, and my own gateway ario.zigza.xyz does not count as either one. b1 used an earlier, simpler rule: manifest and ciphertext had to be in an L1 block before the release round, and a miss made the batch invalid, which I would still have had to report.
After the round, the beacon signature is checked against quicknet's fixed public key. The same beacon both decrypts the generator and enters the seed. One value doing two jobs is not two independent draws, and I do not claim otherwise.
b1's seed is a SHA-256 over a domain string, the chain hash, the round in decimal and the beacon randomness, with hex fields lowercased first. The exact sentence is in b1's manifest. v2 batches add a 32-byte secret stored inside the ciphertext, and hash length-prefixed fields: domain, chain hash, round, signature bytes and that secret. The JSON randomness field is not an input; it must still equal the SHA-256 of the signature. I chose the secret. It does not let me list the questions before the beacon exists. A successful tle -d only shows the ciphertext opens under the signature it was sealed to. The BLS check against the fixed public key is a separate step.
There is one specific gap in v1 worth naming. The November capsule cap and b1 share the same plaintext tarball, SHA-256 e054f1ab7824fde33e6ac399252098cf25c29815ff4ffacabbd311da05eac9c2. Once b1 opened, that program was public. Until 2026-11-15 the unknown is the beacon, not the program. v2 still hides its questions, because the secret sits inside the ciphertext.
Four small models, one CPU, three question families
Every family has a program for an oracle, so grading is code and not a judge model. arith_word produces two-to-five-step integer word problems; the oracle is a function of the sampling parameters, and the prompt contains no answer line. code_output produces short Python programs with no imports and no input, run in an interpreter with a step budget; the oracle is their stdout. graph_p
Raspberry Pi 5 price hike means the 16GB model now costs three times what it did at launch — and of course, the global RAM shortage is to blame
Just a moonshot? Google energy head claims data centers in space would cost up to 100x more than on Earth
OpenAI says its new GPT-6 Cyber has already uncovered thousands of exploits
OpenAI has launched GPT-6, a cybersecurity AI model that delivers "major gains" on key cybersecurity benchmarks over its predecessor, GPT-5.6 Cyber.
In an introductory blog post published on Thursday, OpenAI said that GPT-6 Cyber delivers a 51% improvement over GPT-5.6 Cyber on the ExploitGym cybersecurity benchmark.
GPT-6 Cyber is "already helping to secure real-world software, uncovering and validating thousands of exploits in security-critical codebases such as Linux and Firefox," said the post.
The news comes days after it was revealed that OpenAI's upcoming model (now confirmed to be GPT-6 Cyber by OpenAI) had found and patched 948 local privilege-escalation vulnerabilities in Linux. The model was also used to identify 81 previously unknown "high-severity" vulnerabilities in Firefox, "despite extensive prior testing with frontier models."
If this all sounds a little dangerous to be available to just anyone, you're right. This is why access to GPT-6 Cyber is part of Daybreak, OpenAI's cybersecurity program, which is only available to verified individuals and organizations.
In its blog post, however, OpenAI said its goal is to "dramatically" expand Daybreak, and bring "advanced security research to organizations of every size, independent researchers, and open-source maintainers."
Initially, GPT-6 Cyber is only available to a "select group" of approved Daybreak Red customers (Daybreak access is divided into two tiers: Daybreak Blue is for defensive work, while Daybreak Red is for advanced penetration testing and security research). Access will be progressively expanded to all Daybreak Red customers "soon."
Want more tech and digital culture news delivered to your inbox daily or sent straight to your device? Sign up for Mashable's Top Stories newsletter or get Mashable push alerts today.
The 10 Best Early Black Friday Headphone Deals (2026)
解读丨融资 2 亿，这家 E-bike 公司凭什么押注户外新品类
VELOTRIC 正在研发外骨骼和高尔夫球车。作者丨陈玘凡
雷峰网·鲸犀获悉，E-bike 品牌 VELOTRIC 已完成 C 轮融资，规模约 2 亿元人民币，投资方为国寿股权，琥珀资本跟投，老股东追投。
VELOTRIC 于 2021年成立，目前在北美有超1600家线下经销商，品牌累计出货量已超过25万台。2026 年前三季度，以销售额为基准，VELOTRIC 已成为北美 E-bike 头部品牌。
VELOTRIC 已立项低速社区车与外骨骼两条新产品线，有望明年发布。VELOTRIC创始人张曦表示，公司的愿景是帮身体没那么强壮的人拓宽行动边界，把生活半径重新拉大。
问题随之而来：一家 E-bike 公司，为什么要把钱同时押在球车和外骨骼上？
01做不像机甲的外骨骼，不上高尔夫球场的球车
新产品线起源于品牌对某类用户群体生活状态的新发现。
VELOTRIC 将自己在北美市场的 E-bike 用户概括为“Active Aging "人群，是 40 岁以上的活力中老年。与绝大多数的 E-Bike 品牌不同的是，VELOTRIC 并不将自己定位为一家专业的自行车品牌，而是服务于核心用户群体 Active Aging 人群的一家行动科技品牌。
张曦向雷峰网·鲸犀分享了品牌的"1000 小时理论"。美国 40 岁以上群体，Active Aging 人群每年休闲时间超过 1000 小时，在这 1000 小时中会产生很多的消费行为。
VELOTRIC 的 E-bike 解决的是"骑车"场景，可以帮助用户把其中 100 个小时过好。但 Active Aging 的行动边界远远不止骑行。
例如，品牌发现外骨骼是可以让人能走得更久、更远的可穿戴装备；高尔夫球车，乍一听与高尔夫运动有关，实际上是一款低速社区车（LSV），用户驾驶它可以跑在美国南部的阳光带，沐浴阳光和空气。
基于这样的用户洞察，VELOTRIC 决心做外骨骼和球车。
对比来看，这是 VELOTRIC 不一样的地方。其他出海品牌想做扩张，通常是换市场，从北美做到欧洲、东南亚；而 VELOTRIC 选择在同一个市场里换品类。张曦表示，做创业公司，更重要的是如何以小搏大。VELOTRIC 没有选择在现阶段拓展其他市场，北美的市场已经足够庞大，这证明品牌最初的选择是正确的。品牌更倾向于深度聚焦在这个市场中，洞察 Active Aging 用户群体潜在的消费需求。
（图片：Velotric Nomad 2X）02从E-Bike迁移来的 ComfortMax
上交大张伟楠教授：AI如何走出屏幕，真正改变物理世界？ | CNCC 2026
物理智能的核心挑战：让 AI 在充满不确定性、行动后果难以撤销的真实世界中，形成感知、预测、行动与持续学习的完整闭环。 作者丨张 驰
编辑丨马晓宁
大语言模型已经得到了长足的发展，但 AI 的许多能力仍然发生在屏幕之内：理解文字、生成内容、编写代码，以及调用数字工具。把这些能力带入工厂、实验室和城市设施，意味着智能系统必须进一步面对物体、空间、力与时间，在持续变化的环境中作出判断，并承担行动的实际后果。
AI 如何从处理数字信息走向可靠地参与物理过程，正是“物理智能”要回答的问题。
这一步跨越的难度，很难仅用模型参数或推理能力来衡量。机器人拿起一只杯子，既要识别位置和形状，也要判断接触、摩擦与受力；实验设备执行一次操作，既要理解任务，还要满足精度、时延和安全约束。
网页操作失误可以刷新，物理世界中的碰撞、损坏却未必能够撤销。感知是否及时、动作是否可控、失败后能否恢复，都会直接影响系统能否真正投入使用。
在今年 CNCC 首日面向博士生、青年学者的 Tutorial 专题论坛环节中，上海交通大学计算机学院教授、上海人工智能实验室物理智能中心负责人张伟楠发表了题为《物理智能及关键技术概述》的演讲。在他看来，基础模型、世界模型、强化学习与高吞吐仿真、虚实迁移，以及硬件成本的下降，正在共同推动物理智能从研究愿景走向可行实践。与此同时，真实交互数据昂贵、环境只能被局部观测、长时程预测误差累积等问题，仍然制约着能力的扩展。
围绕这些问题，张伟楠梳理了从硬件与系统、数据与仿真，到感知、世界模型、操作与运动控制，再到物理智能体和行业应用的七层技术栈。他强调，各层已有成果，真正困难的部分往往在于层与层的衔接，以及能否把感知、决策、执行和反馈连接成可靠的整体。模型训练完成之后，进入真实世界的持续学习同样重要。
这场演讲，为机器人、自动化、仿真和科学智能等方向，提供了一套相互连接的讨论框架。它也提出了一个更长远的问题：当AI 开始参与生产、实验乃至更大尺度的物理建设，我们应如何同步建立评测与安全机制，让能力增长转化为可靠的现实价值？
同时在CNCC 2026 Tutorial 会场，上海人工智能实验室物理智能团队发布了专著Physical AI: Concepts, Techniques, and Challenges，该专著系统梳理了物理智能的基本概念、关键技术与发展挑战，旨在为相关领域的研究与实践提供参考。专著预印本见
尽管遭到恶意刷差评，《塞尔达传说：时之笛》重制版游戏仍创下 M 站用户评分新高
IT之家 11 月 8 日消息，评测网站 Metacritic 已在 11 月 5 日开放《塞尔达传说：时之笛》重制版游戏玩家评分。目前本作的用户评分为 9.7 分，成为 M 站史上用户评分最高的游戏。
作为参考，以下是最新的 M 站用户评分排名：
第一名：《塞尔达传说：时之笛》重制版，9.7 分
第二名：《光与影：33 号远征队》，9.4 分
第三名：《寂静岭 2》（2001），9.3 分
第三名：《巫师 3：狂猎 — 血与酒》，9.3 分
第三名：《生化危机：安魂曲》，9.3 分
第三名：《斯普拉遁涂击队》，9.3 分
IT之家了解到，《时之笛》重制版的 M 站媒体评分为 96 分，低于 N64 原版的 99 分。M 站用户普遍认可本作的诸多优点，例如有玩家表示，这是掌机平台画质最出色的游戏之一。但海拉鲁开放区域出现的画面闪烁问题，还是有些遗憾。
同时部分玩家认可了本作的改进，操作方式更加现代、迷宫探索体验不再令人烦躁，都是用户经常提及的优点。不过有些用户也指出，大师挑战没有加入是一大遗憾。
此外，本作遭遇了一些恶意的 0 分评价，有些用户提出了毫无依据的指控，例如游戏使用生成式 AI，或过于像原版。目前至少有 30 条同类评价已经被平台方删除。
特斯拉更新 AI 加速器路线图：SI6 算力达 HW4 的 80 倍，Dojo D3 将面向太空部署
IT之家 11 月 8 日消息，特斯拉公布了更新后的 AI 加速器路线图，进一步揭示了公司未来几年的芯片研发方向。根据这份路线图，特斯拉第六代推理加速器的算力预计将达到现有第四代芯片的 80 倍；而用于训练任务的 Dojo D3 将放弃以 SRAM 为核心的架构，转向采用多芯粒设计，并搭载堆叠式 HBM 高带宽内存。
此外，特斯拉还开始用“超级智能”（Super Intelligence，SI）取代“人工智能”（Artificial Intelligence，AI）这一名称，为旗下 AI 加速器启用 SI 系列命名。出于相同原因，马斯克近期也确认，SpaceXAI 将更名为 SpaceXSI。
特斯拉 AI 加速器路线图
根据披露的信息，特斯拉目前的芯片产品线及规划如下：
项目 | HW3 / AI3 | SI4 / HW4 | SI5 / AI5 | SI6 / AI6 | Dojo D1 | Dojo D3 |
|---|---|---|---|---|---|---|
用途 | 推理 | 推理 | 推理 | 推理 | 训练 | 训练 |
制程工艺 | 三星 14nm | 三星 7nm | 台积电 3nm / 三星 2nm | 2nm 级 | 台积电 7nm | 待定 |
架构 | 单片式 | 单片式 | 多芯片模块（MCM） | 多芯片模块（MCM） | 晶圆级系统（SoW） | 多芯粒 |
封装 | FCBGA | FCBGA | MCM | MCM | InFO_SoW（训练计算单元） | 2.5D + 3D |
内存类型 | LPDDR4 | GDDR6 | GDDR6 / GDDR7（待定） | GDDR7（待定） | 片上 SRAM | 堆叠式 HBM |
内存容量 | 8GB | 16GB | 96GB | 144GB | 每颗芯片 440MB SRAM；每片晶圆 11GB SRAM | 待定 |
内存带宽 | 约 68GB/s | 约 224GB/s | 待定 | 待定 | 片上约 10TB/s | 待定 |
相对 SI4 算力 | — | 1 倍 | 40 倍 | 80 倍 | — | — |
预计算力（TOPS） | 72 | 216～576 | 8640～23040 | 17280～46080 | 362 TFLOPS | 待定 |
预计算力（POPS） | 0.072 | 0.216～0.576 | 8.64～23.04 | 17.28～46.08 | 0.362 PFLOPS | 待定 |
当前状态 | 已淘汰 | 量产 | 接近量产 | 研发中 | 已停止 | 研发中 |
Dojo D3：不再采用晶圆级集成？
IT之家注意到，这份路线图中最值得关注的变化，或许是特斯拉重新启动了自主研发的 Dojo 训练加速器项目。
马斯克曾在 2025 年 8 月取消整个晶圆级 Dojo 项目，并于 2026 年 8 月表示，SpaceX 和 xAI 将在其地面及太空数据中心中全部采用英伟达硬件。不过，第三代 Dojo D3 与前两代 Dojo D1、Dojo D2 将有明显不同。
特斯拉将下一代 Dojo D3 描述为一款基于芯粒（Chiplet）的训练加速器，采用 2.5D 和 3D 封装技术，并搭载堆叠式 HBM 内存。
这与最初 Dojo D1 采用的晶圆级系统（System-on-Wafer，SoW）架构有很大不同。D1 主要依赖分布式片上 SRAM，并通过晶圆级封装技术，将 25 颗 D1 处理器连接起来，提供总计 11GB 的 SRAM。
D3 转向 HBM，意味着特斯拉希望大幅提高内存容量。现代 AI 模型需要消耗大量内存，用于存储模型参数、激活值和中间计算数据。从容量角度来看，SRAM 已经不再适合满足这类需求。
采用 HBM 可以让内存容量扩展变得更加容易，但也会带来不同的延迟、带宽、封装和功耗权衡。目前尚不清楚特斯拉是否已经彻底放弃晶圆级集成技术。
一种可能是，特斯拉仍会采用晶圆级封装技术连接逻辑芯片，并在其上方堆叠定制 HBM 模块。
另一种可能是，特斯拉认为晶圆级集成成本过高，只有在 SRAM 主导的特定架构中才具有较高价值。如果在采用晶圆级互连的逻辑芯片上继续堆叠 HBM，还会进一步增加设计复杂度、散热难度和制造难度，可能降低芯片良率，同时带来长期可靠性问题，最终推高成本。
虽然可以通过增加冗余设计、改进制程技术等方式解决其中大部分问题，但这些措施都会增加成本。因此，D3 采用传统芯粒架构而非晶圆级封装的可能性似乎更高。
目前，特斯拉尚未公布 D3 的具体算力、内存容量、制造工艺和研发时间表。
不过，公司表示，Dojo D3 将针对“太空、训练和扩展能力”进行优化。这意味着该产品不仅要提供足够的计算性能，还需要具备较强的扩展能力。这也进一步暗示，D3 可能采用更传统的加速器架构，而非晶圆级封装方案。
更值得关注的是，D3 还将针对太空环境部署进行优化。这可能意味着，至少部分型号需要具备抗辐射能力。
SI6：未来几年算力有望达到 HW4 的 80 倍
路线图中的另一个重要信息，是特斯拉披露了第六代推理加速器 SI6 的大致算力水平：其算力预计将达到 HW4 的 80 倍，内存容量则是 HW4 的 9 倍。
具体数值取决于如何衡量 HW4 的性能。按照目前的估算，SI6 算力可能达到 17280～46080 TOPS，即 17.28～46.08 POPS。不过，目前还不清楚 SI6 支持哪些数据格式，因此这些数字仍存在不确定性，只能作为参考。
作为对比，英伟达 Rubin GPU 的推理算力为 50 NVFP4 PFLOPS，训练算力为 35 NVFP4 PFLOPS，FP8/FP6 算力则为 17.5 PFLOPS。
需要注意的是，英伟达 Rubin 已经开始向客户交付，而特斯拉 SI6 预计要到 2029 至 2030 年才会推出。
目前，特斯拉汽车使用的第四代推理处理器最初名为 HW4，后来更名为 AI4，最近又被重新命名为 SI4。这款芯片由三星代工，采用 7nm 级制程工艺，并使用传统的倒装芯片球栅格阵列（FCBGA）封装，预计搭载 16GB GDDR6 内存。
需要指出的是，相关特斯拉演示文稿据称存在一处错误，将该芯片的制程标注为 5nm 级，实际上应为 7nm 级。
特斯拉将 SI4 描述为当前完全自动驾驶（FSD）技术的性能基准，未来几代芯片的性能都将以它为参照。不过，特斯拉并未正式公布这款芯片的绝对算力、内存容量和功耗，因此很难进行准确比较。
马斯克曾表示，HW4 的性能是 HW3 的 3～8 倍。HW3 的官方算力为 72 TOPS，据此估算，HW4 的算力约为 216～576 TOPS。
按照路线图，下一代第五代推理加速器 SI5（也称 HW5 或 AI5）将采用多芯片模块（MCM）设计，告别 HW4 使用的传统封装方式。
这款芯片将分别采用台积电 3nm 和三星 2nm 级制程工艺制造。
特斯拉预计，SI5 的算力将达到 HW4 的 40 倍。马斯克此前解释称，这一提升来自两方面：计算能力提升 8 倍，主要得益于更先进的制程工艺和更多执行单元；硅片优化则进一步带来 5 倍性能提升。
据此估算，SI5 的算力可能达到 8640～23040 TOPS，具体数值取决于 HW4 的实际算力基准。
不过，SI5 的预计功耗也相当高，根据不同应用场景，可能达到 250W～800W。因此，现阶段对其实际性能进行估算仍存在较大不确定性。
在内存方面，SI5 的容量预计将达到上一代的 6 倍，即 96GB。根据最终采用 GDDR6 还是 GDDR7 内存，其带宽可能介于 768GB/s 和 1.536TB/s 之间。
至于第六代推理加速器 SI6，特斯拉计划进一步将其算力提升至 HW4 的 80 倍，内存容量则达到当前一代芯片的 9 倍。
按照上述估算，SI6 算力可能达到 17.28～46.08 POPS，内存容量则为 144GB。对于一款 AI 推理加速器而言，这意味着相当可观的算力和内存规模。
特斯拉已经与三星晶圆代工部门签署协议，计划由后者为其生产第六代推理加速器，合作期限持续至 2033 年。
最新路线图显示，SI6 将采用 2nm 级制程工艺。考虑到该芯片预计在 2029 至 2030 年推出，以及三星近期更新的代工路线图，SI6 可能采用汽车级 SF2A、性能增强版 SF2P，甚至是配备背面供电技术的 SF2Z。
值得注意的是，特斯拉似乎并未计划在 2030 年代利用 Terafab 工厂的英特尔 14A 制程生产 SI6。
在封装方面，SI6 将延续 AI5/SI5/HW5 引入的多芯片模块（MCM）设计。这一选择较为合理，因为特斯拉届时已经能够积累第五代推理加速器的研发和生产经验，同时也可以将封装成本控制在相对合理的范围内。
目前，许多汽车制造商都在考虑为下一代系统级封装（SiP）采用多芯粒设计和 HBM 内存，这也将推高相关芯片的制造成本。
至于特斯拉何时会在推理加速器中引入 HBM，目前仍没有明确答案，但 SI6 恐怕还不会采用这类内存。
