一个聊天服务器同时连接着很多客户端，但大多数连接在大部分时间里都没有消息。服务器怎样知道哪个连接需要处理？如果为每个连接都安排一个线程，能不能有更合适的办法？
这正是 I/O 多路复用要解决的问题。select、poll 和 Linux 的 epoll 都能让程序等待多个文件描述符的 I/O 就绪状态。它们的核心差别，在于“要关注的连接由谁保存、每次等待时怎样检查、程序怎样拿到就绪结果”。
读完这篇，你应该能讲清三个重点：就绪通知不等于自动读取数据；select 和 poll 每次都要处理关注集合；epoll 将持续注册的关注项和就绪事件分开管理，因此在大量连接只有少数活跃时通常更有优势。
一、I/O 多路复用在等什么？假设服务器接入 10,000 个 TCP 客户端。此刻客户端 A、C 在发消息，其余连接暂时空闲。服务器真正需要的是：等待一批连接，只处理当前可以继续进行 I/O 的连接。
一个直观但不总是理想的做法是“一连接一线程”：每个连接都由一个线程执行阻塞读取。线程在等数据时可能被操作系统挂起，但大量线程仍会占用栈内存、调度资源，并增加并 ...
服务器把一个文件发给浏览器，为什么要先把数据复制到程序里，再交回操作系统？如果程序只是原样转发，中间这趟搬运能不能省掉？
零拷贝（Zero-Copy）主要解决的就是这类问题：减少大块数据在内存中的重复复制，尤其是减少 CPU 为搬运数据做的工作。 它不是让数据凭空从硬盘出现在另一台电脑上，也不是所有环节都完全没有复制。
下面只用一个例子贯穿全文：服务器把一个 100 MB 文件，通过 TCP 发送给客户端。先看传统读写，再看 mmap、sendfile，最后把它们与 Java NIO、Netty 联系起来。
一、先认清：数据在哪里，谁负责搬运？把服务器想成一个仓库，先认识几个角色：
概念
在这个例子中做什么
磁盘 / SSD
长期保存文件
内存（RAM）
暂存正在读取、处理或发送的数据
CPU
执行程序、处理协议，也可能执行内存复制
DMA（直接内存访问）
让设备在 CPU 配置好操作后，直接与内存交换数据，无须 CPU 逐字节搬运
网卡
从内存取得待发送的数据，通过网络发出去
内核（Kernel）
操作系统核心，管理文件、内存、设备与网络
...
第一次接触大模型微调时，很容易被一串缩写绕晕：CPT、SFT、LoRA、QLoRA、DPO、PPO、GRPO……它们看起来像一排互相竞争的“微调方法”，其实很多并不在同一个维度上。
先记住这篇文章的核心地图：CPT、SFT、DPO、PPO、GRPO 描述“用什么训练信号、想让模型学会什么”；全参数微调、LoRA、QLoRA 描述“哪些参数参与更新、以什么方式更新”。 两条轴可以组合，不是非此即彼。
下文会按“要不要微调 → 训练目标 → 参数更新方式 → 项目选型与评估”的顺序展开。先说结论：微调不是给模型补一份随时更新的知识库，也不是越复杂越好。很多需求用提示词或 RAG 更直接；只有当问题确实需要改变模型稳定的行为模式，而且手头有合适的数据和评估方法时，微调才值得投入。
一、什么是微调？它能解决什么问题？大模型预训练完成后，已经具备通用的语言和任务能力。微调（fine-tuning）是在已有模型基础上继续训练，让它在特定数据、任务或行为要求上更贴合目标。
可以把预训练想成打下通用基础，把微调想成针对岗位继续训练。但这个类比有一个重要边界：微调并不保证原有能力完全保留。 训练数据太窄 ...
很多人第一次看到 Transformer 的 Q、K、V，都会被一串矩阵和公式劝退。其实先记住一个直觉就够了：每个 Token 都会生成一份“我想找什么”（Q）、一份“我有什么特征”（K），以及一份“我能提供什么内容”（V）。
模型用 Q 和其他 Token 的 K 计算相关程度，再按照这个相关程度汇总它们的 V。下面就沿着“文字 → 向量 → QKV → 注意力 → 新表示”这条路，把它一步步拆开。
一、先用一个例子理解 Q、K、V想象你在公司遇到一个问题：“谁能帮我优化数据库查询？”
Q（Query，查询）：你当前想寻找的信息，也就是“我需要数据库优化方面的帮助”。
K（Key，键）：每位同事身上便于匹配的特征，例如“熟悉数据库”“擅长前端”。
V（Value，值）：同事真正能提供的经验和内容。
你用问题去匹配每个人的特征，匹配度越高，就越多地参考对方的经验。注意力机制做的事情很像这样：对一个 Token 来说，它会查看当前允许关注的其他 Token，并根据匹配分数混合它们的信息。
这个类比帮助理解 Q、K、V 的分工，但不要把它们当成模型能读懂的中文标签。真实的 Q、K、V ...
当所有人都在讨论”用哪个 Agent 框架”时，真正站在潮头的编码智能体产品，几乎清一色选择了裸写循环。这不是巧合，而是一场值得深挖的架构哲学分歧。
一、一个反直觉的事实如果你在 2025 年之后接触过 AI 编程工具，大概率听说过这几个名字：Claude Code（Anthropic 官方 CLI）、Codex CLI（OpenAI 官方 CLI）、OpenCode（开源新秀）。它们是目前最炙手可热的一批编码智能体（Coding Agent）。
一个很容易想到的问题是：这些产品是用什么框架搭建的？LangChain？LangGraph？CrewAI？
答案出人意料——一个都没用。它们全部是基于模型厂商原生 API 自研的 Agent 循环。而且不只这三家：Aider、Cline、Gemini CLI、Goose、Pi……你能叫得上名字的主流编码智能体，几乎清一色走上了”无框架、裸写循环”的路线。
为什么？这篇文章试着把这件事讲透。
二、先破除一个误解：Agent 到底是什么在讨论框架之前，先对齐一个认知。很多人被复杂的框架术语（Agent 类、Executor、Graph Nod ...
最开始部署 New API 时，更新一次代码就要登录服务器、停容器、拉新代码、重新构建，再把服务启动起来。偶尔改个小功能，前后折腾几分钟不算什么；线上已经有人在用时，这几分钟就不太好接受了。
我想要的不是一套看起来很复杂的发布平台，而是一个足够稳妥的流程：代码放到自己的仓库，准备好版本后点一下构建，服务器自动启动新版本，确认没问题再把流量切过去；新版本不正常时，能够尽快切回旧版本。
最后落地的是一套小而实用的方案：Gitee 保存代码，Gitee Go 负责流水线，Docker 镜像放在镜像仓库，运行环境是另一家云厂商的 Linux 服务器，Nginx 负责入口切换。服务器不需要和流水线在同一家云上。
图 1：一次发布从代码到线上请求的完整链路。
先把几个概念分开这次最容易绕进去的地方，是把“源码在哪里”“镜像放在哪里”和“服务跑在哪里”当成了一件事。其实它们可以完全分开：
位置
负责什么
这次的选择
代码仓库
保存 Dockerfile、源码和流水线配置
Gitee
构建服务
根据代码构建镜像
Gitee Go
镜像仓库
保存带版本号的 Docker 镜像 ...
2026 年 8 月 17 日，我看到 Tibo Sottiaux 在 X 上发了一组 Codex 配置：选择 gpt-5.6-sol，把上下文预算设为 100 万 Token，并在 90 万 Token 左右开始压缩旧历史。
帖子里有两个数字需要分开看。OpenAI 官方模型页列出的 GPT-5.6 Sol 上下文窗口是 1,050,000 Token，Tibo 写进 Codex 的预算是 1,000,000 Token。这组设置针对 Codex 客户端，不是 chatgpt.com 的设置，也不能直接套到其他 GPT-5.6 型号上。
Tibo 的原帖到底说了什么？我把原帖的核心部分截在下面，方便和配置逐项对照。Tibo 的公开账号简介写的是 “Codex & ChatGPT @OpenAI”。
图 1：Tibo 原帖的核心部分，完整内容和一次性 CLI 命令可以点开原帖查看。
帖子主要说了五件事：
GPT-5.6 Sol 的官方模型规格支持 1,050,000 Token 上下文窗口。
Codex 的默认上下文限制经过了性能和成本调优，默认不开到最大值。
用 ...
API 中转站是位于应用和模型厂商之间的一层 API 网关。你仍然通过 API Key 调用模型，但请求先到中转站，再由中转站转发给 OpenAI、Claude、Gemini、DeepSeek 等上游服务。中转站一般会比官方 API 便宜，这也是大多数人选择它的主要原因。
不过，不同中转站的可信度差别很大。有些商家会偷偷进行模型映射、在后台调整倍率，或者保留用户的请求内容。选择中转站不能只看低价，还要看模型、计费和隐私规则是否透明。
如果你只是想找一个便宜、透明的 OpenAI API 中转站，可以直接试试我自己使用并维护的 newapi.zahml.top：计费公开透明，部分模型最低 0.07 倍率，并且不会保存用户提交给模型的请求与对话内容。
API 中转站是什么？一次请求的链路可以简化为：
123456Codex / Claude Code / CursorCline / OpenCode / Roo Code ↓ API 中转站 ↓ OpenAI / Claude / Gemini 等模型
中转站负责校验 Ke ...
大模型的上下文缓存是什么？从底层原理到 GPT、Claude 的长对话策略使用 GPT、Claude 等大模型进行编程时，经常会出现这样的情况：刚开始对话只有几千 Token，经过多轮代码分析、工具调用和报错修复后，上下文很快就增长到几万甚至几十万 Token。
表面上看，模型每一轮都需要重新读取完整历史：
123456789系统提示词项目规范工具定义用户第一轮问题模型第一轮回答用户第二轮问题模型第二轮回答……当前问题
如果每次都按普通输入重新计算，长对话的费用和响应时间都会快速上升。Prompt Caching，也就是提示词缓存，正是为了解决这种重复计算问题。
不过，缓存并不意味着“历史对话免费”，也不意味着对话可以无限增长。理解它的底层逻辑后，才能真正用好长上下文。
缓存到底保存了什么？大模型收到一段输入后，并不是简单地把文字读进内存。
输入文本首先会被分成 Token，然后经过模型每一层的注意力计算。在这个过程中，模型会为已经处理过的 Token 生成 Key 和 Value 等中间表示，通常统称为 KV Cache。
可以把它理解为：
123456789原始输入 ↓Tok ...
2026 年国内外主流大模型 API 价格对比：GPT、Claude、Gemini、DeepSeek、Kimi、千问、MiniMax 怎么选？大模型能力越来越强，但不同厂商的计费方式也越来越复杂。
除了最基本的输入 Token 和输出 Token，现在还需要考虑：
缓存读取价格
缓存写入价格
长上下文阶梯价格
思考 Token
Batch 批处理折扣
Priority 优先服务
不同地区的部署价格
限时活动和分时折扣
本文整理了目前国内外主流厂商最新、最常用的模型，重点对比官方 API 价格、缓存价格、模型定位和适用场景。
本文价格统计截至 2026 年 7 月 21 日。除特别说明外，价格均为每 100 万 Token，即每 1M Tokens 的价格。本文比较的是厂商官方 API，不是 ChatGPT、Claude、Gemini 等网页会员订阅价格，也不包括第三方中转站加价。
一、先看懂大模型 API 是怎么收费的一次普通模型请求的费用，通常可以简化为：
1234请求费用 =输入 Token 数量 ÷ 1,000,000 × 输入单价+输出 Token 数量 ÷ 1,00 ...
