从 print(‘hello’) 开始：用 dis 验证你的 Python 直觉

你在终端敲下 python -m dis "print('hello')"，看到几行 LOAD_GLOBAL、PUSH_NULL、CALL 之类的输出，大概会点头：“哦，原来 print 是这样执行的。”然后呢？

这串字节码真正的价值，不在于告诉你 print 怎么跑，而在于它提供了一把可重复验证的尺子。比如你可以立刻追问：如果把 print(‘hello’) 换成 sys.stdout.write(‘hello\n’)，哪条指令会消失？字符串 ‘hello’ 是每次调用都重新加载，还是被缓存了？函数名 print 的查找开销到底占多少？这些问题靠读文档或猜是得不到确定答案的，但 dis 能在毫秒级给出可复现的证据。

本文不打算系统讲解 CPython 虚拟机，那是另一个话题。我们只把 dis 当作诊断工具，用一系列“直觉猜测 → dis 验证 → 修正认知”的小实验，解决那些代码看起来没问题、行为却让人困惑的瞬间。所有示例基于 CPython 3.12+，字节码格式在此版本后有较大调整，若你使用更早版本，部分输出可能不一致，建议升级后再跟随操作。

字符串拼接的字节码真相

“f-string 比 % 和 + 拼接都快。”这句话你大概听过无数遍，甚至已经当作编码规范写进了团队文档。但如果你被问到“快在哪里、快多少、有没有例外”，能给出字节码级别的证据吗？

我们先用三段功能等价的代码作为实验对象：

name = "world"
a = f"Hello {name}"
b = "Hello %s" % name
c = "Hello " + name

不看 dis 输出，凭直觉猜一下：哪段指令更少？哪段隐藏开销更大？很多人会认为 f-string 完全在编译期处理，应该最简洁；% 格式化涉及类型检查和格式解析，应该最重；+ 拼接居中。这个直觉对了一半。

用 dis.dis() 分别查看三者，关键差异如下。f-string 的核心指令序列为：

重新认识 pdb：从命令行断点到 Python 运行时探针

凌晨两点，测试环境容器抛出异常，日志只有干瘪的 traceback。没有 IDE，也没法热附加调试器，加 print 调试要等 5 分钟部署循环。这时你才意识到：那些花哨的图形化调试器，在脱离本地开发机后往往束手无策。

很多开发者把 pdb 当作“穷人的调试器”，只在没得选时才用。你可能也只在敲下 import pdb; pdb.set_trace() 时才会想起它。我以前也这么觉得。后来有一次在 CI 里排查一个只在特定环境变量下复现的 bug，才发现 pdb 厉害的地方根本不是打断点。它是 Python 运行时直接暴露给你的人机交互接口。命令行启动、测试框架集成、直接操作 sys.settrace，都不用碰业务代码就能拿到完整的调试能力。对执行模型零抽象访问这件事，在无头环境和自动化流程里真的没法替代。

本文不讲 n/s/c 命令速查，而是分享三个我实际用过的、无需修改业务代码的场景，帮你把 pdb 从应急工具变成手边的运行时探针。

容器里怎么拦一个请求

⚠️ 先说清楚：pdb 没法 attach 到跑着的进程。线上生产事故要是不能中断，请直接上 debugpy remote attach，别在这浪费时间。

这个方案本质是以调试模式重启服务，适合预发布、灰度节点或者你能接受短暂中断的场景。我之前在容器里调试时，最头疼的不是怎么打断点，而是不想改代码重构建又要精准拦住某个请求。后来发现 pdb 启动时就能直接指定条件断点，根本不用碰源码：

# 以调试模式重启服务，注入条件断点
docker exec -it mycontainer python -m pdb app/server.py
(Pdb) b app/views.py:42, request.headers.get("X-Debug-Token")=="abc123"
(Pdb) c

意思是只在 app/views.py 第 42 行、且请求头匹配令牌时才暂停，其他请求照常跑。pdb 交互模式下条件表达式由 Python 直接求值，引号不用转义。不过有个坑我得提一下：条件里要是带逗号（比如 func(a, b) == 1），pdb 会把它当参数分隔符，直接解析失败。遇到这种情况要么避开裸逗号，要么换别的拦截方式。

⚠️ Docker 里一定要加 -it，不然 pdb 拿不到 stdin 就静默退出了，连个报错都没有。另外条件里的变量名得跟目标行作用域对得上，求值失败时 pdb 会打印 NameError，但不会告诉你具体哪个变量出了问题——建议先 l 看一眼上下文再写条件。

我现在养成了一个习惯：凡是需要在容器里排查的问题，优先试 python -m pdb + 条件断点，而不是改代码加 breakpoint() 再走一遍部署流程。省下来的时间够多喝两杯咖啡了。

测试挂了但我只想看那一个

跑 200 个测试用例，第 147 个失败了。重跑整个套件太慢，加 print 又要改代码等重载。pytest 的 --pdb 很多人知道，但我发现真正好用的姿势是把它变成条件触发的手术刀，而不是全局暂停键。

GPU 利用率 90%，用户还是喊卡？大模型推理指标的三重认知陷阱

“我们的模型在公开 Benchmark 上跑出了 200 TPS，为什么上线后用户反馈‘首字等 3 秒、生成像打字机’？”

这不是个例。在大模型推理从实验室走向生产环境的过程中，我们反复观察到一种割裂：监控面板上的指标一片繁荣，用户体验却千疮百孔。问题不在于加速器不够快，而在于我们用错了尺子。

传统 Web 服务的 QPS/延迟模型，在 Token 流式生成的世界里几乎完全失效。本文将拆解三个最致命的认知误区，并给你一个可以立即运行的诊断脚本——不再被白皮书峰值牵着鼻子走。

误区一：负载画像错配——你在测什么？

几乎所有推理框架或硬件白皮书都会亮出一个惊人的 TPS 数字。但当你把同样的模型部署到真实的 RAG 或 Agent 场景中，性能往往打 3-5 折。这是 Benchmark 假设与真实业务负载画像的结构性错配造成的：

评估供应商或选型时，不能只看官方 TPS。你需要要求提供与自身业务输入输出长度分布匹配的实测数据，或者用下文提供的校准脚本自行验证。基于峰值做的容量规划，上线后大概率面临 3 倍以上的资源缺口。

从系统侧看，这种错配的根源在于：加速器利用率是一个“欺骗性指标”——它无法区分算力是被用于有效 Decode、被 Prefill 抢占，还是消耗在 Padding 填充上。真正能反映推理健康度的监控指标，应该是“实际 Batch Size 均值/P99”和“Prefill/Decode 时间占比”。至于为什么利用率会骗人、以及这些替代指标如何指导优化，我们将在 “误区二：Prefill 与 Decode 是两种病” 一节中深入拆解。

认知校准器：你的业务场景到底能跑多少 TPS？

下面这个 Python 脚本是一个 “认知校准器”，基于昇腾 910B3 + Qwen3.5-27B FP16 的参数，用引入 Batch Size 感知的简化 Roofline 模型 + 经验衰减系数，帮你快速建立“业务参数 → 系统指标”的直觉。

大模型量化实战（上）：从显存焦虑到算法本质

想在本地跑个 70B 的大模型？FP16 精度下光权重就得吃掉 140G 显存，连加载都报错。这时候你肯定盯上了量化：换成 INT4，35G 显存搞定，一张 RTX 4090 就能起飞。

但真用起来，坑就来了：

• 明明体积缩小了 4 倍，生成速度怎么没快 4 倍？
• 评测分数看着没掉，怎么让它写个复杂代码就开始胡言乱语了？
• 网上满天飞的 GPTQ、AWQ、W8A8，到底该下哪个包？

很多人以为量化就是“把文件压缩一下”，其实根本不是。它更像是在给大桥换便宜的钢材 ——有些钢缆是主承重墙，换差了桥就塌了；有些只是栏杆，随便换。

而且别被 PPL（困惑度）这种评测指标骗了。很多时候分数没变，但模型的长尾知识召回下降、多步推理链断裂、格式化输出不稳定 ——这些才是量化最常见的“隐形退化”。这就是为什么不能闭着眼睛无脑转 INT4。

为了搞懂这些，我把大模型里需要量化的东西分成了三块，它们的脾气完全不一样：

这篇文章不打算给你背公式。我们直接从这几个实际问题出发，用大白话盘一盘主流算法到底是怎么解决这些“刺头”的，最后给你一张直接能用的选型决策表。

大模型量化实战（下）：从敲命令到验精度

上篇我们聊了量化的本质是“误差甩锅”，也给了选型决策表。但很多读者反馈：“知道该选 AWQ 了，可打开终端还是不知道敲什么。”“量化完怎么验证？PPL 跑完了然后呢？”

这篇就是来填坑的。我们将聚焦两件事：怎么用 ms-swift 一行命令完成量化，以及怎么科学验证量化模型没变傻。不再有“精密博弈”之类的废话，直接上命令、上脚本、上诊断思路。

💡 本篇定位
这是上篇的“实操续集”。如果你还没读过上篇，建议先花 5 分钟了解“误差甩锅”和选型逻辑，否则本篇的命令会显得孤立。

1. 量化实操：ms-swift 能做什么、不能做什么

ms-swift 是国内最友好的量化工具，但它不是万能的。先明确边界，再谈命令：

💡 关键提醒
上篇提到的 SmoothQuant 和 GGUF，在 ms-swift 中无法一键完成。如果你需要这两种方案，请跳转到对应工具链。本篇聚焦 ms-swift 真实支持的四种量化方法及 Ollama 导出。

最小可运行命令（复制即用）