IT社区推荐资讯 - ITIndex.net

小米AI Cube 原型机-本地AI模型部署选择

Wed, 07 Oct 2026 08:13:57 CST

小米刚刚展示了其 AI Cube 原型机，这可能成为来自中国的严肃 GB10 竞争对手 👀 - 3 款定制芯片：Xring O3、O100、D100

- 200 TOPS NPU

- 1.22 TB/s AI 内存带宽

- 最高 160GB 统一内存

- 150W 持续功率

- 120B 模型本地运行

Xring O100：1.22TB/s + 330 t/s 在 150w AI 盒子上真是 🔥 一旦它上市，绝对会像热饼一样热卖。

Xiaomi just showed its AI Cube Prototype and this could become a serious GB10 competitor from China 👀 - 3 custom chips: Xring O3, O100, D100 - 200 TOPS NPU - 1.22 TB/s AI memory bandwidth - Up to 160GB unified memory - 150W sustained power - 120B models running locally Xring O100: 1.22TB/s + 330 t/s on a 150w AI box is 🔥 Once it hit's the marked, going to sell like hot cakes.

文本分类语言模型-Language Models for Text Classification: From Bag-of-Words to Jev

Wed, 30 Sep 2026 09:26:32 CST

词袋模型、循环神经网络、卷积神经网络、Transformer 模型、Jev 类 API 和校准的可视化指南

A Visual Guide to Bag-of-Words, RNNs, CNNs, Transformers, Jev-like APIs, and Calibration

Sebastian Raschka, PhD

Sep 29, 2026

The recently released JevAI model has been quite a cultural phenomenon in technical communities in the past 2 weeks.

While Jev aims to classify things, it’s easy to dismiss Jev as “just a classifier,” and my own view of Jev has evolved quite a bit over the past few days. In particular, my thoughts went from “classifiers used to be my bread & butter; I can easily build this myself” (more on this later) to “wow, this actually works better than I thought.”

Figure 1: Quick overview of the Jev API; more details on that later.

Sure, the latest state-of-the-art GPT and open-weight LLMs can do the same kinds of classification tasks as Jev, while also being capable of much more general decision-making. But Jev’s advantage is that it can handle those classification tasks much faster and more cheaply.

At the other end of the spectrum, for a narrow, well-defined problem, Jev probably won’t classify anything better, faster, or cheaper than a special-purpose classifier. But its selling point is that it is far more general than those task-specific models.

So, what is the methodology behind Jev (based on an educated guess), what can it do, and why is it so popular? I aim to answer all of these later in this article. However, I thought starting with a brief history of language models for decision-making would be a great way to begin. And it hopefully helps demystify some of the hype and show what Jev does very well (”Jev is essentially a text classifier,” but “Jev is also not ‘just’ a text classifier.”)

PS: I am not affiliated with Jev in any way. Also, I am not offered free access to Jev, and this is also not a product endorsement, just a technical article to offer some insights into the history of text classification to help you make sense of the recent hype.

Since this is a long article, I recommend reading it in your browser,where you can access the table of contents menu on the left side.

1. Language modeling and classification in the pre-transformer era

For completeness, before we put Jev in context (no pun intended), I thought it made the most sense to start chronologically. In this section, I want to take a brief tour of applied text classification via naive Bayes, logistic regression, and the more classic (deep) neural networks before transformer-based models came along.

1.1 Bag-of-words: naive Bayes, logistic regression, and XGBoost

Back in the day, when I was a grad student 15 years ago, even though recurrent neural networks already existed (more on that later), text classification was usually done with a bag-of-words representation because it was straightforward and could get good results on moderately sized datasets.

In short, we can think of the bag-of-words representation as a method that makes free-form text input of different lengths compatible with classic classifiers (naive Bayes, Logistic Regression, SVMs, Random Forest, XGBoost, to name a few), which expect a fixed-size input vector.

Popular real-world applications include anything from news article classification to email spam filtering. And yes, allegedly even Gmail’s original spam filter used a Naive Bayes model with a bag-of-words representation.

As a side note, I wrote about thisapproach exactly 12 years ago. It was one of the first things I shared on arXiv.

Figure 2: An old tutorialof mine from 2014 that explains naive Bayes classifiers using a bag-of-words model.

So, what exactly is this bag-of-words representation? It’s a way to convert free-form texts with different lengths, e.g.,

Training example 1: “Zentropa is the most original movie I’ve seen in years. If you like unique thrillers that are influenced by film noir, then this is just the right cure for all of those Hollywood summer blockbusters clogging the theaters these days. Von Trier’s follow-ups like Breaking the Waves have gotten more acclaim, but this is really his best work.”
Training example 2: “This film is just plain horrible. John Ritter doing pratt falls, 75% of the actors delivering their lines as if they were reading them from cue cards, poor editing, horrible sound mixing”
Training example 3: “Zentropa has much in common with The Third Man, another noir-like film set among the rubble of postwar Europe.”

into a fixed-size representation for the aforementioned “classic” classifiers. (The example above is an excerpt from the popular IMDb movie review classification dataset.)

Figure 3: An illustration of a bag-of-words representation.

A bag-of-words model starts by building the vocabulary, which consists of all unique words in the training set (optionally, one can get rid of so-called stopwords like “a” and “the”, which are words that carry little to no semantic meaning in most contexts).

A bag-of-words representation results in these fixed-size inputs by assigning each word in a vocabulary its own position in a vector. We then count how often each word occurs in a document. For example, if we have a vocabulary of 50,000 unique words, it produces a fixed-size vector with 50,000 entries, regardless of whether the input consists of only ten words or 300k words. Note that most entries are zero because each document contains only a small subset of the vocabulary. (Instead of representing the raw counts, there are also normalization schemes like TF-IDF.)

Then, once we have these word frequency vectors, we can train a classifier on a labeled training set, such as emails labeled as spam or non-spam. For example, a logistic regression model would then learn feature weights that correlate certain words (and word counts) with particular labels. For instance, certain words might increase the predicted spam probability, and others may decrease it.

This approach is computationally cheap and can work well when particular words provide strong clues about the label. In a simple classification task such as spam classification, this is often enough to get quick, reasonably accurate results.

But one of the biggest downsides of this approach is that, because of the nature of the bag-of-words representation, it loses word order. So, for example, “the dog bites the man” and “the man bites the dog” produce identical vectors despite describing different events.

(There are some workarounds to preserve some local order by adding word pairs or longer sequences, called n-grams, as features, although this increases the vocabulary size.)

Despite the shortcomings, I still think that a bag-of-words has its place in certain low-stakes applications because it’s so cheap, and a bag-of-words representation + logistic regression remains my go-to baseline for every text classification problem, since it’s so easy to implement.

Figure 4: For those interested in building a simple logistic regression classifier, I have a tutorial up here. This model achieves 89.9% accuracy (on a balanced dataset).

1.2 Deep neural networks for text classification

The aforementioned bag-of-words model would also work with (simple) deep neural networks, like multilayer perceptrons. But the downside still is that we would lose the sentence structure and word order.

However, more sophisticated neural network architectures avoid the bag-of-words workaround: convolutional neural networks (CNNs) and recurrent neural networks (RNNs), which can take word embeddings as input.

1.2.1 Word embeddings

First, before feeding the input texts into a model, we have to convert them into a suitable representation. One such representation is bag-of-words. Another is word embedding vectors. The difference is that a bag-of-words vector represents the entire text by counting how often each vocabulary word occurs, while a word embedding represents an individual word as a dense vector of learned numbers.

Figure 5: Illustration of creating word embeddings.

Word embeddings work similarly to embedding layers in LLMs, i.e., they convert input tokens into dense vectors. Embeddings can happen outside the model (e.g., two classic, popular methods for learning them are Word2Vecand GloVe), or the embedding layer can be part of the neural network architecture itself and be learned and tuned during model training.

These classic embeddings are context-independent at lookup time. The word “bank”, for example, gets the same vector in “river bank” and “bank account” (as you may know, context can be handled via concepts like attention).

For additional resources on embeddings, you may find the following ones helpful:
- Chapter 2: Working with Text Data(this is an LLM chapter but should give you the gist of embedding words or tokens; in LLM tokenizers, we split words into subword tokens; in Word2Vec, 1 word is usually 1 token.)
- Understanding the Difference Between Embedding Layers and Linear Layers(this is an illustration that shows when embedding vectors are mathematically equivalent to Linear layers and matrix multiplications.)

1.2.2 Recurrent neural networks (RNNs)

Since many of you are probably familiar with recurrent neural networks (RNNs), I will keep this section short. RNNs are a classic go-to neural network architecture for natural language processing, and popular variants go back to the 1980s and early 1990s. Transformers, which were introduced in 2017 (and using the attention mechanisms that were first introduced in RNNs; see my Understanding Large Language Modelsfor a brief timeline), then gradually replaced them in many NLP applications.

RNNs read a sequence (like text) one word at a time. At each step, they combine the current word embedding (discussed in the previous section) with a hidden state from the previous step. We can think of the hidden state as a fixed-size vector that summarizes the text processed so far, so this makes word order matter, because rearranging the words changes the sequence of state updates.

Figure 6: Illustration of an RNN classifier.

Note that the figure above shows the RNN in the unrolled representation. I.e., the RNN reuses the same layer stack for each input, hence the term “recurrent”. And since it’s “recurrent”, the input text can have an arbitrary length. The figure below illustrates the “recurrence” with the unrolled representation side by side. Note that both show the identical architecture, it’s just a different visualization.

Figure 7: Rolled and unrolled illustration of the same RNN.

RNNs were notoriously hard to train, and there are important improvements to RNNs, like Long short-term memory(LSTM) networks, introduced in 1997, and gated recurrent units(GRUs), introduced in 2014, which use learned gates to control how information is retained and updated. (There is also the more recent xLSTM: Extended long short-term memory, introduced in 2024).

Also, state-space models are inspired by this idea of a fixed-size hidden state updated sequentially, which is cheaper than transformer attention. However, the bottleneck is still how much information the hidden state can retain, and it still has to be processed sequentially. (Fun fact: attention was first developed for RNNs before the transformer architecture came along, but it’s a story for another time; I’ve written about it in my Understanding Large Language Modelsarticle.)

The bottom line is that RNNs can be used to train text classifiers. Coming back to the IMDb movie review dataset, the bag-of-words classifier with logistic regression achieved about 89.9% accuracy (on a balanced dataset), while an LSTM RNN achieved only 85.66% accuracy. Yes, RNNs can be harder to train (stay tuned for the ULMFiT method below, which trains an RNN with much higher accuracy).

Figure 8: A simple RNN with LSTM tutorial. This model achieves 85.66% accuracy (on a balanced dataset); the higher training accuracy indicates substantial overfitting.

Note that this RNN was trained from scratch. A better approach is to pre-train the model on a larger dataset first, then fine-tune it on this target dataset (classically, we call this approach “transfer learning”).

In the natural language processing domain, one of the most influential papers proposing this approach is ULMFiT(2018), which achieved an impressive 95.4% test accuracy on IMDb.

Figure 9: Annotated figure from the ULMFiTpaper.

1.2.3 Convolutional neural networks (CNNs)

You probably know convolutional neural networks (CNNs) from their use in computer vision. However, it is also possible, although historically less common, to use them for text.

Figure 10: Illustration of a convolutional neural network (CNN) to classify images.

As shown in the image classification example in the figure above, CNNs apply learned filters to image patches (windows). Similarly, in the natural language domain, we can apply learned filters to windows of adjacent word embeddings.

Figure 11: A CNN for text classification, step by step. Only 1 filter (channel) for simplicity.

As illustrated in the figure above, a convolutional filter with a window size of three uses the same weights for each adjacent group of three words. Then, as it slides over the inputs, it moves the filter one word at a time across “the movie had surprisingly good acting”. So, this gives four windows (ignoring padding for simplicity):

1: “the movie had”
2: “movie had surprisingly”
3: “had surprisingly good”
4: “surprisingly good acting”

So, in the last layer, before the classification head, we can either flatten or global max pool the results before connecting it to the classification head. While flattening preserves all information, it would produce differently sized vectors depending on the text input length. (E.g., if “the movie had surprisingly good acting” were longer, we would have longer feature maps.) So, to make it input-length agnostic, global max-pooling would be a better option here.

In short, we can visualize the text CNN as shown below.

Figure 12: CNN for text classification with multiple filters (channels).

Also, what’s nice is that the filter computations across positions can run in parallel, which avoids the step-by-step dependency of an RNN.

For a quick comparison, on the aforementioned IMDb dataset, my experiments show that such a CNN gets about 90.07% accuracy (but note that this is highly architecture-dependent; for example, you may know from computer vision contexts that accuracies can vary widely). (E.g., the good old AlexNet had a ~62.5% top-1 accuracy on ImageNet, and a ConvNeXt V2-H gets 88.9%.)

Figure 13: A CNN trained to classify IMDb movie reviews; it gets 90.07% accuracy on this balanced dataset. You can find the source code here.

2. Transformers

In 2017, the original transformer architecture was introduced in the Attention Is All You Needpaper. Since this topic has been covered so extensively (by me and others), I will focus on the classification-relevant aspects. But for those interested in the attention mechanism and other architecture details, please see my related articles:

The Big LLM Architecture Comparison

Sebastian Raschka, PhD

July 19, 2025

Read full story

A Visual Guide to Attention Variants in Modern LLMs

Sebastian Raschka, PhD

Mar 22

Read full story

The key point is that the original transformer architecture was an encoder-decoder setup used for language translation, but it can be easily adapted for text classification tasks, as I’ll illustrate in the following sections.

Figure 14: The original transformer architecture from Attention Is All You Need.

2.1 Encoder-style language models

I remember all too well the first years after the original transformer architecture release. They were pretty much defined by the rivalry between two different approaches:

Encoder-style models like BERT, primarily developed by Google;
Decoder-style models like GPT, primarily developed by OpenAI.

Encoder-style models were natural text classifiers, whereas GPT models could do zero- and few-shot classification as an emergent property, but their strength was more in generative tasks.

But let’s start with encoder-style models and how to fine-tune and use them to classify text.

One universal aspect of using transformers, whether encoder- or decoder-style, is that we work with models pre-trained on large text corpora, and, in addition to using them as zero- or few-shot classifiers, we can fine-tune them on the target dataset (similar to ULMFiT, as mentioned in the RNN section earlier).

As shown in the figure excerpt from the BERT paper(2018) below, BERT-/encoder-style models have a classification token at the first position that we can conveniently fine-tune for this.

Figure 15: Annotated figure from the original BERT paper.

While BERT models are not nearly as popular as autoregressive GPT-style transformers, thankfully some people still update and modernize them occasionally. One recent example that is often my go-to for classification tasks is the 2024 ModernBERTmodel.

As shown below, on the IMDb movie reviews, ModernBERT gets approximately 95% accuracy with very little fine-tuning effort.

Figure 16: Different LLMs fine-tuned to classify IMDb movie reviews; you can find the source code here. (I did very little hyperparameter tuning, and this can potentially be improved by 1-2% further; however, one of the points here is also that one can get really good results with pretty minimal effort.)

2.2 Decoder-style LLMs

LLMs like GPT are decoder-style, autoregressive transformers that are the center of all attention (no pun intended) for generating text and code.

However, as I explained in chapter 6 of my Build A Large Language Model (From Scratch)book, as a gentle introduction to fine-tuning (before covering instruction fine-tuning), we can also repurpose these for text classification.

Sure, we can also prompt an LLM directly, as shown in the screenshot below.

Figure 17: Prompting an LLM to classify a movie review.

However, if we want structured outputs and we have a specific target domain in mind, this is unnecessarily brittle and inefficient.

Instead, we can replace the output layer with a leaner classification head, as illustrated below:

Figure 18: Swapping the output layer of a GPT-style model with a leaner classification head.

Now, fine-tuning has a few caveats. For instance, because of the autoregressive attention mask, we have to be careful about how we design fine-tuning so that the classification token has information about all other tokens in the sequence.

Figure 19: Attention masks in BERT and GPT.

If you are interested in further technical details, please see my recent end-to-end Building an AI Text Detector From Scratcharticle:

Building an AI Text Detector From Scratch

Sebastian Raschka, PhD

Aug 15

Substack recently launched its AI detector feature in the UI, which is super interesting.

Read full story

Overall, though, the advantage of using GPT-style LLMs over e.g., BERT variants is that there are so many modern open-weight architectures out there to adopt. Anything between the small Qwen 3 0.6B models to the latest Kimi, GLM, or DeepSeek models. (Of course, using such >1B parameter models for classification could be a bit overkill from an efficiency perspective, but hey, it’s possible.)

Figure 20: On the aforementioned IMDb movie review dataset, a relatively small GPT-2 124M model gets approximately 92% accuracy; a larger and newer LLM (like a recent Qwen3 variant) would likely perform better.

2.3 Encoder-decoder style architectures

While the original transformer architecture (an encoder-decoder) was split into two paradigms, encoder-style models like BERT and decoder-style LLMs like GPT, there were also efforts to use encoder-decoder-style variants, with the most recent variant (somewhat unexpectedly) being DeepSeek V4.1 Flash. (However, in this case, it’s a causal encoder not a bidirectional one as in T5.)

Keeping the focus on encoder-decoder architectures for classification, probably the most prominent candidate is Google’s 2019 T5 (Text-to-Text Transfer Transformer).

Architecturally, the differences between T5 and the original transformer include updates to the architecture (as summarized below), as well as changes to training. The original transformer was trained to do language translation (in a supervised fashion); T5 uses pre-training on unlabeled text with span corruption, where the encoder receives text with missing spans and the decoder generates those missing spans.

Figure 21: T5 architecture changes to the original transformer architecture. (The architecture drawing is taken from Attention Is All You Need.)

Now, we can use T5 similar to the other RNN, CNN, and transformer approaches above, by adding a classification head.

Additionally, we can also (train to) have the decoder output the class label prediction (like “positive” or “negative” in the IMDb movie review dataset case), similar to regular LLMs. Let’s call this approach text-to-text classification.

While GPT-style LLMs are trained on massive amounts of text, they usually perform text-to-text classification well out of the box, as shown earlier (the figure below is inserted here again for convenience).

Figure 22: Text-to-text classification with a GPT model.

However, in the case of T5, it is common to further fine-tune the decoder to do well on these types of tasks in a given target domain.

For T5, both approaches work. Here’s a summary:

Figure 23: Classification head vs text-to-text approaches.

3. Jev overview

So far, we have seen that there are plenty of approaches to text classification, from traditional methods like logistic regression and naive Bayes with bag-of-words representations to prompting the latest frontier LLMs like GPT-6 or fine-tuning any open-weight LLM with a classification head (or text-to-text classification).

At first, I (almost) dismissed it as “just a classifier,” something that I build routinely for classification tasks with natural language inputs (e.g., see my AI Detector articleas a recent public example).

3.1 Jev vs existing text-to-text classification

Before continuing this discussion, though, let’s start with a quick Jev overview. Jev is a new model released by TypeSafe AI, which just came out of stealth a few weeks ago and got a lot of attention (at first, it seemed a bit bizarre because it looks just like a classifier).

Jev is a proprietary model (although the release was followed by a huge number of quick open-source clones, but we will get to this later) that is relatively cheap to use and claims to be on par with GPT-5.6 Luna (for decision-making) while being orders of magnitude faster and cheaper:

Figure 24: Benchmark from TypeSafe AI blog.

Here, regarding GPT-Luna, think of this as the text-to-text classification approach discussed earlier.

So why all this hype? I think it’s partly because of the nice API and that it performs so well on all kinds of tasks, so it doesn’t require custom fine-tuning.

For example, I can use it to categorize support tickets/emails (I made a video version to show the response time):

Or, I can have the same model play Tetris in real-time (here, I am using the Choice API):

Maybe the best way to succinctly explain it (before getting into technical details) is as follows: Like ChatGPT in 2022 was exciting because it was a general-purpose chat model that could generate all kinds of texts, one of the reasons the tech community is excited about Jev is that it is the ChatGPT moment for classification, where it can cheaply classify all kinds of text inputs without having to fine-tune a custom classifier for each task.

(As of this writing, there’s not much known about the architecture and exact training algorithm, except that one of the founders said it was trained via “Reinforcement Learning for Calibrated Decisions”, but more on that later.)

3.2 The Jev API

Over the past few years, we’ve gotten used to throwing bigger, better, and more expensive GPT-style LLMs at all kinds of problems, and for targeted decision-making or classification tasks, a cheap & fast approach like Jev may feel refreshing to most. Especially for one-off tasks where collecting training data and fine-tuning a custom ModernBERT sounds too tedious, we might just throw a Luna-like model at it.

But on top of being popular for its versatility (that is, performing well on different target domains out of the box), Jev also has a relatively nice API which we can use via curl in the terminal or via its Python API.

In short, there are three main API types illustrated below. Let’s start with the Choice API, which is convenient for multi-class classification.

Figure 25: Jev’s Choice API. Use this for multi-class classification.

Next is the Noul API, which is simpler and assigns a “yes” probability to a question.

Figure 26: Jev’s Noul API. Use this for binary classification or multi-label classification (with multiple Noul questions).

Lastly, the Score API assigns a score based on a rubric level (in the example below, 0, 1, 2).

Figure 27: Jev’s Score API. Use this for ordinal classification.

To sum it up, the different APIs and use cases are as follows.

Figure 28: Jev API cheat sheet.

3.3 Jev classifying IMDb

To make these APIs more concrete, and to answer the question of how well Jev might do on the aforementioned IMDb dataset, we can run it with either the Choice or Noul API.

Let’s start with the Choice API first. Each review would be formatted as follows:

          export TYPESAFE_API_KEY="YOUR_API_KEY"

curl -sS https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-1.13.0",
    "state": "The acting was excellent and the story kept me engaged throughout. I would happily watch this movie again.",
    "questions": {
      "sentiment": {
        "type": "choice",
        "instructions": "What is the overall sentiment of this movie review?",
        "criteria": {
          "negative": "An overall unfavorable opinion of the movie",
          "positive": "An overall favorable opinion of the movie"
        }
      }
    }
  }'

This Choice API is convenient if we want to use explicit labels for binary (here) or multi-class problems.

An actual response might look as follows:

          {
  "model": "jev-1.13.0",
  "answers": {
    "sentiment": {
      "type": "choice",
      "choice": "positive",
      "confidence": 1.0,
      "probabilities": {
        "negative": 0.0,
        "positive": 1.0
      }
    }
  },
  "usage": {
    "input_tokens": 342,
    "output_tokens": 32
  }
}

Along with the "choice": "positive"label, we also get the confidence for this prediction, which can be really useful in real-world applications, as well as the probabilities for each class. (The confidence field summarizes how concentrated the probability distribution is. It is different from the probability assigned to the winning class.) One of the selling points of Jev is that, according to the documentation, these are well-calibrated (but more on calibration later).

Alternatively, we can also use the Noul API here to classify the reviews. Using the same movie review classification context, the format would be as follows:

          curl -sS https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-1.13.0",
    "state": "The acting was excellent and the story kept me engaged throughout. I would happily watch this movie again.",
    "questions": {
      "is_positive": {
        "type": "noul",
        "instructions": "Does this review express an overall positive opinion of the movie?",
        "criteria": {
          "true": "An overall favorable opinion of the movie",
          "false": "An overall unfavorable opinion of the movie"
        }
      }
    }
  }'

And the answer via the Noul API is:

          {
  "model": "jev-1.13.0",
  "answers": {
    "is_positive": {
      "type": "noul",
      "noul": 0.98
    }
  },
  "usage": {
    "input_tokens": 328,
    "output_tokens": 21
  }
}

(Interestingly, it gives 0.98 instead of 1.0 for the positive class, even though it’s the same text.)

We can also apply the Noul API to multiple classes by asking one question per class, for example:

“Is this article about finance?”
“Is this article about politics?”
“Is this article about technology?”

Here, each question (independently from each other) returns a probability, and these probabilities don’t have to sum to 1. So, for a multi-class classification where each text can have multiple labels, we may prefer Noul, and for classification problems with only one final answer, Choice adds more convenience.

Now, running Jev with either Choice or Noul on the 25,000 movie reviews on the test set gave the following results:

Choice:
- Accuracy 96.47% (24,117 correct)
- Total runtime: 22 minutes 24 seconds
- 15,456,663 input tokens, $0.6492 total cost
Noul:
- Accuracy 96.20% (24,050 correct)
- Total runtime: 23 minutes 3 seconds
- 15,106,663 input tokens, $0.6345 total cost

Note that the small difference in performance and runtime between Choice and Noul could be due to random fluctuation since, similar to other LLMs, the runs are not fully deterministic.

For instance, I ran the Choice API a second time over the same test set and got slightly different results, as shown below.

Figure 29: Repeated Jev runs.

(The non-determinism when serving LLMs and other models at scale is likely due to batch-dependent GPU kernel execution changing the order of floating-point operations, as laid out in a nice blog postby Horace He last year.)

Anyways, the results look quite good overall (caveat: we don’t know if the IMDb test set was part of the training set).

For reference, a ModernBERT model took

23 min to fine-tune on the training set;
7 min to evaluate on the test set.

For comparison, the best ModernBERT model has similar accuracy, as shown below (I expect you can still get 1-2% higher accuracy with additional hyperparameter tuning). Note that this was run on a DGX Spark, and it’s possible to get faster inference performance with quantization and faster hardware.

Figure 30: ModernBERT versus Jev.

But our ModernBERT model can’t play Tetris, for example, or do anything else besides movie classification without us fine-tuning it for the new task. But we could then throw a GPT-5.6 Luna or GPT-6 Luna model at it (which is a bit slower and also more expensive).

A classic rule of thumb was:

Use a cheap LLM (like GPT-6 Luna) for one-off decision-making tasks;
Fine-tune a custom classifier if we want to do this task repeatedly.

Now, something like Jev could take the place of the above to a) reduce latency and save money over Luna and b) save us the work of fine-tuning a custom model. (Although if we have a very high-volume task and we want to maximize speed and accuracy on a very specific task, it, of course, still makes sense to fine-tune.)

4. BERT- and GPT-style models with Jev API

Of course, we could also be adding a Jev-like API on top of a (Modern)BERT or any GPT-style model. Adding a Jev-like API is pretty straightforward. In fact, as soon as Jev was released, I built a Jev-like ModernBERT model to show how simple it is to build your own Jev model.

I decided not to release my Jev clone because I changed my mind in the meantime. I.e., it’s trivial to put a Jev-like API on top of ModernBERT, and it’s trivial to fine-tune it on a bunch of classification tasks. But it’s not trivial to make this model work well on all different kinds of tasks (like Tetris) without extensive training and testing. (Also, there are already enough quick Jev clones riding on the hype train by now; the world doesn’t need another quick clone, but a strong open-weight version would be nice, of course.)

However, if you are interested in how that retrofitting would work, here is a quick overview. For example, we can implement a Jev-like Choice API by adding a small classification head to any BERT-, GPT-, or T5-style model as illustrated earlier. But instead of having the output nodes in this head match the number of classes, we have it with only 1 output node, as illustrated for the modified GPT model below.

Figure 31: GPT model where we replace the output layer (which maps to the whole vocabulary) with an output head with only one node.

Earlier, we discussed fine-tuning these models for a specific task like movie review classification with a pre-defined number of class labels (here, “positive” and “negative”). With this “1 output node” setup, we can actually extend this to a flexible and arbitrary number of classes.

To extend this to an arbitrary number of classes (let’s consider the 3-class case of categorizing a customer ticket into the three categories “billing”, “technical”, “account”), we can do so as shown in the figure below.

Figure 32: Using a BERT- or GPT-style model with a Jev-like choice API.

As shown in the figure above, for each candidate option, we feed the model the input text, the task instructions, and the candidate’s description. The classification (scoring) head maps the output representation to a single scalar score. We then apply softmax across the candidate scores to obtain a probability distribution and return the highest-probability option.

The main point here is that the proposed head has one output per class. Each class description produces its own representation, which the same head scores via the output layer (which is essentially a logistic regression model):

where

s _iis the scalar score for class label i;
wis a learnable weight;
bis a learnable bias unit;
h _iis the output of the transformer before the classification head.

For Ncandidates, this produces Nscores. Softmax then returns Nprobabilities. The learned parameters and stay the same when Nchanges.

Note that for h _i:

BERT-style encoder models use the final hidden state of the [CLS]token (optionally passed through a pooling layer);
GPT-style autoregressive models typically use the final non-padding token’s hidden state, which we need because of the autoregressive nature as discussed earlier (the last non-padding token can attend to the preceding text, instructions, and candidate description).

Then, we fine-tune the model and the scoring head jointly using cross-entropy loss against the correct option. Since all candidates share the same scoring head, we can change the number and descriptions of the options without changing the architecture. But again, how well this works on unfamiliar tasks depends on the training data.

By the way, why BERT- or GPT-style transformer-based models over simpler RNN and CNN architectures mentioned earlier? From a technical perspective, the approach outlined above works with either. But transformer-based models scale really well, meaning they can be pre-trained on larger datasets and benefit more than other models. Also, they can make good use of the information provided in the context (thanks to attention). So, if we want our model to generalize well to different target tasks without explicit fine-tuning on each one, pre-training a transformer-based model on a high-quality dataset likely gets us closer than RNN- or CNN-based models.

5. Jev architecture and training algorithm

So, how come Jev does so well on so many different tasks (from movie reviews to something arbitrary like playing Tetris)? Unfortunately, the architecture, algorithm, and training data details are not public. Also, keep in mind there’s a whole team and multi-million-dollar company behind it that specialized in and worked really hard on this model; we can’t expect to match that level of performance by training a ModernBERT-like model for a week on some open datasets.

That being said, if I had to make an educated guess, architecture-wise, I’d guess that they are using something small similar to ModernBERT, hence, the low latency.

For the training data, as mentioned before, the TypeSafe AI CEO saidthe following:

100% of our data is synthetic (but not the type of crap that is just spit out from an LLM obviously)

So, yeah, I think most of the effort went into curating this dataset. It’s something I’ve also been preaching to students and collaborators for many years. As a short anecdote, about 8 years ago, I was collaborating with another professor in the social sciences department and helped to design the experimental setup for a text classification problem. Her student spent many days hyperparameter tuning both a bag-of-words baseline and a BERT model to eke out ~2-5% accuracy. Then I suggested we each sit down for a few days to hand-label more data (I think our original dataset was around 300 samples, and we doubled the size), which resulted in a >10-20% accuracy boost. Yes, it’s important to plot learning curvesfor that purpose :).

Figure 33: Rule of thumb showing that often more data helps more than additional hyperparameter tuning.

Finally, the training algorithm. Again, the details are not known, but TypeSafe AI’s blog post statesthat they were using a new algorithm called Reinforcement Learning for Calibrated Decisions (RLCD):

“We built a new stack entirely focused on automation: with a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD).”

This method is not public. A published method with a similar calibration objective is RLCR (Reinforcement Learning with Calibration Rewards), from the 2025 paper Beyond Binary Rewards: Training LMs to Reason About Their Uncertainty. Before providing more details, the next section gives a brief overview of calibration in general.

5.1 On calibration

Calibration is not a new topic and a step I recommend for any production model where you want to use and evaluate the class-membership probabilities. In short, calibration adjusts the model’s probability estimates so they better match observed class frequencies.

For example, consider once more our IMDb movie classification problem. A model might assign a review 74% positive and 26% negative. These are probability estimates, but the model may be overconfident or underconfident. We cannot assume that the numerical values are reliable without evaluating calibration. I.e., predictions of 74% positive and 54% positive both yield the class label “positive” at a 50% threshold, although the model expresses more confidence in the 74% case.

Figure 34: Illustration of how calibration works.

Calibration techniques use a separate labeled dataset, e.g., a held-out validation set, to adjust these probability estimates. After successful calibration, among many reviews assigned a positive probability of approximately 74%, roughly 74% should actually be positive. For more information, I recommend the good old scikit-learn documentation.

There are many approaches for this. For example, one that I used in my AI detector projectis temperature scaling. Temperature scaling divides the model’s logits by a temperature ( T) value before applying softmax. We learn T(a positive number) by minimizing the cross-entropy loss on the calibration dataset while keeping the model weights fixed. A temperature above 1 reduces confidence in the highest-probability class, while a temperature between 0 and 1 increases it. We then use this same temperature for new predictions. Because this scaling preserves the ordering of the logits, the predicted class remains unchanged when we select the highest-probability class.

5.2 Reinforcement learning with calibration rewards (RLCR)

Jev’s RLCD training method remains proprietary, but a related idea we can discuss is Reinforcement Learning with Calibration Rewards(RLCR), which was introduced in the 2025 Beyond Binary Rewards: Training LMs to Reason About Their Uncertaintypaper. (Note that there is no officially established connection between the two methods, but I am assuming that they could be related.)

Reinforcement learning with verifiable rewards (RLVR) typically rewards a correct answer with 1 and an incorrect answer with 0. (For a comprehensive explanation and implementation, I recommend checking out my Build A Reasoning Model (From Scratch) book:)).

In short, RLCR adds an additional penalty for inaccurate confidence estimates.

So, in the conventional RLVR method, the reward Ris either 0 or 1 based on the answer correctness (we are ignoring an optional formatting reward and length penalty here, for simplicity).

In RLCR, the model generates reasoning and an answer, which is followed by an uncertainty analysis and a numerical confidence ( q). This modified reward is

$R = c - (q - c)^2,$

where is 1 for a correct answer and 0 otherwise. For example, an incorrect answer with 90% (0.9) confidence receives a reward of -0.81, since

$0 - (0.9 - 0)^2 = -0.81.$

At 20% confidence, the reward is -0.04. And a correct answer at 90% confidence earns 0.99. (Readers familiar with evaluating calibrated models may notice that the squared-error term is the Brier penalty for the stated probability that the answer is correct.)

Figure 35: RLCR overview.

Note that the same (here, Qwen2.5-7B) model generates the uncertainty analysis and q as part of its response.

The uncertainty analysis is a written assessment of where its answer could be wrong. After answering, the model examines missing evidence, ambiguous wording, questionable assumptions, or possible reasoning errors. The paper’s prompt asks it to identify specific uncertainties rather than propose corrections.

Also, the system prompt explicitly asks for q, a number between 0 and 1 inside tags. It represents the model’s estimated probability that its answer is correct. The system generates all these parts sequentially in the same response.

For illustration purposes, the model answer could be as follows:

                  <think>...reasoning about the question...</think>
<answer>positive</answer>
<analysis>
The passage mentions a positive movie review, but the connection to the second paragraph is unclear.
</analysis>
<confidence>0.6</confidence>

Below is an annotated figure from the paper that illustrates how it improves the expected calibration error over regular RLVR with temperature scaling.

On HotpotQA, RLCR reduces expected calibration error (ECE) from 0.37 to 0.03 compared with RLVR, with similar accuracy (62.1% versus 63.0%). Across six other datasets, average ECE falls from 0.46 to 0.21, while accuracy rises from 53.9% to 56.2%. These are the results in the paper’s Table 1(a).

Figure 36: RLCR results from the Beyond Binary Rewards: Training LMs to Reason About Their Uncertaintypaper.

Conceptually, the “Classifier” in “RLVR + Classifier” is a supervised binary classifier that predicts whether the generated answer is correct.

For Jev, I could apply calibration rewards directly to typed decisions, without generating reasoning text. For example, we could equip a GPT-style model with the classification head illustrated in Section 2.2 and adapt the RL training objective to reward accurate decisions and calibrated probabilities. We would train the backbone and classification head together. This would be an adaptation inspired by RLCR, and it remains unclear whether Jev’s RLCD works this way.

Alternatively, since Direct Policy Optimization (DPO) is a cross-entropy (CE) alternative to Reinforcement Learning with Human Feedback (RLHF), we could also directly minimize CE + Brier loss on the classifier’s probabilities. I did this with the ModernBERT model, and there was a modest improvement over regular temperature scaling.

Figure 37: ModernBERT improvements via RLCR-inspired Brier-loss optimization. The ↑ symbol means higher is better. The ↓ symbol means lower is better.

5.3 Side note: Is calibration necessary?

Cross-entropy already encourages accurate probability estimates. Under ideal conditions, that is enough to obtain calibrated predictions without an additional penalty.

I.e., using a simple coin flip example analogous to the movie review classification, the two classes are “heads” and “tails.” If it’s a biased coin that lands heads 80% of the time (in expectation), the true probabilities are 80% heads and 20% tails. On a representative training set, when we optimize cross-entropy, the model will already learn these as a side-effect of minimizing cross-entropy (negative-log-likelihood).

So, in short, if the model learns the true class probabilities, its predictions are calibrated and an additional penalty is unnecessary. (And Brier loss has the same theoretical optimum as cross-entropy, as described in Strictly Proper Scoring Rules, Prediction, and Estimationby Gneiting and Raftery, 2007.)

In practice, however, we never train to the real optimum (in expectation) but train on a finite dataset.

So, once a neural network correctly classifies most training examples, it can further reduce cross-entropy on the training set by becoming more confident. These confidence estimates may then generalize poorly to the test set and new data.

For example, in On Calibration of Modern Neural Networks, Guo et al. (2017) observed “neural networks can overfit to NLL without overfitting to the 0/1 loss.”

That means test accuracy can still improve while test cross-entropy worsens. So overfitting can show up in the probability estimates even when classification accuracy continues to improve.

Adding Brier loss changes how prediction errors are weighted during training. But whether this improves calibration needs to be checked on held-out data, of course. (The modest improvement in my experiment is an empirical observation for this setup, and we should not assume that adding Brier will always help.)

In my experiments (see previous figure), adding the Brier loss to cross-entropy provided only a very small additional calibration benefit.

But the motivation is more direct in RL contexts, such as described in RLCR, where we measure answer correctness and don’t already minimize cross-entropy. So, in RL contexts, the Brier term adds an incentive to report accurate confidence alongside the reward for answer correctness.

6. Who is Jev for?

Now that we covered Jev in reasonable detail, who is Jev for? Based on my assessment, it’s a pretty big target audience that intersects between people who a) want to save time by not having to fine-tune a custom classifier for every decision task and b) want to save money over using “the big guns” like GPT-6 and similar LLMs.

There are also lots of interesting use cases to think of. In the section below is a short list of ideas.

6.1 Jev use cases

The list of use cases is seemingly endless. Sure, there are flashy examples like having it play video games like Tetris (as I showed in my earlier video above to demonstrate the low latency of the API). However, sorting emails is a more practical choice for most. For example, one could use Jev as an additional spam filter, prioritization, and so on.

But beyond things like that, it could also serve as a tool to augment LLM-agent harnesses. Here it could be used as

a pre-screener for regular LLM-agent harnesses to scan our contexts for prompt injection;
select the reasoning effort level for a model;
select a skill.md from your registered skill library;
use it as a judge for evaluation or self-refinement;
find relevant files for context building.

The list is practically endless. Someone even posted a survey on arXivanalyzing 2,170 Jev-related projects that have sprung up recently in just a few days.

6.2 About Jev clones and local Jevs

Since Jev’s launch, 100s, if not 1000s, of quick Jev clones have sprung up. Most of the ones I checked out were just quick examples fine-tuning a ModernBERT or Qwen model with SFT and adding a Jev-like API.

Based on what I can tell, none of them achieves the same level of performance as Jev on such a breadth of tasks. Comparing these projects to Jev is like comparing Alpaca (the early instruction-finetuned LLM based off of the original LLaMA open-weight model) to GPT-6. Sure, it may work similarly in spirit, but your mileage will vary on real-world tasks.

No offense, but they seem like quick projects to jump on the hype train, and I don’t want to plug a specific one here.

One exception here might be the GLiNERproject, which has been around for ~3 years ago, and while it’s not fundamentally the same, it can be used for similar things. However, based on a benchmark, Jev is definitely stronger.

Figure 38: GLiNER vs Jev comparison via https://github.com/AbdelStark/jev-benchmarks/blob/main/results/reports/btzsc-pilot-v1.md

Anyways, there is definitely a genuine need and desire for a good open-weight alternative to Jev. The reason is not necessarily cost (because Jev is so cheap) but privacy. (Also, if Jev is already that fast over the internet, imagine how fast it could be on beefy local hardware.)

So, of course I’d like a DeepSeek (or Kimi, or GLM, or MiMo) moment for Jev. I am sure people are working on this, but it will take some time. TypeSafe AI worked on this for many months with a dedicated team of experts. It’s unrealistic to expect to replicate that development and evaluation work in a week. (However, since this is a smaller and more efficient model than a 1-trillion-parameter model, by nature, it hopefully won’t take that long.)

Update 1 (29 September, 10:20 am PT):OpenAI just announcedthe Decision API at their DevDay 2026 conference (29 September). It appears to be a Jev-like model directly integrated into their platform.

Decisions API enables real-time decision-making by focusing Luna’s intelligence on a specific set of user-defined questions with finite pre-defined answers. Developers supply context using text or images, and get back answers they can use to classify content, route requests, or choose an agent’s next action.

Available in limited preview today with a broad release planned in the coming days.

Figure 39: OpenAI’s Jev-like Decision API announced at the OpenAI Dev Day.

Update 2:A reader shared the Contrastive Language Modelsproject with me in the comments below. It’s one of the nicer-looking Jev-likes. When I tried it, its IMDb test accuracy is just 82.90% (over 96.47% in Jev), and it fails the Tetris test.

Another reader wrote in about Laya, another strong contender. It did better at IMDb (92.33% test accuracy) but then failed the Tetris testeven worse.

So, my point still stands. There are many solid alternatives. But what makes Jev so popular is not a unique idea (as mentioned before, classifiers existed for a long time) but the fact that it performs so well at so many diverse tasks. The only task where it allegedly doesn’t do well (as a reader told me) is legal reviews in non-English languages. (But the weak multilingual performance can be circumvented by connecting it to a cheap translation model, e.g., GPT -6 Luna with a small latency overhead.)

Conclusion

All in all, at first glance, Jev doesn’t seem to offer anything fundamentally new. After all, one might say that “it’s just a classifier” (with a nice API on top of it). However, it works surprisingly well across a huge range of tasks. In that sense, it’s the plug-and-play version of dedicated classifiers.

Sure, experts will still fine-tune specialist models, but the bar to justify fine-tuning a specialized model is now much higher, since it’s easy to just throw a Jev or Jev-like at it and get good-enough results.

Also, I don’t expect Jev and Jev-likes to unlock new capabilities or solve previously unsolvable tasks. However, if we make such models part of our agent harnesses to aid the expensive GPT-6 or Opus 5.5 models in decision-making within that harness, using agent harnesses could become much faster and cheaper in the future.

If you found this article useful, consider becoming a paid subscriberto Ahead of AI. Your support helps me spend more time on the experiments and detailed illustrations behind articles like this.

You can also support my work through my books, Build a Large Language Model (From Scratch)and Build a Reasoning Model (From Scratch), if you’d like to implement these concepts yourself.

Thanks for reading and supporting my independent research!

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR

Mon, 24 Aug 2026 04:45:00 CST

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR #8172，聊聊写 Agent 的那些烂坑

现在的 Agent 圈子很浮躁。

大家喜欢看炫酷的控制台动效，喜欢接几十个工具，喜欢等下一个更强的大模型。

但只要你把 Agent 放进真实的工程环境跑几天，就会发现现实很残酷：

跑了十分钟的任务，网络一抖或者内存一爆，进程挂了，会话直接报废。
执行一个 npm test，吐出三万行日志，上下文当场被撑爆，模型开始胡言乱语。
为了让用户实时插话，框架往会话中间塞了一条消息，底层的 KV Cache 全废了，Token 费用翻了五倍，响应慢得像蜗牛。
搞多 Agent 并发，多个任务抢着写同一个状态文件，数据直接写坏。

模型不是瓶颈，Demo 也没有意义。包裹在模型外面的 Harness（执行底盘）太烂，才是 Agent 落不了地的根本原因。

最近， Pi（ pi.dev / earendil-works/pi） 发布了 harness-v2.md 规范，随后合入了 PR #8172。这是一份没有废话的工业级 Agent 底盘设计。

1. Pi 是谁？

在开源 Agent 项目里，Pi 很低调，但地位很硬。

核心作者与团队：Mario Zechner（GitHub: @badlogic，著名开源游戏引擎 libGDX 的缔造者，典型的老派系统级程序员）与核心团队成员 David Brailovsky（ @davidbrai）、Vegar Stikbakke（ @vegarsti）。在设计文档中甚至明确写着： “如果设计不成立，停下来在 Discord 上找 Mario 商讨。”
PR #8172 作者：Adam Teale（ @adamteale）。这个仓库门槛极高，非协作者提 PR 会被 Bot 秒关，只有 Maintainer 明确给 lgtm 才能进入流程。代码质量把控极严。
项目定位： “Primitives, not features”（只做原语，不做死板特性）。它不搞花哨的 UI，只提供 @earendil-works/pi-agent-core（运行时）、 pi-ai（模型层）和 pi-tui（终端差分渲染）。像 OpenClaw 这类复杂的自主 Agent 框架，底层直接依赖 Pi 的 SDK。

2. 竞品锐评：市面上的 Harness 错在哪？

把 Pi 的设计和主流竞品放在一起看，很多流行框架的做法其实很业余。

锐评 LangChain / LangGraph：自找麻烦的“图状态机”

LangGraph 试图用有向图和 Generator 状态机去模拟每一步执行，搞出一堆复杂的类型转换和模板代码。一旦中途报错，状态机极难恢复。

Pi 的选择：Pi 早期也写过一套 Generator 状态机（ harness-v2-generator.md），后来直接废弃。Mario 的理由很简单： 直线的 async/await 最容易调试和理解。 不需要把代码切成碎块，只要把副作用边界划清就行。

锐评 DeepSeek Harness (dsh)：粗暴丢数据的截断器

处理工具返回的超大文本时，DeepSeek 的 Harness（dsh）采用固定截断策略（保留头 4096 字符、尾 1024 字符，中间直接扔掉）。

PR #8172 的爆破：PR #8172 作者 Adam Teale 指出： dsh 的做法是永久丢失数据。 报错堆栈的关键信息通常就在中间，扔掉之后模型就彻底瞎了。PR #8172 提出了 Spill-copy-on-prune：裁剪 Context 的同时，把完整内容写入磁盘文件，并保留精确的字符偏移。模型不仅知道中间被裁了，还能用 grep 去磁盘文件里把那几行找出来。

锐评 AutoGPT / CrewAI：没有容灾的纸糊玩具

这些项目擅长展示“多智能体开会”，但根本没有真正的持久化与崩溃恢复（Durability）。任务跑了 30 步，第 29 步崩溃，整局重来。

3. Agent 开发者天天踩的五个坑，Pi 怎么解？

坑 1：中途插消息，KV Cache 当场报废

现象： Agent 正在跑工具，用户发了一条修正指令（Steer）。很多框架直接把这条消息插到对话历史里。大模型的 Prompt Cache 依赖严格的前缀匹配。你在中间动一个字，后面的缓存全部失效。费用暴涨，延迟翻倍。

Pi 的解法：Append-Only Context（只增上下文） Pi 确立了一条铁律： 上下文只能在尾部增长。

运行中产生的配置变动、用户插话、延迟写入，先暂存到内存队列。
等当前回合（Turn）跑完，到达 Checkpoint（检查点） 时，统一追加到上下文末尾。
缓存前缀永远不变，KV Cache 命中率永远最高。

坑 2：进程挂了，留下半截死状态

现象：模型发起了两个工具调用，第一个执行完了，进程崩溃。重启后，对话历史里有调用指令却没有工具返回，下一次请求直接报 API 格式错误。

Pi 的解法：WAL 意图日志与预分配 ID Pi 借用了数据库系统的 Write-Ahead Logging 思想：

执行工具前：先写一条 step_attempt 意图记录到磁盘，里面包含预先分配好的结果 ID（ resultEntryId）。
执行完成后：用这个 ID 写入真实的工具结果。

  interface StepAttemptRecord extends RecordBase {
  type: "step_attempt";
  runId: string;
  step: "assistant" | "compaction" | "branch_summary";
  attempt: number;        // 重试次数写在磁盘上，进程重启也不会无限重试
  resultEntryId: string; // 预先指定的 Entry ID
}

系统重启时，恢复程序扫描日志。如果发现有意图记录但没有对应的结果，就能精准知道崩溃发生在哪个位置：能重试的自动重试，不能重试的自动写入一条 "interrupted" 占位， 绝不会出现残缺的孤儿状态。

坑 3：超大输出撑爆上下文，盲目截断导致模型幻觉

现象：执行一个命令吐出 50KB 日志，塞进上下文直接超限；如果直接把中间砍掉，模型看不到错误信息，开始胡乱猜测。

Pi 的解法（PR #8172 三级无损管道）：

> 50K 字符：内容全部写入磁盘文件（ ~/.pi/agent/cache/tool-spill/），上下文里只给简短预览和文件路径。
> 8K 字符：
- 完整内容写入磁盘。
- 上下文保留头 4096 字符 + 尾 1024 字符。
- 在字符串索引 0 处写入标记 [pruned — full at /path...]，并标明被裁剪的精确范围 [start, end)。
防死循环：模型调用读取工具去读溢出文件时，Pruner 自动放行，绝不二次截断。

实战测试数据（基于 GLM-5.3 和 DeepSeek-V4-Flash 的 19 次真实测试）：

未命中缓存的 Prefill Token 减少 72% ~ 88%。
每轮请求上下文占用减少 26% ~ 35%。
幻觉测试通过率 100%（0/9 幻觉），模型能通过精确偏移用 grep/ sed 从磁盘精准读回丢失的日志。

坑 4：多任务并发，状态文件被写烂

现象：多 Agent 系统让多个子任务并发修改同一个状态文件，在 Node.js 或 Python 异步环境下极易产生写覆盖和文件损坏。

Pi 的解法：Lanes（泳道）与不可变树 Pi 把会话结构分成了两层：

   会话树（只增、共享、无状态）:   a ─── b ─── c ─── d
                                       └─── e ─── f
 
 泳道（各自独立）:               main ──> 指向 d
                                slack_thread_1 ──> 指向 f

底层树（Tree）：所有节点只增不减，所有泳道共享，只读不改。
泳道（Lane）：相当于 Git 分支。每个 Lane 只有自己的指针和操作队列，两个 Lane 并行工作完全不需要加锁互斥。
单写者（Single Writer）：整个会话只有一个写入器，所有并发写操作通过单调递增的序列号排队追加。

坑 5：异步 Check-Then-Act 竞态

现象：代码判断“当前任务已结束”，准备关闭会话；就在这一瞬间，用户发来了 abort 或新消息。时序交错，导致中止失败或消息丢失。

Pi 的解法：Lane Mutation Line（泳道原子排队线） Pi 用一条极简的 Promise 链解决了所有竞态问题：

  let tail: Promise<unknown> = Promise.resolve();

function mutateLane<T>(job: () => Promise<T>): Promise<T> {
  const result = tail.then(job);
  tail = result.then(() => undefined, () => undefined);
  return result;
}

状态检查和落盘写入，必须打包成一个同步 Job 放进队列执行。
网络请求、模型调用、工具执行在队列外面跑，跑完了再排队写状态。
任何两个并发操作，在时间线上永远只有 [先 A 后 B] 或 [先 B 后 A]，没有第三种可能。

4. 确定性测试：线上代码怎么写，测试就怎么跑

很多框架的单测都是在 Mock 数据，一到线上就出 Bug。

Pi 定义了一个纯粹的副作用接口 Effects（ fx）：

  interface Effects {
  appendEntry(...): Promise<Entry>;
  appendRecord(...): Promise<T>;
  streamAssistant(...): Promise<SettledAssistantMessage>;
  executeTool(...): Promise<{ result: AgentToolResult; isError: boolean }>;
}

Agent 的所有逻辑，只能通过 fx 操作外部世界。

这带来了一个巨大的优势：

生产环境（ drive: "automatic"）： fx 直通系统，异步全速运行。
测试环境（ drive: "manual"）：每一个操作都会在 fx 边界停住。测试脚本可以像单步调试器一样，一步一步推着 Agent 走——可以在执行工具前强制断电，也可以在两个工具调用中间强行插入中断信号。

测试测的，就是线上跑的原版代码。

5. 总结

做 Agent，写 Prompt 只是第一步。

当系统进入真实工程，决定生死的是这几件事：

保住 KV Cache：不要随意插队改前缀。
做好 WAL 与崩溃恢复：把每一次动作先记下来再执行。
无损管理上下文：大输出落盘，保留偏移，给模型找回数据的能力。
管好并发与时序：单写者、只增树、排队写。

把这些脏活累活做干净，Agent 才能从玩具变成工具。

微软官方开源：一键把全新 Windows 11 变成干净、清爽的开发机

Sun, 27 Sep 2026 20:13:10 CST

重装 Windows、换新电脑，或者新建一台虚拟机，在安装好系统之后，最麻烦的还是配置环境：关闭 Widgets 和各种推荐，打开文件扩展名，装 Git、VS Code、Python、Node.js，再配置 WSL、Ubuntu……

这些事情都不难，就是又多又碎，又容易遗漏。

前段时间，微软开源了一个神奇的工具： Windows Developer Config，按照微软自己的说法就是：

一次操作即可将一台全新的 Windows 11 电脑变成一个干净、无干扰的开发工作站

标准安装

这款叫做 Windows Developer Config 的开源工具，用起来简单粗暴，只需要在 PowerShell 中运行：

irm https://aka.ms/devconfig/standard/setup.ps1 | iex

就可以实现：

删除/关闭

减少开始菜单、Windows Search 中的推荐和干扰内容
调整文件资源管理器中的最近项目、推荐等内容
减少部分 Windows 默认界面中的干扰项

安装/配置

VS Code、Git、GitHub CLI、GitHub Copilot CLI
Python 3.14 + uv
Node.js LTS + nvm
.NET SDK 10
Windows Terminal、PowerShell 7、Oh My Posh
WSL + Ubuntu
PowerToys、Coreutils for Windows、Windows App CLI
配置 Cascadia Mono NF 字体、深色模式、长路径等 Windows 设置

这是一套完整的开发环境，再也不需要手动设置了。

完整安装

而如果使用更激进的 Full 配置：

irm https://aka.ms/devconfig/full/setup.ps1 | iex

就可以实现：

关闭/调整

关闭 Widgets 小组件
关闭 Windows Search 中的 Web 搜索结果
关闭 搜索亮点（Search Highlights）
关闭开始菜单中的 推荐内容
关闭开始菜单中的 账户通知
关闭文件资源管理器「快速访问」中的 常用文件夹
关闭「快速访问」中的 最近文件
关闭文件资源管理器中的 推荐文件、云端文件
关闭文件资源管理器中的 同步提供商提示
隐藏 蓝牙托盘图标
关闭 PowerToys Always On Top 的通知
Edge 新标签页改成 空白页
跳过 Edge 首次运行欢迎界面
全局开启 勿扰模式，关闭 Toast 通知

安装

Windows Terminal
Intelligent Terminal
PowerShell 7
Git
GitHub CLI
Azure CLI
GitHub Copilot CLI
Visual Studio Code
.NET SDK 10
Python 3.14
uv
Node.js LTS
nvm for Windows
Coreutils for Windows
Oh My Posh
Windows App CLI
PowerToys
WSL + Ubuntu

同时配置：

开启 Developer Mode
开启 Windows Sudo
开启 Win32 长路径支持
开启 Remote Desktop
显示文件扩展名
显示隐藏文件
文件资源管理器默认打开「此电脑」
标题栏显示完整路径
任务栏右键增加「结束任务」
Windows 和应用切换为 深色模式
PowerShell 7 设为默认终端配置
配置 Oh My Posh
安装并使用 Cascadia Mono NF 字体
配置 GitHub Copilot Terminal Profile

WSL Comfort：顺手配置 WSL

Windows Developer Config 还提供了一套 WSL Comfort 工具，专门用来把刚装好的 WSL 命令行环境配置得更顺手。

只需要运行：

.\wsl-comfort\install.ps1

就会进入交互式设置，让你：

选择 zsh 或 bash，
自动安装常用工具： Starship、fzf、ripgrep、fd、bat、eza、zoxide、jq、Homebrew 等
配置 Cascadia Code Nerd Font 和 Windows Terminal 的 WSL Profile

还支持 -NonInteractive 无人值守安装。

另外，其中负责 Linux 环境配置的 comfort-shell-bootstrap.sh 也可以脱离 WSL，单独用于普通的 Ubuntu 主机。

也就是说，你可以非常容易的将同一套终端环境，复用到多台设备上。

只装需要的开发环境

对于不需要一键预装一大堆开发软件的用户来说，还有一个 Single-language workloads 功能，可以按需配置某一种语言或开发环境。

目前包括 TypeScript、Python、Go、Rust、Java、PHP、.NET、SQL、PowerShell、WinForms、WinUI 3、Windows App CLI 等。

例如，只需要 Python：

.\Workloads\python\install.ps1

就会自动安装 Python 3.14 + uv。

只需要 Java：

.\Workloads\java\install.ps1

则会安装 Microsoft Build of OpenJDK 25 LTS。

这样无论是准备一台完整的 Windows 开发机，还是只想快速搭一套 Python、Java、Rust 开发环境，都可以直接使用现成的配置。

获取

GitHub

怎么样，是不是有一种微软秘密武器的感觉？

开放权重模型逐渐形成了生态-软硬件、量化、Agent、推理引擎、后训练

Thu, 24 Sep 2026 11:43:22 CST

开放权重模型的竞争，已经不只是比谁 Benchmark 更高了。 Nathan Lambert 最新这篇文章，把能力、价格、下载量、真实调用和学术采用放到了一起看。一个很明显的变化是，中国开放权重模型已经形成了自己的生态。按他的统计，中国模型在 Hugging Face 的累计下载量约 32 亿，是美国的两倍；OpenRouter 上开放模型每周使用量已经从一年前约 1T Token 涨到 80T，其中中国模型占比超过 80%。学术圈也很明显。Qwen 现在出现在约 30% 的 AI 论文里，中国开放权重模型整体已经超过 40%。更关键的是，Lambert 估计最强的中国开放权重模型距离美国闭源前沿只差大约 2–5 个月。这当然是他的估计，但已经足够说明变化有多快。所以我现在更在意的不是「开放模型能不能追上闭源」。而是谁的模型会成为别人做研究、搭 Agent、做产品时默认踩着的那一层。一旦形成这种习惯，影响的就是整个开发生态。文章： interconnects.ai/p/the-current-…

不要被 AI 炒作愚弄

Wed, 23 Sep 2026 23:29:02 CST

Anthropic 声称其模型 Claude Mythos 在发现软件漏洞上胜过大多数安全专家。随后发生了 OpenAI–Hugging Face 安全事件，此后 Anthropic（自豪）和 Meta（不情愿）也披露了各自模型的类似事件。紧接着 Anthropic 宣称其模型取得了数学领域的突破；OpenAI 也声称自己取得了数学突破。Anthropic 工程师 Jacob Coxon 在宣布离职时引发了广泛关注，他声称该公司与 OpenAI 正“冲向自我进化的超级智能，并拿我们的生命在赌博”。媒体大肆报道了这些事件，且沿用了相关公司赋予其软件的拟人化叙事——即把软件描绘成不仅功能强大，而且已初具通用人工智能（AGI）雏形的产物。但深入研究的专家则给出了不同的答案，虽然这些发现并不能吸引眼球。网络安全专家指出，涉及模型的安全事件更多是 OpenAI 的疏忽大意，未能采取基本的安全措施，而不是“模型失控”或“AI 智能体创造文明”。OpenAI 模型在解决数学难题上的突破其原创性也相当可疑。数学家公开对 AI 企业利用其专业领域进行炒作提出了警告。AI 公司通过炒作模型失控也将自己置身事外，将责任归咎于大模型而不是公司本身，逃避应承担的责任。以 OpenAI 为例，当该公司开发的恶意软件被用于入侵另一家公司时，媒体、名人和议员谈论是“失控模型”而不是 OpenAI 的责任，仿佛大模型真的会自动发动攻击，公众的注意力被转移到虚构的“超级智能”的恐惧之上。我们不要被 AI 公司的炒作所愚弄。

Jev 工程学：为 coding agent 而作

Wed, 23 Sep 2026 16:00:35 CST

Jev 工程学：为 coding agent 而作

2026 年 Jev 工程实践工作笔记副标题：TypeSafe 创始人的 Jev 构建蓝图 A Synthesis for Study · Based on design notes by Diogo Almeida (TypeSafe) 独立汇编，2026 年 9 月。与 TypeSafe 无隶属关系，亦未获其背书。

本文是原文 PDF的完整中文翻译，保留原有结构与全部七张插图。

本仓库现在有两份文档

本页（根目录）：第三方根据笔记 汇编整理的工作笔记——结构正式、有图表、「六个症状」已表格化

source-notes/：作者的 原始设计笔记——保留了原始项目符号结构、随手记的链接，以及尚未定型的口语化表达

两份对照读，能看到从笔记到成文的加工过程。原始笔记里有汇编版没有的内容（如 SLOP 子任务拆解、附录 2 引用的原始推文、以及作者的推理过程）。

图 1. Jev harness。显式状态（左）以可寻址、带类型的块存储。Jev（右）回答每一轮的问题：显示哪些块、是否复用缓存、用哪个模型和工具、以及一条命令能否执行。上下文组装层与路由器驱动运行时，运行时以「片段优先」的方式披露数百个工具，并在安全策略下把工作路由到前沿模型、子 agent、廉价模型或后台模型。

摘要

Coding agent 简单得出人意料。大多数就是一个模型加少量工具的 while 循环，而模型本身之外几乎没有什么有意义的创新。

这份笔记综合了 TypeSafe 创始人 Diogo Almeida 的设计笔记，讲的是围绕 Jev 构建 coding agent 的思路——Jev 是 TypeSafe 的决策模型，把结构化状态转换成类型化输出，例如 choice、score 和 noul 决策。

笔记从一个挑衅性的问题开始： 如果语言模型没有 KV cache，你会怎么设计一个 coding agent？

这个问题暴露了当前 agent 不加审视就继承的六个设计选择： 亏损的路由、挤占上下文的工具调用、盲目压缩的 compaction、几乎不触发的子 agent、丢弃状态的重启、以及电池之争。

我们呈现笔记提出的替代架构：一个围绕显式、带类型状态构建的 harness，由 Jev 做每一轮的决策。其中上下文块按查询逐个打分，路由定价时计入重新处理的成本，工具分级披露，指令按条件加载，只读的后台任务共享一次检索。

我们还演算一遍路由算术、真实 agent 会话的 token 经济学，以及按文件敏感度（而不仅是难度）路由的安全论证。

索引词：Jev、TypeSafe、coding agent、harness 工程、KV cache、上下文工程、模型路由、子 agent、工具调用、compaction、AGENTS.md、后台 agent。

I. 为什么还要再做一个 agent

笔记以四个工作假设开场。

第一，coding agent 很简单，尤其是 agent 的部分：一个循环、一个模型、少量工具。

第二，现有 agent 中最好的部分可以复用。前沿模型都能通过 API 拿到，开源项目提供了灵感和甚至 UI 组件，而只有少数领域（比如 MCP 服务器的认证）才带有真正的复杂性。

第三，第一方 agent 的成本优势可能在缩小，因为用量正从捆绑订阅转向按量付费的 API 定价。

第四，也是最重要的，有些能力只能原生构建。它们无法作为插件交付给别人的 agent，因为它们要求控制 每一轮上下文是如何被组装的。

第四个假设就是论点。 如果 agent 只是一个循环，那么杠杆不在循环里。杠杆在于循环每一轮喂给模型的东西。

A. Jev 站在哪里

Jev 不是写代码的模型，它是旁边那层决策层。

harness 把当前应用状态（目标、上下文、规则、可用动作、之前的动作）和一个预定义问题交给 Jev，Jev 返回一个类型化答案：choice、score 或 noul，每个都带概率。然后由前沿模型、子 agent、工具和确定性代码去做实际工作。

因为输出是类型化的而不是自由文本，harness 可以验证它、施加阈值、基于它分支，而不必解析散文。

这份笔记里每一个原生功能，底层都是在高频决策点上问 Jev 一个问题。 每个会话被问上千次，那些小决策才是杠杆所在。

B. 组织起一切的那个问题

笔记描述了一个他喜欢问其他工程师的问题： 如果语言模型没有 KV cache，你会怎么设计 coding agent？

KV cache 是 agent 被建成「只追加对话记录」的原因。复用缓存前缀很便宜；改动上下文早期的东西会让缓存失效，迫使模型重新处理改动之后的一切。 这个单一的经济事实塑造了当前 agent 的几乎每一个设计决策——而且通常没人把这件事说出来。

想象把缓存拿掉，会做两件事。它允许一种为 Jev 设计的、状态显式的架构—— 上下文是被组装的，而不是被累积的。同时它揭示为什么「把简单活路由给便宜模型」这种直觉上正确的想法在实践中会失败。

笔记管这叫 「KV cache 的暴政」。

II. KV cache 的六个症状

症状	为什么存在	代价
1. 路由失效	交还给大模型时需要重新处理上下文	混合路由比纯前沿更贵
2. 工具挤占上下文	schema 必须待在系统消息里	token 花在无关工具上；选择质量下降
3. Compaction	假设所有未来轮次共享同一份状态	查询无关的压缩丢掉了后面需要的东西
4. 子 agent 稀少	决定传什么上下文进去、什么合并回来很难	几乎没有自动并行
5. 重启	有状态的对话记录会随时间腐坏	相关的旧状态跟着坏状态一起被丢弃
6. 电池之争	每个内置能力都永久消耗上下文	在易用与强大之间被迫二选一

A. 路由不工作

直觉方案是让前沿模型规划、把执行交给便宜模型、再让前沿模型回来审查。笔记用 Opus（$5 输入 / $25 输出每百万 token）和 Sonnet（$3 / $15）的标价算了这笔账。设 X 是上下文 token，Y 是生成的输出 token，Z 是工作中额外读入的 token（比如命令输出和文件读取）。

      路径 1  纯 Opus
  生成        25·Y
  读取        5·Z
  合计        25Y + 5Z

路径 2  Opus → Sonnet → Opus
  Sonnet 载入上下文         3·X
  Sonnet 生成               15·Y
  Sonnet 读取               3·Z
  Opus 重新加载变化的部分    5·(Y+Z)
  合计                      3X + 20Y + 8Z

当会话很长（X 大）、或工作读取远多于写入、或两者兼有时，路径 2 更贵。 代入一个合理的会话形态 X = 0.65、Y = 0.12、Z = 0.23，纯 Opus 是 4.15，路由路径是 6.19。

留在前沿模型上的成本，大约是那条本该省钱的路径的三分之二。

图 2. 路由陷阱。把执行委派给便宜模型，会在下行时加一次上下文载入、在回程时加一次重新处理，两者加起来超过了每 token 的折扣。

教训不是「路由是错的」，而是 按 token 定价、而不是按上下文重建定价的路由是错的。路由只有在两个条件下才可行： harness 能给便宜模型一个小而专用的上下文（而不是完整记录），且回程不强迫前沿模型重读助手产出的一切。

B. 工具调用是个奇怪的取舍

工具必须提前在系统消息里声明，带着完整的参数 schema，不管这轮用不用得上。这消耗大量上下文，而且笔记的判断是： 它并不产生特别聪明的工具选择。

工作假设是：模型在「高基数」（一次给太多工具）和「离策略工具调用」（工具的使用模式与训练时见过的不符）的某种组合上挣扎。

这可能就是为什么 skills——加载一句短描述、细节延后——常常胜过裸工具列表和 MCP 服务器。

C. Compaction 存在

如果每个未来轮次都想要同一份共享状态，compaction 就完全合理。笔记质疑的正是这个假设。

Compaction 试图做通用压缩，这既难又有损。而查询感知的压缩容易得多：如果你知道下一个问题是什么，你就知道该留什么。

在问题已知之前写下的摘要，一定会丢掉问题需要的东西。

D. 子 agent 很平庸

模型并行的程度低于预期。怀疑的原因在状态管理： 决定父上下文的哪些部分要传进去、每个子 agent 的发现中哪些要合并回来。

当这个决策既昂贵又容易出错时，模型就会回避它。

E. 重启存在

重启会话是对话记录漂移或损坏时的标准补救。 但它把坏状态和好状态一起丢掉了。

有了可寻址状态，替代方案是干净启动、按需只重新加载仍然相关的旧块。

F. 电池并非内置

关于 agent 是否该内置能力，有一场持续的争论。今天它是在「易用」（重度内置的 agent 在一端）和「强大」（Claude Code、Codex 这类高级用户工具在另一端）之间的取舍。

这个取舍存在，仅仅因为每块电池都永久消耗上下文。把那个成本拿掉，争论就消解了。

III. token 到底花在哪

在重新设计 harness 之前，先搞清楚一次会话里哪个部分吃掉了预算。下表估算典型 CLI coding agent 会话中，各子任务占总处理 token 的份额。 这是输入密集视角，所以重复读取每次计数。

子任务	约占	说明
读文件内容	30–40%	最大项；文件作为上下文被反复读取
搜索代码库	10–18%	grep、glob、列表；输出噪音大
命令输出	10–20%	堆栈和日志在失败时爆开
系统提示、工具 schema、AGENTS.md	5–12%	每一轮都付的固定开销
对话重放放大器	—	为什么上面每一项都被重复计数
推理与规划	5–15%	困难调试时更高
写和编辑代码	4–10%	diff 和 str_replace 编辑很紧凑
向用户解释	2–5%	CLI agent 默认简洁

图 3. 检索占主导。读取、搜索和命令输出合计约占处理 token 的三分之二；写代码不到十分之一。

最触目惊心的是倒数第二行：写代码，也就是 coding agent 存在的理由，是其中最小的开支项之一。读取和搜索占主导。

独立的分析指向同一方向： 微软的 fastcontext 项目报告，在 GPT-5.4 的轨迹里，读取和搜索占所有工具调用轮次的 56.2%、占主 agent 总 token 的 46.5%。

如果这能推广，coding agent 里最大的效率收益不是更好的模型或更好的 diff 格式，而是更聪明的检索。

IV. 基础层：权限与工具路由

有两项改进可以集成到任何现有 agent 里，无论原生与否。

A. 可编程权限

每一条 agent 运行的命令都提出「它到底该不该跑」的问题。Claude 的 auto 模式用分类器回答这个。 笔记提议走得更远：权限表达为对「什么允许、什么不允许」的可编程查询，而且在风险足够高时做更深的检查——比如在执行前读取 Python 或 shell 文件的内容，而不是只批准命令名。

policy "exec":deny   if command touches ~/.ssh or .env*deny   if script contents contain network egressand task.scope != "deploy"ask    if command writes outside repo rootallow  if command in read_only_setallow  if tests/ and exit code is expected

B. harness 作为工具路由器

不是把每个工具 schema 都暴露给模型，而是让 harness 坐在意图和调用之间。 模型用纯文本描述它想干什么。harness 然后用一串类型化的 Jev 调用来选出最合适的那个工具（或前几名候选），并构造参数。

模型永远不必在上下文里持有几百个 schema，而错误的参数类型会变成验证错误，而不是静默失败。

V. 元注意力：把上下文本身当成决策

核心提议去掉了「上下文是静态的」这个观念。

对每一个用户查询，harness 问 Jev 两件事：

第一，之前的上下文有多好——复用现有 KV cache 是对的吗，还是从头重建更便宜也更好？ 这被框定为一个显式的、成本感知的决策，而不是默认行为。

第二，如何构造一个包含所有相关的、且不含任何多余的新上下文。

最简单的形态是：对每一个上下文块做一次 noul——每次工具调用的输入、每次工具调用的输出、每一段内部推理、以及可能每一次与用户的交流。 后续版本把分数换成可见性级别。

图 4. 可见性阶梯。同一个块可以被隐藏、简短总结、详细总结或完整展示，取决于当前查询。 这就是查询感知的压缩——compaction 所缺的那个属性。

收益是： compaction 背后的想法活下来了，但它的主要缺陷消失了。Compaction 在知道问题之前压缩一次；阶梯在知道问题之后按查询压缩。

一个 2400 行的 grep 结果，对某个问题可以是十二条相关命中，对下一个问题可以是不可见的——而它从未从状态里被删除。

笔记还加了一个值得注意的视觉想法： 如果 harness 能热力图显示 grep 输出里哪部分相关，它就能按预算允许的程度随意过滤那份输出。而且，笔记观察到， 它看起来也会很酷。

VI. 路由与子 agent 重访

一等公民的动态上下文，是让路由重新可行的原因。

一旦 harness 能为子任务构造一个小而相关的上下文，把这个子任务交给更便宜或更快的模型就不需要便宜模型载入整个会话， 而结果可以作为被评分的块合并回来，而不是一份前沿模型必须重读的记录。

同一机制解锁了子 agent。 笔记的猜测是：今天子 agent 成本的大部分，是决定传什么上下文的工作——相比之下，用户敲一条简单指令反而容易。

如果构造那个上下文变得便宜且自动，子 agent 就能用得频繁得多。

它还打开了一个面向用户的控制： 多花钱换更快或更好的结果，还是保守运行、尽量少花。

A. 极端并行

如果派发任务变得便宜，很多任务会同时跑，harness 就继承了并发系统的全部问题： 同步原语、agent 间通信、多个 agent 共享状态时的写冲突。

笔记建议用带锁的共享状态。 而显式区分读与写让它变得可处理，因为只读任务永远不会争锁。

B. 目标去重

对 /goal 这类目标驱动的循环，一个悬而未决的问题是：agent 会不会重复劳动。

一个缓解措施： 在派发任何子任务之前，把它注册为子目标，并与所有历史子目标去重。已经做过的、或正在飞行中的工作，永远不会被启动两次。

VII. 工具与技能，从第一性原理出发

笔记主张在「今天总是加载的工具」和「按需加载的 skills」之间加一层。

模型无法提出一个它不知道存在的动作，所以它需要短片段来描述有什么可用，类似于 skill 描述。 但这些片段不必住在系统消息里——它们可以在相关时动态加载。

它们背后是「在需要时倾倒出可用动作的完整 schema」的能力，类似一个工具搜索工具。

把这一切绑在一起的要求是：这些东西在不再需要之后，都不能污染上下文。

图 5. 三级披露。模型看到一张廉价的全局地图，只为它选中的东西付细节的钱，用完之后把细节从上下文中丢掉。

如果这能成，第二节里的电池之争就消失了：当一个内置能力在被使用之前几乎不花成本，agent 就能带着几百个工具和几千页文档发布。

笔记还点出第二个好处： 近乎零成本的集成是强有力的联合营销渠道，而且它们让事情「就是能用」。

A. 更好的电池

很多社区工具承诺帮助 agent，实际上并没有。笔记举了一个工具输出压缩器作为例子，并猜测原因： 模型并不原生理解这些工具。

一个原生 harness 可以发布第一方的提示词，教模型如何使用每一个工具——实际上相当于每个工具配一个内置的子 agent 或 skill。而它干净的上下文意味着工具的自定义逻辑不会污染会话的其余部分。

这里也有营销角度： 为你当前流行的工具发布集成，能让 agent 保持在对话之中。

VIII. 条件化指令

今天的 AGENTS.md 是全量加载的。笔记提议按条件加载。

改前端代码就加载风格指南；在某个子目录里工作就加载那个目录的坑文件（ 而且笔记建议每个子目录都该有一个）。

图 6. 条件化 AGENTS.md。指令附着到条件上而不是会话上，而且条件片段会被钉住，使 compaction 无法把它摘要掉。

这像 skills，但笔记画出了一个区别： skills 通常意味着「现在做这个」。条件化指令意味着「把这段记在某处」。

第二种还需要一个 skills 没有的属性：免疫于压缩。一个在长会话早期加载的 skill 最终会被压缩或摘要掉； 而一个绑定到条件的指令会在条件成立时被重新加载。

笔记在普通聊天里观察到同样的需求：请求摘要应该拉入一个偏好的格式；请求用自己风格写作应该拉入样本和一份「不要什么」的清单；请求代码应该拉入风格指南和一条「不要加一百万条断言」的提示。

A. 结构化 skills

取决于 harness 变得多可编程，skills 可以携带行为变更而不只是指令，类似 Claude Code 的 skill hooks 但更强大。

笔记指出的当前 hook 系统的一个限制是：一旦加上，hook 就永久留在会话里。结构化 skills 会随触发它们的条件附着和脱离行为。

B. 递归语言模型

一个相关方向是递归语言模型（recursive language models）的方法，它把 agent 更多的状态当作显式变量而不是对话记录文本。

一个状态保存在具名变量里的世界，可能比「状态就是上下文窗口里恰好剩下的那些东西」的世界干净得多。

IX. 安全感知的路由

今天的路由围绕难度和成本。 笔记加了第三个轴：信任。

一些通过低价供应商提供的开放权重模型比前沿 API 便宜得多，而笔记提出的担忧是： 经过某些端点的数据可能不再私有。

提议是给每个子任务一个「可能触碰哪些文件」的估计，把策略附着到文件类型上，并据此路由。

可能触碰的文件	策略	可用模型
公开文档、开源依赖	开放	任意，最便宜的优先
应用代码	标准	经过审查的供应商
密钥、env、基础设施配置	受限	只用第一方前沿模型
专有研究代码	自定义	排除指定供应商

最后一行反映了一个更广的观点： 难度和成本不是路由的唯一理由。

一个团队可能因为自己在做模型研究而避开某家供应商的模型，或因为安全工作而避开某些供应商。 一旦路由是策略驱动的，这些偏好就变成配置而不是纪律。

X. 后台处理

笔记识别出几种流行 agent 工作流里的一个共同模式：

构建随工作进展而并行更新的 HTML 页面
「理解而非生成才是新瓶颈」的论点
在后台生成 eval
用几张图加极少的字解释系统的 ELI5 技能
让 agent 维护一个小型已部署的进度页面，带截图和笔记， 可以在长任务期间从手机查看

还有一个相关的生产模式： 把线上流量镜像到候选模型，自动生成约一天的 eval，然后才决定是否切换。

它们的共同点是： 在后台运行、作为正常工作流的扩展、而且都是当前代码库状态的只读函数。跨模型审查（让一家供应商的 agent 审查另一家的产出）属于同一模式。

图 7. 显式状态上的后台处理。找出与某个改动相关什么的这项昂贵工作，只做一次，由每个只读后台任务共享。

这正是 Jev 论点兑现的地方。以 Jev 为中心的 harness 必须精确知道上下文里有什么、以及每个操作是读还是写。 找出与某个代码改动相关的信息，是件不平凡的工作。

如果这份检索在所有后台任务间共享、而不是每个任务重复一遍，运行它们就会便宜得多，也就能经济地跑更多。考虑到第三节的发现——检索占主导地位—— 共享它就是最大的单项节省。

把读写显式区分开，用笔记的话说， 最终应该给 agent 超能力。

XI. 电池候选清单

笔记最后列了几个可以被原生集成的开源项目，每个都附了「以 Jev 为中心的 harness 会怎么用它」的设计说明。

项目	角色	原生角度
headroom	上下文压缩器	用分类器检查压缩是否保住了需要的事实
rtk	工具输出压缩	第一方提示，让模型理解它
ast-grep	结构化搜索	加载一次手册，生成 N 个查询，按相关性过滤
ast-outline	结构化大纲	层级调用：选出要检查的子树
fastcontext	仓库探索子 agent	路由到它，或用结构替代它的搜索
fff	路径与内容搜索	内存索引、频率排序，长会话里比 ripgrep 快

XII. 结论

设计笔记提出的论点 说起来容易、做起来难：

coding agent 是简单的循环，而杠杆不在循环里。杠杆在于 harness 每一轮放在模型面前的是什么——而今天这个决定是由默认值做的，由一份围绕 KV cache 经济性塑造的、只追加的对话记录做的。

把缓存拿掉当作思想实验，六个熟悉的行为就变了样：

路由失败是因为上下文被重新处理，不是因为便宜模型弱
工具挤满窗口是因为它们必须提前声明
Compaction 丢信息是因为它在问题已知之前压缩
子 agent 稀少是因为传状态很难
重启把好状态和坏状态一起丢掉
电池之争之所以存在，只是因为每个内置能力永久消耗上下文

所提议的 harness 用一个动作应对全部六项： 让状态显式且带类型，让 Jev 按查询决定上下文、路由、工具和权限。

块在可见性阶梯上被打分。路由按上下文重建定价。工具分级披露。指令附着到条件上。后台任务共享一次检索。

这些都不需要更好的模型。它需要把上下文窗口当作一件被有意组装的东西，而不是一件偶然累积的东西。

来源说明

独立汇编，供研究之用。与 TypeSafe 无隶属关系，亦未获其背书。Jev 依据 TypeSafe 材料描述为一个返回带概率的类型化 choice、score 和 noul 决策的决策模型。

核心论点、路由算术、六个症状以及所提议的功能，来自 TypeSafe 创始人 Diogo Almeida 提供给汇编者的设计笔记。

读取与搜索的份额数字（GPT-5.4 轨迹中占工具调用轮次的 56.2%、占主 agent token 的 46.5%）如微软 fastcontext 项目所报告。

token 份额表是对 CLI coding agent 会话的示意性估计。递归语言模型：A. Zhang, 2025。工具引用：headroom、rtk、ast-grep、ast-outline、fastcontext、fff（GitHub）。模型标价取自笔记所用，可能已经变动。所有图表均为原文所绘。

关于本翻译

原文： assets/original.pdf（12 页，WeasyPrint 生成）
原文纯文本： assets/original-text.txt
插图：从原 PDF 的矢量图表按 300 DPI 精确裁切，共 7 张，位于 figures/
翻译保留原章节编号与结构；英文原文的排版错误（如小标题的大小写异常 sIX sYMPTOMs OF THE Kv CACHE）在译文中已按正常书写呈现
上游原始笔记： source-notes/（本文档所依据的设计笔记，及其中文翻译）

人工智能软硬件推理优化进行中-Inside the Inference Hardware Revolution Of 2026 - IEEE Spectrum

Wed, 16 Sep 2026 09:30:27 CST

IEEE Spectrum《The AI Inference Revolution Is Here》（Matthew S. Smith，2026年9月15日）核心内容总结

文章指出，2020年以来AI的重心在于训练更大的模型，而到2026年，推理（inference）已取代训练成为行业焦点。原因有三：模型真正变得好用、用户激增；如今大量模型是"推理模型"，会通过思维链多次自我提问，高推理强度时输出的文本量可达低强度的约20倍；以及智能体（agentic AI）让推理从实时问答变成全天候自主运行。

技术上，推理与训练的计算特征不同。由于模型是自回归的，生成每个新词元都要读取全部权重和此前的上下文。回复分为两个阶段：预填充（prefill）并行处理整个提示词、计算注意力，适合GPU；解码（decode）逐词元生成，每预测一个词元都要从内存中读出整个模型，再加上KV缓存的开销。数据搬运所需带宽常常超出硬件能力，导致计算单元空转——有研究发现运行开源大模型的英伟达H100有50%到80%的时间处于闲置状态。

因此内存成为主战场，各家路线各异：d-Matrix把计算芯片直接堆叠在DRAM之上，将数据传输距离压缩到微米级；Majestic Labs则改进内存接口，用专有铜链路与聚合芯片连接远至约一米外的廉价DRAM，单机架可支持高达128TB内存，远超英伟达GB300 NVL72约20TB的HBM3E；SK海力士等则押注已量产的HBM4。

巨头选择"分工组合"：英伟达用Rubin GPU处理计算密集的预填充，用片上SRAM丰富的Groq 3 LPU处理内存密集的解码；AWS则将Trainium与Cerebras晶圆级引擎配对，后者把整片晶圆做成单芯片，集成超过4万亿个晶体管和44GB片上SRAM。

软件侧，量化（如NVFP4、MXFP4）以极小的精度损失换取数倍性能；Tensordyne用对数数系以加法替代乘法，Etched则把Transformer架构直接固化进硅片。文章最后认为，不会有单一赢家——推理硬件将像当年的CPU一样，沿多条路径并行演进。

Since about 2020,AI has largely focused on training bigger and better models. Large language models (LLMs) ballooned from millions of parameters to trillions. This proved effective: The largest version of OpenAI’s GPT-3, released in 2020, correctly answeredjust 43.9 percent of questions on a popular knowledge-and-reasoning benchmark. Just four years later, GPT-4o reacheda score of 88.7 percent on the same exam, effectively matching those of human experts.

Advanced AI labs are still training ever larger models, but that training has somewhat receded to the background of the AI conversation. In 2026, inference—the use of trained models to produce code, write essays, or make images of ourselves as elves—has come to the forefront.

“It’s like training is yesterday’s news,” says Matt Kimball, principal data-center analyst at Moor Insights & Strategy. “All that any chief information officer wants to talk about is inference.” Nvidia CEO Jensen Huang, speaking at the company’s GTC 2026 conference, touted this change as the “ inflection point of inference.”

Part of what’s caused the shift is very simple: LLMs are becoming useful, so people are using them. On top of that, many models on the market today are reasoning models. In response to a user’s query, they run inference not just once but multiple times, reprompting themselves in a process called chain of thought. Reasoning models generate longer outputs, and models with high reasoning effort can produce up to 20 timesas much text as those with low or no effort. Adding even more to the world’s inference workload, the rise of agentic AIhas resulted in inference running not just as a real-time response to a user’s query but also around the clock, working autonomously toward a user-defined goal.

Amazon’s Trainium chip was originally designed for AI training. However, Amazon Web Services chose to break up AI inference into two parts, with Trainium running the more computationally complex portion and Cerebras’s wafer-scale engine taking on the more memory-intensive portion. Amazon

The resulting explosion in inference demand has led to unexpected alliances among tech giants. OpenAIand Amazonhave deployed chips the size of a dinner platedesigned by Cerebras, despite Amazon having its own Trainiumchips. Nvidia boughtkey talent and intellectual property from AI-inference startup Groqin a controversial deal worth US $20 billion. And Anthropicis payingLLM competitor SpaceXAIover a billion dollars per month to lease spare compute.

Although they might seem similar, AI training and AI inference are computationally different. These big moves from tech giants signal that in order to support the inference demand, we’re going to need a very different mix of hardware than experts may have expected even a couple of years ago.

How does AI inference differ from AI training?

An untrained LLM is like a jumble of Scrabble tiles on a table. Instead of single letters, though, the tiles show fragments of words, called tokens. Everything you’d need to write almost anything is present, but nothing makes sense.

Training a model organizes this jumble using a guessing game played at scale. The model is shown real text with the next token hidden and asked to predict what comes next. After each guess, the correct token is revealed and then compared to the prediction, and the difference is used to calculate the model’s accuracy. The game is played not with a single sentence but over billions of passages.

While a real game of Scrabble can be played over a bag of chips and a few drinks, AI training is computationally intense. The model updates its parameters through backpropagation, a process that repeatedly calculates how each of a model’s billions or trillions of parameters should shift to make the next prediction better. This is why tech giants are buildinglarger data centers than ever before.

Eventually the model’s creator decides further training isn’t worth the cost, and the guessing game stops. Backpropagation ends, the parameters are frozen, and the LLM becomes a pretrained model. Fine-tuning—a short training run on smaller, more specialized data—adds final tweaks, and the model is deployed.

Nvidia’s Groq 3 language-processing unit minimizes data movement by placing on-chip SRAM memory and computational blocks in the order they are needed on-chip.

Nvidia

Next comes inference. This is the process of using the deployed model, which, now that it’s been trained, has learned to spit out Scrabble tiles—tokens—in a sensible order.

You might think that AI inference is less computationally demanding because the backpropagation calculations used to update parameters are eliminated. But Sudeep Bhoja, founder and CTO of the inference-hardware company d-Matrix, explains that inference adds new challenges.

The models are “autoregressive” in nature. That is, the next output depends on the previous one. “So to generate the next token, you have to read all of the weights and all of the [context] from the previous token,” explains Bhoja. The context includes all of your prompts, all of the LLM’s replies, and all of the files you upload. It’s a lot of data and a lot of processing.

An LLM generates its reply in two phases: prefill and decode. Prefill is the model reading a prompt. It processes every token at once, computing how each token relates to all the others. This operation is called attention, and it’s a defining characteristic of the transformer architecture behind modern LLMs. It allows them to respond to a word in its sentence, paragraph, and larger context rather than on its own. Think of it like arranging Scrabble tiles before you place them in a game. Many players move tiles around to imagine how they connect. Self-attention plays a similar role, though instead of moving physical tiles, each token sends a query to the others and receives a score indicating the token’s relevance.

These queries result in two types of vectors: the keys and values. They are typically placed in a store called the KV cache. This isn’t strictly required, as a model could instead recompute these vectors with each new token it generates. But nearly all LLMs use a KV cache to reduce how much computing they do. The KV cache is stored in memory and becomes a scratchpad to which the LLM can return to understand a conversation, and though it starts small, it can swell to dozens of gigabytes.

Prefill is a problem that can be easily divided up and worked on in parallel. This is why GPUs became the dominant AI accelerator as LLMs surged in popularity. Graphics rasterization (computing the color of every pixel on a screen) is also massively parallel, so GPU architectures were a natural fit.

Cerebras’s wafer-scale engine chips maximize memory bandwidth by keeping everything—both memory and computational units—side by side on the dinner-plate-size chips.

Cerebras

Next comes decode. Here, the model generates its reply one token at a time. At each step it takes the most recent token, weighs it against everything in the KV cache, uses that information to predict the next token, and adds the new token’s key and value to the cache. Then it repeats in sequence, token by token.

This is where the autoregressive nature of the model works against inference speed. Predicting each token requires reading the entire model from memory, and that model consists of possibly tens to hundreds of gigabytes of parameters (the numbers representing what the model learned in training). Crucially, this is in addition to the memory required to store the KV cache.

As a result, the movement of all this data through memory often requires more bandwidth than inference hardware has available. So at least some of the computing parts of a GPU sit idle as it waits for data. Researchers foundthat Nvidia H100 GPUs running open-source LLMs sit idle 50 to 80 percent of the time.

Memory’s role in inferencing

Shahriar “Sha” Rabii, former head of silicon engineering at Meta and cofounder of the AI startup Majestic Labs, says idled processors are why many companies that are trying to improve AI-inference performance are laser-focused on memory. “With the GPU-based approach, you end up greatly over-provisioning compute and starved on memory. That’s driving the big [memory] scale out,” he says.

Bhoja’s d-Matrix and Rabii’s Majestic Labs both focus on this memory bottleneck. However, their companies imagine different solutions.

d-Matrix’s second-generation AI accelerator, Raptor, aims to improve inference performance by minimizing the distance between compute and memory. The GPUs in most current AI-inference deployments do this by placing high-bandwidth memory (HBM) around the perimeter of the GPU. Each HBM is a stack of DRAM dies linked together and connected to a superfast interface to the GPU. This is great for training, but for inference, the amount of memory you can stack this way and the bandwidth it can provide leave something to be desired.

d-Matrix’s stacked-die architecture

Memory bandwidth—how quickly data can be read from memory to logic—is a major bottleneck in AI inference. The startup d-Matrix is increasing that bandwidth by stacking the logic die directly on top of the memory, in this case DRAM. This allows for lots of extremely short interconnects.

Chris Philpot

d-Matrix’s Raptor removes that bottleneck by stacking an AI accelerator on a DRAM die. Instead of stacking memory, d-Matrix stacks memory and compute. Bhoja says this reduces the distance that data must travel to “micrometers instead of millimeters.” Like building a skyscraper, going vertical makes it possible to do more inside the same physical footprint.

Majestic takes the opposite approach. Instead of trying to minimize the length that data must travel between compute and memory, the company is focused on improving the memory interface to accommodate longer wire traces while keeping bandwidth high. Longer wires allow Majestic to connect memory stacks that aren’t directly next to the GPU, removing the space limitation of HBM.

“A memory interface has a very short physical distance it can operate over. In the case of HBM, it’s up to 2 or 3 millimeters. You have this shoreline around the periphery, which is the only place where you can put HBM,” says Rabii.

Majestic claimsits memory interface can transmit bits as far as about a meter. That’s achieved with a proprietary copper link and a memory-aggregator chip that coordinates data. “The aggregator is the endpoint for the high-speed interface and a way to fan out to many, many commodity DRAM chips,” says Rabii. Because of this, Majestic can support up to 128 terabytes of DRAM memory in a single server rack—a significant increase over Nvidia’s GB300 NVL72 rack, which has about 20 TB of HBM3E.

Majestic Labs’ memory-aggregation architecture

Majestic Labs plans to satisfy AI’s memory appetite via a proprietary interconnect and a memory-aggregator chip, allowing a single rack access to up to 128 terabytes of cheap DRAM memory.

Chris Philpot

d-Matrix and Majestic have one thing in common: Instead of HBM, they both use off-the-shelf DRAM. This is the most common type of computer memory in the world; it’s in everything from smartphones to cars. Memory analyst Jim Handysays HBM costs two to three times as much as DRAM. d-Matrix and Majestic chose DRAM in part because of this price advantage. However, the proponents of HBM, which include memory giants like Samsungand SK Hynix, aren’t sitting idle.

HBM4, the latest version of HBM memory, is now in production and will be used by Nvidia’s Vera Rubin GPU, which is expected to ship in the second half of 2026. Hoshik Kim, head of memory-systems research at SK Hynix, says HBM4 “will decisively break the memory bottlenecks constraining AI inference today” by doubling HBM’s maximum memory bandwidth and increasing the amount of HBM memory per stack.

Combining chips for faster inference

The big players—Nvidia and Amazon—are going for an all-chips-on-deck approach. Nvidia’s GPUs and Amazon’s Trainium training accelerators are still great for part of the inference workload: the prefill stage, where all the context keys and values are calculated. But to accelerate decode, the part where new tokens are generated, they are looking to new, memory-centric architectures from smaller players.

In Nvidia’s case, the smaller player was Groq (not to be confused with Grok, the family of LLMs trained by SpaceXAI). Nvidia purchased intellectual property and hired talent from Groq at the end of 2025, and just three months later at the Nvidia’s GTC 2026 conference, Jensen Huang unveiledthe Nvidia Groq 3 language-processing unit ( LPU). Groq’s architecture relies on memory—in its case, SRAM—built directly into the chip’s architecture.

Unless you’re a chip architect, or a hardcore PC gamer,you probably never give SRAM a thought. SRAM has the benefit of being tightly integrated into a compute chip’s architecture—it’s on the same piece of silicon as the processor—and has the drawback of being less dense and more expensive than DRAM. Most chips include only a few dozen megabytes of SRAM. AI inference, however, has ignited new interest in SRAM as a means of bringing the model weights stored in memory closer to compute.

Ian Buck, vice-president and general manager of hyperscale and high-performance computing at Nvidia, says the LPU has a much different set of priorities than the company’s GPUs. The LPU has far less raw computing power than a standard GPU, but it gains 500 megabytes of on-die SRAM connected directly to its floating-point math units. “The benefit is the memory bandwidth. The LPU has seven times the memory bandwidth of the GPU,” he says.

Between the Rubin GPU and the Groq LPU, prefill and decode can both be accelerated to get the best of both worlds, the theory goes. “We do all the attention math and context processing on the Vera Rubin [GPU] rack,” explains Buck. “For all the expert calculations…the matrix multiplications, we do that part on the LPU.” The company packs 256 LPUs into the Groq 3 LPX, a system the size of a data-center rack.

Nvidia’s two-chip approach to inference

Nvidia also plans to split the inference workload across two chips. The company’s newest Rubin GPUs will tackle the compute-intensive prefill phase, while the Groq 3 language-processing unit (LPU), with lots of on-chip SRAM, will handle the memory-intensive decode phase.

Chris Philpot

Amazon Web Services (AWS), for its part, struck a dealwith Cerebras, to pair the Trainium accelerator with Cerebras’s Wafer-Scale Engine 3 (WSE-3). Cerebras takes a similar approach to Groq, though at a much larger scale. WSE-3 turns an entire silicon wafer into a single chip that contains over 4 trillion transistors. The design doesn’t connect to external memory but instead etches 44 gigabytes of SRAM into each wafer. “We store the [model] weights on the SRAM,” says James Wang, formerly director of product marketing at Cerebras who has since moved to SpaceXAI. “So that’s easily 40 to up to 80 billion parameters that we can support on one chip.”

Amazon plans to use AWS Trainium chips for prefill, and Cerebras for decode. But Cerebras’s chips can also go it alone in inference. WSE-3 was deployed by OpenAI to power GPT-5.3-Codex-Spark, a variant of the company’s coding mode, outputting over 1,000 tokens per second. For comparison, OpenAI’s standard GPT-5.4 deployment outputs 50 to 125 tokens per second.

Amazon Web Services’ two-chip inference strategy

Amazon Web Services combined their Trainium chips with Cerebras’s dinner-plate-sized wafer-scale engine (WSE) to tackle different parts of AI inference. Trainium chips handle the computationally intensive prefill phase, while the WSE, with interleaved on-chip SRAM memory, handles the memory-bandwidth-limited decode phase.

Chris Philpot

Cerebras can also tackle prefill without moving the workload to different specialized chips. For this, it networks together multiple WSE-3 chips to form a single pool of memory. Cerebras has demonstrated it can serve models with up to 1T parameters, such as MoonshotAI’s Kimi 2.6, though Wang says “the architecture has no innate limitation in terms of how many parameters it will do.”

Despite these differences in strategy, Nvidia and AWS seem to agree that the future of AI inference will be solved by a systems approach that pools different kinds of chips together to tackle the largest LLMs. Or, as Buck says: “To do modern AI inference, you need all the chips.”

Learning to do more with less (bits)

Nvidia became the world’s most valuable tech company because it designed the world’s most desired GPUs. But not all of the attention is focused on improving AI-inference hardware. AI researchers are also learning how to optimize LLM software and hardware in tandem to make the best use of the memory and compute components.

Most computers store numbers in a 32-bit or 64-bit format. These determine how many bits are available to represent a single number. If too few bits are available, the number can’t be stored without losing information. The quality of an LLM benefits from more-precise number formats, but this creates a problem for inference performance. More-precise numbers aren’t free. The bits that describe them take up more space in memory and require more silicon and energy to compute.

Gilles Backhus, cofounder of the AI-accelerator company Tensordyne, says this creates a tension between model size and number precision. “Would you prefer a model that is size xbut runs in 8-bit, or would you prefer a model that is twice the size but runs in 4-bit?” The size of each model will be roughly the same in terms of memory and compute, “but the 4-bit approach gives you twice as many synapses, if you will. And people are figuring out that [the 4-bit approach] is worth it.”

The process of converting an LLM from a more-precise number format to a less-precise format is called quantization, and it’s been in use for several years. However, researchers are finding new ways to quantize models down while retaining a large majority of the model’s quality.

Nvidia recently created a new 4-bit number format, NVFP4, for this purpose. AMD, Intel, and Qualcommhave instead rallied around a competing 4-bit number format called MXFP4that Nvidia also contributed to developing. “It’s the black art of AI,” says Buck, of Nvidia. When Nvidia quantized DeepSeek-R1 from FP8 to NVFP4, scores on seven major benchmarks degraded by less than one percent while performance improved by three times, the company says.

Quantization is likely just the tip of the spear, as AI researchers and startups are investigating a diversity of opportunities for optimization, some of which could dramatically change the silicon found in AI-inference hardware.

Tensordyne’s unique approach to AI inference combines a logarithmic number format with bespoke hardware in the company’s Napier chip. Tensordyne

Tensordyne is expected to accelerateAI inference with a logarithmic number system that leans on a property of logarithms: The log of A times B equals the log of A plus the log of B. So, storing numbers as their exponents lets the chip add where it would otherwise multiply. That matters in silicon because multiplier circuits draw more power and use more die area than adders do. Tensordyne says its rack-scale hardware, called Napier, can produce up to 1,300 tokens per second per user, and can do so while using less than a tenthas much power as comparable Nvidia hardware.

Etched, a startup based in San Jose, Calif., is even designing AI accelerators that translate the transformer architecture used by LLMs directly into silicon. Rather than building general-purpose GPUs, the company is wiring up the connections needed for efficient transformer calculations into its chip, making the chip much less flexible but more efficient for the tasks most performed by current LLMs. The company says its first AI accelerator, Sohu, can run Meta’s Llama70B model at a stunning 500,000 tokens per second, though this approach also means it won’t be able to run LLMs that move away from a typical transformer architecture.

Whether these ideas will prove fruitful remains to be seen. Etched just shippedtheir first rack in August. Tensordyne believes its first hardware will be available in 2027. Even so, these startups show how the demand for inference performance is fueling unconventional ideas.

Inference is everyone’s game

The sheer variety of approaches to AI-inference acceleration—stacking compute on memory, extending interfaces from millimeters to meters, using an entire silicon wafer for SRAM, squeezing models into 4 bits—raises a question: Which is going to win, and which is going to lose?

But that’s likely not the right question, experts say. The demand for AI is currently insatiable, and while fears of an AI bubble stalk the industry, it has yet to hamper growth.

On the contrary, Kimball of Moor Insights & Strategy thinks inference could drive intense demand for AI hardware in the long term, because it’s not obvious where that demand will end. “You could add a million agents into your organization,” he says. “These things work 24 hours a day; they don’t go home at five at night like we do.”

If AI inference remains as desirable as Kimball expects, the evolution is likely to follow the same trajectory as the CPU. The CPU didn’t improve along a single axis but instead across multiple frontssimultaneously. Once transistor scaling slowed, chip and system architecture innovations of all kinds proliferated. The list of individual innovations that led to today’s ubiquitous, powerful personal compute could fill dozens of books.

A few decades from now, the history of AI inference innovation will show similar depth.

From Your Site Articles

养狗有助于降低老人患认知症风险

Mon, 14 Sep 2026 18:49:35 CST

日本国立环境研究所等机构从 2016 年起，历时 7 年半对约 1.1 万名老年人开展了调查。他们在学术期刊上发表了研究成果。养狗的老年人因认知症需要接受护理的风险比从未养狗的人群低 48%。研究认为，遛狗带来的身体活动以及社交往来起到了积极作用。曾经养过狗的人患认知症的风险也低于从未养过狗的人群。虽然该差异在统计学上并不显著，但推测养狗时期建立的人际联系等因素可能带来了积极影响。研究还表明，养狗能拉动经济。若养狗人群增加，宠物食品、宠物保险、宠物寄养等相关商品与服务的需求预计随之上涨。

Cloudflare 免费服务使用指南

Mon, 14 Sep 2026 21:22:19 CST

Cloudflare 的免费套餐因其慷慨的额度，在开发者社区中常被戏称为“赛博大善人”，它提供的服务远不止基础的 CDN 加速。

Cloudflare 提供的免费服务

Cloudflare 免费层能覆盖的内容，按「值得用」排序：

优先级	用途	免费层是否够用	关键限制
1	域名 DNS 托管 + 免费 HTTPS	完全够用	无实质限制
2	CDN 缓存 + 基础 DDoS 防护	完全够用	无流量计费
3	静态站托管（Pages）	完全够用	500 次构建/月
4	内网服务暴露（Tunnel + Access）	完全够用	50 用户上限
5	域名邮箱转发（Email Routing）	完全够用	只能转发，不能发信
6	反爬 / 验证码（Turnstile）	完全够用	20 个 widget
7	边缘 API（Workers）	小流量够用	10 万请求/天、10ms CPU
8	对象存储（R2）	小文件量够用	10 GB 存储、零出口费
9	数据库（D1 + KV）	原型够用	500 万行读/天
10	AI 推理（Workers AI）	只够试玩	1 万 Neurons/天

一句话判断标准： 只分发不计算，免费层几乎无限；一旦要算、要存、要实时，就会撞墙。

为什么值得用：免费层的底层逻辑

理解 Cloudflare 的定价哲学，比背额度表有用得多。

它把成本结构拆成两块：

成本类型	定价态度	原因
带宽 / 分发 / 连接	几乎免费送	边缘节点带宽边际成本极低，且流量能反哺网络规模
CPU 时间 / 存储 / 写入	严格按量计费	这是真实的可变成本

这解释了为什么 Pages 敢写「无限带宽、无限请求」，而 Workers 只给 10 毫秒 CPU——带宽对它来说接近免费，CPU 不是。

对应的三条推论：

静态内容越重，越占便宜。图片站、文档站、博客、下载站放在这里，成本趋近于零。
动态逻辑越重，越容易付费。视频转码、爬虫、长任务、复杂数据库查询，很快就会越过免费线。
免费层的天花板由并发而非流量决定。1000 请求/分钟的突发限制，比每天 10 万次的总量更早撞上。

免费额度是硬限制。超出后请求直接失败并返回错误码（Workers 是 1015 / 1027），不是排队也不是降速。这意味着它适合个人站、演示、原型，不适合当作有 SLA 承诺的生产依赖。

免费产品地图

Cloudflare 免费层大致分五层。理解分层，就知道该在哪个位置放什么。

域名层：DNS + TLS + CDN + DDoS

能力	免费层说明	核实状态
权威 DNS	Anycast 全网解析，支持 API 与常见记录类型	已核实
免费 TLS 证书	自动签发、自动续期，覆盖根域与泛域名（泛域名需付费）	已核实
CDN 缓存	静态资源缓存、缓存规则、Cache Rules 基本能力	已核实
DDoS 防护	L3/L4 不限量清洗，L7 基础防护	已核实
WAF	自定义规则、免费托管规则集、IP 访问规则、UA 封禁	已核实
速率限制	Free 计划 1 条规则	已核实

这一层是免费层的入口，也是性价比最高的一层。绝大多数人只需要做一件事：把域名 nameserver 改成 Cloudflare 的。

托管层：Pages + Workers

项目	Workers Free	Pages Free
请求	100,000 次/天（账号内所有脚本合计）	静态请求不限量
CPU 时间	10 ms / 次调用	静态资源无 CPU 消耗
突发限制	1,000 请求/分钟	静态资源不适用
脚本 / 项目数	最多 100 个 Worker 脚本	每账号 100 个项目
内存	每 isolate 128 MB	—
构建	—	500 次/月，1 并发，单次超时 20 分钟
自定义域名	可用	每项目 100 个
站点文件数	—	20,000 个，单文件 ≤ 25 MiB
日志	200,000 条/天	—

关键点：Pages 的静态资源请求不占用 Workers 配额；只有 Pages Functions 才计入 Workers 那 10 万次/天。

数据层：KV + D1 + R2 + Queues + Durable Objects

服务	免费额度	定位	核实状态
Workers KV	读 100,000/天、写 1,000/天、删除 1,000/天、列表 1,000/天、存储 1 GB	配置、会话、读多写少的缓存	已核实
D1	读 500 万行/天、写 100,000 行/天、总存储 5 GB	SQLite 兼容关系库	已核实
R2	存储 10 GB-month/月、A 类操作 100 万/月、B 类操作 1000 万/月、出口流量免费	对象存储，对标 S3	已核实
Queues	10,000 次操作/天、消息保留 24 小时	异步任务、削峰	已核实
Hyperdrive	100,000 次数据库查询/天	加速访问外部 Postgres/MySQL	已核实
Durable Objects	请求 100,000/天、时长 13,000 GB-s/天	有状态协作、WebSocket	已核实
Workflows	步骤 3,000/天、存储 1 GB-month	多步骤任务编排	已核实

三个容易踩的坑：

D1 的「读 500 万行」是按扫描行数算，不是返回行数。一条没有索引的 SELECT * FROM t 在 5 万行的表上跑一次就是 5 万行读取，跑 100 次当天额度就没了。索引不是优化项，是配额保护。
R2 的 10 GB 免费额度只适用于标准存储。低频访问存储不享受免费额度（官方明确写了 free tier only applies to Standard storage）。
Queues 的免费额度实际比看上去小。一条消息完整走完要 3 次操作（写、读、删），1 万次/天大约只够 3000 条消息。

安全与身份层：Access + Tunnel + Turnstile

服务	免费额度	替代了什么
Cloudflare Tunnel	免费，隧道与路由不限量	ngrok、frp、DDNS + 端口转发
Zero Trust Access	50 用户上限，永久免费	VPN、跳板机、内网鉴权
Gateway	DNS / HTTP 过滤，免费	企业 DNS 过滤
Turnstile	免费，20 个 widget，验证次数不限	reCAPTCHA、hCaptcha
WARP 客户端	个人版免费	加密 DNS + 私网接入

Tunnel + Access 是免费层里最被低估的组合：它一次性干掉了动态 DNS、端口转发、Nginx 反代配置、certbot 证书续期这四件麻烦事，而且路由器上不需要开任何入站端口。

观测与效率层

服务	免费额度
Web Analytics	免费，无 Cookie、无指纹追踪
Email Routing	免费，域名邮箱转发
Workers AI	10,000 Neurons/天
AI Gateway	核心功能免费
Registrar	按成本价注册，无加价
Vectorize	口径存疑：文档中同时存在「需 Workers Paid」与部分 Free 行，不要作为稳定免费依赖
Browser Rendering	免费额度很小且口径不一，上线前需核对官方文档

Cloudflare的使用场景

场景一：把域名接入 Cloudflare（DNS + TLS + CDN）

这是所有后续操作的前提。根域名要挂 Pages、要开 Tunnel，都必须先让域名成为 Cloudflare 的一个 zone。

前置条件

一个已注册的域名，能修改 nameserver
一个 Cloudflare 账号（免费，不需要信用卡）

步骤

登录cloudflare.com，选择 Add a site，输入根域名。
选择 Free 计划。
Cloudflare 会自动扫描现有 DNS 记录。这里要做的第一件事是核对扫描结果——自动扫描经常漏掉 MX、TXT、CNAME 记录。改 nameserver 之前，先把原 DNS 服务商的所有记录导出或截图留档。Cloudflare 自动扫描不是 100% 完整，漏一条 MX 记录就意味着域名邮箱立刻失效。
去域名注册商处，把 nameserver 改成 Cloudflare 分配的两个地址。
等待生效，通常几分钟到 24 小时。
进入 SSL/TLS，把加密模式设为 Full (strict)。如果源站没有有效证书，先用 Full，但不要用 Flexible。
进入 Speed → Optimization，开启 Brotli 与 Early Hints；Auto Minify 已被弃用，不需要设。
验证：

# 确认 nameserver 已切换
dig NS example.com +short

# 确认解析走的是 Cloudflare
dig A example.com +short

# 确认证书与 HTTP 版本
curl -sI https://example.com | head -n 5

三个高频坑

现象	原因	处理
522 连接超时	源站没有放行 Cloudflare 回源 IP，或回源端口不通	放行官方 IP 段，确认 443 可达
无限重定向	SSL 模式用 Flexible，源站又强制 HTTPS	改为 Full (strict)
邮件收不到	自动扫描漏了 MX 记录	手动补 MX，且必须保持 DNS only（灰云）

橙色云（代理）与灰色云（仅 DNS）的区别要记住：邮件相关记录必须是灰云，否则收不到信。

场景二：静态站部署到 Pages

Pages 是免费层里最慷慨的产品：无限站点、无限席位、无限静态请求、无限带宽，只有 500 次/月的构建次数是硬限制。

三种部署方式对比

方式	适用场景	限制
Git 集成	长期维护的项目	一次提交触发一次构建，消耗构建配额
Wrangler CLI	本地已有构建流程	需要 Node 环境，最灵活
拖拽上传	一次性静态页	最多 1000 个文件，不支持 functions/ 目录编译

方式一：Git 集成

进入 Workers & Pages → Create → Pages → Connect to Git。
授权 GitHub / GitLab，选择仓库。
配置构建参数：

字段	说明
Project name	决定 <name>.pages.dev 子域名
Production branch	一般为 main
Framework preset	按框架选择，纯静态 HTML 选 None
Build command	例如 npm run build
Build output directory	例如 dist / out / public
Root directory	monorepo 必填
Environment variables	敏感配置与 NODE_VERSION

保存并部署。之后每次 push 会自动构建，每个 PR 会生成独立的预览链接。

方式二：Wrangler CLI

npm install -g wrangler
wrangler login
npm run build
wrangler pages project create my-site
wrangler pages deploy dist

注意 wrangler pages deploy 消耗的是构建配额之外的直接上传通道，但仍受每站点 20,000 文件上限约束。

三个构建期陷阱

报错	根因	修复
npm ci 直接失败	lockfile 与 package.json 不同步	本地重跑 npm install 提交新 lockfile
Failed to load SWC binary for linux/x64	macOS 生成的 lockfile 只含 darwin 平台可选依赖	在 Linux 环境重新生成 lockfile，或显式加 @next/swc-linux-x64-gnu 到 optionalDependencies
修完依赖仍报同样错	构建缓存复用了旧的 node_modules	加 postinstall 兜底，或关闭构建缓存

这三条都是同一个根源：构建发生在 Cloudflare 的 Linux 容器里，而你的 lockfile 是本地平台生成的。

不要用 <project>.pages.dev 裸域名面向国内用户。该域名段长期存在 DNS 污染与针对性阻断的社区实测反馈，属于不稳定而非完全不可用。绑自定义域名能明显改善，最稳的做法是前置一家国内可用的 CDN。

场景三：Tunnel + Access 暴露内网服务

替代方案是 DDNS + 端口转发 + Nginx 反代 + certbot 四件套。用 Cloudflare 只需要一条出站连接。

架构

本地服务 → cloudflared 出站连接 → Cloudflare 边缘 → 用户路由器上不需要任何入站端口。

步骤

安装 cloudflared（Windows 用 winget 或直接下载 exe）。
登录并授权：cloudflared tunnel login
创建隧道：cloudflared tunnel create homelab
配置 DNS 路由：cloudflared tunnel route dns homelab nas.example.com
写配置文件yml：

tunnel: homelab
credentials-file: C:/Users/you/.cloudflared/<tunnel-id>.json
ingress:
  - hostname: nas.example.com
    service: http://localhost:5000
  - hostname: grafana.example.com
    service: http://localhost:3000
  - service: http_status:404

前台验证：cloudflared tunnel run homelab
确认可访问后，注册为系统服务：cloudflared service install

加上 Access 鉴权

隧道本身只是把服务接上公网，任何知道域名的人都能访问，所以鉴权这一步不能省。

进入 Zero Trust → Access → Applications → Add an application → Self-hosted。
填入受保护的域名。
创建策略：Action 选 Allow，Include 选 Emails 或 GitHub 组织，填入允许的账号。
保存。免费层支持 50 个用户，个人和家庭场景完全够用。

验证方式：用未授权的浏览器或无痕窗口访问，应该被拦截到登录页。

注意点

yml 里最后一条 service: http_status:404 是兜底规则，不能省，否则未匹配的 hostname 会报配置错误。
隧道服务运行在后台时，日志不会自动输出，排查问题先用前台模式跑。
Access 的免费层日志保留期只有 24 小时。

场景四：免费域名邮箱（Email Routing）

免费层能把 hello@yourdomain.com 转发到你的常用邮箱，但它不是邮箱托管——只能收，不能发。

步骤

进入 Email → Email Routing，点击启用。
Cloudflare 会自动添加所需 MX 与 TXT（SPF）记录，确认添加即可。
添加目标邮箱，去该邮箱点击验证链接。
创建自定义地址：hello@yourdomain.com → 转发到目标邮箱。
可选：启用 Catch-all 规则，把所有未匹配地址统一转发。

限制

项目	说明
发信	不支持，需要 SMTP 服务商
邮件内容	Cloudflare 声明不存储、不访问邮件正文
已有 MX 记录	会冲突，启用前需确认没有现存的邮箱服务

如果需要在域名邮箱里回复，方案是转发到 Gmail 后在 Gmail 里添加「以别名发送」，需要该 SMTP 服务商（如 Zoho Mail 免费版）配合。

场景五：纯免费的全栈小应用

把 Workers + D1 + R2 组合起来，可以搭一个没有固定成本的小后端。

初始化

npm create cloudflare@latest my-api
cd my-api
wrangler d1 create my-db

绑定配置 wrangler.jsonc

{
  "name": "my-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "d1_databases": [
    { "binding": "DB", "database_name": "my-db", "database_id": "<上一步返回的 id>" }
  ],
  "r2_buckets": [
    { "binding": "BUCKET", "bucket_name": "my-files" }
  ]
}

示例代码 src/index.ts

export interface Env {
  DB: D1Database;
  BUCKET: R2Bucket;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);

    if (url.pathname === "/items" && request.method === "GET") {
      const { results } = await env.DB
        .prepare("SELECT id, name FROM items WHERE id = ?1")
        .bind(Number(url.searchParams.get("id")))
        .all();
      return Response.json(results);
    }

    if (url.pathname === "/upload" && request.method === "PUT") {
      const key = crypto.randomUUID();
      await env.BUCKET.put(key, request.body);
      return Response.json({ key });
    }

    return new Response("Not Found", { status: 404 });
  },
};

建表与部署

注意示例里 WHERE id = ?1 命中了主键，只读 1 行。如果换成无索引列的条件查询，读取行数会按扫描量暴涨，直接吃掉 D1 的每日配额。这是免费层里最容易被忽略的隐形消耗。

wrangler d1 execute my-db --remote --command \
  "CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT NOT NULL);"

wrangler d1 execute my-db --remote --command \
  "CREATE INDEX idx_items_id ON items(id);"

wrangler deploy

组件	免费额度	这个应用的实际消耗
Workers 请求	10 万/天	按访问量计
D1 读取	500 万行/天	命中索引时每查询 1 行
D1 写入	10 万行/天	每次新增 1 行
R2 存储	10 GB	按文件大小计
R2 出口	免费	下载不产生费用

只要按索引查询、上传文件控制在 10 GB 内、日请求低于 10 万次，这个应用的月成本是 0。

免费额度总表

类别	服务	免费额度	核实状态
域名	DNS / TLS / DDoS	无实质限制	已核实
域名	Registrar	成本价注册，无加价	已核实
托管	Pages	无限带宽、无限请求、500 构建/月、100 域名/项目	已核实
托管	Workers	10 万请求/天、10ms CPU、100 脚本	已核实
数据	KV	读 10 万/天、写 1000/天、1 GB	已核实
数据	D1	读 500 万行/天、写 10 万行/天、5 GB	已核实
数据	R2	10 GB-month、A 类 100 万/月、B 类 1000 万/月、出口免费	已核实
数据	Queues	10,000 操作/天、保留 24h	已核实
数据	Hyperdrive	10 万查询/天	已核实
数据	Durable Objects	10 万请求/天、13,000 GB-s/天	已核实
数据	Workflows	3,000 步骤/天、1 GB-month	已核实
安全	WAF	自定义规则 + 免费托管规则集	已核实
安全	速率限制	1 条规则	已核实
安全	Turnstile	20 widget，验证次数不限	已核实
安全	Zero Trust Access	50 用户	已核实
安全	Tunnel	隧道与路由不限量	已核实
观测	Web Analytics	免费	已核实
邮件	Email Routing	免费转发	已核实
AI	Workers AI	10,000 Neurons/天	已核实
AI	Vectorize	口径存在冲突，勿依赖	口径存疑
AI	Browser Rendering	免费额度小且口径不一	未核实
媒体	Images / Stream	不属于免费核心能力	已核实

风险与坑

免费层没有 SLA

免费计划不提供服务等级承诺，也没有工单支持通道。把关键业务押在免费层上，等于接受「可能突然不可用且无人负责」。

免费额度是硬中断

错误码	含义	表现
1015	触发突发速率限制	1000 请求/分钟以上，被拦截
1027	Worker 因超日限额被暂停	路由默认 fail open（绕过 Worker），可改为 fail closed
1016	源站 DNS 解析错误	回源域名解析失败
522	回源连接超时	源站未放行或端口不通

fail open 与 fail closed 的选择很关键：安全类 Worker（鉴权、校验）应该设成 fail closed，否则额度耗尽时请求会直接穿透到源站，等于安全策略失效。

CDN 代理非 HTML 内容有条款限制

Cloudflare 服务条款第 2.8 节限制用 CDN 代理大比例的流媒体与部分非 HTML 内容。个人博客、文档站、图片站没有风险，但把它当免费视频 CDN 用会违反条款。视频走 R2 或 Stream 是合规路径。

构建环境与本地环境不一致

前面提到的 lockfile 平台差异问题，本质是所有云端构建的通病。对策是锁定 NODE_VERSION、显式声明平台相关可选依赖、必要时关闭构建缓存。

新账号的隐性限制

新注册账号在最初一段时间创建项目可能受限（防滥用机制）。如果第一天就报错，通常不是配置问题，等一等即可。

国内访问不稳定

pages.dev 与 workers.dev 裸域名长期存在解析异常反馈。生产域名必须绑自定义域名，主要面向国内用户时建议前置国内可用的 CDN。

容易误判的免费项

以下几项常被当成免费能力，实际不是或口径不明：Images、Stream、Argo Smart Routing、Load Balancing、高级 Bot Management、Containers、Vectorize。规划架构时不要把它们算进免费方案。

什么时候该付那 5 美元

Workers Paid 是每月 5 美元，包含 1000 万请求、3000 万 CPU 毫秒、1000 万 KV 读取。判断标准很清晰：

信号	说明
日请求逼近 10 万	免费层没有弹性，超了直接 1027
单次任务 CPU 超 10ms	免费层的 CPU 上限锁死了计算类任务
需要 Durable Objects 完整能力	WebSocket 与有状态场景
需要有意义的技术支持	免费层只有社区论坛
业务不能接受无 SLA	这是最实际的付费理由

反过来说，如果只是博客、文档站、家庭内网、小工具 API，免费层可以长期稳定运行，没有必须付费的理由。

参考资料

Cloudflare 开发者平台定价：https://www.cloudflare.com/plans/developer-platform
Workers 定价与限制：https://developers.cloudflare.com/workers/platform/pricing
Workers 限制文档：https://developers.cloudflare.com/workers/platform/limits
Pages 定价：https://pages.cloudflare.com
R2 定价：https://developers.cloudflare.com/r2/pricing
D1 产品页：https://www.cloudflare.com/developer-platform/products/d1
Zero Trust 定价： https://www.cloudflare.com/plans/zero-trust-services

相关文章:

基于 AI 生成 HTML 动态页面，然后录视频，是否是制作短视频的一个可行方案

Sun, 13 Sep 2026 10:30:03 CST

AI Agent + HTML转视频框架（全自动）

这是当前更前沿的“Vibe Motion”趋势，将录屏步骤也自动化了。代表性开源框架包括：

HyperFrames：由 HeyGen 开源，专为 AI Agent 设计。你只需用自然语言描述需求，Agent 就会编写 HTML+CSS+GSAP 动画代码，然后框架通过无头浏览器逐帧捕获，用 FFmpeg 直接渲染成 MP4。
html-video：Open Design 团队出品，基于 HyperFrames 构建。它提供21套预设模板（如数据可视化、电影感标题），支持粘贴文章链接自动生成视频，进一步降低了使用门槛。

HyperFrames

https://github.com/heygen-com/hyperframes

HyperFrames 是一个开源框架，可将 HTML、CSS、媒体内容以及可播放的动画转换为格式固定的 MP4 视频。它可以通过命令行工具在本地使用，也可以与具备相应功能的 AI 编程工具配合使用。此外，它还可以作为托管式内容创作流程中的渲染核心组件来使用。

html-video

https://github.com/nexu-io/html-video

HTML 内容可以直接转换成视频——而且是在你的笔记本电脑上完成。你可以使用各种编程工具来辅助这个过程：Open Design、Windsurf CLI、Trae CLI、Claude Code、Cursor、Codex、Gemini、Grok、Qwen、OpenCode、Copilot、Aider、Hermes，或者 Anthropic API。你只需描述一下想要制作的视频内容，或者粘贴相关文章的链接或 GitHub 代码库的地址，这些工具就会把内容转换成多帧动画视频。最后，这些视频会被直接保存为 MP4 格式，保存在你的电脑上。整个过程非常简单：只需使用相应的工具，无需额外付费，也不会受到任何软件或服务的限制。Apache-2.0 许可证，完全免费使用，无任何附加条件。

选哪个方案

我看了一下这俩个 github 项目，HyperFrames 无论是 star 数量，还是更新频率，及 commit 更新数量，都远远优于 html-video。所以，我还是优先尝试 HyperFrames 吧。

编程 Agent 连接本机大模型的注意点

Fri, 11 Sep 2026 15:01:51 CST

如果你曾经考虑过把编程 Harness 发出的 API 调用替换成本地模型，那么结果很可能令人失望。你可能快速跑了一下 `llama-bench`，以为自己会得到一个“每秒 X token”的结果。但这个基准测试无法告诉你实际使用这些 Harness 时的体验。

不同 Harness 的开发体验差异非常大。你可能会坐在那里等几分钟才看到模型开始响应；或者刚开始运行得不错，中途却突然卡住。

“是谁把 Prefill 的时间全吃光了？”

这并不是你的错： 大多数编程 Harness 从设计之初就没有考虑本地模型。

这并不是要批评其他团队的优秀工作。我只是想可靠地测量： 当你把数据中心换成本地主机（localhost）之后，实际会发生什么。

需要说明的是，我一直在折腾 chad，这是一个专门针对 Apple Silicon 上 Qwen 3.8 27B 优化的 coding harness。

Laptop Physics：笔记本的物理限制

大多数 Harness 会从三个方面与本地模型“作对”。

1. 巨大的 System Prompt 和 Tool Schema

假设你的笔记本读取速度是 90 tokens/s，生成速度大约 10 tokens/s。

这分别对应编程 Harness 每一轮中的 Prefill 和 Generation。

按照这个速度：

每增加 1,000 个 Prompt Token，就意味着模型开始输出前，你要盯着光标等待约 11 秒。

而在模型真正开始干活之前，它必须先读取：

整个 System Prompt
所有加载的 Tool Schema

例如：

Harness	Prompt Token
pi	2,008
OpenCode	18,046

在数据中心 GPU 上，Prefill 可能达到 10k+ tokens/s，因此：

pi：约 0.2 秒
OpenCode：约 1.8 秒

几乎感觉不到区别。

但在你的笔记本上：

pi：约 22 秒
OpenCode：约 226 秒

也就是 将近 4 分钟。

这已经完全无法接受了。

2. 更小的有效 Context Window

LLM 处理完 System Prompt 后，真正能够用于工作的 Context Window 已经减少了。

你的上下文窗口其实比你想象得小。

具体剩余多少，取决于：

你的内存大小
模型权重占用
KV Cache
其他运行时开销

对于一台配置合理的笔记本，可以粗略认为还有 32,000 tokens 可用。

那么：

pi：

System Prompt 只占 2,008 tokens。

大约还有 94% 的 Context 可以真正用于工作。

OpenCode：

一开始就消耗了 18,046 tokens。

真正用于工作的 Context 只剩下约 44%。

3. 大量 Side Request

传统的：

本地客户端 → 远程服务器

架构下，Harness 可以随意向数据中心发起各种额外请求。

但本地模型不同：

你的笔记本既是 Client，又是 Server。

最好的情况是这些 Side Request 排队等待。

最糟糕的情况是：

它们不断触发重复 Prefill。

在测试的 24 个任务中：

OpenCode：33 次 Side Request
Crush：51 次
dsh：24 次

而且几乎都与 Agent Turn 重叠。

结果就是：

OpenCode：GPU 忙碌时间达到实际时间的 125%
Crush： 114%

也就是说：

一块 GPU 上同时跑了两个请求。

Harness 测试结果

作者使用 9 个 Coding Harness，测试了 8 个 Exercism 编程任务。

每个任务都使用：

相同的一句话 Prompt
Auto-approve 模式
同一台 M4 MacBook Pro
24GB 内存
macOS 26.6.2
Qwen 3.8 27B
3-bit 量化
llama.cpp build 10470

所有 Harness 共用同一个 llama-server。

采样参数统一为：

temperature = 1.0
top_k = 20
top_p = 0.95
min_p = 0.05

Context Cache 统一：

32,768 tokens / 4 slots

其中：

wait before 1st token：第一次生成 Token 前的等待时间，也就是 System Prompt + Tool Schema + First Request 的 Prefill 时间
wait / later turn：之后每一轮的等待时间
cache reuse：后续 Turn 有多少比例来自 Prefix Cache
experienced tokens/s：真正用户体验到的速度，包括 Prefill、Tool 等全部时间
pass：Exercism 任务是否通过，作者特别强调不要把它当成模型能力排名

Harness	Tools	首轮 Prompt	首 Token 等待	后续 Turn	Cache	实际 tok/s	通过
mini-swe-agent	1	1,171	12.2s	3.6s	96%	8.0	11/24
pi	4	2,008	21.6s	1.3s	99%	8.1	19/24
cline	26	5,876	64.1s	9.9s	94%	7.3	17/24
codex	10	7,804	87.8s	9.6s	94%	6.9	19/24
dsh	25	8,052	94.4s	2.2s	99%	7.2	18/24
goose	18	9,617	110.3s	1.0s	100%	8.0	22/24
crush	26	16,263	199.8s	1.8s	100%	5.8	18/24
opencode	10	18,046	225.7s	4.6s	99%	5.7	15/24
chad（llama.cpp）	5	2,563	25.6s	0.8s	99%	7.9	24/24
chad（MLX serial）	5	2,566	4.7s	1.0s	99%	12.4	21/24
chad（MLX dflash2）	5	2,562	4.6s	0.9s	99%	17.4	22/24

作者把这些 Harness 分成三类

① Lean and Stable：轻量、稳定

pi、mini-swe-agent、chad

特点：

精简 System Prompt
96–99% Cache Reuse
本地模型和云端模型都能比较好地工作

其中 mini-swe-agent 的问题是：

24 个任务只通过 11 个，并且 Timeout 最多。

② Heavy but Disciplined：比较重，但设计合理

dsh、cline、codex、goose

它们的问题主要来自：

较长的 System Prompt
大量 Tool Schema

但有一个很重要的优点：

Prefix 是稳定的。

所以一旦 Prefill 完成，后面还是比较能够接受的。

作者特别提到 Goose：

1.50.0 版本已经解决了一个问题。

早期版本每一轮都会把一个精确到分钟的 Timestamp 重新写进第一条 User Message，导致 Cache Reuse 从接近 100% 降到了 78%。

③ Heavy to Start：启动非常重

Crush、OpenCode

你会先等：

3～4 分钟

才能看到模型开始工作。

为什么作者认为 chad 特别适合本地模型？

作者认为这些 Harness 并不是设计得不好。

例如：

OpenCode 使用 18K Token 的 System Prompt

这对于：

数据中心 + Frontier Model + 10k+ tokens/s Prefill

完全合理。

同样：

Crush 使用 26 个 Tool Schema

当你拥有：

200K Context
几乎免费的高速 Prefill

这也完全没问题。

问题在于：

这些设计都是建立在“Prefill 几乎免费”的数据中心环境上的。

一旦换成：

本地模型 + 笔记本 + 低 Prefill 速度

原来的设计就会彻底暴露问题。

原文：https://nasutton.notion.site/Nine-coding-harnesses-vs-your-laptop-3d139990182b80d59fa3cf500f0450ba

科学家建议冲马桶合盖以减少气凝胶

Tue, 08 Sep 2026 23:16:05 CST

Flinders 大学的研究人员发现，冲马桶会向周围空气释放气溶胶和生物气溶胶，气溶胶颗粒甚至会进入到成年人的呼吸区，而冲水后气溶胶会在空气中悬浮至少 20 秒。这些发现是基于对 22 项马桶气溶胶研究的分析。结果表明，保持良好的厕所卫生，包括定期清洁马桶及其周围表面，以及使用后洗手，有助于最大限度减少微生物污染和潜在的微生物疾病风险。使用马桶的低冲水模式也有助于最大限度减少气溶胶的产生。充足的通风有助于扩散和清除悬浮的空气颗粒，关闭马桶盖会改变气溶胶的扩散方向，气溶胶会从马桶盖和马桶座之间的缝隙逸出，而不是向上扩散。研究人员建议保持卫生间通风良好，在冲水前盖上马桶盖。

人工智能的效率提升可能会让我们失去下一代专家（如何保护人类技能）

Fri, 04 Sep 2026 09:00:53 CST

十多年前，我曾主导设计美国一座核电站的首套全数字控制系统。从设计图纸上看，这套系统堪称完美——它被设计成像现代客机一样自主运行，操作员只需偶尔监控一下，几乎不需要他们干预。然而，我们却做出了一个在注重效率的观察者看来有些倒退的决定：我们故意在系统能够自主执行的程序中保留了一些手动步骤。

我们当时在解决一个具体问题。一个只负责监督自动化系统的操作员，会逐渐失去操作能力。他的手会变得冰冷，对工厂实际运行情况的认知也会变得模糊。然后，自动化系统就会把控制权交还给他。这总是最糟糕的一天，因为自动化系统只有在出现故障或出错时才会停止工作。但到那时，坐在操作台上的人已经好几年没真正操作过这套系统了。手动操作步骤的存在是为了保持操作员的技能水平。这种设计本身就效率低下，而且是故意为之。

那个核电站最终并没有建成。由于美国核电行业复杂的政治和经济因素，这个项目被搁置了，而这些因素与工程设计本身无关。但是，设计理念却超越了项目本身，而且我逐渐意识到，对于如今席卷所有董事会的争论——“当人工智能取代人类的专业知识来构建它们时，人类的专业知识将何去何从？”——这或许是我能提出的最有价值的观点。

人工智能正在颠覆工程职业发展阶梯

这些数据已不容忽视。哈佛大学一份涵盖超过28万家美国公司约6500万名员工的工作报告发现，在公司采用生成式人工智能后，初级员工的就业率在六个季度内比未采用人工智能的公司下降了约9%，而高级员工的就业率则持续增长。斯坦福大学对ADP工资记录的分析也指向了同样的结果：在人工智能应用最广泛的职业领域，最年轻的员工在2022年底之后就业率下降，而他们经验更丰富的同事则保持了就业水平。斯坦福大学的研究人员发现，就业率下降主要集中在人工智能实现工作自动化的领域；而在人工智能仅仅是辅助工作的领域，初级员工的就业率则保持稳定或有所上升。

因果关系仍存在争议，坦诚相告至关重要。纽约联邦储备银行的研究人员认为，应届毕业生失业率上升的主要原因并非人工智能，而是远程办公。他们认为，企业不愿雇用缺乏经验、无法进行远程培训和指导的人员。但请注意这些解释的共同之处。无论是人工智能吸收了早期培训，还是远程办公切断了指导关系，两者都描述了同一个失效的机制：学徒制渠道——即专业知识从资深员工传授给初级员工的途径——已经失效。无论如何，“入门级”悄然变成了“需要三年工作经验”。

抛开一切杂音，你会发现一个看似简单却又至关重要的问题：你不可能不先当过初级工程师就成为高级工程师。专业知识并非唾手可得，而是需要通过失败的构建、毫无进展的调试以及那些“这到底是怎么回事”的困惑时刻来积累的。而如今，人工智能会很乐意让新手免于经历这些。如果让新手免于经历足够多的此类困惑，你就会培养出一批能够纸上操作模型，却始终无法培养出那种能够准确判断模型何时出现灾难性错误的直觉的人才。

大多数评论止步于诊断，或者试图提出将初级岗位流失视为经济问题的政策解决方案。然而，这同时也是一个工程问题，而安全攸关领域已经花费数十年时间研究如何解决这个问题。

航空业关于自动化悖论的教训

我的职业生涯始于自动化领域的尖端。毕业后的第一份工作是验证和确认数字喷气发动机控制器中的软件，该控制器能够比任何飞行员更快地决定战斗机发动机的响应。即使在20世纪80年代末，这种核心矛盾也显而易见：在常规情况下，机器的性能优于人类；但在机器无法预料的情况下，人类却是飞机免于灾难的唯一保障。这种矛盾被称为“ 自动化悖论”，即随着自动化能力的不断提升，操作人员的实践机会越来越少，而留给他们的却只有最棘手的难题。

航空业曾多次付出惨痛的代价，才明白当人为技能在自动化系统和人工操作之间的鸿沟中退化时，会发生什么。最典型的例子就是2009年坠入大西洋的法航447航班。事故的直接原因很普通：结冰的空速传感器向自动驾驶仪提供了错误数据，自动驾驶仪按照其设计程序断开连接，将飞机控制权交还给机组人员。接下来发生的并非硬件故障，而是飞行员能力的缺失。原本可以挽回的局面变成了无法挽回的悲剧，因为飞行员们在数千小时的自动驾驶操作下，无法识别高空气动失速并手动驾驶飞机脱困。飞机本身没有问题，但被自动化系统悄然削弱的飞行员训练却失效了。

业界的应对措施颇具启发性，与我们在核电站控制室采取的措施如出一辙。他们并没有拆除自动驾驶系统，而是重新引入了刻意的手动飞行练习。2017年，美国联邦航空管理局（FAA）发布了第17007号运营商安全警示——《手动飞行操作熟练度》，其中明确指出“手动飞行是其他飞行技术的基础”。该警示正式承认技能衰退本身就是一种危险。一些航空公司修改了操作规程，鼓励在天气状况良好的情况下进行初始爬升和初始下降阶段的手动飞行，他们明知会牺牲少量燃油效率，却依然努力保持机组人员的飞行技能。这种权衡取舍至关重要。一个看似完美却培养出不称职操作员的系统，根本算不上完美。它只是把故障模式转移到了电子表格无法识别的地方。

手动门禁系统或可保护工程技术

将航空业的经验教训和核武器的本能放在一起比较，它们都指向了我们在人工智能增强型工作中需要的一种设计模式：刻意的“手动关卡”。

手动操作环节是指工作流程中由人接管控制权的某个点，这并非因为这是完成任务最快的方式，也不仅仅是为了安全联锁，而是为了锻炼和保持一项否则会退化的技能。其显著特点在于，它是人为选择的。在设计过程中，你需要决定你的组织必须保留哪些员工的技能，因为在关键时刻，这些技能至关重要。然后，你需要精心设计必要的机制来保持这些技能的熟练度。

想象一下，在一个主要依赖人工智能编写代码的软件团队中，这种机制会如何运作。团队会为他们最不能失去的技能—— 调试——设置一道人工屏障。当关键模块中出现缺陷时，指定的工程师（通常是初级工程师）必须首先重现故障，追溯根本原因，并编写一个能够捕获该缺陷的自动化测试，所有这些操作都必须在人工智能助手关闭的情况下进行。只有在工程师确定诊断结果后，模型才会重新启动，提出修复方案，生成替代方案，并在代码库中搜索类似的缺陷。然后，工程师会将自己的诊断结果与模型的分析结果进行比较。如果两者不一致，那就说明这种设计是有效的，它能够在问题发生之前就发现分歧，而不是在问题发生时才发现。

这种方法彻底改变了初级工程师的角色。如今人们的本能是让人工智能来完成入门级工作，因为它速度更快、成本更低。但有些工作并非可以随意削减的额外开销。它们是培养未来高级员工的基石，你应该像保护其他关键基础设施一样保护它们。或许它在本季度效率不高，但悄悄地拆除它，就等于把未来十年的能力抵押出去。

为什么企业必须持续培养初级工程师

这一切都不是免费的，假装免费是对那些必须签署预算的人的侮辱。人为设置的人工关卡，从本质上来说，短期内效率低于完全自动化。让初级员工从事基础工作并执行手动流程，现在付出一些成本，是为了将来能够获得更好的结果。

在如今这个以季度业绩评判大多数领导者的市场中，这种做法很难奏效。如果一位新聘高管手下有“不必要”的员工，而这些员工本可以被人工智能取代，那么在获得回报之前，董事会就会对此提出批评。只有那些能够免受这种压力影响的人才能从中获益：例如拥有控制权的创始人、私营公司、真正具有长远眼光的机构，或者像飞行员那样，愿意要求员工定期展示技能的监管机构。这意味着，最有可能保留自身专业技能的组织，是那些在结构上能够将短期利润投入到长期能力建设中的组织；其他所有组织都需要外部推动。

所以，论点可以用一句话概括：刻意降低效率并非浪费。在安全至关重要的工程领域，我们一直将其视为一种保障，而且我们是有意为之。随着人工智能接管那些需要专业知识才能完成的工作，明智的做法不是抵制自动化，而是从设计之初就将控制权牢牢掌握在手中——这样，即使自动化最终总会失效，也仍然有人能够胜任。

Chronos-2 Small (112M)一个时间序列预测的强大模型

Tue, 01 Sep 2026 10:30:03 CST

Chronos-2 是一个用于时间序列预测的基础模型，基于 Chronos 和 Chronos-Bolt 构建。它提供了显著的能力改进，可以处理早期模型不支持的多种预测场景。它提供了显著的能力改进，可以处理早期模型不支持的多种预测场景。支持的场景包括（1）单变量时间序列预测：经典的时间序列预测任务；（2）跨项目学习：利用多个相关时间序列的信息进行预；（3）多变量预测：同时预测多个相关目标变量（3）带协变量的预测：仅过去协变量：在预测时已知的历史协变量（如过去的天气数据） + 已知未来协变量：预测期间已知的协变量（如节假日、计划事件）

功能对比

功能	Chronos	Chronos-Bolt	Chronos-2
单变量预测	✅	✅	✅
跨项目学习	❌	❌	✅
多变量预测	❌	❌	✅
仅过去协变量（实数/分类）	❌	❌	✅
已知未来协变量（实数/分类）	🧩	🧩	✅
微调支持	✅	✅	✅
最大上下文长度	512	2048	8192

🧩 Chronos/Chronos-Bolt 不原生支持未来协变量，但可以与外部协变量回归器结合使用（参见 AutoGluon 教程）。这仅对每个时间步的效果进行建模，而不是跨时间的效果。相比之下，Chronos-2 原生支持所有协变量类型。

更多关于 Chronos-2 的详细信息，请参阅技术报告。

安装

pip install 'chronos-forecasting[extras]>=2.2' 'matplotlib'

快速开始

加载模型

import os

# 使用仅 1 个 GPU（如果可用）
os.environ["CUDA_VISIBLE_DEVICES"] = "0"

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
from chronos import BaseChronosPipeline, Chronos2Pipeline

# 加载 Chronos-2 管道
# 推荐使用 GPU 加速推理，CPU 也支持（使用 device_map="cpu"）
pipeline: Chronos2Pipeline = BaseChronosPipeline.from_pretrained(
    "amazon/chronos-2", 
    device_map="cuda"
)

单变量预测

# 加载数据（长格式 pandas DataFrame）
context_df = pd.read_csv("https://autogluon.s3.amazonaws.com/datasets/timeseries/m4_hourly/train.csv")
print("输入数据框形状:", context_df.shape)
display(context_df.head())

# 执行预测
pred_df = pipeline.predict_df(
    context_df, 
    prediction_length=24, 
    quantile_levels=[0.1, 0.5, 0.9]
)

print("输出数据框形状:", pred_df.shape)
display(pred_df.head())

predict_df 参数说明

参数	说明	默认值
`df`	长格式 DataFrame，包含 id、timestamp 和目标列	-
`future_df`	可选的未来协变量 DataFrame（同时存在于 df 和 future_df 中的列被视为已知未来协变量）	None
`id_column`	时间序列标识符列	"item_id"
`timestamp_column`	时间戳列	"timestamp"
`target`	要预测的目标列名	"target"
`prediction_length`	预测步数	-
`quantile_levels`	要计算的分位数	[0.1, 0.2, ..., 0.9]

返回包含预测值（包括点预测和分位数）的 DataFrame。

带协变量的预测

Chronos-2 可以利用协变量来提高预测准确性。以下是一个实际的能源价格预测示例：

# 能源价格预测配置
target = "target"  # 包含要预测的值的列名（能源价格）
prediction_length = 24  # 要预测的小时数
id_column = "id"  # 标识不同时间序列的列（国家/地区）
timestamp_column = "timestamp"  # 包含日期时间信息的列
timeseries_id = "DE"  # 要可视化的特定时间序列（德国）

# 加载历史能源价格和协变量的过去值
energy_context_df = pd.read_parquet(
    "https://autogluon.s3.amazonaws.com/datasets/timeseries/electricity_price/train.parquet"
)
energy_context_df[timestamp_column] = pd.to_datetime(energy_context_df[timestamp_column])

# 加载协变量的未来值
energy_test_df = pd.read_parquet(
    "https://autogluon.s3.amazonaws.com/datasets/timeseries/electricity_price/test.parquet"
)
energy_test_df[timestamp_column] = pd.to_datetime(energy_test_df[timestamp_column])
energy_future_df = energy_test_df.drop(columns=target)

# 使用协变量进行预测
pred_df = pipeline.predict_df(
    df=energy_context_df,
    future_df=energy_future_df,
    id_column=id_column,
    timestamp_column=timestamp_column,
    target=target,
    prediction_length=prediction_length,
    quantile_levels=[0.1, 0.5, 0.9],
)

可视化预测结果

def plot_forecast(
    context_df,
    test_df,
    pred_df,
    timeseries_id,
    target,
    timestamp_column="timestamp",
    id_column="item_id",
):
    fig, ax = plt.subplots(figsize=(12, 3))
    
    # 筛选特定时间序列的数据
    ts_context = context_df[context_df[id_column] == timeseries_id].set_index(timestamp_column)[target]
    ts_ground_truth = test_df[test_df[id_column] == timeseries_id].set_index(timestamp_column)[target]
    ts_pred = pred_df[pred_df[id_column] == timeseries_id].set_index(timestamp_column)
    
    # 绘制历史数据、真实值和预测值
    ts_context.plot(ax=ax, label=f"历史 {target}", color="xkcd:azure")
    ts_ground_truth.plot(ax=ax, label=f"未来 {target} (真实值)", color="xkcd:grass green")
    ts_pred["predictions"].plot(ax=ax, label="预测", color="xkcd:violet")
    
    # 绘制预测区间
    ax.fill_between(
        ts_pred.index,
        ts_pred["0.1"],
        ts_pred["0.9"],
        alpha=0.7,
        label="预测区间",
        color="xkcd:light lavender",
    )
    
    ax.axvline(x=ts_context.index[-1], color="black", linestyle="--", alpha=0.5)
    ax.legend(loc="upper left")
    ax.set_title(f"{target} 预测 - {timeseries_id}")
    fig.show()

支持的场景

单变量时间序列预测：经典的时间序列预测任务
跨项目学习：利用多个相关时间序列的信息进行预测
多变量预测：同时预测多个相关目标变量
带协变量的预测：
- 仅过去协变量：在预测时已知的历史协变量（如过去的天气数据）
- 已知未来协变量：预测期间已知的协变量（如节假日、计划事件）

硬件要求

GPU（推荐）：支持 CUDA 的 NVIDIA GPU，可显著加速推理
CPU（支持）：可在 CPU 上运行，但推理速度较慢

参考

时间序列基础模型Moirai 2.0

Mon, 31 Aug 2026 22:01:50 CST

时间序列基础模型是过去两年最热的方向之一：Google 的 TimesFM、亚马逊的 Chronos、Datadog 的 TOTO 先后登场，都想做一个模型预测所有领域。2025 年 8 月，Salesforce 发布的 Moirai 2.0 给出了一个反直觉的答案——把架构做得更简单，模型做得更小，反而更强，论文标题直接就叫《When Less Is More》（少即是多）。

Moirai 2.0 是一个纯解码器（decoder-only）时间序列基础模型，在 3600 万条序列、约 2950 亿观测值的语料上预训练，直接输出 9 个分位数（0.1～0.9）的概率预测。它的 Small 版本只有 11.4M 参数，却比上一代 311M 参数的 Moirai 1.0-Large 更准，推理快约 2 倍、体积小约 30 倍。

为什么需要 Moirai 2.0？

先给结论：Moirai 2.0 的诞生，是对时序基础模型就该又大又复杂这一假设的系统性纠偏——它砍掉了前代三个最复杂的组件，换来更准、更快、更小。

时间序列本身很难：非平稳、多尺度、采样不规则、观测有缺失，跨领域泛化极难。传统做法是每个场景训一个专用模型（ETS、ARIMA，或 PatchTST、N-BEATS 这类深度模型），维护成本高。基础模型的思路是像 GPT 之于文本一样，用海量跨域数据预训练一个通用模型，新场景零样本直接用。Moirai 1.0（2024 年，ICML Oral）正是这条路线最早的践行者之一：基于 LOTSA 数据集（27B 观测、9 大领域）预训练，曾登顶 GIFT-Eval 排行榜。

但 1.0 的成功也暴露了三个结构性短板：

数据利用率低：掩码编码器架构下，每条训练样本只产生一个损失，全序列仅约 15% 的 token 真正参与了损失计算，大部分训练信号被浪费。
多补丁设计过重：为适配不同时间频率引入了多补丁输入，反而限制了跨频率学习，还增加了计算开销。
混合分布输出难优化：用混合分布（mixture of distributions）做概率预测，理论上灵活，实践中梯度不稳定、优化复杂，收益却不明显。

Moirai 2.0 的回应是三个砍：掩码编码器 → 纯解码器；多补丁 → 单补丁；混合分布 → 分位数。结果是一条样本产生 T−1 个训练损失、训练和推理都大幅简化、概率输出天然可用——用论文里的原话，这套改动让它比自己家族里更大的模型表现更好。

这条演进路线的时间线如下：

时间	事件	意义
2024.02	Moirai 1.0 论文发布（arXiv:2402.02592）	最早的大规模通用时序基础模型之一
2024.03	Uni2TS 框架与 LOTSA 数据开源	代码、数据、权重全部开放
2024.05	论文被 ICML 2024 接收（Oral）	学术界的标志性认可
2024.06	Moirai 1.1 发布	低频数据（年度/季度）NMAE 提升约 20%
2024.10	Moirai-MoE 发布	混合专家架构版本
2024.11	GIFT-Eval 基准发布	时序基础模型的公共评测场，Moirai-Large 曾登顶
2025.08	Moirai 2.0 发布（Salesforce 官方博客）	架构全面转向 decoder-only，非数据泄露模型中 MASE 第一
2025.11	Moirai 2.0 论文发表（arXiv:2511.11698）	完整公开架构、数据与消融实验

五大核心设计：Less 究竟砍掉了什么

先给结论：Moirai 2.0 的少，落在架构、输出、解码、训练四个层面，每一刀都精准对准 1.0 的一个痛点。下图是它的端到端流水线。

纯解码器架构：让每个 token 都「练到」

如果说掩码编码器像老师拿着全文让学生做一道阅读理解题，那么纯解码器就像顺着文章往下读，每读一个词都预测下一个词——每个位置都参与训练，预测永远只依赖当前及之前的内容（因果性）。

这一改动带来了三方面收益。其一，训练信号量级提升：一条长度为 T 的序列，decoder-only 能产生 T−1 个损失，而掩码编码器只有 1 个，数据利用率从约 15% 的 token 参与损失提升到全部 token。其二，推理天然自回归：预测未来就是接着往下写，与模型的训练目标完全一致。其三，可复用 KV 缓存：重复/扩展预测时，已算过的键值对直接缓存复用，论文报告迭代式扩展预测最多可提速 17 倍。

架构上它与现代 LLM 同构：输入补丁经残差块（SiLU 激活）投影为 token，送入多层因果多头自注意力 + 前馈网络的堆叠，最后输出投影把每个 token 映射为多令牌、多分位数预测。small / base / large 三个变体分别是 12 / 24 / 48 层。

分位数预测与 Pinball 损失：原生概率输出

先给结论：Moirai 2.0 不预测未来是多少，而是预测未来有 90% 概率落在哪个区间，这个区间由 9 个分位数（q=0.1, 0.2, …, 0.9）直接给出，无需事后拟合分布。

分位数是什么？把历史数据按大小排序，第 q 分位数就是有 q 比例的数据不超过它的那个值。预测时，模型对每个未来时间步直接输出 9 个分位数值：q=0.1 和 q=0.9 之间的区间就是 80% 置信带，q=0.5（中位数）则天然可作为点预测。如下图所示。

训练时用分位数损失（又称 Pinball 损失）直接优化这 9 个分位数。对时间步 t 的真实值 $y_t$ 与预测分位数值 $\hat{y}_t^{(q)}$：

$$\ell_q(y_t, \hat{y}_t^{(q)}) = \begin{cases} q\,(y_t – \hat{y}_t^{(q)}) & \text{if } y_t \ge \hat{y}_t^{(q)} \\ (1-q)\,(\hat{y}_t^{(q)} – y_t) & \text{if } y_t < \hat{y}_t^{(q)} \end{cases}$$

逐项拆解这个公式：当真实值高于预测值（$y_t \ge \hat{y}_t^{(q)}$，低估了），惩罚是 $q \times$ 偏差；当真实值低于预测值（高估了），惩罚是 $(1-q) \times$ 偏差。系数 q 的作用是不对称：对高分位数（如 q=0.9），低估（真实值比预测高）会吃到 0.9 倍偏差的惩罚，比高估（0.1 倍）重得多——这迫使模型把 q=0.9 这条线抬高，保证90% 的值都不超过它，从而形成正确的分位数排序与间距。总损失是所有分位数、所有时间步的平均：

$$\mathcal{L}_Q = \frac{1}{H|Q|} \sum_{t=1}^{H} \sum_{q \in Q} \ell_q\big(y_t, \hat{y}_t^{(q)}\big), \quad Q = \{0.1, 0.2, \dots, 0.9\}$$

为什么直接回归分位数比混合分布更好？因为分位数损失是概率预测评估指标 CRPS 的离散近似——训练目标和评测指标对齐了，且逐点损失对异常值稳健、梯度稳定，没有混合分布那样的模式坍缩与优化困难。消融实验显示，仅这一项改动就把 MASE 从 0.850 拉到 0.744，是整个模型中收益最大的一刀。

这套设计的局限与应对：默认 9 个分位数等权，对重尾分布表达有限；但损失函数支持对不同分位数加权（如容量规划强调 q=0.9 的高分位），可按业务定制。最佳场景是金融风控（要上下界）、运维容量规划（要 P95/P99）、任何预测错了要付出不对称代价的场景。

多令牌预测：一次吐出一串未来

如果说单令牌预测是一个词一个词往外蹦，那么多令牌预测就是一次说出一句完整的话。Moirai 2.0 的每个输出 token 同时预测 $n_{token}$ 个未来补丁（patch），输出投影从 $\mathbb{R}^d$ 映射到 $\mathbb{R}^{n_{token} \times n_q \times p}$，一次前向就覆盖一段更长的预测范围。

这么做的直接收益是效率与稳定性：自回归迭代次数成倍减少，长预测范围下的误差累积也随之降低——论文的消融实验证实，多令牌预测在最终版本中贡献了约 0.011 的 MASE 改善（0.739 → 0.728 的路径上）。

自回归多分位数解码：先展开、再折叠

这里有个必须解决的矛盾：每一步输出 9 个分位数，自回归时该把哪一个当作输入传给下一步？取中位数会丢掉全部不确定性信息；直接传 9 个又维度不匹配。Moirai 2.0 的解法是一个深度为 2 的扩展—折叠（expand-then-fold）束搜索：

具体到每一步：第一步直接用上下文预测出 9 个分位数；展开阶段，把上一步的每个分位数值当作输入分别解码，得到 $9 \times 9 = 81$ 个候选；折叠阶段，对这 81 个候选在每一步取对应分位数（$\hat{y}_{t+1}^{(q)} \leftarrow \text{Quantile}_q(\text{candidates})$），聚合回 9 个标准分位数；如此循环直到预测范围结束。这相当于在保留全概率信息的同时，把多值自回归变成了可行计算。

训练三件套：防泄漏、抗缺失、滤噪声

除了架构，训练策略还有三个看似细节、实则关键的机制：

防泄漏归一化：decoder-only 模型若对整个序列做全局实例归一化，归一化统计量会偷看未来的 70% 数据。因此只用序列前 30% 计算均值和方差，后 70% 用于因果预训练，杜绝未来信息泄露。
Patch 级随机掩码：训练时随机掩掉 50% 的输入补丁，让模型学会从残缺输入中预测，增强对真实场景缺失值的鲁棒性。消融实验表明它单独使用反而降精度，但与其他策略组合时有正向贡献。
数据过滤：既然归一化只看前 30%，后 70% 段可能发生分布偏移。用 Z-score 异常检测对比两段统计量，把不可预测的低质量序列从预训练语料中滤掉，稳定收敛。

预训练数据：3600 万条序列从哪来

先给结论：Moirai 2.0 在 3600 万条序列、约 2950 亿观测值的混合语料上预训练，真实数据与合成数据并重，覆盖运维、能源、医疗、经济、交通、电商等主要领域——这是它零样本跨域能力的根基。

数据来源	序列数	观测数	说明
GIFT-Eval Pretrain（无泄露版）	约 325 万	约 2300 亿	LOTSA 的子集，精心挑选避免与评测任务重叠
GIFT-Eval TrainTest 训练集	约 14.4 万	—	评测集训练部分，用于增强
Chronos-Mixup（合成）	3000 万	约 630 亿	基于 TSMixup 生成，仅用 Chronos 非泄露子集
KernelSynth（合成）	100 万	约 10.2 亿	高斯过程合成：趋势、局部变化、季节核随机组合
Salesforce 内部遥测（匿名）	约 215 万	约 14.8 亿	日粒度云监控数据，覆盖约一年（自 2024 年 1 月起）
合计	3600 万	约 2950 亿	真实 + 合成混合，8 大领域

值得注意两点。第一，合成数据占比很高（Chronos-Mixup 3000 万条占了近九成），说明在真实高质量时序数据稀缺的情况下，合成数据是扩大覆盖面的有效手段——这一点与 Chronos 论文的做法一脉相承。第二，语料的领域分布并不均衡：自然/环境类序列偏少，这直接导致了后面实验里Natural 领域表现偏弱的结果。

实验结果：小模型如何打赢大模型

先给结论：在 GIFT-Eval 基准（55 个数据集、97 种任务配置、37 个模型参赛）上，参数最少的 Moirai 2.0-Small（11.4M）反而在所有尺寸中表现最好，并在非数据泄露模型中拿到 MASE 第一。这是一份缩小模型反而变强的实证。

缩放实验：参数不是越多越好

模型	参数（M）	MASE ↓	CRPS ↓
Moirai 2.0 Small	11.4	0.728	0.516
Moirai 2.0 Base	87.1	0.732	0.525
Moirai 2.0 Large	305	0.743	0.530

从 11.4M 扩到 305M，性能不升反降。论文给出的解释是：当前预训练数据的规模与多样性和模型容量不匹配，仅堆参数无效——这打破了参数量 = 精度的直觉，也把未来方向指向了数据扩展而非模型扩展。

消融实验：哪一刀收益最大

变体	预训练数据	损失	架构	投影	多令牌	递归解码	随机掩码	MASE ↓	CRPS ↓
Moirai 1.0 small	GIFT-Eval Pretrain	分布	enc-only	线性	—	—	—	0.946	0.650
v0	GIFT-Eval Pretrain	分布	dec-only	线性	—	—	—	0.929	0.647
v1	新语料	分布	dec-only	线性	—	—	—	0.850	0.580
v2	新语料	分位数	dec-only	线性	—	—	—	0.744	0.553
v3	新语料	分位数	dec-only	线性	—	✓	—	0.736	0.533
v4	新语料	分位数	dec-only	线性	—	✓	✓	0.772	0.560
v5	新语料	分位数	dec-only	线性	✓	✓	✓	0.739	0.527
Moirai 2.0	新语料	分位数	dec-only	残差块	✓	✓	✓	0.728	0.516

这条消融链清晰展示了每个决策的贡献：decoder-only 骨架带来小幅提升（0.946 → 0.929）；新语料是第二大步（0.929 → 0.850）；分位数损失是单项收益最大的一刀（0.850 → 0.744）；递归分位数解码（v3）与多令牌预测（v5）各添一分；随机掩码单独用反而降（v4 的 0.772 高于 v3），但在完整组合里有利；最后把线性投影换成残差块，凑出最终成绩。

与前代的全面对比

对比维度	Moirai 1.0	Moirai 2.0
架构	掩码编码器	纯解码器
输入补丁	多补丁（多频率）	单补丁
概率输出	混合分布 + 采样	9 个分位数直接输出
损失	分布 NLL	分位数（Pinball）损失
训练数据利用率	约 15% token 参与损失	全部 token，T−1 个损失/样本
KV 缓存推理	不支持	支持，重复预测最多提速 17 倍
模型规模（最优款）	Large 约 311M	Small 仅 11.4M（小约 30 倍）
推理速度	基准	快约 2 倍
精度	基准	MASE +16%、CRPS +13%

领域层面的结论也值得关注：Moirai 2.0 在 Web/CloudOps、金融等领域表现突出（与其内部云监控数据有关），在自然/环境序列上明显偏弱（预训练语料该类数据太少），交通领域则略逊于 Moirai 1.0。按预测长度分组，短序列排名第 4、中期第 6、长期第 8——优势随预测范围拉长而收窄。

效率上它处于最优性价比区间：同批竞品中，Kairos-50M 更快但精度明显落后（参数还是它的近 5 倍），Granite-FlowState-R1 精度略高但推理慢约 3 倍。Moirai 2.0 在精度、速度、体积三者的权衡上最均衡。

快速上手：五分钟跑通 Moirai 2.0

先给结论：装一个 uni2ts 库，加载 Hugging Face 上的预训练权重，三行代码就能做零样本概率预测，Small 模型在普通 GPU 上即可跑。

安装（官方推荐的 PyPI 方式，框架基于 PyTorch，推理依赖 GluonTS）：

pip install uni2ts

零样本预测完整示例——从 pandas 宽表出发，预测并可视化：

import pandas as pd
import matplotlib.pyplot as plt
from gluonts.dataset.pandas import PandasDataset
from gluonts.dataset.split import split
from uni2ts.eval_util.plot import plot_single
from uni2ts.model.moirai2 import Moirai2Forecast, Moirai2Module

# 1) 读入宽表：行 = 时间，列 = 各条序列
df = pd.read_csv(ts_wide.csv, index_col=0, parse_dates=True)

# 2) 转为 GluonTS 数据集并做滚动切分
ds = PandasDataset(dict(df))
train, test_template = split(ds, offset=-100)  # 末 100 步作为测试
test_data = test_template.generate_instances(
    prediction_length=100,  # 预测长度
    windows=1,              # 滚动窗口数
    distance=100,           # 窗口间隔
)

# 3) 加载预训练权重（Moirai 2.0 Small，仅 11.4M 参数）
model = Moirai2Forecast(
    module=Moirai2Module.from_pretrained(Salesforce/moirai-2.0-R-small),
    prediction_length=100,
    context_length=1680,
    target_dim=1,
    feat_dynamic_real_dim=0,
    past_feat_dynamic_real_dim=0,
)

# 4) 零样本预测 + 可视化
predictor = model.create_predictor(batch_size=32)
forecasts = predictor.predict(test_data.input)
inp = next(iter(test_data.input))
label = next(iter(test_data.label))
forecast = next(iter(forecasts))
plot_single(inp, label, forecast, context_length=200, name=pred, show_label=True)
plt.show()

关键参数速查：

参数	含义	建议
MODEL = moirai2	选择模型家族	可选 moirai（1.x）/ moirai-moe / moirai2
SIZE = small	模型尺寸	small / base / large；论文结论 small 已最优
prediction_length	预测长度（步数）	任意正整数，按业务设定
context_length	输入上下文长度	建议 1000+（论文示例用 1680）
batch_size	推理批大小	按显存调整，small 模型 32 起步
target_dim	目标变量维度	单变量为 1；多变量按列数设为 N

两个落地提示：一是多变量数据会被拆成多条独立单变量序列分别预测（模型本身不支持跨变量联合建模）；二是上下文给足、预测长度别一口气拉太长，长 horizon 的精度衰减是它的已知短板。

应用场景与落地建议

先给结论：Moirai 2.0 最适合多领域、多频率、需要概率边界、算力预算有限的预测任务；它是零样本快速起步的最佳选择之一，也是中小规模部署里性价比最高的时序基础模型。

IT 运维容量规划：对 CPU、内存、流量等云监控指标做多步预测。为什么适配——预训练语料里就有大量 Salesforce 内部云监控数据，Web/CloudOps 是它最强的领域；分位数输出直接给出 P90/P99 上界，正好服务按峰值扩容的决策；KV 缓存 + 11.4M 参数让它能在边缘节点低延迟运行。
金融风控与财务预测：预测波动率、交易量、营收指标并给出置信区间。为什么适配——分位数损失对齐 CRPS、对异常值稳健，天然适配尾部风险分析；金融领域的跨域表现位居前列。
零售与供应链需求预测：零样本预测新品或冷启动品类的销量。为什么适配——跨域泛化能力强，无需为每个 SKU 单独训练；合成数据训练的多样性让它对没见过的销售形态也有一定鲁棒性。
在线/边缘实时预测：小模型 + KV 缓存意味着毫秒级推理，适合设备端或网关侧的流式预测。为什么适配——模型体积小（Small 约 45MB 权重），可在资源受限环境部署。

与同赛道模型的定位对比（帮你选型）：

模型	架构	输出	模型规模	特点
Moirai 2.0	decoder-only	9 个分位数	11.4M / 87M / 305M	效率与精度最均衡，概率输出开箱即用
TimesFM 系列	decoder-only	点预测为主	200M 级	Google 出品，生态成熟，点预测基线强
Chronos / Chronos-Bolt	编码器-解码器	采样分布	20M～710M	Amazon 出品，Bolt 推理极快
Moirai 1.x / Moirai-MoE	掩码编码器 / MoE	混合分布	14M～311M	前代家族，MoE 版本追求更大容量

落地时注意三点反模式：一是别把预测长度设成上下文的好几倍，长 horizon 衰减明显；二是需要协变量（天气、节假日）强介入的场景，先考虑微调或传统模型，它目前不消费外部特征；三是追求多变量联合概率（如多仓库存联动）的场景它做不到，只能逐条预测。需要针对性微调时，Uni2TS 自带 CLI：

python cli/train.py data=etth1 model=moirai_1.1_R_base trainer.max_epochs=50

局限与破局：四条边界与各自的解法

先给结论：Moirai 2.0 的边界清晰且诚实——它把能做和暂时不能做分得很开，每条局限也都有明确的破局路径。

只做单变量：多变量被拆成多条独立序列，丢失了变量间的联合依赖（如多条指标的相关性）。破局方向：论文明确把多变量联合概率预测列为后续工作，或先用合成数据训练多变量分支；短期可自行用多变量模型（如 DeepAR）做对照。
不消费外部协变量：天气、节假日、促销等外生特征无法输入，限制了强外部驱动场景（如零售大促）。破局方向：对协变量敏感的任务用传统统计模型或微调接入；社区也在探索把协变量编码进补丁嵌入的扩展。
长 horizon 精度衰减：短序列排名第 4、长期降到第 8，多令牌 + 迭代解码只是缓解而非根治。破局方向：论文建议长程建模专项研究 + 数据扩展；实践上分段滚动预测（每次预测一段，回填再推）比一口气预测到底更稳。
参数扩展收益为负：4M → 305M 性能反降，说明瓶颈在数据而非模型。破局方向：先扩大预训练语料规模与多样性（论文的明确未来工作），再谈增大模型；应用侧直接用 Small 即可，不必盲目上 Large。

展望未来，论文给出的方向包括结合 LLM 推理能力的时序分析、文本/图像/时序的多模态基础模型，以及数据扩展与长程建模。对一个少即是多的模型来说，下一步的想象力在于：当数据这块短板补上之后，更小的架构还能撬动多大的性能天花板。

相关文章:

基于LLM的开源时序预测模型Lag-Llama

Mon, 31 Aug 2026 22:09:03 CST

Lag-Llama 是时间序列预测领域的第一个开源基础模型：它用 LLaMA 式的解码器 Transformer，把一段历史序列翻译成对未来概率分布的预测，无需针对每个数据集重新训练。2023 年 10 月由 Kashif Rasul 等 18 位作者发布（arXiv:2310.08278，代码 Apache-2.0 开源），2024 年 2 月官方权重在 Hugging Face 开放。它不解决多变量相关性这类大问题，只做一件事——单变量序列的通用概率预测，却因此成为时序基础模型赛道的起点：此后 TimesFM、Chronos、Moirai 相继登场，几乎都以它为对比基准。

时间	事件	意义
2017	DeepAR 发布	概率预测的经典深度模型，但每个数据集都要单独训练
2022–2023	PatchTST、OneFitsAll 等出现	探索通用架构：有人直接把 GPT-2 搬到时序上（OneFitsAll），效果平平
2023-10	Lag-Llama 论文发布	首个时序预测基础模型，架构、数据、权重全部开源
2024-02	官方权重 + Colab Demo 开放	零样本预测开箱即用，任何频率、任意预测长度
2024 全年	TimesFM、Chronos、Moirai 相继发布	时序基础模型赛道爆发，Lag-Llama 成为公认的早期基准

为什么需要时序预测基础模型

时序预测长期处于碎片化状态：换一个领域、换一种采样频率，就要重新训练一个模型。DeepAR、N-BEATS、TFT 等模型在各自的数据集上表现很好，但它们是数据集专用模型——训练时见过什么模式的序列，就只会预测什么模式的序列。真实世界的预测场景常常很窘迫：新城市的客流数据只有三个月、新上线的设备只有几十条记录、某个行业的数据分布和公开基准完全不一样。没有足够历史数据，专用模型根本训练不起来。

NLP 和 CV 领域早已给出答案：先在海量数据上做通识教育（预训练），再在具体任务上微调，甚至完全不训练直接使用（零样本）。GPT、CLIP 都是这个范式。Lag-Llama 要做的，就是把这条路搬到时间序列上，具体带来三个价值：

零样本泛化——面对一个全新的领域/频率，加载预训练权重即可直接预测，不需要任何该领域的训练数据；
少样本快速适应——只给 20% 的历史数据做微调，效果就能追上用 100% 数据训练的专用模型（论文实验证实，详见下文）；
概率输出开箱即用——预测的不是一个点，而是一整个分布，预测区间直接服务于库存、容量、风险这类需要边界值的决策。

基于 lag 的 token 化：把周期性直接写进输入

lag 特征就是回头看的间隔：预测今天 10 点的客流量，最有用的输入不是全部历史，而是昨天 10 点（间隔 24 小时）、上周一 10 点（间隔 168 小时）和上一小时（间隔 1）这几个特定时刻的值。对每个时间步 $t$，模型取过去若干个固定间隔的值组成向量：

$$k_t[j] = x_{t – \mathcal{L}[j]}$$

其中 $\mathcal{L} = \{\ell_1, \ell_2, \dots\}$ 是一个排好序的 lag 索引集合。举个手算的小例子：小时级序列在 $t$ 时刻，取 $x_{t-1}=102$、$x_{t-2}=98$、$x_{t-24}=110$、$x_{t-168}=95$，那么这一时刻的 lag 特征就是向量 $[102, 98, 110, 95]$。预训练使用的 lag 集合覆盖季度、月、周、日、小时、分钟、秒 7 档频率（由 GluonTS 的 get_lags_for_frequency 按频率自动生成后合并去重），所以同一天/周/年的周期在不同采样频率下都能被表达。

这个设计的核心动机是频率无关性：模型不需要知道数据是小时级还是季度级，只看相对间隔。代价是它需要比上下文窗口更长的历史——实际输入长度 = context_length + 最大 lag，历史太短的序列喂不饱它（这一点我们在局限一节再展开）。

日期时间特征：让模型读懂时间刻度

如果说 lag 特征回答的是多久之前，那么日期时间特征回答的就是这一刻是几点几分、周几、几月。每个 token 额外拼接一组从秒内分钟一直覆盖到年内季度的时间特征。这些特征有个巧妙性质：相邻两个时间步之间，只有一个时间特征发生变化——模型因此能隐式推断出序列的采样频率，从而处理预训练时从未见过的频率组合。

汇总统计量：告诉模型这条序列的量级

如果说 lag 特征给出形状，汇总统计量给出的就是量级。预训练语料里有的序列是几十瓦的传感器读数，有的是几百万的订单量，数值范围差几个数量级。Lag-Llama 在每个窗口上计算中位数 Med 和四分位距 IQR 作为两个时间无关的标量协变量拼进每个 token，相当于告诉模型：这条序列大致多大、波动有多宽。这保证了跨数据集归一化后模型不会晕数字。

LLaMA 式解码器：RMSNorm + RoPE 的因果 Transformer

特征准备好后，交给一个和 LLaMA 同构的解码器：M 层带因果掩码的 Transformer 层，每层使用 RMSNorm 预归一化，并在注意力层的 query/key 上施加旋转位置编码（RoPE）。因果掩码保证只用过去预测未来；RoPE 把相对时间距离编码进注意力，让模型知道两个 token 隔了多远。官方发布的权重规模仅约 245 万参数（论文搜索出的最优配置：8 层、9 个注意力头、每头 16 维、上下文 32 步）——在动辄上百亿参数的大模型时代，它小得几乎可以放进任何环境。

分布头：输出 Student-t 分布，而不是一个点

最后一层把隐藏向量映射为 Student-t 分布的三个参数：自由度 $\nu$、均值 $\mu$、尺度 $\sigma$，训练目标是最小化预测分布的负对数似然（NLL）。预测的不是明天 10 点的客流是 1200，而是它服从一个中心约 1200、带厚尾的分布——这是概率预测的核心思想。

为什么选 Student-t 而不是最简单的正态？因为它有厚尾：真实业务序列里常有促销、天气突变、故障这类尖峰，正态分布会把这些当成不可能事件过度惩罚，厚尾则天然宽容。论文刻意选了最简单的参数化分布头（未来可换 normalizing flows、copula 等更复杂的分布），保持模型尽可能简单是作者反复强调的设计原则。

推理时采用贪心自回归解码：用预测出的分布采样下一步，把采样值当作已知历史继续往后推，直到预测长度 P 为止；多次采样得到多条未来轨迹，取经验分位数即可得到预测区间。

鲁棒标准化与数据增强：训练稳定性的两道保险

标准化公式采用减中位数、除 IQR的鲁棒版本，而不是常见的减均值、除标准差：

$$x’_t = \frac{x_t – \operatorname{Med}(x_{1:C})}{\operatorname{IQR}(x_{1:C})}, \qquad \operatorname{IQR}(x_{1:C}) = \operatorname{Med}(\{x_{\lceil C/2 \rceil : C}\}) – \operatorname{Med}(\{x_{1 : \lfloor C/2 \rfloor}\})$$

直观地说：一个突然放大 100 倍的尖峰足以把均值、标准差拉爆，但对中位数和四分位距的影响很小，所以异常值不会污染整个窗口的归一化。数据增强方面使用频域增强 Freq-Mask / Freq-Mix（随机遮蔽/混合序列的频率分量），预训练最优增强概率为 0.5，配合按数据集序列总数加权的分层采样，有效缓解跨领域语料上的过拟合。

设计要素	一句话作用	代码/参数入口
lag token	注入周期先验，实现频率无关	lags_seq（按频率自动生成）
日期时间特征	让模型识别采样频率	time_feat=True
汇总统计量	传递序列的量级与波动信息	scaling（mean/robust）
解码器	因果序列建模	n_layer、n_head、n_embd_per_head
分布头	概率输出（Student-t）	distr_output=studentT
数据增强	缓解过拟合	aug_prob、freq_mask_rate、freq_mix_rate

预训练与效果验证

预训练语料是 27 个公开数据集、约 7,965 条单变量序列、约 3.52 亿个窗口 token，覆盖能源、交通、经济、自然、空气质量、云运维六大领域。作者用 catch22 特征（一套 22 维的时序特征描述符）验证了语料覆盖了广泛的时序表现型，这是模型能泛化到未见数据的前提。

预训练配置	取值
数据语料	27 个公开数据集，六大领域（能源/交通/经济/自然/空气质量/云运维）
序列规模	7,965 条单变量序列 ≈ 3.52 亿窗口 token
采样策略	分层采样：按数据集总序列数加权
数据增强	Freq-Mask / Freq-Mix，增强概率 0.5
优化器 / 学习率	Adam / 1e-4
Batch size	256
每 epoch 窗口数	100（长度 = 最大 lag + 上下文）
早停	50 epochs（按验证损失）
训练硬件	单张 Nvidia Tesla P100（12GB）

论文还给出了超参数搜索的最优配置（随机搜索 100 组配置，按预训练验证损失挑选），其中最值得注意的两点：上下文长度只需要 32 步，权重衰减和 Dropout 都设为 0——模型很小，正则化反而多余；以及一个重要的宏观发现：验证损失随预训练数据量按幂律下降，说明时序基础模型同样遵循神经网络的缩放定律，数据与模型继续做大仍有收益。

超参数	搜索范围	最优值
层数 M	1–9	8
注意力头数	1–9	9
每头嵌入维度	16–512	16
上下文长度 C	32–1024	32
增强概率	0–1.0	0.5
Freq-Mask 比率	0–1.0	0.5
Freq-Mix 比率	0–1.0	0.25
权重衰减 / Dropout	0–1.0	0 / 0

效果验证采用 CRPS（连续排序概率分数，把预测分布与真实值在所有分位数上的差距积分，越低越好）：

$$\operatorname{CRPS}(F, x) = \int_{-\infty}^{\infty} \left(F(y) – \mathbb{1}\{y \geq x\}\right)^2 \, dy$$

下表是 7 个未见过的数据集上、基于 100 个经验采样样本计算的 CRPS 值，以及模型在 15 个基线中的平均排名：

数据集（领域）	零样本 CRPS	微调后 CRPS
weather（天气）	0.164 ± 0.001	0.132 ± 0.001
ped-counts（行人计数）	0.285 ± 0.033	0.227 ± 0.010
ett-m2（电力变压器温度）	0.063 ± 0.002	0.017 ± 0.001
platform-delay（平台延迟）	0.091 ± 0.002	0.096 ± 0.002
requests（服务器请求量）	0.090 ± 0.015	0.012 ± 0.002
beijing-pm2.5（空气质量）	0.130 ± 0.009	0.125 ± 0.021
exchange（汇率）	0.011 ± 0.001	0.009 ± 0.000
平均排名（15 个基线）	6.714	2.786

两个结论值得记住。第一，零样本已经很能打：不训练任何参数，平均排名 6.714，已经和一大批认真训练过的专用模型处在同一水平（DeepAR 5.714、Informer 6.429），在 weather、platform-delay 等数据集上尤其接近最优。第二，微调才是它的高光：在 ETT-M2、weather、requests 三个数据集上达到 SOTA，平均排名 2.786，领先最强监督基线 TFT（5.000）两个名次以上；更夸张的是少样本场景——只给 20% / 40% / 60% / 80% 的历史数据做微调，平均排名分别达到 1.857 / 1.500 / 1.571 / 1.429，每一档都是全场第一。注意也有反例：platform-delay 微调后 CRPS 不降反升（0.091 → 0.096），说明微调不是万能药，数据量过小时反而可能扰动预训练学到的知识。

上手实践：零样本 → 微调 → 评估

官方实现基于 GluonTS 构建，安装、下载权重、预测的流程非常短。第一步永远是先跑零样本：一个 29MB 的权重文件 + 十行代码，就能拿到带区间的预测。

git clone https://github.com/time-series-foundation-models/lag-llama.git
cd lag-llama
pip install -r requirements.txt

# 下载官方预训练权重（约 29MB，Apache-2.0 许可）
huggingface-cli download time-series-foundation-models/Lag-Llama lag-llama.ckpt --local-dir .

import torch
from lag_llama.gluon.estimator import LagLlamaEstimator

# 1) 加载官方预训练权重（lag-llama.ckpt 与脚本同目录）
ckpt = torch.load(lag-llama.ckpt, map_location=cpu)

# 2) 创建估计器：预测未来 24 步，用历史 64 步，采样 100 条轨迹
estimator = LagLlamaEstimator(
    ckpt_path=lag-llama.ckpt,
    prediction_length=24,
    context_length=64,
    nonnegative_pred_samples=True,   # 客流/电量等非负场景建议开启
    num_parallel_samples=100,        # 轨迹数越多，分位数越平滑
)

predictor = estimator.create_predictor(
    estimator.create_transformation(),
    estimator.create_lightning_module(),
)

# 3) 用 GluonTS 内置数据集做零样本预测（示例：澳大利亚用电需求）
from gluonts.dataset.repository.datasets import get_dataset

dataset = get_dataset(australian_electricity_demand, regenerate=False)
test_data = dataset.test

for forecast in predictor.predict(test_data):
    mean    = forecast.mean                  # 预测均值
    p50     = forecast.quantile(0.5)         # 中位数
    lo, hi  = forecast.quantile(0.1), forecast.quantile(0.9)  # 80% 预测区间
零样本确认可用后，再用自己的数据微调。微调的关键是从预训练权重出发、减小模型规模、放宽正则——官方 notebook 的常用配置如下：
from lag_llama.gluon.estimator import LagLlamaEstimator
from gluonts.dataset.common import ListDataset

# 把自己的数据包装成 GluonTS 格式：每条序列一个 {start, target}
train_data = ListDataset(
    [{start: start_ts, target: values}],   # start 为 pd.Timestamp，values 为 np.ndarray
    freq=H,                                   # 数据频率（D/H/T 等）
)

estimator = LagLlamaEstimator(
    ckpt_path=lag-llama.ckpt,   # 从预训练权重出发（迁移学习）
    prediction_length=48,
    context_length=32,
    n_layer=3,                    # 微调时减少层数，防止小数据过拟合
    n_embd_per_head=16,
    n_head=4,
    scaling=mean,
    nonnegative_pred_samples=True,
    aug_prob=0.5,                 # 数据增强开关
    freq_mask_rate=0.1,
    freq_mix_rate=0.05,
    lr=1e-3,                      # 微调用更大学习率
    batch_size=32,
    num_parallel_samples=50,
)

transformation = estimator.create_transformation()
train_dl = estimator.create_train_dataloader(train_data, transformation)
valid_dl = estimator.create_validation_dataloader(valid_data, transformation)

trainer = estimator.create_trainer()
trainer.fit(estimator.create_lightning_module(), train_dl, valid_dl)
最后用 GluonTS 的评估工具量化效果。注意论文里的 CRPS 与分位数加权损失本质等价（CRPS 是对所有分位数的 pinball loss 求积分），因此用 GluonTS 的 Evaluator 即可：
from gluonts.evaluation import make_evaluation_predictions, Evaluator

forecast_it, ts_it = make_evaluation_predictions(
    dataset=test_data,          # GluonTS 格式的测试集
    predictor=predictor,
    num_samples=100,
)

evaluator = Evaluator(quantiles=[0.1, 0.5, 0.9])
agg_metrics, _ = evaluator(ts_it, forecast_it)
print(agg_metrics[mean_wQuantileLoss])   # 分位数加权损失（越低越好）

实践中还有四个容易踩的坑：

权重版本——官方在 2024 年中修复了 KV-cache 的因果注意力正确性问题，务必从 Hugging Face 拉取最新lag-llama.ckpt，并在自己的数据上做回归对比；
采样数——num_parallel_samples直接决定区间质量：太少（如 10）分位数毛糙，100 是常用值，但推理成本随之线性上升；
lag 集合——默认 lag 面向常见周期，如果你的序列有不常见周期（如 30 天账期、学期制），需要自定义lags_seq；
单变量限制——每条序列独立预测，多变量问题要么逐通道预测，要么换 Moirai / TimesFM 等多变量方案。

它最合适的三个场景：

库存/安全库存——决策需要边界值而非均值，概率输出（分布头 + 采样）直接给出缺货概率，适配原因：区间越准，备货成本越低；
运维容量与成本——服务器请求量、云资源用量通常只有少量历史且模式多样，零样本即可上线，微调后逼近专用模型，适配原因：少数据场景正是基础模型的主场；
出行/零售的客流需求预测——早晚高峰、周末、节假日的周期性极强，lag 特征天然覆盖日/周/年周期，而大促、突发天气带来的尖峰正好落在 Student-t 厚尾的容忍范围内。

与同期模型的横向对比

Lag-Llama 之后，时序基础模型迅速形成四强并立的格局。它们最大的分歧在于如何把连续序列变成模型能吃的输入：Lag-Llama 用 lag 特征，TimesFM 用 patch 化，Chronos 把数值量化成 token（把时序当语言建模），Moirai 则同时支持多变量与混合频率。

维度	Lag-Llama	TimesFM	Chronos	Moirai
提出时间	2023-10（论文）/ 2024-02（权重）	2024	2024-03	2024-05
输入表示	lag 特征 + 日历特征	patch 化	量化 token	patch + 任意变量
概率输出	Student-t 分布头	分位数头	token 分类分布采样	分布输出
变量类型	单变量	单变量（可加协变量）	单变量	任意变量
参数量	≈2.45M	≈200M	8M–710M（5 档）	small / base / large
最擅长	轻量、易微调、原生概率	长上下文、零样本	把时序当语言建模	多变量、MoE
许可证	Apache-2.0	Apache-2.0	Apache-2.0	Apache-2.0

选型建议可以一句话概括：要原生概率输出、要在小数据上快速微调、预算有限——选 Lag-Llama；要超长上下文零样本——选 TimesFM；要处理多变量联动——选 Moirai；想体验把时序当语言的新范式——看 Chronos。

局限与破局

基础模型不是银弹，Lag-Llama 的边界非常清晰，四条局限都对应着明确的破局路径：

只做单变量——不建模多个变量之间的相关性，多变量系统只能逐通道预测、丢失联动信息。破局：Moirai 等任意变量模型直接建模多变量；Lag-Llama 自身也有引入 LSTM 增强长期依赖的变体研究；
lag 特征要求最小上下文——实际输入必须 ≥ 最大 lag，短序列（如只有一周数据的冷启动场景）喂不饱。破局：Chronos 的量化 token 和 TimesFM 的 patch 化对上下文要求更宽松；极短序列也可回到 ETS / ARIMA 等传统方法；
零样本只是能打，不是最强——真正的 SOTA 要靠微调，且个别数据集微调后反而变差（如 platform-delay）。破局：预算内优先微调，用官方 notebook 配置起步；用验证集做早停，防止小数据过拟合破坏预训练知识；
生态更新节奏慢——2024 年中才修复 KV-cache 正确性问题，checkpoint 演进不如大厂模型频繁。破局：锁定版本 + 建立回归测试；需要长期维护的生产系统可评估 TimesFM 等更新更活跃的选项。

Lag-Llama 用lag 特征 + LLaMA 解码器 + Student-t 分布头这个朴素组合，证明了时序基础模型这条路走得通，并由此开启了 2024 年时序基础模型的全面爆发——今天的 TimesFM、Chronos、Moirai，都是在回答它提出的同一个问题：如何让一个模型学会预测所有时间序列。

相关文章:

高性价比大模型GLM 5.3 Flash 和 Qwen3.8-Flash 同一天发布

Thu, 27 Aug 2026 11:24:21 CST

Ox Alpha 正式模型名称为 GLM 5.3 Flash Vison

划重点：

- 国产芯片雄起，这几天全球每天超过 100T 的供应量，全部由国产芯片提供算力支持，低价管饱，改变行业格局

- Artificial Analysis Intelligence Index 57 分，和 Opus 4.8 打平

- 模型定价，现在限时半价，只要 Opus 4.8 的 1/40，新的性价比斩杀线已经形成

- 超低成本的全新架构，参数 320B，激活参数 18 B，价格做到了上一代 GLM 5.3 的十分之一

- 真正原生多模态模型，不止是能看见，还能感知环境，通过视觉迭代改进，可以自己在 Blender 画出一个厨房。。。

GLM 5.3 Flash 目前已经在 http://z.ai 上线

http://colaos.ai 已经在上周五接入限免测试版，明天正式上线正式版

价格和接入：

https://docs.bigmodel.cn/cn/guide/models/vlm/glm-5.3-flash…

开源：

https://huggingface.co/zai-org/GLM-5.3-Flash…

Qwen3.8-Flash

一个多模态 MoE 模型，同时也是 Qwen4 架构的早期预览版，现已开源权重！

生产版本 Qwen3.8-Flash 即将通过 QwenCloud API 提供，价格仅为 $ 0.16/1M 输入令牌和 $ 0.47/1M 输出令牌。

125B 参数 + 51B N-gram 嵌入，每个令牌仅激活 6B。无与伦比的性价比。

新特性：

- 下一代架构：GDN + QSA 混合注意力、门控残差、N-gram 嵌入 & Muon 优化器，作为 Qwen4 中使用的架构的前身。

- 训练和推理成本大幅降低：训练成本仅为 Qwen3.7-Plus 的 1/9，同时在各方面超越它，尤其在编码和办公任务中表现出色。

- 强劲性能：在 DeepSWE 1.1 上得分 58.7，在 SWE-bench Pro 上得分 62.5，在 CoWorkBench 上得分 73.9，在 AndroidWorld 上得分 84.5，在 MathVision（带 CI）上得分 95.7。

- 262K 原生上下文，可通过 YaRN 扩展至 1M。

Qwen还发布了 Qwen3.8-Flash-Next 的权重 - 博客： https://qwen.ai/blog?id=qwen3.8-flash-next…

- 技术报告： https://github.com/QwenLM/Qwen3.8-Flash-Next/blob/main/tech_report.pdf…

- Hugging Face： https://huggingface.co/Qwen/Qwen3.8-Flash-Next?spm=a2ty_o06.30285417.0.0.1d73c921FsyOPe&file=Qwen3.8-Flash-Next…

刚刚，新款 Mac mini 发布！价格大涨2500元，苹果第一次为 AI 造电脑

Tue, 25 Aug 2026 21:10:31 CST

2026 年最好的 AI PC，刚刚迎来了一大波更新。

苹果正式发布全新一代 Mac mini 和 Mac Studio。新一代桌面 Mac 带来了 M6、M5 Pro、M5 Max 与 M5 Ultra 四款芯片选择，也进一步拉高了苹果在本地 AI 计算领域的性能上限。

其中，Mac mini 提供 M6 和 M5 Pro 两种版本，起售价分别为 6999 元和 12999 元。针对教育用户，苹果还提供对应优惠价格，M6 版 Mac mini 起售价为 6199 元，M5 Pro 版为 12199 元。

Mac Studio 则提供 M5 Max 与 M5 Ultra 两种版本，起售价分别为 19999 元和 46999 元，将模型容量、内存带宽和多机扩展推向更高层级。

作为对比，M4 Mac mini 国行起售价在今年 6 月已经由 4499 元涨至 5999 元，M4 Pro 版目前为 12499 元起。新款 M6 和 M5 Pro 版又分别上涨 1000 元和 500 元。

四款全新机型均于 8 月 27 日开启预购，9 月 22 日起发售。其中，配备 512GB 统一内存的 Mac Studio 将于 10 月下旬上市。

苹果最小的 Mac，正在成为 AI 时代的新入口

过去，Mac mini 在苹果产品线里的定位非常明确。它是一台价格相对友好的 Mac，让用户用较低成本进入 macOS 生态。

但新款 Mac mini 的任务伴随着年初 OpenClaw 的爆火，它除了承担办公、影音和日常创作，也逐渐成为越来越多用户运行本地 AI 模型和 AI Agent 的设备选择。

具体而言，新款 Mac mini 的核心变化，来自全新的 M6 芯片。

作为苹果首款采用 2 纳米制程的 M 系列芯片，M6 配备 12 核 CPU、12 核 GPU，以及两组 16 核神经网络引擎。其中，CPU 包含 2 个超级核心、4 个性能核心和 6 个能效核心，核心总数比 M5 增加 2 个。

苹果官方给出的数据显示，M6 的多线程 CPU 性能最高达到 M5 的 1.2 倍、M1 的 2.4 倍。放到 Mac mini 中，与上一代 M4 版本相比，其 CPU 性能最高提升 40%，图形性能最高达到 2 倍，AI 性能最高达到 4 倍。

M6 的 12 核 GPU 首次在 Mac mini 的每个 GPU 核心中加入神经网络加速器。其 AI 峰值计算能力较 M5 提升接近 30%，较 M1 提升超过 8 倍，主要用于加快大模型的提示词处理。

两组 16 核神经网络引擎的峰值计算能力最高达到前代的 2 倍。系统框架可以同时调用两组引擎，提高设备端模型的执行效率。

M6 版从 16GB 统一内存起步，最高可选 32GB，内存带宽达到每秒 170GB，较 M5 提高 10%，是 M1 的 2.5 倍。

在具体应用中，这款机型使用 LM Studio 处理大模型提示词的速度，最高达到 M1 版 Mac mini 的 13.5 倍、M4 版的 4.8 倍。

其 Microsoft Excel 表格计算速度最高达到 M1 版的 2.3 倍、M4 版的 1.5 倍。在支持光线追踪的《赛博朋克 2077：终极版》中，游戏性能最高达到 M4 版的 2 倍。

由此来看，M6 版 Mac mini 已经不只是入门办公电脑。

它同时面向普通用户、学生、开发者、AI 爱好者和企业用户，可以处理智能编码、图像生成、模型推理和轻量级 Agent 任务。

如果你有更复杂的工作负载，苹果还准备了 M5 Pro 版本。

M5 Pro 最高配备 18 核 CPU 和 20 核 GPU，每个 GPU 核心同样包含神经网络加速器。统一内存最高达到 64GB，带宽达到每秒 307GB，可以容纳体量更大的模型、复杂三维场景、ProRes RAW 视频文件和科研数据集。

在 LM Studio 中，M5 Pro 版 Mac mini 的大模型提示词处理速度最高达到 M2 Pro 版的 8.5 倍、M4 Pro 版的 4 倍。其 Blender 光线追踪渲染性能最高达到 M2 Pro 版的 4.5 倍，Affinity 图像处理性能最高达到 2.1 倍。

苹果官方介绍还将其描述为适合 AI Agent 或创意工作流的安静、高效常驻设备。这一定位说明，Mac mini 的使用场景正在从用户主动操作，延伸到后台持续运行。

连接能力也围绕这一方向升级。

两种版本均支持 Wi-Fi 7、蓝牙 6 和 2.5Gb 以太网，并可选配 10Gb 以太网。机身正面配备两个支持 USB 3 的 USB-C 接口和一个高阻抗耳机插孔。

M6 版背面配备三个 Thunderbolt 4 接口，M5 Pro 版则配备三个 Thunderbolt 5 接口，另外还有 HDMI 和以太网接口。

借助 Thunderbolt 5，多台 M5 Pro 版 Mac mini 可以组成集群，共同承载超出单机能力的模型。新增的 USB-C 同步锁相功能，则可以让显示设备与 iPhone 17 Pro 等拍摄设备实现精确同步。

至此，Mac mini 获得了一个新身份。它既是一台个人桌面电脑，也可以成为连接数据、应用和 Agent 的小型 AI 节点。体型虽小，野心拉满。

从单机到集群，Mac Studio 组队越级

如果说 Mac mini 提供了个人 AI 计算的入口，那么 Mac Studio 承担的就是更高强度的模型推理、训练与创意工作。

新款 Mac Studio 提供 M5 Max 与 M5 Ultra 两种版本。

M5 Max 配备 18 核 CPU，其中包括 6 个超级核心和 12 个性能核心。GPU 最高拥有 40 个核心，每个核心都内置神经网络加速器。统一内存最高达到 128GB，带宽达到每秒 614GB。

与 M4 Max 相比，M5 Max 在 LM Studio 中处理大模型提示词的速度最高达到 3.9 倍，文生图性能最高达到 3.5 倍，DaVinci Resolve Studio 的 Magic Mask 性能最高达到 3 倍。与更早的 M1 Max 相比，其大模型提示词处理速度最高达到 10.7 倍。

到了 M5 Ultra，苹果干脆把「力大砖飞」写进了芯片结构。

它通过新一代 UltraFusion 技术，将两颗采用双芯片晶粒设计的 M5 Max 连接起来，形成苹果首个四晶粒 M 系列系统级芯片。

UltraFusion 的晶粒间带宽超过每秒 4.4TB，连接密度提升超过 6 倍，使四个晶粒可以像一个统一处理器一样运行。

M5 Ultra 最高配备 36 核 CPU 和 80 核 GPU，并首次在 Ultra 芯片的每个 GPU 核心中加入神经网络加速器。其 AI 峰值性能最高达到 M3 Ultra 的 4.3 倍、M1 Ultra 的 9.8 倍。按照芯片层面的峰值 GPU AI 算力计算，其性能最高达到 M3 Ultra 的 4.5 倍。

搭载 M5 Ultra 的 Mac Studio 最高支持 512GB 统一内存，带宽达到每秒 1.2TB。这样的容量可以在设备内保存大型数据集，并承载数百亿乃至数千亿参数的模型。

在 LM Studio 中，该机型的大模型提示词处理速度最高达到 M1 Ultra 版的 9.8 倍、M3 Ultra 版的 4 倍，文生图性能最高达到 8.2 倍和 4.3 倍；Foundry Nuke 的 CopyCat 训练速度最高达到 M1 Ultra 版的 15.4 倍。

M5 Ultra 还配备更强的媒体引擎，可以同时播放最多 33 路每秒 30 帧的 8K ProRes 422 视频。新款 Mac Studio 的存储速度最高提升至 2 倍，采用基于 PCIe 6 的新一代固态存储架构。

Mac Studio 首次支持 Wi-Fi 7 和 Bluetooth 6，同时加入 Thunderbolt 5 连接能力，可以连接高速外置存储、PCIe 扩展机箱和其他专业设备。整机最多支持 8 台显示器，或者 4 台以 5K 分辨率、120Hz 刷新率运行的 Studio Display XDR。

相比单机性能，多机集群更能体现这次升级对产品逻辑的改变。

新款 Mac Studio 支持通过 Thunderbolt 5 和远程直接内存访问技术连接。多台设备可以组成低延迟网络，共同执行分布式 AI 推理。根据苹果公布的数据，4 机集群的推理性能最高可以达到单机的 3 倍。

值得一提的是，今年 6 月，苹果在 WWDC26 期间的一场特别活动中，展示了这种集群的实际运行方式。

现场的 4 台 Mac Studio 通过 Thunderbolt 5 连接，并利用 RDMA over Thunderbolt 建立低延迟通信网络。

借助 LM Studio 当时即将推出、基于 MLX Distributed 的功能，LM Studio 员工加载并运行了 Kimi K2.6 这一万亿参数规模的开放权重模型。

其背后的关键是分布式计算。

对于一万亿参数模型，如果采用 FP16 精度，仅模型权重理论上就需要约 2TB 内存，尚未计入缓存和其他运行开销。单台个人电脑很难提供如此大的可用空间，多机协同则可以同时扩展计算能力、内存容量与带宽。

不过，桌面集群的实际性能仍然受到模型精度、内存配置、通信速度和模型架构影响。

下一代个人电脑的用户，未必是人类

今年 2 月 6 日，可能是人类最后一次在 AI 服务中消耗了比 AI Agent 更多的 token。

OpenRouter 数据显示，此后 Agent 的 token 使用量超过人类，并在约半年内增长至原来的 14 倍，人类当然并没有减少使用 AI，只是越来越多 token 的触发指令被交给了 Agent 代劳。

因 OpenClaw 爆火而受到关注的 Mac mini，也展示了一种此前并不突出的硬件需求。

以前，人敲打键盘，电脑执行，然后等待下一次指令。Agent 的到来改变了这种供需关系。

一台面向 Agent 的设备，需要保留用户的文件、历史记录、应用权限、模型状态和任务上下文。它不仅要完成一次推理，还要知道此前做过什么、当前进行到哪一步，以及接下来可以调用哪些资源。

从这个角度看，以 Mac mini 为代表的 Mac 电脑受到关注，不只是因为它体积小、功耗较低或者性能足够强。更深层的原因是，它具备成为这种数字环境的基本条件。

它可以接入用户的本地文件和系统应用，也能将敏感数据保留在设备内。

不过，外形和能效只能解释它为什么适合常驻桌面，真正决定模型运行能力的，是 Apple Silicon 的统一内存架构。

传统电脑通常由 CPU 使用系统内存，独立 GPU 使用显存。

模型权重和计算数据需要通过总线在两类内存之间传输。独立显卡虽然拥有很强的峰值算力，但消费级产品的显存通常只有几十 GB，模型规模很容易受到容量限制。

Apple Silicon 让 CPU、GPU、神经网络引擎和其他模块共享同一个物理内存池。模型权重、输入数据和中间结果只需要保存一份，减少了重复存储和数据搬运。

M6 最高支持 32GB 统一内存，带宽为每秒 170GB。M5 Pro 将两项指标提高至 64GB 和每秒 307GB。M5 Max 进一步达到 128GB 和每秒 614GB。M5 Ultra 则提供最高 512GB 容量与每秒 1.2TB 带宽。

统一内存负责容纳模型，芯片提供计算能力，Core AI、Core ML、Metal 和 MLX 等框架负责调度硬件，操作系统与本地应用则向 Agent 提供数据和工具。

这些能力结合在一起，构成了 Mac 在 Agent 时代的优势。它提供的不只是一次模型推理，而是一套覆盖上下文、权限、状态和执行过程的本地 AI 环境。

电脑角色的变化，也开始影响 Mac 的产品分层。

过去，苹果主要按照性能需求、工作负载、预算和便携性划分产品线。在这套体系中，mini、Pro、Max 和 Ultra，不同程度地代表着用户对性能的需求，以及所从事工作的专业程度。

当电脑的操作者开始包含 AI，新一代桌面 Mac 因而显露出另一套分档逻辑。

M6 版 Mac mini 面向日常 AI 工具、智能编码和轻量级 Agent 任务。M5 Pro 版可以承载更复杂的模型与内容处理。M5 Max 版 Mac Studio 进入专业 AI 开发、图像视频生成和大型数据集处理。M5 Ultra 版则指向前沿模型推理、本地训练与多机协同。

某种程度上，mini、Pro、Max 和 Ultra 正在逐渐代表一台机器可以承载的 AI 工作负载等级。

这不是苹果第一次强化 Mac 的相关性能，却可能是 AI 第一次如此完整地影响 Mac 的整机定位、层级划分和扩展方式。

而当 Agent 消耗的 token 超过人类，电脑行业也必须重新面对一个基础问题：一台电脑究竟在为谁工作？新一代 Mac 给出的答案是，它仍然属于人类，但使用它的已经不只有人类。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

为什么你的本地LLM用起来感觉比实际更“笨”

Mon, 24 Aug 2026 11:24:11 CST

快速引言

我们都有过这样的经历：在论坛、聊天、Reddit、Discord、YouTube等地方，听到有人惊呼“哦！某某模型简直太棒了！”，然后下载了它（或者更可能是它的某个量化版本），一试之后却觉得“呃…这太烂了！”

这篇文章将是一系列相当技术性的实验，旨在展示推理过程中，因具体实现方式（implementation-specific）而产生的差异所造成的影响。我会用“参考实现”这个词来指代那些发布模型并提供官方托管、并公布原始基准测试结果的实验室。他们的硬件和软件都会与你的大不相同。而本文中的对比，也不会是在Ollama中跑几个测试提示词、比较2.58-bit的GGUF模型那么简单。

为了让大家更容易理解，我会故意略过一些新兴的研究领域和大量研究论文。请不要对我的过度简化吹毛求疵，否则我可能会让你去读那又长又烦人、还带数学公式的版本。

你的本地实现很糟糕。但没关系，因为其他人的也一样。

如今，每一个运行LLM的硬件和软件实例都略有不同，在某些情况下甚至可能大相径庭。一般的家庭实验室用户可能混合使用着不同世代的GPU，这些芯片上的指令集各不相同。这些指令集在执行数学运算来计算你的下一个token时，方式也会因人而异，即使大家运行的是完全相同的权重。

这就引出了第一个问题：你的特定配置到底有多“糟糕”？事实证明，有很多不同的方法可以衡量这一点。

实际的方法很直接：运行标准的基准测试，并且要多样化。比如terminal bench、hle、SWEthis、HELLAthat、MMLU-whatever……随便选。关键是要确保这些测试能代表你的实际工作负载和用例。不要只是把温度调到0，粘贴3个测试提示词，然后就断定模型好或不好。零样本（Zero-shot）测试并不能很好地模拟大多数智能体（agentic）任务。你需要长上下文的工具调用和特定领域的知识评估，才能在与他人运行相同权重并复现相同基准测试时，找出你配置的弱点所在。

但我将从纯粹的数学角度开始讨论，因为正如@wendell所说：

数学就是数学！

“Logits（逻辑值）”是模型对每个可能的下一个token给出的评分。这些评分会被归一化为概率，然后通过配置好的采样器（sampler），最后由解码器（detokenizer）转换回文本，从而在解码过程中生成 THE→NE→XT→TOK→EN。

关于采样器设置的一个旁注：Hugging Face模型卡通常会明确指定你应该使用的采样器设置（以及聊天模板），例如 temp 1.0, top-p 0.95 等，不同模型有所差异，请确保你使用了正确的设置。顺便说一句，温度设得太低就是导致你的Qwen模型陷入循环、无法跳出其“THINK”输出的原因。不用谢，很高兴能帮你解决这个问题。

当下一个token的概率发生足够大的变化时，THE→NE→XT 就可能变成 THE→NE→W→DAY……虽然这些微小的变化可能没问题，但很可能是你潜意识里总觉得“哪里不对劲”的源头。

你们有些人可能听过KLD（KL散度，Kullback-Leibler Divergence）这个术语。别担心，我不会让你做数学题，也不会用一堆小数表格轰炸你的大脑。简单来说就是：将输出的logits转换为概率分布，然后衡量该分布相对于选定基线移动了多少。较低的KLD值意味着更接近基线，但并不自动代表模型“更聪明”。 KLD也是有方向的，所以两个分布的顺序很重要。

提醒一句：不要被某个量化模型HF模型卡上低得不可思议的KLD声明所迷惑。除非作者披露了参考检查点、完整的运行时环境、评估文本、校准数据、上下文长度、采样位置、KL方向、任何词汇表截断以及测量结果的聚合方式，否则这个数字是无法解读的。方法论和数字本身同样重要，而很多人在这方面会出错。

vllm到底在做什么？

现在，我们需要简要探讨一下你的推理引擎上那庞大的软件栈到底在做什么，以便理解这些差异的一些来源。

在这个被极度简化的流程图中，每一步都包含可以根据你的具体硬件/软件配置、模型、量化方式、张量形状等进行配置或更改的组件。

我抓取的vLLM每日构建版（nightly）容器镜像包含了734个软件包。这意味着有734个代码库，每个都有其自身的错误和未文档化的特性。你的特定实现穿过这座“代码山”的路径将是独一无二的。

测试1：注意力后端的精度基准测试

让我们从推理流程图中的一部分开始。在预填充（prefill，即提示词处理）阶段，你的推理引擎会从几个注意力后端中选择一个。这会影响预填充的速度和精度，同时不同的GPU家族/流处理器（SM）计算能力版本需要不同的CUDA内核。我们来测试并比较它们。

（非常抱歉，但我觉得有必要这么做…）

我从Qwen3.6-27B的官方BF16检查点开始，在RTX PRO 6000 Blackwell GPU上运行，张量并行度（tensor parallelism）设为1。KV缓存使用BF16格式，没有采用权重、激活或KV缓存的量化。软件环境是固定版本的vLLM每日构建版。我使用了eager执行模式，禁用了CUDA图、前缀缓存和MTP，并采用了2k-token的分块预填充（chunked prefill）。

Qwen3.6-27B是密集（dense）模型，而非MoE（混合专家）模型，但它仍是一个混合架构：64层以“三个门控DeltaNet/线性注意力层”加“一个全注意力层”的模式重复。只有那16个全注意力层在此实验中使用可选注意力后端；门控DeltaNet路径保持不变。

这里重放的工作负载是“Prompt 2”，一个约10万token的上下文，来自真实的Turnstone实验室工作流，包含多次工具调用和实际工作产物。选择它是因为它模拟了本地智能体实际的工作方式，而不是那种合成的“大海捞针”测试。而且更重要的是，这个工作负载没有出现在当今任何基准测试或训练数据集中。没有人能针对这个进行过基准优化，或校准他们的量化方案来适应它。

在这个工作负载下，vLLM中有三个可用的全注意力后端可供选择：FlashAttention 2、Flash Inference 和 Triton Attention。这是执行之间唯一更改的设置，其余硬件和软件栈保持稳定。

我还进行了相同后端、跨GPU的可重复性控制测试。在这张图表中，我每32个提示词token捕获一次BF16格式的完整词汇表logits。像KLD这样的分布比较，是之后在FP64精度下从这些存储的logits中计算得出的。

“Top-1一致性”是指具有最高logit的token（即贪婪解码的argmax）是否相同。所有三个后端都针对相同的强制token历史进行了评估。因此，“top-1翻转”意味着在该位置，某个后端会选择不同的贪婪解码下一个token。我们并没有让这个选择改变后续的历史。这保证了数学比较的可控性，但它无法展示一个不受约束的生成过程会如何分支，或者一次工具调用是否会最终失败……这部分将在测试2中揭晓 ;D

下图显示了导致token翻转的采样logits百分比：

在最初的几千个token中，无论使用哪种后端，模型对下一个token的预测都是一致的。但在提示词的后半部分，后端开始出现分歧。这里选择Triton作为基准，以简化后续的量化对比。

每个8k-token窗口包含250个采样位置（每32个token探测一次）。百分比指的是在这些探测点中，其他后端得分最高的token与Triton不同的比例。

通过使用相同的注意力后端多次运行相同测试，来排除随机噪声的影响。结果显示，每次运行的logits在每个隐藏状态上都逐位（bit for bit）相同。这意味着观察到的差异完全来自于在预填充期间，在Triton/FA2/FI内部发生的矩阵乘法和加法运算。

分歧呈集群式出现，并且随提示词内容变化，而非随上下文长度平滑增加。这并不能证明存在某个使模型“崩溃”的通用长度阈值……但我们很快就会讲到……

现在我们有了一个关于特定提示词工作负载的基线比较，让我们深入探讨……

测试2：KV缓存量化，或为什么你的LLM在超过4万token后智商陡降

重复相同的方法，我们以上述运行Triton的BF16权重和BF16 KV缓存基线为基准，进行了下一个实验：保持权重和激活不变，仅量化KV缓存，会发生什么？

答案就是：分歧。这引出了我们今晚的第一个“大型翻车现场”：一个完全可重现的工具调用错误。

在工具调用期间，足够多的top-token被翻转了。我们让它们继续执行，结果发现：BF16一切正常，int8 KV缓存最终设法恢复了，而 int4 KV缓存则完全无法恢复！

测试3：权重，别告诉我！

这次我们保持所有KV缓存为完整的BF16大小。但我们引入了一些新的选手来进行比较：

BF16参考：Qwen/Qwen3.6-27B 官方
官方FP8：Qwen/Qwen3.6-27B-FP8 官方
INT8 W8A16：TheHouseOfTheDude 社区量化
NVIDIA NVFP4：nvidia/Qwen3.6-27B-NVFP4 官方
AWQ W4A16：cyankiwi 社区量化

这4种量化方案代表了权重和激活的广泛图景。对我们“数学爱好者”来说，一个值得注意的信息是，计算每种量化logits时所实际运行的CUDA内核 / GEMM（通用矩阵乘法） / MMA（矩阵乘加）指令都是不同的：

Qwen3.6-27B (参考)

权重/激活：BF16权重，BF16激活
线性层/GEMM：未量化线性方法 → torch.nn.functional.linear。每个CUDA块由其相关的形状/几何结构选择。
KV缓存：BF16（强制）
特性：参考检查点。

Qwen3.6-27B-FP8

权重/激活：128×128块中的E4M3 FP8权重；在转换后的线性层内进行动态FP8激活量化； lm_head等排除模块保持BF16。
线性层/GEMM：Fp8LinearMethod → CutlassFp8BlockScaledMMKernel
KV缓存：BF16（强制）
特性：由于vLLM将其E8M0缩放格式标记为此架构（SM120）的精度降级，DeepGemm被自动禁用；转而选择了CUTLASS。发布文件中未识别出校准数据集。

Qwen3.6-27B-INT8

权重/激活：静态、对称、通道级别的INT8线性权重；BF16激活 (W8A16)。GDN/linear_attn投影和 lm_head被排除在量化之外。
线性层/GEMM：CompressedTensorsWNA16 → MarlinLinearKernel
KV缓存：BF16（强制）
特性：一次性量化（one-shot），明确没有使用校准数据集。考虑到W8A16加上未量化的GDN投影，其异常良好的保真度就不那么神秘了。

Qwen3.6-27B-NVFP4

权重/激活：混合检查点——覆盖64个全注意力投影和144个GDN投影的208个静态FP8 W8A8目标；覆盖192个MLP投影加上 lm_head的193个NVFP4 W4A16目标，组大小16。
线性层/GEMM：
- FP8目标：ModelOptFp8LinearMethod → FlashInferFP8ScaledMMLinearKernel
- NVFP4目标：NVFP4 GEMM → MarlinNvFp4LinearKernel
KV缓存：BF16（强制）
特性：在我们的上游每日构建版运行中，并非原生FP4算术。vLLM判定该GPU路径缺乏原生FP4支持，并明确通过Marlin选择了纯权重的FP4压缩。检查点中嵌入的FP8 KV方案在本次对比中被BF16 KV覆盖。

Qwen3.6-27B-AWQ-BF16-INT4

权重/激活：静态非对称INT4权重，组大小32，MSE观察器；BF16激活 (W4A16)。GDN/linear_attn投影和 lm_head被排除。
线性层/GEMM：CompressedTensorsWNA16 → MarlinLinearKernel
KV缓存：BF16（强制）
特性：AWQ校准数据集被披露为“STEM和智能体（STEM and Agentic）”。

本次运行的其它值得注意信息：

所有模型的完整softmax/GQA注意力均为 AttentionBackendEnum.TRITON_ATTN；JIT监视器观察到 kernel_unified_attention。
GDN预填充：Triton/FLA GDN预填充内核，请求为 triton， head_k_dim=128。
执行期间，循环路径还JIT编译了 _causal_conv1d_update_kernel， fused_recurrent_gated_delta_rule_packed_decode_kernel 和 reduce_segments。
张量并行度1，eager模式，无CUDA图，无MTP/推测解码，仅语言执行。

下一个token翻转的结果相当可预测。TheDude的INT8 (W8A16) 方案表现最佳，击败了第一方的FP8 (W8A8) 和NVIDIA（FP4名不副实）的发布版。事实上，在5个选项中，NVIDIA的发布版排名垫底，在上下文达到88k时，其token翻转率达到了约50%。

在工具调用方面，NVFP4和AWQ W4A16都未能正确关闭它们的工具调用，并且搞乱了Cisco的命令行语法（正确命令是'show arp'，而它们执行了'show run'），而FP8和INT8都能成功完成正确的调用。

在未来的实验中，我将尝试探索对相同权重使用不同融合GEMM的影响，这是另一个有趣的差异来源，有时你不得不在精度和速度之间做出取舍。

IT社区推荐资讯 - ITIndex.net

小米AI Cube 原型机-本地AI模型部署选择

小米刚刚展示了其 AI Cube 原型机，这可能成为来自中国的严肃 GB10 竞争对手 👀 - 3 款定制芯片：Xring O3、O100、D100

- 200 TOPS NPU

- 1.22 TB/s AI 内存带宽

- 最高 160GB 统一内存

- 150W 持续功率

- 120B 模型本地运行

Xring O100：1.22TB/s + 330 t/s 在 150w AI 盒子上真是 🔥 一旦它上市，绝对会像热饼一样热卖。

文本分类语言模型-Language Models for Text Classification: From Bag-of-Words to Jev

词袋模型、循环神经网络、卷积神经网络、Transformer 模型、Jev 类 API 和校准的可视化指南

A Visual Guide to Bag-of-Words, RNNs, CNNs, Transformers, Jev-like APIs, and Calibration

1. Language modeling and classification in the pre-transformer era

1.1 Bag-of-words: naive Bayes, logistic regression, and XGBoost

1.2 Deep neural networks for text classification

1.2.1 Word embeddings

1.2.2 Recurrent neural networks (RNNs)

1.2.3 Convolutional neural networks (CNNs)

2. Transformers

The Big LLM Architecture Comparison

A Visual Guide to Attention Variants in Modern LLMs

2.1 Encoder-style language models

2.2 Decoder-style LLMs

Building an AI Text Detector From Scratch

2.3 Encoder-decoder style architectures

3. Jev overview

3.1 Jev vs existing text-to-text classification

3.2 The Jev API

3.3 Jev classifying IMDb

4. BERT- and GPT-style models with Jev API

5. Jev architecture and training algorithm

5.1 On calibration

5.2 Reinforcement learning with calibration rewards (RLCR)

5.3 Side note: Is calibration necessary?

6. Who is Jev for?

6.1 Jev use cases

6.2 About Jev clones and local Jevs

Conclusion

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR #8172，聊聊写 Agent 的那些烂坑

1. Pi 是谁？

2. 竞品锐评：市面上的 Harness 错在哪？

锐评 LangChain / LangGraph：自找麻烦的“图状态机”

锐评 DeepSeek Harness (dsh)：粗暴丢数据的截断器

锐评 AutoGPT / CrewAI：没有容灾的纸糊玩具

3. Agent 开发者天天踩的五个坑，Pi 怎么解？

坑 1：中途插消息，KV Cache 当场报废

坑 2：进程挂了，留下半截死状态

坑 3：超大输出撑爆上下文，盲目截断导致模型幻觉

坑 4：多任务并发，状态文件被写烂

坑 5：异步 Check-Then-Act 竞态

4. 确定性测试：线上代码怎么写，测试就怎么跑

5. 总结

微软官方开源：一键把全新 Windows 11 变成干净、清爽的开发机

标准安装

删除/关闭

安装/配置

完整安装

关闭/调整

安装

WSL Comfort：顺手配置 WSL

只装需要的开发环境

获取

相关阅读

开放权重模型逐渐形成了生态-软硬件、量化、Agent、推理引擎、后训练

不要被 AI 炒作愚弄

Jev 工程学：为 coding agent 而作

Jev 工程学：为 coding agent 而作

摘要

I. 为什么还要再做一个 agent

A. Jev 站在哪里

B. 组织起一切的那个问题

II. KV cache 的六个症状

A. 路由不工作

B. 工具调用是个奇怪的取舍

C. Compaction 存在

D. 子 agent 很平庸

E. 重启存在

F. 电池并非内置

III. token 到底花在哪