IT社区推荐资讯 - ITIndex.net

人工智能软硬件推理优化进行中-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的影响，这是另一个有趣的差异来源，有时你不得不在精度和速度之间做出取舍。

关于邪教、骗局和阴谋的非虚构类书籍

Mon, 24 Aug 2026 10:39:32 CST

嘿，亲爱的：销售、姐妹情谊、至高无上的地位，以及多层次营销背后的其他谎言

作者：艾米丽·保尔森

我的书是关于什么的？

《嘿，亲爱的：销售、姐妹情谊、至上主义以及多层次营销背后的谎言》 是一部发人深省、幽默风趣又充满危险的个人故事。作者艾米莉·琳恩·保尔森在多层次营销（MLM）领域一路攀升至金字塔顶端，却最终发现其文化和商业模式远非时髦的营销手段，而是美国白人至上主义的核心。本书对多层次营销的运作方式进行了深刻的批判，精辟地揭示了其在社会孤立现象蔓延中所扮演的角色，以及贯穿于培训、营销和一对一互动中的邪教式意识形态。保尔森的第一人称叙述、辛辣的讽刺和犀利的评论，既引人入胜又发人深省，读完之后，你对那些充斥邮箱的“嘿，亲爱的”信息将会有全新的认识。

邪教：狂热主义的语言

作者：阿曼达·蒙特尔

我为什么喜欢这本书

阿曼达是一位语言天才，她出色地展现了邪教主义是一个光谱；我们都是不当影响的受害者。

她谈到，社区和组织使用的语言是获得对人们不当影响的关键，而这种影响渗透到从创业公司到护肤品再到健身计划的方方面面。

这本书研究透彻，引人入胜，读后会让你质疑自己对最基本事物的强烈认同。

《伤痕：我如何逃离NXIVM邪教的真实故事》

作者：莎拉·埃德蒙森、克里斯汀·加斯巴尔

我为什么喜欢这本书

我看了纪录片 《誓言》，就彻底入迷了。

我立刻想了解更多关于莎拉·埃德蒙森在NXIVM邪教组织中的经历，所以当然买了这本书。她出色地讲述了自己被洗脑的真相，并对组织中的其他人表现出极大的同情。

这有力地说明了，没有人会主动加入邪教，他们加入的只是自己认为好的组织。而且，你也能清楚地看到，在这样的组织中，实际影响和初衷并不总是相符的。任何人都有可能成为这些骗局的受害者！

沉默者的眼泪：一位阿米什人讲述童年性虐待、残酷背叛和最终幸存的真实犯罪回忆录

作者：米斯蒂·格里芬

我为什么喜欢这本书

这本书既令人心碎又发人深省。

坦白说，在读这本书之前，我对阿米什人的文化和宗教了解甚少，除了我住在宾夕法尼亚州时所见所闻之外，但我一直很好奇。读完这本书后，我开始质疑我们国家所谓的“宗教自由”究竟是什么，它竟然能如此轻易地庇护那些滥用自由、剥削妇女儿童的人。

宗教在其最糟糕的表现形式下会造成极大的危害，这一点在本书中得到了很好的阐述。

斯洛尼姆·伍兹 9：回忆录

作者：丹尼尔·巴尔班·莱文

我为什么喜欢这本书

我又一次因为一部纪录片而对一本书产生了兴趣！

看完关于莎拉·劳伦斯学院的纪录片后，我非常想了解更多。丹尼尔·巴尔班·莱文的故事真实地展现了一个脆弱的年轻心灵是如何被心怀不轨之人所影响的。

他生动地描述了自己与一位操控欲极强的邪教头目（拉里·雷）相处的经历，他的叙述令人不安地揭示了类似的事情多么容易发生在我们身上。对于那些因遭受精神操控或被虐待的朋友、导师或伴侣伤害而失去话语权的人来说，这令人深感悲哀和共鸣。

十亿年：我逃离山达基教最高层的生活

作者：迈克·林德

我为什么喜欢这本书

我带着对科学教是一个披着光鲜外衣的犯罪组织的认知开始阅读这本书，而这本书证实了我的想法！

这本书讲述了一个令人难以置信的救赎故事。迈克·林德并没有轻描淡写自己在山达基教中的角色，他承认自己多年来一直在传播山达基教的理念，并影响了许多人。但是，当你了解山达基教徒为了让批评者噤声会做到什么地步时，你就会明白为什么人们不离开，或者说，不失踪！

林德是那个“封杀”民众的人，我想不出还有谁比亲身经历过这个组织运作的人更适合解释它的内部运作。这本书让我爱不释手。

33条良好社交技巧规则

Thu, 20 Aug 2026 09:49:09 CST

最重要的一点：在几乎所有对话情境中，通常都应该让对方赢。请注意，赢并非零和博弈：在大多数情况下，你和对话中的每个人都可以（也应该）获得胜利！
大多数情况下，你主导对话会带来最佳结果。（请注意，主导对话并不一定意味着其他人会注意到这一点，或者你会滔滔不绝。）
了解某人来自哪里的冷门当地梗，是快速建立融洽关系的最佳秘诀。
在游戏初期，有条不紊的冷读比直接提问更能引起对方的兴趣。
运用直觉和冷读术快速了解对方的价值观，然后在此框架内展开接下来的对话，尽可能让对方感到舒适。
当有人进入房间时，转身微笑并打招呼。总之，即使你不是主人，也要假装自己是主人。
真诚的赞美或对共同话题的玩笑式评论是开启对话的最佳方式。
跟随你的好奇心。对他人保持真诚的兴趣，但前提是这种兴趣必须是发自内心的。没有人想要那种为了问问题而问问题、像戴尔·卡耐基那样机械式的提问。
找出某人热衷的事物，然后不断地提出更深入的问题，保持强烈的好奇心。
闲聊自有其用处——它有助于建立对话界限和氛围——但不要持续太久。一旦双方都感到自在，就应该迅速结束闲聊。
尽量避免使用陈词滥调的问题或句式。即使是对常见的闲聊问题稍作改动，也能获得更好的答案，例如用“你最近对什么感兴趣？”代替“你是做什么的？”
只有在绝对必要的时候才把话题转回到你的故事上。
如果你和另一个人同时开始说话，就让他们先说。（比较少见的例外情况是，如果你经常被别人打断，在这种情况下，你应该更积极地表达自己的观点。）
在群体谈话中，当有人似乎想从外面加入时，看着他们的眼睛，微笑，并将你的身体向外移动，以鼓励他们这样做。
……当他们加入时，询问他们的姓名，并向他们介绍当前主题的背景信息。
如果谈话变得乏味，可以主动用眼神和微笑吸引路人加入，然后在新认识的人熟悉之后，你可以选择退出。
即使是开玩笑，也不要破坏彼此间的融洽关系，除非对方表示同意。
模仿对方的肢体语言。转身面对对方，全身心地投入。不要双臂交叉或目光四处游移。
如果你不得不暂时离开，请让他们知道（“请继续说，我只是去倒杯水”），或者如果你必须拿出手机来记下他们告诉你的事情（“让我把它写下来”）。
如果你发现对方的肢体语言破坏了融洽的关系，他们很可能对你没兴趣，你应该顾及面子，找个借口结束谈话。
如果有人问你问题，请尽可能详细地回答，以便提问者有尽可能多的后续对话线索。
在小组中，一开始只能拿自己开玩笑，不能拿别人开玩笑，直到建立起幽默的氛围。
用反讽式幽默来逗乐别人，但不要总是用它来试图强加某种群体氛围。
在小组讨论中，对话必须在小组中每个人都能理解的语境和参考资料水平上进行。
虽然你应该保持谈话的积极氛围，但实际上，人们更容易通过轻松的抱怨建立联系，而不是通过共同的兴趣爱好。
提及相关内容时，应结合谈话对象的文化背景。没有人想显得愚蠢或与周围环境脱节。
如果要提及与他人语境无关的内容，只有当他们表现出好奇心，并且出于真诚的告知兴趣而非炫耀的目的时，才应该这样做。
如何更深入地了解对方：先分享一些关于自己的敏感信息，然后观察对方的反应，再问他们同样程度的问题。
避免一切重复：比如两次讲同一个笑话，讲述别人已经听过的故事（即使你和他们只是群体对话中的一部分），等等。
如果你聪明又成功，低调处理自己的才智和成就反而会更受人青睐。永远保持谦逊。
比起滔滔不绝的天才，扮演好奇而深思熟虑的中庸之辈更能赢得人心。大多数情况下，你的对话者最好感觉自己要么比你略胜一筹（=他们在教你），要么和你智力相当（=你们在即兴发挥）。
除非你们之间有过真正有意义的对话，否则不要要求交换联系方式，更不要要求使用 LinkedIn。
你可以直接删除与讨论无关的话题，例如：任何会导致争论或不良氛围的话题，或者任何出于好意但可能会对参与者造成（隐性）心理伤害的话题。

我一直觉得市面上关于社交技能的通俗读物质量不高，也一直想写一本像我其他作品一样的综合指南。

分享我过去十年收藏的5万多个HN书签中最优质的资源

Thu, 20 Aug 2026 09:48:20 CST

多年来，我每天早上读两页HN，晚上读两页。

最近我注意到，前两页的内容几乎全是人工智能这人工智能那，法学硕士这法学硕士那，模型这模型那模型。

今天，我打算打破这个惯例，分享我过去十年收藏的5万多个HN书签中最优质的资源。

我这边有一套书签添加流程。

- 最具视觉冲击力的解释者获得 S 级评级

来自信誉良好的来源的信息得A级，来自非信誉良好的来源的信息得B级。

评论类博客的质量最低，可能被评为C、D、E甚至F级，具体取决于质量。

以下是我的S级排名

- 变形金刚工作原理的动画讲解 https://poloclub.github.io/transformer-explainer/

- K均值聚类算法的可视化介绍 https://k-means-explorable.vercel.app/

- 视觉LLM的3D动画简介 https://blog.mdturp.ch/posts/2024-04-05-visual_guide_to_vision_transformer.html

- 机器学习动画入门 https://r2d3.us/visual-intro-to-machine-learning-part-1/

- 数学概率论动画入门 https://seeing-theory.brown.edu/basic-probability/index.html

- 通过动画演示，一步一步从零开始构建 3D 世界 https://aibodh.com/posts/bevy-tutorial-build-your-first-3d-editor-in-rust/

- 算法可视化 https://algorithm-visualizer.org/

- 浏览器向服务器发送请求的动画分步演示 https://200ms.thenodebook.com/#act-1-the-click

- 内燃机内部工作原理的视觉介绍 https://ciechanow.ski/internal-combustion-engine/

- 3D实时机器人代码模拟器 https://bittlex-sim.petoi.com/

- 动画讲解：椭圆曲线密码学 https://growingswe.com/blog/elliptic-curve-cryptography

- 速率限制算法可视化 https://smudge.ai/blog/ratelimit-algorithms

- 图形管线可视化入门！https://fremaconsulting.ch/blog/vulkan

- 动画讲解如何从零开始构建 ReactJS！https://pomb.us/build-your-own-react/

- 小游戏：如何从最基本的门电路开始构建整个 CPU https://select.supply/game/chipbuilder

- 从零开始搭建神经网络 https://graphgame.sabrina.dev/

- 3D可视化：重力是如何运作的 https://qunabu.github.io/Gravity/#what-is-gravity

- 小游戏：CSS Grid 的工作原理 https://cssgridgarden.com/

- 线性代数、向量等数学动画书籍 https://immersivemath.com/ila/index.html

- 动画讲解：FAISS 矢量搜索的工作原理 https://fremaconsulting.ch/blog/faiss

- 从零开始打造健康可穿戴设备的3D动画演示 https://www.lumafield.com/scan-of-the-month/health-wearables

- 半导体制造工艺的3D动画演示 https://ig.ft.com/microchips/

- 小游戏：Git 的工作原理 https://learngitbranching.js.org/

- 小游戏：从零开始学习 SQL https://sqlpd.com/

- 另一个小游戏：SQL https://lost-at-sql.therobinlord.com/

- 动画讲解视频，展示颜色、屏幕、图形、渲染、着色器、编译器、解释器的工作原理 https://www.makingsoftware.com/

- 动画讲解视频由内而外地展示了网络七层协议栈的工作原理 https://fazamhd.com/mental-models/networking/

- 用于线性回归、逻辑回归、神经网络和机器学习的动画讲解器 https://mlu-explain.github.io/

- 3D 讲解碰撞检测、着色器、渲染、剔除和游戏开发相关内容 https://krupitskas.com/posts/modern_culling_techniques/

- 3D动画演示和讲解身体各部位的锻炼动作 https://musclewiki.com/

- 小游戏：从零开始构建一个英伟达GPU https://jaso1024.com/mvidia/

- 神经网络前向传播和反向传播的动画讲解 https://aegeorge42.github.io/

还有很多很多，今天打字打得我有点累了。

好了，够了，别再让那些人工智能观点文章充斥首页了，HN，你等着瞧！

PostgreSQL 适用于一切

Thu, 20 Aug 2026 09:30:47 CST

Intro

I started using PostgreSQL roughly in 2003 for a research project called ColumbaDB. Columba is no more, but PostgreSQL is still alive and kicking more than ever.

In 2003, MySQL was much more widely used than PostgreSQL. MySQL was also potentially faster as it did not implement all features of the SQL standard. At the same time MySQL was lacking many features that we needed (full-text search, powerful indexes, SQL standard compliance etc). PostgreSQL felt more like a “real” database in comparison to MySQL - like a tiny version of Oracle - but in open source clothes.

During that research project I learned a lot about databases, indexes and the power of PostgreSQL. One important use-case was full-text search. We could have used MySQL in conjunction with another system like Lucene / Solr to make our database searchable. But that would have meant running and maintaining two such systems. Complicated.

PostgreSQL allowed us to use a fulltext search pluginto do everything in one system. No need to sync any data. No need to maintain and run two systems. It just worked and made us smile (after some tweaks of course). Simplicity.

Since then I used PostgreSQL for many use-cases throughout my career as CTO / Interim Manager. Most recently I used PostgreSQL to store very high volume web analytics time series data via its TimescaleDB plugin. Check out Privatracker - the best way to do web analytics and respect the privacy of your visitors- to see it in action.

Many others discussed the topic from different angles. And each article is really worth your time ( SQL is Agile, Stephan Schmidt on Using SQL for Everything). Also check out my Linkedin post.

And if you are using PostgreSQL I can highly recommend reading Hazel Bachrach’s nice post on “What I Wish Someone Told Me About Postgres”.

In my humble opinion the power of PostgreSQL comes from three sources:

It is rock-solid and stable.
It is easy to run, install and scale.
It massively simplifies your IT setupby being not only a RDBMS, but also a full-text search engine, a document storage and much much more&mldr;

Let’s have a closer look&mldr;

Rock Solid and Stable

PostgreSQL is boring old technology. The first PostgreSQL release dates back to 1996. PostgreSQL is also very widely used - for a very long amount of time. Ironing out bugs - especially in database systems - takes time. PostgreSQL had that time.

It also has a very active community that diligently adds more and more features without breaking any old parts of it. In recent years PostgreSQL got many amazing features like json document storage, partitioning support, common table expressions and much much more. Each new release of PostgreSQL is exciting and brings new nice features.

True - PostgreSQL is old - but the features are very very modern - and PostgreSQL becomes better with every release.

Easy to Run, Install and Scale

PostgreSQL can be installed very easily locally. It is bundled with all major Linux distributions, part of Mac brew, but can also be installed with applications like PostgresApp.

When running tests, it comes in handy using Testcontainers with PostgreSQL. It was never easier running your tests against a real PostgreSQL database that is 100% similar to the production thing.

If you want to run PostgreSQL on a server then you can simply apt-get install it. Or run it in a docker container.

All cloud providers allow you to run (and scale!) PostgreSQL by clicking a single button. You got ample of choice at your fingertips:

That makes PostgreSQL one of the most widely supported software systems in the market. And for you this means less maintenance and more time for creating new features for clients.

Simplifies Your IT Setup

Running PostgreSQL in the cloud is already just one click. But it gets even better. PostgreSQL can replace many systems that youd’d have to run otherwise.

PostgreSQL Replaces Solr and Elastic: Full-Text Search

PostgreSQL allows you to turn your text data into user-searchable data. Without a separate system. It’s also language agnostic and you’ll never have any sync problems between your data and your fulltext search system.

The most impressive article on the topic is how Contentful used PostgreSQL to enable fulltext search for their users. It’s a tale in simplicity that enables growth.

Instacart did something very similar: They built their modern search infrastructure on Postgresinstead of running a separate search cluster. Same story, different company.

More on the topic: https://www.postgresql.org/docs/current/textsearch.html

PostgreSQL replaces MongoDB: Excellent Json Support

PostgreSQL has excellent support for storing and querying(!) json. It also features an index type (GIN) that makes these operations blazingly fast. Is there a need for MongoDB any more?.

The Guardian also wrote an excellent article how they switched from Mongo to PostgreSQL. Thanks for sharing Jan-Otto! Hazel also wrote a nice piece on jsonband what to take into account when using it.

PostgreSQL replaces Kafka and RabbitMQ: PostgreSQL as a queue

Events, queues and persistent logs are getting more and more important in today’s software systems. Systems like Kafka, RabbitMQ, SQS and others provide that functionality. But maintaining them is annoying, custom and you need the skillset.

The good news: You can just use PostgreSQL. The magic comes from

SELECT .. FOR UPDATE
SELECT .. SKIP LOCKED

Using these SQL features you can effectively use a table as queue. Either in a persistent fashion with a cursor and many consumers, or in a read-once fashion.

The article at crunchydata explains this concept very well.

My tip: Start with PostgreSQL as a queueing system. Only when that does no longer perform well switch to other systems like Kafka, RabbitMQ or SQS. You’ll be surprised how well PostgreSQL works.

PostgreSQL Replaces Clickhouse: High Volume Time Series Data

Time series data is special. Often you get many data points in a very short amount of time. And then you have to aggregate the data frequently, doing some statistics on it and so on.

There are specialized software systems like Clickhouse (amazing by the way&mldr;). But you can also use a plugin for PostgreSQL that allows you to do (nearly) the same: Timescale.

I’ve used Timescale and can recommend it. The good news is that you can continue using PostgreSQL - even for high volume data easily. No need to learn and maintain something new.

PostgreSQL as Vector Database for AI Workflows

Timescale lately released the pgvector extension, that turns your PostgreSQL into a vector database. This allows you to use the tech you already know for indexing and retrieval of relevant data. That’s an essential part of AI LLM workflows.

Timescale also recently announced pgaithat includes pgvector, but also a lot of other nice extensions that make it super simple to index data, call LLM models and retrieve data based on similarity.

PostgreSQL Replaces Redis: Non-Persistent High Performance Caching

Caching is important. Most applications use something like Redis as a cache to get information like sessions and more quickly. A cache can by definition lose data and can be regenerated from the original source.

But. Why use Redis when PostgreSQL can be tuned to be as fast (in most usecases) as a Redis cache? The secret is using an UNLOGGED table. You can even emulate Redis’ automatic expire by a trigger. A lot has been written about this- I can just recommend trying it out.

PostgreSQL Replaces File System: For Raw Data

For one of my clients we had to read and write a huge amount of small pieces of binary encoded information. We initially thought that doing this via the file system was the fastest way to do so.

After some performance checks it became clear that PostgreSQL was even faster than reading from the file system for our use-case. PostgreSQL uses the file system very efficiently for its data - and it adds a lot of caching and efficient reading and writing strategies that can outperform writing and reading raw data on a file system.

We used Flatbuffersto store the data in a blob column. Data was then de-serialized on the client. You might want to try that approach as well.

PostgreSQL Replacing Your Graph Database

Hierarchical data can be managed in SQL via recursive queries. That’s ok, but also super-hard to read, maintain and debug. Not even speaking of performance.

The better way is the LTREE datatype of PostgreSQL. It helped me not only once to implement hierarchical tag structures. Easy to read, maintain and blazingly fast.

PostgreSQL Replacing Your Microservice

Most of the “microservices” these days are only about models, getting data from a database and returning json to the client.

But you know what? PostgreSQL can turn any query into a Json result. That effectively replaces your server middleware. There are Pros and Cons to this approach, but it shows the capabilities of PostgreSQL. The amazing Lukas Eder wrote about the topic- not PostgreSQL specific - but everything mentioned there is very well doable in PostgreSQL as well

PostgreSQL - Replacing your Playstation 5

Well. Some enthusiast implemented Tetris as Common Table Expressions in pure SQL. Crazy. And maybe not to be taken too seriously.

Conclusion

The list above is not very exhaustive. PostgreSQL is a very flexible piece of software. And it can be extended with plugins to do more and more.

You need simplicity if you want to move fast. If you come across a new requirement always ask: Can’t PostgreSQL do this? And do we really need that shiny new technology X?

PostgreSQL might not be the answer to everything - but it is the answer to a lot more than you might think!

本地化部署大模型工具 llama.cpp

Fri, 14 Aug 2026 20:11:25 CST

什么是 llama.cpp？

llama.cpp 是一个由 Georgi Gerganov 于 2023 年 3 月发起的开源项目，旨在用纯 C/C++ 实现 LLaMA 系列大语言模型的高效推理。最初它只是为了在 Mac 笔记本上运行 Meta 的 LLaMA 模型，但如今已经发展成支持数百种模型架构、跨平台、支持 GPU 加速的通用推理引擎。

该项目最大的特点是：不依赖 Python 深度学习框架，不需要复杂的环境配置，仅靠 C/C++ 就能在 CPU 上流畅运行数十亿参数的大模型。这使得大语言模型第一次真正走进了普通个人电脑、树莓派、手机以及各种边缘设备。

核心特性与优势

极致的 CPU 推理性能

llama.cpp 通过大量底层优化，让原本需要高端 GPU 才能运行的模型在普通 CPU 上也能获得可用速度。它充分利用了现代处理器的 SIMD 指令集，如 x86 平台的 AVX、AVX2、AVX-512，ARM 平台的 NEON，以及 Apple Silicon 的 AMX 等。在 M 系列 Mac 上，它还能通过 Metal 调用 GPU 进行加速。

量化技术降低资源门槛

llama.cpp 引入了多种量化方案，将模型权重从 16 位浮点数压缩到 8 位、4 位甚至更低精度。常见的量化格式包括：

Q8_0：8 位量化，质量损失极小
Q4_0、Q4_K_M：4 位量化，体积大幅缩小，质量仍可接受
Q2_K、IQ2_XXS：极低比特量化，适合资源极度受限场景

例如，一个 7B 参数的模型，FP16 格式约需 14GB 内存，而 Q4_K_M 量化后仅需 4GB 左右，普通笔记本也能轻松加载。

GGUF 统一模型格式

llama.cpp 早期使用 GGML 格式，后来迁移到更完善的 GGUF 格式。GGUF 将模型权重、分词器、元数据打包在单一文件中，具有更好的扩展性和兼容性。现在 Hugging Face 上有大量现成的 GGUF 模型可以直接下载使用。

跨平台与多后端支持

llama.cpp 支持 Linux、macOS、Windows、FreeBSD 等操作系统，并支持多种计算后端：

CPU：通过 BLAS 库（OpenBLAS、Intel MKL 等）加速
GPU：CUDA、Metal、Vulkan、SYCL、ROCm
混合推理：可以部分层在 GPU，部分层在 CPU

这意味着同一份代码可以在从树莓派到数据中心 GPU 服务器的各种硬件上运行。

llama.cpp 的进阶能力

混合推理，CPU + GPU 协同，部分层卸载到系统内存，突破 VRAM 限制。8GB 显存也能跑 70B 模型。
推测解码，Speculative Decoding，用小模型生成草稿、大模型验证，推理速度提升 2~3 倍。
语法约束，GBNF Grammar，约束输出为 JSON / 特定格式，100% 格式正确率。
KV Cache 量化，运行时量化，推理过程中动态量化 KV Cache，进一步降低内存占用。
多模态，Vision + Text，llama-server 原生支持图片输入，兼容 LLaVA / Gemma-3 等多模态模型。
嵌入服务，Embedding API，提供 /embedding 端点，可直接用于 RAG / 语义搜索等场景。
重要性矩阵，Imatrix 校准，使用领域数据校准量化，Q4 及以下精度提升 10~20%。
编辑器集成，VS Code / Vim 插件，官方 FIM 补全插件，本地代码助手开箱即用。

llama.cpp的架构与工作原理

llama.cpp 的核心是一个精简的 Transformer 推理实现。它主要包含以下组件：

GGML/GGUF 张量库：负责底层矩阵运算和量化计算
模型加载器：解析 GGUF 文件，将权重映射到内存
推理引擎：实现 Transformer 的前向传播，包括注意力机制、FFN、归一化等
采样器：支持多种采样策略，如 top-k、top-p、temperature 等
内存管理：通过 mmap 内存映射，按需加载模型权重，减少内存占用

llama.cpp 还实现了一些高级特性，如连续批处理（continuous batching）、并行解码、推测解码（speculative decoding）、KV 缓存量化等，进一步提升了推理效率。

三层架构：前端模型代码 → GGML 张量库 → 多硬件后端

llma.cpp 的核心设计原则：零依赖（纯 C/C++，无需 PyTorch/Python）、量化优先（1.5~8 bit 整数量化）、全平台（从树莓派到 A100）、混合推理（CPU+GPU 协同，突破显存限制）。

GGUF 模型格式

2023 年 8 月推出，取代旧 GGML 格式，成为本地大模型的事实容器标准

为什么 GGUF 比 GGML 更好？

旧 GGML 格式在新增模型架构时容易破坏向后兼容性。GGUF 采用 Key-Value 元数据设计，新字段可以自由添加而不会影响旧版本解析器，同时将 Tokenizer 内嵌在文件中，不再需要额外加载 vocab 文件。

量化技术详解

llama.cpp 的核心竞争力：把 14GB 的 7B 模型压缩到 4GB，质量损失不到 3%。量化是 llama.cpp 最关键的技术。通过将模型权重从 16 位浮点数压缩到 2~8 位整数，大幅降低内存占用和推理延迟。llama.cpp 的 K-quant（分组量化）方案是业界最成熟的量化实现之一。

量化类型对比表

llama.cpp 量化类型命名详解

在 llama.cpp 中，量化类型的名称并不是随意取的，每个字符都有明确的含义。理解这些命名规则，能帮助你快速判断一个量化模型的精度、体积和适用场景。本文将以最常见的 Q4_K_M 为例，逐字符拆解，并扩展到其他常见量化类型。

Q4_K_M 可以拆分为四个部分：Q、4、K、M。

字符	含义
Q	Quantization（量化）的缩写，表示该类型属于量化格式。
4	表示名义平均比特数：每个权重约占用 4 bits（即 0.5 字节）。实际由于混合精度，可能略有出入。
K	表示采用 K-quants 量化方案（由 GitHub 用户 ikawrakow 提出），这是一种基于重要性矩阵和混合精度的先进量化方法。
M	表示该 K-quant 变体针对 Medium（中等规模模型）进行了优化。另有 S（Small）和 L（Large）等变体。

所以 Q4_K_M 可以理解为：采用 K-quants 方法的 4-bit 量化，针对中等规模模型调优的版本。

注意：4 并不是说每个权重都严格用 4 位存储。K-quants 采用混合精度，某些对输出影响较大的张量（如注意力层中的部分权重）会使用 6 位甚至 8 位，其他大部分权重使用 4 位。整体平均位数大约在 4.5~4.8 bit/weight 左右，因此模型文件比纯 4-bit 略大，但质量更高。

K-quants 系列

K-quants 是 ikawrakow 为 llama.cpp 开发的一套新量化方案，旨在用同样的平均比特数取得更好的模型质量。其核心思想包括：

重要性加权：利用校准数据计算每一层权重的重要性，对重要权重分配更多 bit。
混合精度：在同一模型内对不同张量使用不同精度，例如注意力层的v、o 权重可能用 6-bit，FFN 层用 4-bit。
超级块（super-block）：将 256 个权重组织为一个超级块，内部再分为多个子块，并单独量化缩放因子和最小值，进一步减少元数据开销。

S、M、L 的含义

这三个字母代表该量化变体针对不同规模的模型进行了优化：

S（Small）：针对小模型（如 1B~3B 参数）优化。小模型对量化更敏感，需要更保守的策略。通常 S 变体会对重要张量使用更高精度，以弥补小模型容量不足的问题。
M（Medium）：针对中等规模模型（如 7B~13B）优化，是平衡质量与体积的默认选择。
L（Large）：针对大模型（如 30B+）优化。大模型冗余较多，可以更激进地量化，因此 L 变体往往在保持质量的同时进一步减小体积。

值得注意的是，并非每种 K-quant 都同时拥有 S/M/L 三种变体。实际存在的 K-quant 类型包括：

类型	后缀	说明
Q2_K	（无）	2-bit K-quant，仅一种配置，质量较低，适合极限压缩
Q3_K	S / M / L	3-bit K-quant，三种变体，S 质量最好，L 体积最小
Q4_K	S / M	4-bit K-quant，S 和 M 两种，Q4_K_M 是目前最常用的均衡选择
Q5_K	S / M	5-bit K-quant，质量接近 Q6_K，体积稍大
Q6_K	（无）	6-bit K-quant，质量很高，接近 Q8_0，但体积更小

为什么 Q4_K 没有 L？K-quants 在设计时针对不同位宽选择了不同的变体数量，并非强制每种都有三个等级。Q4_K 的 S 和 M 已经能够覆盖大多数需求。

IQ 系列（Importance Matrix Quants）

后来，llama.cpp 又引入了基于重要性矩阵（Importance Matrix）的量化方法，命名以 IQ 开头。这类量化使用校准数据集计算权重的重要性，并在量化过程中显式优化输出误差，可以在极低比特下保持较好的质量。

IQ 系列的命名规则是：IQ{bits}_{size}，其中 {size} 表示量化激进程度，常见后缀有 XXS、XS、S（有时还有 M、L）。

例如：

IQ2_XXS：2-bit 极限压缩，体积最小，但质量损失较大。
IQ2_XS：比 XXS 稍好。
IQ2_S：2-bit 中质量最好的变体。
IQ3_XXS、IQ3_XS、IQ3_S：3-bit 的不同压缩等级。
IQ4_XS、IQ4_NL：4-bit 的 IQ 变体，质量通常优于同级别的 K-quants。

IQ 系列的后缀（XXS、XS、S）与模型规模无关，而是表示量化质量的等级：后缀越小（XXS 最小），量化越激进，体积越小，质量越低。

不同内存大小的量化推荐

与其他推理框架对比

llama.cpp

优势

纯 C/C++，零依赖，编译即用
CPU/GPU/混合推理，全平台支持
量化方案最丰富 (1.5~8 bit)
单用户性能最优 (比 Ollama 快8x)
70B 模型 8GB 内存即可运行
OpenAI 兼容 API + Web UI

不足

需要手动编译/配置
并发处理能力弱于 vLLM
无内置模型管理（需手动管理 GGUF 文件）

Ollama

优势

一键安装，零配置
内置 1700+ 预训练模型
图形界面友好
跨平台 (Win/Mac/Linux)
底层基于cpp

不足

单用户性能比cpp 慢 18~23%
额外占用3GB 显存开销
量化选项有限
灵活性受限

vLLM

优势

PagedAttention + 连续批处理
多用户并发性能碾压对手
GPU 利用率 90%+ (70B 模型)
张量并行多 GPU 支持
显存占用优化 (70B 仅需 48GB)

不足

仅支持 Linux + NVIDIA GPU
安装复杂，需 Docker + GPU 驱动
不支持 CPU 推理
不支持 GGUF 量化格式
单用户性能反而不如cpp

SGLang

优势

RadixAttention 缓存优化
结构化输出提速 10x
长上下文处理优秀
零开销批处理

不足

仅 Linux 环境
需要高端 GPU (A100/H100)
部署门槛高
社区生态较小

多维度对比一览表

llama.cpp 安装使用指南

llama.cpp 的安装

这里仅记录下Windows的安装方法，如果需要了解其他操作系统，可自行搜索。在Windows 11下为llama.cpp启用GPU加速，主要有两种路径：使用官方预编译包（最快捷）和从源码编译（更灵活）。推荐使用预编译包，可以省去繁琐的编译过程。

方法一：使用官方预编译包 (推荐)

这是最快、最不容易出错的方法。

检查并安装CUDA
- 检查驱动兼容性：打开终端（CMD或PowerShell），运行nvidia-smi，查看右上角的 CUDA Version。这个数字代表你的驱动能支持的最高CUDA版本，你需要安装一个不高于此版本的CUDA Toolkit。
- 下载并安装CUDA Toolkit：访问 NVIDIA CUDA Toolkit官方下载页面，选择与你的系统匹配的版本（建议选择exe (local)格式）。安装时，推荐选择自定义安装，并取消勾选“Driver”组件（除非你的驱动确实过时）。安装完成后，重启电脑。
下载cpp预编译包
- 访问 cpp的GitHub Releases页面。
- 在“Assets”区域，下载名为llama-cuda-winx64.zip 的文件。这个文件名明确表示它是为Windows系统准备的、带有CUDA支持的版本。
- 将下载的zip包解压到一个你喜欢的文件夹，例如D:\llama.cpp。
验证GPU加速
- 打开终端，进入你解压的cpp 文件夹。
- 运行以下命令来测试（请将你的模型文件.gguf 替换为实际文件名，并确保模型文件存在）：./llama-cli.exe -m 你的模型文件.gguf -p “Hello” -n 128 –n-gpu-layers 99
- 关键参数是–n-gpu-layers 99。这个命令告诉cpp将模型的大部分层加载到GPU显存中。如果一切正常，你会在输出中看到类似 offloading … layers to GPU 的信息，并且推理速度会明显加快。

方法二：从源码编译 (进阶)

如果你需要针对自己的显卡架构进行特定优化，或想尝试最新特性，可以选择从源码编译。

安装必备软件：按顺序安装以下工具：
- Git：用于克隆代码仓库。
- CMake：构建工具。
- Visual Studio 2022：安装Community（社区版）即可。在安装时，必须勾选以下工作负载：
  - 使用C++的桌面开发
  - C++ CMake tools
  - Windows 10/11 SDK
- 安装CUDA Toolkit：与方法一相同，根据你的显卡驱动安装匹配的CUDA Toolkit。
- 克隆并编译
  - 打开“x64 Native Tools Command Prompt for VS 2022”（可在开始菜单搜索找到）。
  - 克隆cpp仓库并进入目录：git clone https://github.com/ggerganov/llama.cpp.git && cd llama.cpp
  - 创建构建目录并配置CMake。关键是在CMake命令中-DGGML_CUDA=ON 来开启GPU支持：mkdir build && cd build && cmake .. -G “Visual Studio 17 2022” -A x64 -DGGML_CUDA=ON
  - （可选）指定显卡架构：如果你知道显卡的计算能力（Compute Capability），可以通过-DCMAKE_CUDA_ARCHITECTURES=”xxx” 来指定，以获得更优性能。例如，RTX 30系列是”86″，RTX 40系列是”89″。
- 开始编译：cmake –build . –config Release
- 编译完成后，所有可执行文件（.exe）会位于build\bin\Release\ 目录下。

方法三：使用自动化脚本 (备选)

如果你不想手动处理复杂的依赖和编译，可以尝试社区维护的自动化脚本。

cpp-installer：一个PowerShell脚本，能自动安装所有依赖并编译llama.cpp。在管理员权限的PowerShell中运行即可。
cpp-windows-builder：提供批处理脚本，可一键安装和编译。

获取 GGUF 模型

llama.cpp 使用 GGUF 格式的模型。你可以从Hugging Face获取。

下载示例（以 Llama-3-8B Q4_K_M 为例）：

# 使用 huggingface-cli 下载
huggingface-cli download TheBloke/Llama-3-8B-GGUF llama-3-8b.Q4_K_M.gguf --local-dir ./models

或者直接通过浏览器下载 .gguf 文件并放入 models/ 目录。

基本使用

编译完成后，主要可执行文件包括：

llama-cli：命令行交互式推理
llama-server：启动 HTTP 服务器，兼容 OpenAI API
llama-quantize：对 FP16/FP32 模型进行量化
llama-perplexity：计算模型困惑度
llama-bench：性能基准测试
llama-embedding：提取文本嵌入
llama-imatrix：生成重要性矩阵（用于 IQ 量化）

命令行聊天 llama-cli

最简单的用法：

./build/bin/llama-cli -m models/llama-3-8b.Q4_K_M.gguf -p "你好，请介绍一下你自己" -n 256

进入交互模式（持续对话）：

./build/bin/llama-cli -m models/llama-3-8b.Q4_K_M.gguf -cnv

-cnv 表示开启对话模式，使用 — 分隔用户输入和系统提示，例如：

./build/bin/llama-cli -m models/llama-3-8b.Q4_K_M.gguf -cnv -p "你是一个乐于助人的助手。"

llama-cli 常用参数

参数	说明
-m, –model	模型文件路径（GGUF 格式）
-p, –prompt	初始提示词
-n, –n-predict	最大生成 token 数（默认 -1 表示无限）
-t, –threads	使用的 CPU 线程数（默认自动）
-c, –ctx-size	上下文长度（默认 512，可根据模型支持调整）
-ngl, –n-gpu-layers	卸载到 GPU 的层数（如 -ngl 99 表示全部卸载）
–temp	温度参数，控制随机性（默认 0.8）
–top-k	Top-K 采样（默认 40）
–top-p	Top-P 采样（默认 0.95）
–repeat-penalty	重复惩罚（默认 1.1）
-b, –batch-size	批处理大小（影响内存和速度）
-cnv	启用交互式对话模式
–color	彩色输出
–no-display-prompt	不显示输入提示

启动 OpenAI 兼容服务 llama-server

llama-server 提供了一个与 OpenAI API 兼容的 HTTP 服务，方便集成到各种应用中：

./build/bin/llama-server -m models/llama-3-8b.Q4_K_M.gguf --host 0.0.0.0 --port 8080

启动后，可以这样调用：

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3-8b",
    "messages": [
      {"role": "system", "content": "你是一个乐于助人的助手。"},
      {"role": "user", "content": "你好"}
    ],
    "temperature": 0.7,
    "max_tokens": 256
  }'

llama-server 还提供 Web UI，浏览器访问 http://localhost:8080 即可进行对话。

llama-server 常用参数

参数	说明
–host	监听地址（默认 127.0.0.1）
–port	监听端口（默认 8080）
-ngl	GPU 卸载层数
-c	上下文长度
-t	线程数
–api-key	设置 API 密钥（可选）
–embedding	启用嵌入端点
–parallel	并行请求数（默认 1）

更多参数可通过 ./build/bin/llama-cli –help 查看完整列表。

量化模型 llama-quantize

如果你有一个 FP16 的 GGUF 模型，可以使用 llama-quantize 将其转换为低比特量化版本：

./build/bin/llama-quantize models/llama-3-8b-f16.gguf models/llama-3-8b.Q4_K_M.gguf Q4_K_M

常用量化类型：Q4_0、Q4_K_M、Q5_K_M、Q8_0、IQ4_XS 等。关于量化类型的详细说明，请参考前文《llama.cpp 量化类型详解》。

性能测试 llama-bench

测试模型在不同硬件上的推理速度：

./build/bin/llama-bench -m models/llama-3-8b.Q4_K_M.gguf

该命令会输出 token 生成速度（t/s）等指标，帮助你选择合适的量化类型和硬件配置。

计算困惑度 llama-perplexity

评估模型在某个数据集上的困惑度：

./build/bin/llama-perplexity -m models/llama-3-8b.Q4_K_M.gguf -f data.txt

data.txt 是每行一个文本样本的文件。

生成嵌入 llama-embedding

./build/bin/llama-embedding -m models/llama-3-8b.Q4_K_M.gguf -p "你好世界"

输出文本的向量表示。

高级用法

GPU 卸载

如果你有 GPU，可以通过 -ngl 参数将模型层卸载到 GPU 加速：

./build/bin/llama-cli -m models/llama-3-8b.Q4_K_M.gguf -ngl 99 -p "你好"

99 表示尝试卸载所有层。如果显存不足，可以减少层数，例如 -ngl 20。

上下文扩展

许多模型默认上下文长度有限，可以通过设置 -c 扩大：

./build/bin/llama-cli -m models/llama-3-8b.Q4_K_M.gguf -c 4096 -p "..."

注意：上下文越大，内存占用越高。

多卡推理

如果有多块 GPU，可以使用 –main-gpu 和 –tensor-split 指定设备分配：

./build/bin/llama-server -m model.gguf -ngl 99 --main-gpu 0 --tensor-split 1,1

使用 mmap 加载大模型

llama.cpp 默认使用内存映射（mmap）加载模型，可以节省物理内存并加速加载。如果遇到问题，可以用 –no-mmap 禁用。

提示词模板

不同模型使用不同的提示词模板。llama-cli 和 llama-server 支持 –chat-template 指定 Jinja 模板，或自动从 GGUF 元数据中读取。可以使用 –chat-template 覆盖：

./build/bin/llama-cli -m model.gguf --chat-template "{% for message in messages %}{{ message['role'] }}: {{ message['content'] }}\n{% endfor %}"

性能调优

使用-t 设置合适的线程数（通常为物理核心数）
启用 BLAS 可显著提升 CPU 推理速度
使用-b 调整批处理大小，较大的批次可提高吞吐但增加内存
在 GPU 上使用-ngl 99 获得最大加速

常见问题

编译错误：找不到 BLAS

确保已安装 BLAS 库并正确设置 GGML_BLAS_VENDOR。如果未安装，可省略 BLAS 选项。

运行时报错：error loading model: unknown (magic, version) combination

模型文件可能不是 GGUF 格式。确认下载的是 .gguf 文件，或使用 convert_hf_to_gguf.py 转换。

生成结果乱码或质量差

检查提示词模板是否匹配模型
调整采样参数（温度、top-p 等）
尝试更高质量量化类型（如 Q5_K_M、Q8_0）

内存不足

选择更低比特量化类型
减少上下文长度-c
使用–no-mmap 或减少线程数

GPU 未被使用

确认编译时启用了对应后端（GGML_CUDA=ON等）
使用-ngl 指定 GPU 层数
检查驱动和 CUDA/Metal 环境

相关文章:

爬楼梯有助于延寿

Thu, 13 Aug 2026 22:32:43 CST

根据发表在《American Journal of Cardiovascular Drugs》期刊上的一项研究，爬楼梯能显著降低死于心血管疾病的风险。研究期间，相比与不常爬楼梯的人，常爬楼梯的人死于心脏相关疾病的风险降低 39%，全因死亡率降低 24%。常爬楼梯的人患心脏病、中风和心力衰竭等严重心血管疾病的风险也较低。研究人员称，心血管疾病是全球首要死因，1990-2019 年间相关病例数几乎翻了一番。研究人员分析了来自 9 项高质量研究的逾 48 万名参与者的数据，中位随访时间为 14 年。研究人群包括健康参与者和有心脏病史的参与者。年龄范围为 35-84 岁，其中 53% 为女性。“与去健身房或进行锻炼不同，爬楼梯很容易融入日常生活，无论是在家、在工作场所还是外出。对于没有太多时间或不方便锻炼的人而言，这是一个不错的选择。”“所以，如果可以选择走楼梯或乘电梯，那就选择楼梯，因为它对你的心脏有益。”

科技巨头想要收集你的思想

Thu, 13 Aug 2026 23:46:10 CST

消费级神经技术正从实验室迅速走向工作场所和家庭，包括苹果、Meta 和 Snap 在内的公司开发能监测或解读大脑活动的产品。研究人员警告，神经数据可能成为下一个隐私争夺焦点。部分神经学家开始呼吁“神经权利”以保护“精神隐私”、“身份”和个人“自主权”。过去二十年研究人员利用 fMRI 技术构建日益详细的哺乳动物脑皮层结构图谱和相关连接清单。得益于机器学习 AI 的巨大进步，fMRI 扫描现在可用来识别从抑郁情绪到嫉妒和幸灾乐祸等情绪。