大模型后训练路线
1 | 大模型后训练（Post-training） |
方法类型：直接偏好优化。通常使用提前准备好的离线偏好对，不需要在训练过程中运行完整的强化学习 rollout。
DPO（Direct Preference Optimization）的核心思想是：直接拿“好回答”和“差回答”训练，让模型更倾向好回答，不再先训练一个阅卷老师，再做一轮 PPO。
训练时还会保留一个冻结的 reference model 作为参照，避免模型只顾拉开好坏答案的差距而偏离原模型太远。可以理解为：
1 | 对同一个问题： |
定义：在海量通用或混合语料上使用自监督目标训练模型，主要获取语言、知识和基础能力。
通俗解释：给模型阅读海量网页、书籍、代码等内容，让它反复做“猜下一个 token”的练习。原始数据不需要人工逐条写答案，文本的下一个 token 本身就是答案。
样例数据：预训练数据通常只是连续文本，而不是问答对。
1 | {"text": "水在标准大气压下的沸点约为100摄氏度。温度继续升高时，液态水会逐渐转化为水蒸气。"} |
模型会自动从每段文本中产生大量“根据前文预测下一个 token”的训练题。
适用场景：
优势：能力上限和数据分布可控，可形成自主基座。
劣势：数据、算力、稳定性、分布式系统和评测成本极高；失败代价大。
定义：从已有基座继续使用语言建模目标训练，而不是使用问答标签。
通俗解释：基座模型已经读完“通识课程”，现在让它集中阅读某个专业的原始材料。例如继续阅读证券研报、法律条文或公司代码库，使它熟悉该领域的术语、表达和知识分布。
金融领域样例数据：
1 | {"text": "资产负债率是企业负债总额与资产总额的比率，常用于衡量企业的长期偿债能力……"} |
一个典型大语言模型（LLM）的生命周期可以概括为：
1 | 原始数据 |
预训练主要解决“能力和知识从哪里来”，SFT 解决“如何按指令表现”，偏好优化解决“多个看似合理的答案中更偏好哪个”，推理系统解决“如何以可接受的成本和延迟把能力交付出来”。
查看更多
家里的显示器是2K显示器，默认分辨率是标准的 2560x1440 分辨率，但是在mac 下，字体小，锯齿严重
然后mac 默认开启的HiDPI 能过很好解决锯齿问题，但是HiDPI最大分辨率选项只有1280*720 HiDPI
https://github.com/xzhih/one-key-hidpi
1 | bash -c "$(curl -fsSL https://raw.githubusercontent.com/xzhih/one-key-hidpi/master/hidpi.sh)" |
每次到年底就多愁善感～
2025年，工作整体平淡但稳定。我与另一位同事共同负责多个存量项目的维护与迭代，项目规模大、历史包袱多，大部分精力只能用于满足客户日常需求、修复问题和保障系统稳定。新功能开发空间有限，几乎无法推进较大创新。
2026年：“守住底线、稳中求进”
2025年：个人投资收益率约为78%，较2024年的130%大幅回落，但仍属于较高水平。主要原因在于本金基数较小，且积极参与今年Alpha空投活动。
全年主要投资动作：
2026年：任何赛道一旦参与者增多，超额收益都会迅速均值回归。alpha赛道的收益已经不做期望了。2026年的投资目标是继续积累本金，保持耐心，等待合适机会低位回补，同时探索是否有新的低风险高收益路径。同時也清醒认识到，本金越大，维持高收益率的难度越高，需更加注重资产配置的稳健性（还没大到这个步骤，时机到了还是要敢于下注）。
VictoriaMetrics 是后出的一款面向可观测指标的时序数据存储和查询引擎， 传闻比prometheus 查询性能强，存储成本还低，我们也有做指标数据平台，特来学习下
以下分析基于 v1.45.x 版本
VictoriaMetrics 的存储设计可以概括为以下几点：
vminsert、vmstorage 和 vmselect 分离写入、存储与查询职责；TSID；TSID 聚合，并将时间戳和值分别进行列式压缩；Part，再通过后台 Merge 合并；small 和 big 两级目录平衡近期数据的读取速度与历史数据的压缩率；VictoriaMetrics 集群由三个核心组件组成。
| 组件 | 主要职责 |
|---|---|
vminsert |
接收写入请求，通过一致性哈希将数据分发到不同的 vmstorage 节点 |
vmstorage |
保存标签索引和时序数据，并执行本地检索 |
vmselect |
接收查询请求，从一个或多个 vmstorage 节点读取数据并汇总结果 |
三个组件可以分别扩容。vmstorage 采用 Shared-Nothing 架构：节点之间不共享数据，也不需要互相通信。这种结构降低了节点间协调成本，使扩容和故障隔离更简单。
原本是测试某款产品和 vm的对比， 某款产品没有对比意义，已经移除相关对比数据， 只看vm的查询性能即可
| 对比项 | vectoria metircs |
|---|---|
| 写入吞吐 | 886k/s(1.66m/s) |
| 压缩率（源json） | 0.22% |
| 查询性能(1并发) | 6.19 |
| 查询性能(10并发, 7个用例同时进行10、50、100个时间段查询，统计总用时) | 34.18 s |
| 查询性能(50并发) | 560.47 |
| 查询性能(100并发) | 2040.83 |
| 查询性能(50并发,47.5w/s写) | 575.19 |
| 对比项 | X2.0 | vectoria metircs | score |
|---|---|---|---|
| 写入吞吐 | x | 886k/s(1.66m/s) | |
| 压缩比（源json） | x | 0.22% |
pod 4c6G
数据生成速率
1 | 3000*1230 active time series |
数据协议，prometheus remote write
数据格式（转json 后）
1 | {"metric":{"__name__":"node_scrape_collector_success","job":"node_exporter","instance":"host-2362","collector":"mdadm","replica":"0","revision":"r0","url_replica":"0"},"values":[1],"timestamps":[1724313603243]} |
Update your browser to view this website correctly. Update my browser now