@lyping 能不能跑起来基本只跟显存有关，34b 的模型 4bit 量化后，24G 显存勉强能跑起来，但量化毕竟是有精度损失的。消费级硬件 3090 性价比最高，一张不够就两张，两张不够就四张。

@siriussilen 是的，我已经强调了本质还是数据样本不够均衡。怀疑他们的数据是蒸馏 chatgpt 搞出来的，蒸馏的时候无脑加了 think step by step ，又没有仔细的人工审查

@siriussilen 举一个例子
SFT 标注数据
inst：泰山和嵩山哪个高？
output1：泰山的海拔高度为 1545 米，而嵩山的海拔高度为 1491.71 米。因此，泰山比嵩山高。
output2：泰山高。
在这种需要多步推理的任务中，output1 实际上是更易于模型推理的，然而，如果训练数据中都是这种 target ，甚至在指令中明确要求了不要输出无关内容，但依旧标注了推理链路，就会造成下面这种不遵循指令的情况。（本质还是数据样本不够均衡）

推理
inst：请判断下面的评论是好评还是差评，好评输出 true ，差评输出 false 。评论：真难看，不推荐购买
output1："真难看，不推荐购买"有明显的消极观点，因此是差评，所以，输出 false 。
output2：false
假设我们的业务只需要 true 或 false ，那么 output1 实际上不可用。

@yplam yi 的 base 模型还是不错的，但是对齐的时候可能用了大量 cot 数据，导致做一些需要直接输出的任务很差，比如抽取？也会给你先分析一通，基本不可用

@siriussilen demo 是 yi 34b base 做 sft ，推理 demo 4bit 量化过。未量化版本 mtbench 7.30 ，alignbench 5.93 ，至于评估的严谨度，这种 llm as judger 只能做个参考 更多的反应的是是否符合裁判员模型的偏好。

像那些 ceval mmlu 之类的选择题任务，已经没有评估的意义了，很多"高分"的模型（或者说绝大多数国产模型）都是通过预训练阶段加评估集实现的，然后公关说是无意的语料泄露，懂得都懂。

@stimw 因为 llama 在预训练的时候并没有多少中文语料 中文 ppl 会非常高，所以中文任务最好用国产的预训练模型

@skyqqcc581 @lstz 具体还是要看场景的，举个极端的例子，假设是离线跑批量预测的场景（例如生成文章），那么你用 vllm/tgi 一张 4090 推理 7b 的模型，是几乎能达到千 token/s 的，那么一小时能生成 3600k token ，成本只有两块钱，而阿里云上 7b 的模型跑这么多 token 需要花 0.006 * 3600 = 21.6 元。
另外，假设你需要微调模型的生成风格，直接用 API 也是无法做到的。

@yuyue001 可以选择租卡，训练的话，4090 24G 显存用 lora 就足够微调 7b 甚至 13b 的模型了，一小时不到两块钱，a100 40G 也就 4 块钱，还是可以接受的

开源大模型比较不错的有 qwen baichuan yi ，也有领域特化的，像 deepseek coder 这种。
具体看你是什么任务，如果是比较简单的问答 文本生成，或者传统 nlp 任务，又或者你希望在下游微调一些特定任务，那么开源模型是能不错的完成的，但是代码和数学与 gpt 3.5 有明显差距。

另外推荐一下自己微调的 LLM ，主旨是提供一套公开的 SFT 数据（因为目前大部分中文开源模型只公开了权重，但是训练数据，尤其是指令对齐的数据并不公开，导致从 Base 到 Chat 的复现有一定难度）
https://github.com/Azure99/BlossomLM
在线 Demo
https://blossom-chat.com/

自己的项目 4

有没有可能，有种分表策略叫哈希分表？

还是抱着我 29 刀 2C2G 40G 1T 的 DC3 CN2GT 吧

我觉得 Hexo 更香，一个是一群搞前端的人做的，一个是一群搞后端的人做的，特色都十分鲜明。不过我选 WordPress

一加还有小米这些是解锁后能保修的。可以看下一加 8t，前一阵 12+256 掉到 2700，los pe pa 这些都有官方支持。当然，氢 /氧 OS 现在这副样子已经不配称作类原生了。

@tbg 基本都是老生常谈的几个点。
首先是降低服务器响应时间，这里直接上缓存后，响应速度与静态页面无异。
第二是减少首屏资源，比如我网站的首屏资源只有文档跟一个主要 css 加起来大约 40kb，其他诸如 fontawesome 图标库、以及实现各种交互功能的 js 统统延迟加载，不要阻塞首屏渲染。
如果条件允许，可以针对首屏资源上 ServerPush，将文档和首屏资源同时推送给用户，减少一个 RTT 。
针对静态资源可以上 CDN，如果没有做动静分离的话，动态资源回源可能会慢很多，推荐用阿里云 /百度云的动态加速，原理很简单，就是动态资源绕过中间缓存节点，然而国内做的好的只有这两家，别家基本都是动态减速。
此外，还可以耍一些小把戏，比如在桌面端鼠标悬停时 /移动端手指触摸时就预加载页面，能够争取几十 ms 的时间，instant.page 是一种实现，可以参考一下

其实 WordPress 和 Typecho 这种动态 CMS 可以考虑用 nginx 的 fastcgi 缓存+一套自己的清除机制。
命中缓存时只走 nginx，可以带来媲美静态博客的速度，然后针对文章变动(涉及分页、分类、归档等)、评论变动(文章页)去动态清理缓存，效果会很不错。
而对于有大量文章且频繁更新的，比如 lz 这种采集站？新文章的发布必然导致频繁的缓存失效 or 不一致(二选一)，还是更建议在持久层做 cache 。PS：这种情况静态生成器也不能很好胜任。

多说无益，可以看一下效果，使用 WordPress 速度还凑合 https://www.rainng.com/