本地跑大模型：各种参数和速度到底该怎么看

经常有人问，我这台机器能不能跑某个模型。回答到最后往往会变成一个数字：每秒多少 token。可这个数字得看是哪个阶段的速度。同一台机器、同一个模型，你把一整段文档灌进去的时候，它能到两百多 token/s；等它一个字一个字往下写，就只剩十几 token/s 了。差了十几倍。这不是机器抽风，是这两件事根本不是一个活儿。

我在写优化器那篇的时候说过，公式看不明白不要紧，脑子里大概知道这个过程是怎么回事，心里就有底了。这篇也差不多，不推公式，就顺着一次生成的流水线从头走一遍，说清楚每一段在干什么，哪一段决定你要等多久，哪一段决定它写多快，以及本地这些硬件到底卡在哪。

一次生成都经历了什么

按了回车之后，机器干的活大概是这么一串：

你的输入先被切成 token，查成向量（embedding），然后送进一层层的 Transformer[1]。每一层里面主要是两件事：注意力（attention）和前馈网络（feed-forward network，FFN），现在不少模型会把 FFN 换成混合专家（mixture of experts，MoE）[2]。跑完最后一层，拿最后一个位置的输出送进 lm_head，得到一个在词表上的分数向量，也就是 logits。采样器从 logits 里挑出一个 token，如果开了流式，就先把这一个字吐给你看。然后把这个 token 接回输入，回到刚才那一层层里接着算，直到遇到结束符，或者撞上长度上限。

这里有一个关键的分界。第一次进入那些层的时候，喂进去的是你整段提示词，几百上千个 token 一起铺开算，这一步叫 prefill，预填充。从第二次开始，每一轮只喂一个新 token 进去，这一步叫 decode，解码。除了这两个名字，剩下的东西都是围着它们转的。

Prefill：把提示词一次性读完

prefill 最大的特点是并行。你那一段话里的所有 token 是一起进去的，模型对它们做的是矩阵乘矩阵那种运算，行话叫通用矩阵乘（general matrix multiplication，GEMM）。GPU（graphics processing unit，图形处理器）最喜欢这种活，因为一大块算力可以被完全填满。衡量这件事有个指标叫算术强度，也就是每读一个字节的数据能干多少次浮点运算。GEMM 的算术强度高，所以 prefill 通常是计算受限的，瓶颈在算力上[3-4]。

prefill 决定的是第一个字什么时候出来，也就是首 token 延迟（time to first token，TTFT）。这也是本地跑长文档问答时最难受的地方：你贴进去一篇几万字的材料，它不是慢慢来，而是先一动不动，等把整篇读完才开口。

还有一处成本容易被忽略。注意力要算所有 token 两两之间的关系，这部分大致是序列长度的平方。序列长度翻一倍，注意力那部分的工作量差不多翻四倍。所以提示词越长，prefill 的成本涨得比线性还快。

针对 prefill 最出名的优化是 FlashAttention[5]。它的做法是把注意力切成小块，在芯片上的高速存储里算完就丢，不把整张 n×n 的分数矩阵写回显存。结果是显存占得少了，速度还快了，因为少了一大堆来回搬数据的动作。FlashAttention-2[6] 又改了并行和工作划分，把 GPU 的利用率进一步拉高。这两篇值得一读，它们也顺便说明了，很多性能问题不是算得慢，是数据搬得多。

Decode：一次只往前走一个字

decode 的最大特点是串行，这一轮必须等上一轮出结果才能开始。更要命的是，每生成一个 token，都得把整个模型的权重从显存里读一遍，做一次乘加。

这就导致 decode 的算术强度极低：每读一个字节，可能就做一两次运算。于是瓶颈从算力换到了显存带宽，decode 是访存受限的[3,7-8]。

拿数字感受一下。一个 7B（7 billion，70 亿参数）的 fp16（16 位半精度浮点数）模型，权重是 14GB（gigabyte，吉字节）。如果显卡的显存带宽是 900GB/s，那么理论上限是 900 除以 14，大约每秒 64 个 token。按经验，实际能跑到六成就算不错了[9]。这个算法也能解释一个反直觉的现象：把权重从 fp16 压到 4bit[10-11]，字节数变成大约四分之一，同一个卡上 decode 理论上能快四倍左右，代价是质量可能掉一点。所以本地跑模型，显存带宽比商家广告上的 FLOPS（floating-point operations per second，每秒浮点运算次数）更值得看。算力再高，数据读不进来也是干等着，这就是当年说的内存墙[12]。

还有个地方容易搞混：服务器上之所以能同时服务很多人，靠的是批处理。一次读进来的权重，可以同时给一批请求里的每个 token 用[13-15]，算术强度上去了，吞吐也跟着上去，但单条请求的延迟会被拉长。本地一个人用，批大小基本就是 1，你永远待在访存受限的那一头。

键值缓存（key-value cache，KV cache）：本地跑长上下文的真正成本

模型在算当前 token 的时候，要用到之前所有 token 的键值对（key 和 value，写作 K 和 V）。每算一步就重算一遍前面所有位置是不现实的，所以要把它们存下来，这就是键值缓存（key-value cache，KV cache）[16]。

它的大小可以这么估：2（K 和 V 两份，也就是 key 和 value）乘以层数，乘以 KV 的头数，乘以每个头的维度，乘以每个元素占的字节数，再乘以上下文长度。如果同时跑多条请求，还要再乘一个批大小。

拿一个 7B、32 层、32 个头、每头 128 维、fp16 的模型算，每个 token 的 KV 是 2 乘 32 乘 32 乘 128 乘 2 字节，等于 512KB（kilobyte，千字节）。跑到 32K（即 32768）上下文，光 KV 就是 16GB，比 4bit 的权重还大。这就是为什么上下文一拉长就爆显存，跟参数多少没关系，是这段算术决定的。

围绕这几十个 G，大家都在想办法：

分组查询注意力（grouped-query attention，GQA）和多查询注意力（multi-query attention，MQA）是让多个 query 头共享同一组 KV 头，直接把公式里的「KV 头数」降下来[17-18]。现在开源模型基本都用 GQA，更激进的是多头潜在注意力（multi-head latent attention，MLA）[19]，比如 DeepSeek-V2 那样，把 K 和 V 压成一个潜在向量，缓存里存的是压缩后的东西。

PagedAttention 是另一条路。它像操作系统的虚拟内存分页那样管理 KV，按块分配、按需映射。vLLM 就是靠这个把显存碎片压到很低，从而塞下更多并发请求[20-21]。

再狠一点就是量化或者丢弃。KIVI[22] 把 KV 压到 2bit；H2O（Heavy-Hitter Oracle）[23]、StreamingLLM[24] 这类干脆只保留一部分 token 的 KV，靠注意力汇聚点的现象撑住。这些都会牺牲一部分质量，属于拿精度换显存和带宽。

还有一层影响是隐性的：上下文越长，decode 本身也会越来越慢。因为每步要读的 KV 变多了，注意力那部分开销从「可以忽略」变成「不能忽略」[25]。下面我自己的实测里就能看到这个趋势。

采样：最后挑字那一步

logits 出来之后，一般不会直接取分数最高的那个（那叫贪心解码），而是先做一串处理：temperature 缩放、top-k、top-p（也就是 nucleus 采样）、min-p[26]、重复惩罚，最后按概率抽一个。

这些名字听着乱，其实是在回答两个问题：要不要稳，要不要新。温度低就稳，容易复读；温度高就活，也容易跑偏。Holtzman 那篇 The Curious Case of Neural Text Degeneration 讲的就是为什么纯贪心和纯 top-k 都会退化，以及 nucleus 采样是怎么缓解的[27]。现在到处都能看到的 repetition_penalty，最早来自 CTRL（Conditional Transformer Language Model）那篇[28]。

采样本身几乎不耗时，但它直接决定了体验。同一段提示词，参数调得不一样，出来的是两个脾气完全不同的助手。

还有一类东西也发生在这一步：结构化输出。你让它必须按某个 JSON（JavaScript Object Notation，一种数据交换格式）格式或者某种语法生成，引擎就在解码时把那些不合法的 token 直接屏蔽掉。XGrammar 这类引擎把语法编译成下推自动机的形式，把每个 token 上的额外开销压得很小[29]。代价是解码的并行度受一点影响，换来的是确定性和不用事后擦屁股。

几个指标别看错

TTFT，首 token 延迟，主要看 prefill。流式对话、文档问答里，这个数字最影响「手感」。

TPOT（time per output token）或者 ITL（inter-token latency），也就是相邻两个 token 的间隔，看 decode。人眼阅读大概每秒十到二十个 token 就比较舒服，低于这个数就会明显感觉一顿一顿的。

吞吐，整台机器每秒产出多少 token，只有在批处理、多用户场景里才有意义。

goodput，是在满足延迟要求的前提下能服务多少请求。服务器上的目标往往是这个，而不是单纯的吞吐，因为把延迟拖坏了，吞吐再高也没用。DistServe 那篇[30]就是专攻这个指标的。

顺便说一句，评价这套东西，业界已经有相对标准的方法了，比如 MLPerf（Machine Learning Performance）Inference，它把 TTFT 和 TPOT 这类指标明确写进了生成式模型的测量里[31]。自己在家测的时候，至少也要说清楚是哪个阶段的数字，不然很容易拿苹果比梨。

各种优化分别作用在哪一段

把常见的招数按环节摆一下[8,32]，会清楚很多：

其中 chunked prefill 值得单独说一句。它不是减少 prefill 的总工作量，而是把一大段 prefill 拆成几小段，跟正在解码的请求交替着算。这样长提示词不会把别人的 decode 卡住，整体的 TTFT 分布也平滑得多。SARATHI[33] 就是干这个的。

投机解码也值得说。它的思路是先用一个小的草稿模型（或者模型自带的小头）一次猜好几个 token，再让主模型一次并行验证，猜对的照单全收，猜错的退回。注意它不改变最终输出的分布，是精确加速，不是玄学[42-43]。代价是要额外养一个草稿模型，而且提速倍率被接受率卡着，接受率低就白忙。Medusa[44] 和 EAGLE[45] 就是在这条路上换了几种实现。对本地这种访存受限的场景，投机解码往往比堆算力更有效，因为它把「一次读权重只算一个 token」变成了「一次读权重算好几个 token」。

本地机器的三个硬约束

说回本地，绕来绕去就是三样东西：

显存容量，决定你能不能装下权重、上下文能开多大、能并发几个请求。

显存带宽，决定 decode 有多快。这是本地体验里最要紧的一条，因为权重每个 token 都要读一遍。

算力，决定 prefill 有多快，也决定批处理时的吞吐上限。

三样都想要，往往只能选两样。模型大一点，容量先告急；上下文长一点，KV 先告急；量化到极限，容量和速度都好了，质量开始告急。

显存不够的时候，就只能 offload，把一部分层、专家或者 KV 放到内存甚至硬盘上。FlexGen[48] 是这套思路里比较有代表性的，它明确是拿吞吐换延迟、为了离线批处理设计的。PowerInfer[49] 利用激活的局部性，把经常被用到的神经元留在 GPU 上，热的算 GPU、冷的算 CPU（central processing unit，中央处理器）。LLM in a flash[50] 更直接，从闪存里流式读权重。这些方案[48-51]都能让你把原本跑不动的模型跑起来，但共同点是 decode 会掉到另一个数量级，而且速度被内存带宽、PCIe 带宽或者硬盘速度按着。顺便一提，普通内存的带宽往往只有显卡显存的几分之一到十几分之一，这个落差是补不回来的。

多卡是另一条路。Megatron-LM 那套张量并行[52]把权重切开放在几张卡上，但每一层、每一轮都要卡间通信。消费级卡大多没有 NVLink，只能走 PCIe（Peripheral Component Interconnect Express，一种高速外设互连标准），decode 本来就是访存受限，再叠上通信，两张卡不一定等于一张快一倍的卡。

最后还有两个容易被忘掉的环节。一个是冷启动，第一次跑模型要把几个 G 的权重从磁盘读进显存，这段时间也是用户实实在在在等的。另一个是散热，笔记本上连续生成，前几分钟和后十几分钟经常不是一个速度。

我在这台 M4/16G 上测了一组数

光说原理没意思，我在手头的机器上量了一组。机器是 Apple M4、16GB 统一内存，模型是 qwen3.5:2b（ollama 0.35.0）[53]，ollama ps 里显示 2.5GB、百分之百在 GPU 上。温度设成 0，上下文窗口 8192，每次请求固定生成大约 200 个 token。

另外测了一次流式输出：3716 个 token 的提示词，TTFT 是 20.3 秒，对应的 prefill 速度是 185.6 token/s。

这几个数字能对上前面讲的东西。decode 只有 prefill 的十分之一上下，这就是访存受限和计算受限的差别。上下文从七百多涨到七千多，decode 从 17.7 掉到 12.5，这是每步要多读 KV 的代价。至于那个 20 秒的 TTFT，就是本地跑长文档问答难受的根源——不是模型不行，是它得先把整篇读完。

这里必须补一句，免得误导。上表都是单次测量，同一台机器在不同时刻会飘，散热、后台负载都会影响。而且我测的过程中撞上过一个现象：同一个前缀重复请求时，prefill 会「消失」，我见过 3812 个 token 只花 0.12 秒的情况，那是前缀缓存命中了。这事对 agent 场景反而是好消息：反复带着同一段系统提示词去调用，第二次几乎不用再花 prefill 的钱。

那到底该看什么

如果只是聊天、写东西，decode 速率最要紧，每秒十几到二十个 token 人就能接受。这种场景下，选一个小一点、别压到极限的模型，往往比选个大模型再量化到 2bit 舒服。

如果是长文档问答、代码库问答，那 prefill 和 KV 才是重点。先看显存够不够放下那么长的 KV，再看那几十秒的 TTFT 你能不能忍。另外也得记住，上下文塞得越长，模型对中间内容的使用往往越差[54]。

如果是多用户，或者要拿它当服务跑，就得看吞吐和 goodput，考虑连续批处理和前后分离那一套。

如果是 agent 那种反复调用、上下文高度重复的用法，前缀缓存能救命[36-37]。

说到底，本地跑模型不是一道「能不能跑」的是非题，而是「哪一段慢、你受不受得了」的取舍题。prefill、decode和KV都要关注，重要的是要根据场景来具体衡量。

参考文献

1. Transformer 原始架构：Vaswani, A. et al. "Attention Is All You Need." NeurIPS（Neural Information Processing Systems）2017. arXiv:1706.03762. https://arxiv.org/abs/1706.03762
2. MoE（mixture of experts）：Fedus, W., Zoph, B., Shazeer, N. "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity." JMLR（Journal of Machine Learning Research）2022. arXiv:2101.03961. https://arxiv.org/abs/2101.03961
3. prefill 与 decode 的算力/带宽分析：Pope, R. et al. "Efficiently Scaling Transformer Inference." MLSys（Conference on Machine Learning and Systems）2023. arXiv:2211.05102. https://arxiv.org/abs/2211.05102
4. 算术强度与屋顶线模型：Williams, S., Waterman, A., Patterson, D. "Roofline: An Insightful Visual Performance Model for Multicore Architectures." Communications of the ACM（Association for Computing Machinery）, 52(4):65–76, 2009. DOI（Digital Object Identifier）: 10.1145/1498765.1498785
5. FlashAttention：Dao, T. et al. "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness." NeurIPS 2022. arXiv:2205.14135. https://arxiv.org/abs/2205.14135
6. FlashAttention-2：Dao, T. "FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning." arXiv:2307.08691. https://arxiv.org/abs/2307.08691
7. LLM（large language model）推理的屋顶线综述：Yuan, Z. et al. "LLM Inference Unveiled: Survey and Roofline Model Insights." arXiv:2402.16363. https://arxiv.org/abs/2402.16363
8. 高效推理综述：Zhou, Z. et al. "A Survey on Efficient Inference for Large Language Models." arXiv:2404.14294. https://arxiv.org/abs/2404.14294
9. 推理性能调优实务：Databricks. "LLM Inference Performance Engineering: Best Practices." https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices
10. GGUF（GPT-Generated Unified Format）量化格式：ggml 项目文档, "GGUF." https://raw.githubusercontent.com/ggml-org/ggml/master/docs/gguf.md
11. llama.cpp：https://github.com/ggml-org/llama.cpp
12. 内存墙：Wulf, W. A., McKee, S. A. "Hitting the Memory Wall: Implications of the Obvious." ACM SIGARCH（Special Interest Group on Computer Architecture）Computer Architecture News, 23(1):20–24, 1995. DOI: 10.1145/216585.216588
13. 连续批处理（迭代级调度）：Yu, G.-I. et al. "Orca: A Distributed Serving System for Transformer-Based Generative Models." OSDI（Operating Systems Design and Implementation）2022. https://www.usenix.org/system/files/osdi22-yu.pdf
14. 连续批处理的科普说明：Anyscale. "Achieve 23x LLM Inference Throughput & Reduce p50 Latency"（continuous batching 那一篇）. https://www.anyscale.com/blog/continuous-batching-llm-inference
15. TensorRT-LLM（Tensor Runtime for Large Language Model，含 in-flight batching 与 kernel 实现）：https://github.com/NVIDIA/TensorRT-LLM
16. KV（key-value）cache 的工程说明：Hugging Face Transformers Documentation, "KV cache." https://huggingface.co/docs/transformers/en/kv_cache
17. MQA（multi-query attention）：Shazeer, N. "Fast Transformer Decoding: One Write-Head is All You Need." arXiv:1911.02150. https://arxiv.org/abs/1911.02150
18. GQA（grouped-query attention）：Ainslie, J. et al. "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints." EMNLP（Conference on Empirical Methods in Natural Language Processing）2023. arXiv:2305.13245. https://arxiv.org/abs/2305.13245
19. MLA（multi-head latent attention）与 KV（key-value）压缩：DeepSeek-AI. "DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model." arXiv:2405.04434. https://arxiv.org/abs/2405.04434
20. PagedAttention 与 vLLM：Kwon, W. et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP（Symposium on Operating Systems Principles）2023. arXiv:2309.06180. https://arxiv.org/abs/2309.06180
21. vLLM 的分页注意力实现说明：vLLM Documentation, "Paged Attention." https://docs.vllm.ai/en/latest/design/paged_attention/
22. KV（key-value）量化：Liu, Z. et al. "KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache." ICML 2024. arXiv:2402.02750. https://arxiv.org/abs/2402.02750
23. KV（key-value）淘汰（H2O，Heavy-Hitter Oracle）：Zhang, Z. et al. "H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models." NeurIPS 2023. arXiv:2306.14048. https://arxiv.org/abs/2306.14048
24. 注意力汇聚与 StreamingLLM：Xiao, G. et al. "Efficient Streaming Language Models with Attention Sinks." ICLR 2024. arXiv:2309.17453. https://arxiv.org/abs/2309.17453
25. Flash-Decoding：Dao, T. et al. "Flash-Decoding for Long-Context Inference." PyTorch Blog, 2023. https://pytorch.org/blog/flash-decoding/
26. min-p 采样：Nguyen, M. N. et al. "Turning Up the Heat: Min-p Sampling for Creative and Coherent LLM Outputs." ICLR 2025. arXiv:2407.01082. https://arxiv.org/abs/2407.01082
27. 核采样：Holtzman, A. et al. "The Curious Case of Neural Text Degeneration." ICLR 2020. arXiv:1904.09751. https://arxiv.org/abs/1904.09751
28. 重复惩罚的来源：Keskar, N. S. et al. "CTRL: A Conditional Transformer Language Model for Controllable Generation." arXiv:1909.05858. https://arxiv.org/abs/1909.05858
29. 结构化输出（XGrammar）：Dong, Y. et al. "XGrammar: Flexible and Efficient Structured Generation Engine for Large Language Models." arXiv:2411.15100. https://arxiv.org/abs/2411.15100
30. 以 goodput 为目标的分离式服务：Zhong, Y. et al. "DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving." OSDI 2024. arXiv:2401.09670. https://arxiv.org/abs/2401.09670
31. 推理基准测试方法：MLCommons. MLPerf（Machine Learning Performance）Inference. https://mlcommons.org/benchmarks/inference-datacenter/
32. 推理优化技术综述（NVIDIA）：NVIDIA. "Mastering LLM Techniques: Inference Optimization." https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/
33. chunked prefill：Agrawal, A. et al. "SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills." arXiv:2308.16369. https://arxiv.org/abs/2308.16369
34. 前后分离：Patel, P. et al. "Splitwise: Efficient Generative LLM Inference Using Phase Splitting." ISCA（International Symposium on Computer Architecture）2024. arXiv:2311.18677. https://arxiv.org/abs/2311.18677
35. vLLM 的分离式预填充：vLLM Documentation, "Disaggregated Prefill." https://docs.vllm.ai/en/latest/features/disagg_prefill/
36. 前缀缓存与 RadixAttention：Zheng, L. et al. "SGLang: Efficient Execution of Structured Language Model Programs." NeurIPS 2024. arXiv:2312.07104. https://arxiv.org/abs/2312.07104
37. vLLM 的自动前缀缓存：vLLM Documentation, "Automatic Prefix Caching." https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/
38. GPTQ：Frantar, E. et al. "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers." ICLR（International Conference on Learning Representations）2023. arXiv:2210.17323. https://arxiv.org/abs/2210.17323
39. AWQ：Lin, J. et al. "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration." MLSys 2024. arXiv:2306.00978. https://arxiv.org/abs/2306.00978
40. LLM（large language model）.int8()：Dettmers, T. et al. "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale." NeurIPS 2022. arXiv:2208.07339. https://arxiv.org/abs/2208.07339
41. SmoothQuant：Xiao, G. et al. "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models." ICML 2023. arXiv:2211.10438. https://arxiv.org/abs/2211.10438
42. 投机解码：Leviathan, Y., Kalman, M., Matias, Y. "Fast Inference from Transformers via Speculative Decoding." ICML（International Conference on Machine Learning）2023. arXiv:2211.17192. https://arxiv.org/abs/2211.17192
43. 投机采样：Chen, C. et al. "Accelerating Large Language Model Decoding with Speculative Sampling." arXiv:2302.01318. https://arxiv.org/abs/2302.01318
44. Medusa：Cai, T. et al. "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads." ICML 2024. arXiv:2401.10774. https://arxiv.org/abs/2401.10774
45. EAGLE：Li, Y. et al. "EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty." ICML 2024. arXiv:2401.15077. https://arxiv.org/abs/2401.15077
46. vLLM 的投机解码：vLLM Documentation, "Speculative Decoding." https://docs.vllm.ai/en/latest/features/speculative_decoding/
47. Mixtral：Jiang, A. Q. et al. "Mixtral of Experts." arXiv:2401.04088. https://arxiv.org/abs/2401.04088
48. 单卡 offload 的吞吐型方案（FlexGen）：Sheng, Y. et al. "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU." ICML 2023. arXiv:2303.06865. https://arxiv.org/abs/2303.06865
49. 激活局部性与 CPU（central processing unit）/GPU（graphics processing unit）协作（PowerInfer）：Song, Y. et al. "PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU." SOSP 2024. arXiv:2312.12456. https://arxiv.org/abs/2312.12456
50. 从闪存流式推理（LLM in a flash）：Alizadeh, K. et al. "LLM in a Flash: Efficient Large Language Model Inference with Limited Memory." ACL（Association for Computational Linguistics）2024. arXiv:2312.11514. https://arxiv.org/abs/2312.11514
51. 多卡推理与 offload：Aminabadi, R. Y. et al. "DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale." SC（Supercomputing Conference）2022. arXiv:2207.00032. https://arxiv.org/abs/2207.00032
52. 张量并行：Shoeybi, M. et al. "Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism." arXiv:1909.08053. https://arxiv.org/abs/1909.08053
53. Ollama（本地运行的默认参数与行为）：https://github.com/ollama/ollama
54. 长上下文中的位置效应：Liu, N. F. et al. "Lost in the Middle: How Language Models Use Long Contexts." TACL（Transactions of the Association for Computational Linguistics）2024. arXiv:2307.03172. https://arxiv.org/abs/2307.03172